Features · Databases & storage

Every app gets its own.

A real Postgres database and an S3-compatible bucket, created for the app and handed over as credentials. Or your own, with nothing in the app changing.

Three choices, per app

Internal

Astrodock creates the database and the bucket, with their own credentials, and backs them up along with everything else.

External

Point at a managed service instead. You supply the credentials; the platform passes them through untouched.

None

Plenty of apps need neither. Nothing is provisioned, and nothing is billed to your disk.

The part that matters later

Outgrowing it isn't a migration project.

Internal and external hand the app the same variable name. The code reads a connection string; it has no idea whether the database is on the same box or in another company's data centre.

So the day one app needs a managed Postgres with replicas, that's a settings change and a redeploy — not a rewrite, and not a reason to have picked differently at the start.

Bringing your own database →

app.json

{
  "database": { "mode": "internal" },
  "storage":  { "mode": "none" }
}

# the app reads, either way:
ASTRODOCK_DATABASE_URL

Side by side

What actually changes.

The answer is deliberately boring: the variable your app reads is the same in both columns. That is the whole point.

	Internal	External
Who creates it	Astrodock, on deploy	You, at your provider
Where it runs	Your machine	Neon, RDS, Supabase, R2
App reads	`ASTRODOCK_DATABASE_URL`	`ASTRODOCK_DATABASE_URL`
Code changes	None	None
Backed up by	Astrodock, nightly	Your provider
Good for	Starting, and most small apps	Scale, replicas, compliance

Next Deploys & runtimes Push, upload, or let an agent do it

Or install Astrodock and try it on a machine you control.