Apps and databases on ghosty.page

Your agent publishes full-stack apps (Express, Next, React Router…) at <slug>.ghosty.page. You need no hosting account and no keys: ask for it in the chat and the agent builds it, publishes it and gives you the link.

Publish an app

The agent uses the site_publish tool (from code, the SDK: publishSite({ title, app: { dir, repo? } })).

• Blue/green deploy. The new version is built on the side and only goes live once it is ready. If the build fails, the previous version keeps serving.
• Many apps per account. An account can have several apps and several sites. The agent lists them all with site_status and todas: true.
• Answer with evidence. site_publish returns aplicado and verificado: the HTTP status and the real <title> read from the live link. The agent only says "done" with that evidence.

With your GitHub repo

With repo, the code lives in your GitHub. Each push to the main branch of that app's repo publishes it again in 1–3 minutes. In any other repo, the agent works with a branch and a PR.

Real state: site_status

site_status is the platform's truth about each app:

• The app's box (2 vCPU / 2 GB) and whether it is awake.
• The commit being served and the one being built ("redeploy in progress").
• The full error of the last failed build (the previous version keeps serving).
• The database and its tables.
• The names of the environment variables (never their values).
• The expiry date.
• With log: true, also the tail of the build log and the process log.

Each app's database

Each app has its own libSQL database, app-<slug>:

• It reaches the app in DATABASE_URL and DATABASE_AUTH_TOKEN (also with the TURSO_* aliases).
• It survives every new publish.
• It shows up in /app/dbs.
• The agent that published the app reads and writes it with db_select and db_exec.

Checkpoints: take the database back to an earlier point

Before the first write of each turn to any database, the platform saves a checkpoint.

• db_checkpoints {base} lists the checkpoints: time, reason and how many rows each table had.
• db_restore {base, checkpoint} takes the database back to that point, after you approve it.
• Restoring first saves another checkpoint, so it can be undone too.
• The last 30 per database or the ones from the last 14 days are kept.
• Very large databases (over 50 MB) get no checkpoint, and the agent tells you before writing.

Example:

You: Load the 40 catalog products I sent you into production.

Agent: Done: 40 new rows in productos of app-tienda-luna. A checkpoint was saved before writing (12:04, 0 products).

You: Wrong file, undo it.

Agent: I'll take app-tienda-luna back to the 12:04 checkpoint (0 products). Do you approve?

You: Yes.

Agent: Done. productos has 0 rows again. I saved another checkpoint before restoring, in case you want the 40 back.

Also from other places:

Environment variables

site_env (in the SDK, setSiteEnv(slug, { set, unset })) adds or removes variables and restarts the app without rebuilding it. They are stored encrypted and never go to the repo.

Free plan and Pinned sites

Apps follow the same rule as sites: on the Free plan they pause after 30 days without changes. Pinned sites ($49 USD a year, includes up to 3 sites) keeps them published. Details in Sites.