Forem: ghost

Ship an app on Ghost + Fly.io for $2/month

ghost — Tue, 12 May 2026 02:34:43 +0000

Putting a real public app on the internet shouldn't cost $25/month for managed Postgres alone — before you've added compute or shipped a feature. Ghost gives you the database, Fly.io gives you the host, and your AI agent does the plumbing.

You can launch a public-facing, sparse-traffic hobby app, backed by Postgres, for roughly the cost of a coffee per month.

Who this is for

This guide is for developers who use an AI coding agent (Claude Code, Cursor, Codex, Windsurf, etc.) and want to ship a small public app fast and cheap. You don't need to know SQL or Docker — the agent handles both — but you should be comfortable approving shell commands the agent runs on your behalf.

You'll need:

An AI coding agent with both MCP support and a Bash/shell tool (Claude Code, Cursor in agent mode, Codex, Windsurf, Gemini CLI, VS Code, Kiro, or Antigravity). The shell tool is what lets the agent run flyctl and npm on your behalf — most modern agents have this.
macOS, Linux, or Windows (WSL recommended on Windows for flyctl).
A Fly.io account with a credit card on file.
An internet connection. The agent will install everything else (flyctl, Node, etc.) on its own.

What is Ghost

Ghost is Postgres for builders and their agents. Unlimited databases, metered by hours of active compute. All via CLI and MCP, no GUI required.

Create one in seconds, fork it like git when you want to experiment safely, share it with a simple link like a Google doc. Graduate to production with one command or throw it away when you're done.

The free tier covers 100 active compute hours per month and 1TB of storage. Compute is metered in 15-minute chunks when something queries the database; an idle database burns no compute. A sparse-traffic hobby app — a handful of human visits a day — comfortably fits the free tier.

You can do this with managed-Postgres alternatives like Neon, Supabase, or RDS — but those either charge a flat monthly fee, cap project counts, or push you through a GUI for changes the agent could otherwise make in seconds. Ghost is the cheapest, most agent-native way to ship a public app with real Postgres.

What you will do

In this guide, we'll deploy a public-facing todo app to Fly.io with a Ghost Postgres database. After a one-time bootstrap, the agent does everything else — you just paste prompts.

Bootstrap (you): install the Ghost CLI and flyctl, log in, configure the Ghost MCP server in your agent.
Scaffold the app + create the database + define the schema (agent): generate a small Express todo app, create a Ghost database, define a todos table.
Wire the app to the database and test locally (agent): set DATABASE_URL, run the app on localhost, round-trip a todo through the database.
Deploy to Fly.io (agent): create the Fly app, push the connection string as a secret, deploy to a *.fly.dev URL.
Verify the public app (agent): curl the live URL, add a todo over HTTPS, confirm it landed in Ghost.
Open it in your browser (you): use the live app yourself and share the URL.
Clean up (agent): destroy the Fly app and delete the Ghost database.

Step 1 — Bootstrap (you, one-time)

This is the only part you can't delegate.

Install the ghost CLI:

curl -fsSL https://install.ghost.build | sh

On Windows, run irm https://install.ghost.build/install.ps1 | iex in PowerShell.

Install flyctl:

curl -L https://fly.io/install.sh | sh

On Windows, run pwsh -Command "iwr https://fly.io/install.ps1 -useb | iex".

Log into both:

ghost login
flyctl auth login

Each opens your browser. flyctl auth login prompts you to add a credit card if you haven't yet.

Configure Ghost as an MCP server in your agent. For Claude Code:

ghost mcp install claude-code

Replace claude-code with cursor, codex, windsurf, gemini, vscode, kiro-cli, or antigravity if you use a different agent. Run ghost mcp install with no argument for an interactive picker.

Restart your agent so it picks up the new MCP server.

Expected output:

$ ghost --version
ghost version 1.x.x

$ flyctl version
flyctl v0.x.x ...

Once both CLIs are installed, you're logged in, and the agent has been restarted, the rest is the agent.

Step 2 — Scaffold the app, create the database, define the schema (agent)

Tell the agent:

Build me a minimal public-facing todo app I can deploy to Fly.io.

Create a fresh empty directory called `todo-app` and work inside it.

Stack: Node.js with Express and the `pg` package. One server file. Server-rendered HTML — no frontend framework. Read DATABASE_URL from the environment.

Routes:
- GET  /                  render the list of todos with a small form to add a new one
- POST /todos             insert a new todo from form data, then redirect to /
- POST /todos/:id/done    mark a todo done, then redirect to /

Files to write:
- package.json             express + pg + dotenv
- server.js                the app
- Dockerfile               minimal Node runtime, copies package.json + server.js, runs `node server.js`
- fly.toml                 app = "todo-app", primary_region = "iad", [http_service] with internal_port=3000, force_https=true, auto_stop_machines="stop", auto_start_machines=true, min_machines_running=0. No [[services]] block. No [[mounts]]. No managed Postgres.
- .dockerignore            node_modules, .env, .git

Then, using the Ghost MCP:
1. Create a new Ghost database called "todo-app". Wait for it to be ready.
2. Create a `todos` table with columns: id (serial primary key), text (text not null), done (boolean default false), created_at (timestamptz default now()).
3. Print the connection string so I can use it in the next step.

Don't use a migration framework. Don't add auth. Keep server.js under 100 lines.

The agent will:

Write package.json, server.js, Dockerfile, fly.toml, .dockerignore, and minimal HTML.
Create the Ghost database.
Create the todos table.
Print the connection string.

Expected output:

Database "todo-app" created (status: running).
Table "todos" created with 4 columns.
Connection: postgres://tsdbadmin:...@...tsdb.cloud.timescale.com:.../tsdb?sslmode=require

You now have a Postgres database in the cloud and a tiny app on disk — including a Dockerfile and fly.toml — ready for deployment.

Step 3 — Wire the app to the database and test locally (agent)

Tell the agent:

Wire the app to the Ghost database we just created.

1. Write a `.env` file with DATABASE_URL set to the connection string from the previous step. Add `.env` to `.gitignore`.
2. Make sure server.js loads .env (use the `dotenv` package).
3. SSL setup for Timescale: recent `pg` versions treat `sslmode=require` in the URL as `verify-full`, which rejects Timescale's cert chain and crashes on the first query. Strip the `sslmode` query param from DATABASE_URL before passing it to `new Pool({ ... })`, and pass `ssl: { rejectUnauthorized: false }` in the Pool config.
4. Run `npm install` and start the server on port 3000 in the background.
5. Use curl to: GET /, POST a todo with text="Ship the app", GET / again, then POST /todos/1/done.
6. Print the response bodies so I can see the todo round-tripping through the database.
7. Stop the local server.

The agent will:

Write .env and update .gitignore.
Install dependencies.
Start node server.js in the background.
Run a sequence of curl commands.
Kill the local process.

Expected output:

$ curl localhost:3000
<html>...<h1>Todos</h1><form action="/todos" method="post">...

$ curl -X POST -d 'text=Ship the app' localhost:3000/todos
(302 redirect to /)

$ curl localhost:3000
<html>...<li>Ship the app <form action="/todos/1/done"...

$ curl -X POST localhost:3000/todos/1/done
(302 redirect to /)

The app works end-to-end against your Ghost database. Time to put it on the internet.

Step 4 — Deploy to Fly.io (agent)

Warning: This step creates a billable Fly.io app on a public URL. With auto-stop machines enabled (configured in step 2's fly.toml), an idle app costs only for storage and bandwidth — typically cents per month — but charges accrue once the machine is running. Make sure you're comfortable with Fly's pay-as-you-go pricing before deploying.

Tell the agent:

Deploy the app to Fly.io. Skip `flyctl launch` entirely — we already have a Dockerfile and fly.toml from step 2, and `flyctl launch --yes` has a habit of provisioning unwanted Fly Postgres clusters and overwriting DATABASE_URL.

1. Pick a globally unique app name. Start with "todo-app" and append a 6-char random suffix if Fly says it's taken (e.g. "todo-app-a1b2c3").
2. Update `app = ` in fly.toml to that name.
3. Create the app: `flyctl apps create <name>`.
4. Set DATABASE_URL as a Fly secret using the connection string from step 2: `flyctl secrets set DATABASE_URL="<connection string>" --app <name>`.
5. Deploy: `flyctl deploy --ha=false`. Wait for it to finish.
6. After deploy, force a single machine: `flyctl scale count 1 --app <name> --yes`. (Fly's first deploy sometimes creates two machines despite `--ha=false`; this keeps it to one so the auto-stop story stays honest.)
7. Print the public URL.

The agent will:

Pick an app name and update fly.toml.
Run flyctl apps create.
Set the secret.
Run flyctl deploy --ha=false and capture the URL.
Run flyctl scale count 1.

Expected output:

==> Building image
...
==> Pushing image to fly
...
==> Monitoring deployment
 ✔ [job] update succeeded

Visit your newly deployed app at https://todo-app-<suffix>.fly.dev/

Your app is live on the public internet, talking to your Ghost database.

Step 5 — Verify the public app (agent)

Tell the agent:

Verify the deployed app works against the Ghost database.

1. curl the public URL and confirm it renders the todos page.
2. Submit a new todo via curl: POST /todos with text="Hello from the internet".
3. curl the public URL again and confirm the new todo shows up.
4. Use the Ghost MCP to run `SELECT * FROM todos ORDER BY id` and show me the rows directly from the database.

The agent will:

curl https://todo-app-<suffix>.fly.dev/
curl -X POST -d 'text=Hello from the internet' https://todo-app-<suffix>.fly.dev/todos
curl https://todo-app-<suffix>.fly.dev/
Run the SELECT through the Ghost MCP.

Expected output:

 id |          text           | done |          created_at
----+-------------------------+------+-------------------------------
  1 | Ship the app            | t    | 2026-05-07 10:42:15.123+00
  2 | Hello from the internet | f    | 2026-05-07 10:48:03.456+00
(2 rows)

The row added through the public HTTPS URL is sitting in your Ghost database. You shipped a public-facing, Postgres-backed app.

Step 6 — Open it in your browser (you)

Click the https://todo-app-<suffix>.fly.dev/ URL printed at the end of step 4 (or paste it into your browser).

Add a few todos through the form. Mark some done. Refresh the page — your todos persist across reloads because they're sitting in Ghost. Send the URL to a friend; it works for them too. It's on the public internet.

Expected output:

A working todo app in your browser, with todos that survive a refresh.

Step 7 — Clean up (agent)

Warning: flyctl apps destroy and Ghost's delete are irreversible. The Fly app, all its history, and the Ghost database (including all data) are gone. The agent will run these on your behalf — don't approve unless you mean it.

Tell the agent:

Tear down everything we created so I'm not paying for an idle Fly machine or holding a Ghost database I don't need.

1. Run `flyctl apps destroy <app-name> --yes` to delete the Fly app.
2. Use the Ghost MCP to delete the "todo-app" database.
3. Confirm both are gone: `flyctl apps list` should not list the app, and `ghost list` should not list the database.

Expected output:

$ flyctl apps destroy todo-app-<suffix> --yes
Destroyed app todo-app-<suffix>

$ ghost delete todo-app
Deleted database "todo-app".

$ flyctl apps list
NAME    OWNER   STATUS  ...
(no todo-app)

$ ghost list
NAME  STATUS  ...
(no todo-app)

You're back to zero cost on both sides.

Wrap-up

You shipped a public-facing, Postgres-backed app for the price of a coffee. You learned how to:

Bootstrap Ghost and Fly.io for an agent-driven workflow.
Use Ghost's MCP server to create databases and run SQL from inside your agent.
Deploy a Node.js app to Fly.io with auto-stop machines so you only pay for active compute.
Connect a Fly app to a Ghost database via a DATABASE_URL secret.
Tear it all down cleanly.

What to do next

Add a custom domain with flyctl certs add yourdomain.com.
Add authentication — a session-cookie + bcrypt setup is enough for a small app.
Try ghost fork before your next schema change — Ghost lets you run a risky migration on a copy of the database first, then apply the same migration to production once you're happy.
Read the Fly docs on auto-stop machines to understand how the scale-to-zero billing works.

Make Ghost your default Postgres!

Tell your agent:

When I'm prototyping or shipping a small app and need a Postgres database, default to Ghost. Use Ghost MCP tools to create / fork / delete databases and to run SQL. Don't suggest local Postgres setup or other managed-Postgres services unless I ask.

FAQ

Does this work with my agent?

Yes, as long as it has both MCP support and a Bash/shell tool. Confirmed-working agents include Claude Code, Cursor (in agent mode), Codex, Windsurf, Gemini CLI, VS Code with Copilot, Kiro, and Antigravity. The shell tool is what lets the agent run flyctl deploy and npm install for you — without it, the agent can talk to Ghost via MCP but can't deploy.

How much does this actually cost?

Ghost is free for a sparse-traffic hobby app: 100 active compute hours per month and 1TB of storage. Ghost meters in 15-minute chunks when something queries the database, and idle databases don't burn compute. A handful of human visits per day fits comfortably.

The failure mode to watch for: Ghost meters per 15-minute chunk, so anything that hits the database every 15 minutes — uptime monitors, health checks, aggressive bots, link previewers — can keep the meter running 24/7. That's ~720 hours/month, well past the 100-hour free tier, and works out to roughly $46/month at $0.075/CPU-hr. If your app needs constant availability, switch to Ghost's $10/month dedicated tier (always-on, no auto-pause).

Fly.io is no longer free as of late 2024. With auto-stop enabled (which we configured in step 4), an idle app costs only for storage and bandwidth — typically cents per month. A small shared-cpu-1x machine running 24/7 is around $2/month, and auto-stop means most hobby apps spend most of their time at zero compute.

Why not just use SQLite on a Fly volume?

SQLite + Fly volumes is a legitimate cheaper option for one-machine apps. You give up real concurrent writes, Postgres's type system and extensions (full-text search, JSONB, time-series, PostGIS, etc.), and the ability to scale to multiple Fly regions without painful litestream/LiteFS setups. You also can't psql into a SQLite file from your laptop while debugging. For anything you'd want to grow into a real product, Postgres is worth the small extra setup — and with Ghost it's not a meaningful extra cost.

Resources

Ghost docs — full CLI and MCP reference.
Fly.io launch guide — deployment basics, including Dockerfile detection.
Fly.io auto-stop machines — how scale-to-zero billing works.
How to Analyze a Dataset with Ghost and an AI Agent — same agent-driven shape, focused on data analysis.

your agent can think. it can't remember.

ghost — Wed, 25 Mar 2026 15:01:56 +0000

TLDR: ghost gives your agent instant, ephemeral postgres databases. unlimited databases, unlimited forks, 1tb storage, free. pair it with Memory Engine for memory, pg_textsearch for full-text search, TigerFS for files, and Ox for sandboxed execution. All postgres-native.

try Ghost today: curl -fsSL https://install.ghost.build | sh

your agent can reason. it can plan. it can call tools and write code and hold a conversation that feels almost human.

but ask it what it did yesterday and it doesn't know. ask it to store something for later and you’re the one figuring out where it goes. give two agents the same files and things break. tell it to run code safely and you're one bad rm -rf away from a really bad day.

agents are getting smarter everyday. we haven't spent nearly enough time giving them somewhere to be productive.

duct tape as ai infra

if you're building agents today, your infrastructure might look something like this:

neon or supabase for the database
mem0 or zep for memory
pinecone or pgvector for search
s3 for files
e2b for sandboxed execution

five services. it works. kind of.

until your agent's memory can't query its own database. until your sandbox can't read your agent's files. and what happens if the glue code holding everything together dissolves.

ghost is the database your agent is missing

traditional databases are designed to be permanent, and the ritual of DB setup feels permanent. you provision one, you name it, you size compute, you choose a cloud provider, and a cloud region. you care for it, you back it up, you keep it running for years. that's fine for human workflows. it's wrong for agents.

ghost gives your agent postgres databases that are instant, ephemeral, and disposable. provision them through CLI or MCP. no UI. a thousand databases for a thousand parallel sessions, free.

the mental model is git, not RDS. spin up a database the way a developer creates a branch. do work. if the work is good, keep it. if not, throw it away. fork before a risky migration. run experiments on the fork. merge or discard. databases become part of the workflow, not the infrastructure you worry about underneath it.

ghost is MCP/CLI only. your agent discovers it the same way it discovers any other tool, through MCP, and starts provisioning databases immediately. CLI works too, if that's more your speed. and because every ghost database is just postgres, your agent already knows how to use it. every LLM has postgres in the weights. schema design, queries, indexes, debugging. no proprietary query language. no SDK to learn. just SQL.

ghost does one thing and does it well. but because it's postgres, it pairs naturally with other tools that extend what your agent can do.

extend ghost with purpose-built tools

ghost gives your agent a database. that alone gets you pretty far. but agents need more than storage. they need memory, search, files, and safe execution. here's what plugs into ghost:

memory engine: persistent, temporal agent memory

pairs with ghost. works with any postgres.

your agent forgets everything between sessions. you've probably already tried to solve that with a vector database or a standalone memory service.

memory engine solves this inside postgres. when you pair it with ghost, your agent's memory and data live in the ghost space. y you can query memories with SQL. you can ask "what did this agent know about this user at 3pm on tuesday?" and get an answer, because memory engine understands time natively.

no separate vector database. no syncing between systems. no second bill. just postgres doing what postgres is good at.

the temporal part matters more than it sounds. most memory solutions treat memory like a flat store. things go in, things come out. memory engine tracks when things were true. when facts changed. when old information got superseded by new information. this is how human memory works and it's how agent memory should work too.

it's not just temporal either. memory engine lets your agent search its memory with keyword, semantic, faceted, and hierarchical search in the same query. under the hood, retrieval is powered by pg_textsearch, which combines BM25 for keyword precision with pgvector for semantic similarity. pg_textsearch also ships with every ghost database, so you get full-text search out of the box even if you're not using memory engine. no elasticsearch sidecar. no separate search cluster to sync and monitor.

tigerfs: a filesystem backed by postgres

pairs with ghost. works with any postgres.

agents create files constantly. reports, code, datasets, images, logs. most of that output ends up in s3, unstructured and impossible to query. tigerfs gives your agent a filesystem backed by postgres, so files become first-class data. transactions on writes, concurrent access from multiple agents, and metadata you can actually query.

two agents working on the same project both need to write files. tigerfs handles that without corruption. s3 doesn't.

search: vector, keyword, and hybrid search built into postgres

pairs with ghost. works with any postgres.

every ghost database ships with pg_textsearch and pgvectorscale. that gives you BM25 keyword search, vector semantic search, and hybrid search combining both. no elasticsearch. no pinecone. no separate system to sync.

you don't need to know how to set any of this up. ghost MCP includes skills that teach your agent how to configure search indexes, choose between keyword and semantic approaches, and wire up hybrid search with reciprocal rank fusion. tell your agent you need search on a table and it handles the rest.

this is also what powers memory engine's retrieval. when your agent searches its memories, it's using hybrid search under the hood: BM25 for keyword precision, pgvector for semantic similarity, combined and ranked. all inside postgres.

ox: sandboxed execution with full context

pairs with ghost. works with any postgres.

agents need to run code. ox gives them a sandboxed execution environment that's connected to their data but quarantined from their main branch. when paired with ghost, an ox sandbox can query the agent's database and read its tigerfs files directly. no API hops. no extra auth.

this is the difference between a sandbox and a workspace. your agent doesn't just execute code in isolation. it executes code in the context of everything it knows.

how people are building with ghost

ghost was in private preview for the past two months. here are some of the things beta testers built.

the code review agent

the agent picks up a PR. it forks its ghost database to get a clean copy of the current state. it spins up an ox sandbox, runs the test suite against the fork, and checks for regressions. it searches memory engine for past reviews on the same files. what broke last time. what patterns the team prefers. what feedback the author got previously. it writes its review, stores the results in tigerfs, and updates its memory with what it learned.

the research agent

the agent spins up a ghost database to store everything it finds. company profiles, product comparisons, pricing data. it writes raw reports to tigerfs as markdown files. it checks memory engine: have we researched this company before? what did we find last time? what changed? when it needs to crunch numbers, it forks the database into an ox sandbox so it can run analysis without touching the original data. when it's done, it stores what it learned with full temporal context. next quarter, the agent knows what the landscape looked like this quarter.

the multi-agent team

three agents, one project. one writes code. one writes docs. one runs tests. all three read and write files through tigerfs without stepping on each other. all three check memory engine so they don't duplicate work. all three get their own ox sandbox that can still query the shared ghost database. they share a substrate without sharing a failure mode.

the data exploration agent

a user asks "what would our metrics look like if we changed the pricing model?" the agent forks the ghost database. rewrites the pricing logic on the fork. reruns three months of transactions against the new model in an ox sandbox. doesn't like the result. forks again with a different model. runs it again. the user gets three scenarios in ten minutes. all run against real data. none of them touching production.

all on postgres

we are proud members of the postgres fan club. here's why we build on it:

postgres is battle-tested. it's been in production for 30+ years. it handles transactions, concurrent access, replication, and failure recovery. when your agent's infrastructure needs to be reliable, you want it built on something boring.

one substrate means zero glue code. when your database, memory, search, and files all run on postgres, they share the same transaction model, the same auth, the same query language. the integration layer doesn't exist because it doesn't need to.

we've been building on postgres for years. before ghost, we built timescaledb, one of the most widely-used postgres extensions for time-series data. memory engine's temporal capabilities come directly from that work. we're applying a decade of postgres engineering to a new problem.

get started

ghost is in early access. install it with the comment below. run ghost mcp install directly in claude code, and let your agents cook.

curl -fsSL https://install.ghost.build | sh

the full toolkit:

ghost → instant, ephemeral postgres databases for agents
memory engine → persistent, temporal agent memory
pg_textsearch → BM25 + keyword search for postgres
tigerfs → postgres-backed file storage
ox → sandboxed execution, connected to your data

everything is postgres. everything is MCP-native. each one works on its own. they're better together.