Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.slipway.sh/llms.txt

Use this file to discover all available pages before exploring further.

Slipway can stand up a database alongside every convoy, share it with every component in that convoy, and optionally restore it from a snapshot on first boot. The seed runs once when the addon is first attached — subsequent deploys to the same convoy reuse the running database with whatever state it has, just like a real production environment. Databases are convoy-only today. Standalone single-repo deployments and 5-minute ephemeral previews don’t support addons yet.

​
What you can attach

The catalog you’ll see depends on what your plan includes — Postgres is the default starting point. If you need a database engine or version that isn’t listed, open an issue.

​
Attach a database to a convoy

  1. Open the convoy and go to its Databases tab.
  2. Click Attach addon.
  3. Pick a database from the catalog.
  4. Give it a short DNS-safe name — this becomes the env-var prefix every component sees. db is conventional.
  5. (Optional) Pick a snapshot from your org’s snapshot library to seed from.
  6. Click Attach.
The addon moves through creating → seeding → healthy. Convoy deploys block until every attached addon is healthy.

​
Connection strings — automatic

Every component in the convoy gets these env vars merged into its container automatically, without you touching slipway.yaml:
VarExample
SL_ADDON_<NAME>_URLpostgres://postgres:xyz@db.sl-envaddon-…:5432/app?sslmode=disable
SL_ADDON_<NAME>_HOSTdb.sl-envaddon-….svc
SL_ADDON_<NAME>_PORT5432
SL_ADDON_<NAME>_USERpostgres
SL_ADDON_<NAME>_PASSWORD(random per-instance)
SL_ADDON_<NAME>_DATABASEapp
<NAME> is whatever you typed in the attach dialog, uppercased. If your slipway.yaml already sets a value for one of these keys (e.g. services.api.env.DATABASE_URL), your value wins — addon env vars only fill in keys you haven’t set yourself.

​
Seeding from a snapshot

Slipway doesn’t anonymize production dumps for you — bring your own. The typical workflow:
  1. Take a dump from your real database locally and run it through whatever redaction script your team uses.
  2. Upload the resulting artifact at Addons → Snapshots. The upload form asks which database engine the snapshot is for; the accepted file extensions are listed inline.
  3. When attaching a database, pick the snapshot from the dropdown — only snapshots that match the engine you picked appear.
What slipway does with the bytes depends on the engine. For Postgres, the snapshot is restored with pg_restore --clean --if-exists once, on first attach.

​
Lifecycle

  • Provision — the database starts up in an isolated namespace alongside the convoy.
  • Seed — if you picked a snapshot, slipway restores it once.
  • Healthy — the database is reachable from every component in the convoy via the SL_ADDON_* env vars.
  • Detach — clicking Detach in the UI removes the database and its storage. All data is lost.
  • Convoy teardown — every attached database is automatically torn down before the convoy itself goes away.

​
Not yet supported

  • Migration-script seeding (migrate up against an empty database).
  • Fixture-file seeding (committed seed/*.sql).
  • Automatic anonymized-snapshot generation on a schedule.
  • Per-component databases (every database is convoy-scoped today — all components share it).
  • Databases for standalone (non-convoy) deployments.
If any of these would unblock you, open an issue.