juudd

Declares a secret a site’s functions will read as env.<NAME> — an API key, a webhook signing secret, anything that must not be in deployed code, because deployed code is public — and returns a link where the customer pastes the value themselves. The value never comes through this connection, on purpose: a key in a tool call is a key in this transcript and in every log between here and there, so no tool here takes one. Write the code that reads env.<NAME> and deploy it; the route that needs the key fails until the value is set, and starts working when it is. Names are uppercase with underscores, like STRIPE_SECRET_KEY. DATABASE_URL is not one of these: the database binding is made and carried by deploy_site. The site has to have been deployed at least once before a value can be set, because the value is written by republishing the site’s current version with one more binding. Once set, every later deploy carries the value forward without anyone reading it. Tell the customer which name to set and where.

request_secret

Builds a project a framework needs building — React or Vue with Vite, Next.js with output: 'export', Nuxt — from its source, on this platform, and stores the result as a version of the site; publish_deploy then puts it live. Send the source: package.json, the framework config, src/, app/, pages/, public/, index.html — text as text, images as base64. Nothing is installed from package.json: the build runs against a toolchain this platform pins, and a dependency outside it is refused by name with the whole list in the reply. Server code is not built: files under functions/ pass through as plain-JavaScript functions, by the rules deploy_site states. The reply names a job; a quick build finishes inside the reply, a longer one says to call build_status. Source is bounded at 4 MB as sent; one build at a time per account; at most 3 a minute. The first build for an account takes a minute or two longer while the toolchain is installed. For a project that is already built, or a site that is already plain HTML, this is the wrong tool: request_upload and deploy_site respectively.

start_build

Reports a build start_build started: still running, done with the stored version, or failed with the last lines the build printed. A build takes ten seconds to a few minutes; call this once, wait, and call it again rather than looping. When it is done, publish_deploy with the site puts the version live.

build_status

Answers where a claimed domain has got to, and moves it forward when it is ready. This is the tool that answers questions about a domain — claim_domain acts, this one reports, and calling claim_domain twice will not help. Call it after the customer says they have added the DNS record. Call it again later if the answer is still pending; a check costs nothing but does not make DNS propagate faster, so leave real time between calls rather than looping. Two separate things have to be true before a domain serves: the domain has to be proven to point here, and a certificate has to be issued for it. This reports both, because a domain that resolves without a certificate fails in the browser with a security warning rather than a 404. When both are done the domain starts serving within moments, not instantly — a first request that misses is worth one retry before it means anything. If the customer later points their DNS somewhere else, nothing tells us — this tool is how that is found, and it stops the domain serving when it finds it.

domain_status

Creates a Postgres database for a site. Use apply_sql to create tables in it and read them back. One per site: calling again returns the existing one rather than making a second. It does not return a connection string and cannot: the owner credential is shown to the person in the browser panel, not handed to an assistant. You do not need it — apply_sql already runs against this database, and the site’s own functions are given a separate, restricted connection string automatically at deploy time as env.DATABASE_URL. Tell the customer where it is rather than asking them for it. Every table needs row-level security before the site can be deployed against it, and deploy_site says exactly what to run if any is missing.

create_database

Says whether a site has a database and whether this platform still holds it.

database_status

Stores a recoverable bundle of a site — files, subdomain and version — in the artifact store, then publishes it and returns the live URL. On a control plane with no deploy target configured it stores the bundle and publishes nothing; the reply says which of the two happened, and this tool is offered either way because storing a recoverable bundle is worth doing on its own. Give each file either text or base64: text for HTML, CSS and JavaScript, base64 for images, fonts, icons and anything else that is not text. Add `functions` for server-side code — a file at functions/api/orders.js answers /api/orders, and every other URL is served from `files`. A bundle is bounded at 4 MB of content as sent (text plus base64 together); a larger site is refused with nothing changed, so keep images small or fetch big assets from elsewhere. One account may deploy at most 12 times a minute. A project built by a framework — React or Vue with Vite, Next.js, Nuxt, SvelteKit, Astro — is deployed as its build output, built where the code is; nothing is built here. For that, call request_upload instead of carrying the output through this call: it returns a link and a script that posts the built folder. A photo the person uploaded on juudd is named by an id like 3f2a…c9.jpg; send it as a file with `image` set to that id and a path of your choosing (e.g. images/hero.jpg), and the bytes are copied in here instead of being written out as base64. A page that refers to images/<that id> gets the photo even if the file is left out.

deploy_site

Returns a one-time link and a short Node script that posts a built folder to it, for a project a framework built — React or Vue with Vite, Next.js, Nuxt, SvelteKit, Astro. Nothing is built here: build the project where its code is, then send the output folder (dist, out, .output/public). The post stores a version under this site exactly as deploy_site would; it publishes nothing, so call publish_deploy afterwards to put it live. Use this instead of deploy_site whenever the files were produced by a build rather than written by you — a built site is too large to carry through a tool call. The same bound applies: 4 MB as sent, text and base64 together. Server code is not part of a build: framework API routes and server rendering do not come across, and plain-JavaScript functions under functions/ are sent beside the folder with --functions. The link works once, for 15 minutes; a failed post spends it, and calling again gives a fresh one. At most 12 a minute.

request_upload

Writes a connection string onto a deployed site, as env.DATABASE_URL. It exists for one situation and refuses the rest: after transfer_database the customer owns the database, and the only copy of the credential their site is using is a write-only binding on the site itself — this platform cannot read it, copy it or work it out. Change that password and the site loses its database with nothing anywhere able to put it back. This is what puts it back. While the database is still held by this platform there is nothing to do here, and it will say so: deploy_site provisions a restricted role that row-level security applies to and binds it for you, whereas a hand-written string goes around that role — the owner’s above all, which reads and writes every row past every policy. If a site whose database is still held here cannot reach it because that role was dropped or re-passworded by hand, reset_database_credential is the repair instead: it rebuilds the role and rebinds the site, without anyone choosing what credential a public script carries. This tool takes effect by republishing the site’s current stored version: the same files, unchanged, with a different binding. The value is not stored, not read back and not tested, so check it by loading the site. Copies of the site may keep serving with the previous credential after this returns, for a length of time nothing here can promise, so do not drop the old password at the database’s end until the site has been answering on the new one.

set_database_url

Returns a one-time URL that moves the database into the customer’s own account, after which this platform loses all access to it. This is the exit door and it has no deadline — a new URL can be minted whenever it is asked for, however old the database is.

transfer_database