The ten tools

Returns a greeting and the account this connection is acting as. It proves the connection works end to end, and it names the account that owns anything deployed through it. Every refusal anywhere else is about that account, and this is the one place you can read it.

Stores a recoverable bundle of a site, its files, subdomain and version, in the artifact store, then publishes it and returns the live URL. Each file arrives as text or as base64: text for HTML, CSS and JavaScript, base64 for images, fonts, icons and anything else that is not text. Server code goes in functions, where the path spells the URL, so functions/api/orders.js answers /api/orders and every other URL is served from the files. Routing can be given as static or spa, and when it is not given it is inferred; the reply says which was used. Publishing reads the bundle back out of the store rather than reusing what is in memory, so what gets served is what can be recovered.

Publishes a version that is already in the artifact store, the newest one by default or any earlier one by name. Rolling back is publishing an earlier version, which is the same code path a disaster recovery runs, so the rollback is exercised every time anyone deploys.

With no argument, lists the sites this account owns. With a site id, lists every stored version of that site, newest last, marking which one is current. Sites belonging to another account are not listed and cannot be read.

Creates a Postgres database for a site. One per site: calling again returns the existing one rather than making a second. It returns the owner connection string, for anyone who has a terminal, and that string must not go into the site files or into a function, because deployed code is public. The site's own functions are given a separate, restricted connection string automatically at deploy time, as env.DATABASE_URL.

Runs SQL against a site's database as the owner. This is how tables, policies and seed data get made, and how they are read back. Every statement runs in one transaction: if any of them fails, none of them applied. Each table and its row-level security policy belong in the same call, because a table without one cannot be deployed against. The reply says what every statement returned and what the deploy gate would still refuse.

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

Returns a one-time URL that moves the database into your own account, after which this platform loses all access to it: it can no longer read the database, back it up, or get it back. 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, so an expired link is not a window you missed.

Writes a connection string onto a deployed site as env.DATABASE_URL, by republishing the site's current stored version: the same files, unchanged, with a different binding. It exists for one situation and refuses the rest. After transfer_database you own the database, and the only copy of the credential your site is using is a write-only binding on the site itself, which this platform cannot read, copy or work out. This is what puts it back. The value is not stored, not read back and not tested, so check it by loading the site.

Repairs a site that can no longer reach the database this platform holds for it, because the restricted role its functions connect as, juudd_app, was dropped or re-passworded by hand from a terminal. The role is created again with NOBYPASSRLS, given a fresh password, granted only what the schema gate allows over the tables that exist right now, and the site's current stored version is republished to carry it. It is a rotation, so the old password stops working immediately, and nothing on this side can tell a wrong password from a right one. Be sure of the diagnosis first.