Provision a Managed Postgres Database on Launchverse

Most production web apps need a database. You don't want to run one yourself if you can avoid it — backups, replication, version upgrades, and disk growth are real distractions from shipping product. This guide walks through provisioning a managed Postgres instance on Launchverse and connecting it to your application.

1. Open the Resources tab

Inside any project, the Resources tab is where you attach databases and marketplace services. Click "Provision Resource" and pick PostgreSQL from the catalogue.

2. Configure

You'll be asked for three things:

Name — internal identifier; it becomes the hostname of the database on the project's private network.
Default database name — the database created on first boot. Leave it blank to use the engine's default (postgres).
Public access — toggle this only if you need to connect from outside the platform (e.g. for migrations from your laptop). Most production apps keep this off and connect via the internal URL.

Submit. Provisioning takes 30–60 seconds; you'll see a Provisioning pill while the engine pulls the image and runs the first boot. Once it's healthy, the Resources tab will populate the credentials block.

3. Connect from your app

Two URLs appear once provisioning completes:

Internal URL: postgres://user:pass@dbname:5432/postgres. Use this from inside any Launchverse-deployed application — traffic stays on the project network, no NAT, no public hop.
External URL: only present if you flipped Public on. Use this from your laptop / migration scripts.

Set DATABASE_URL in your application's env vars to the internal URL. Most ORMs (Prisma, Drizzle, TypeORM, Knex) read DATABASE_URL automatically.

4. Run migrations

The first time you deploy, the database is empty. Two patterns work:

Build-time migrations: add prisma migrate deploy (or your equivalent) to the post-build hook. The engine runs it automatically on each deploy.
One-off migration: open the project Shell tab and run the migration manually. Same env vars are available.

Build-time is the safer default — you can't deploy code that doesn't match the schema if the migration runs first.

5. Backups

Launchverse takes daily snapshots of every managed database by default. Restoration is a single click: pick a snapshot, confirm, and the engine recreates a new instance from the snapshot point. Your application can then be repointed to the new instance with a single env var change.

For tighter recovery objectives (Pro+), enable point-in-time recovery on the database settings page.

6. Credential rotation

The Resources page shows the current admin credentials. To rotate:

Stop the application that's connected to the database.
Restart the database with a new root password (the engine generates one for you).
Update the DATABASE_URL env var on the application.
Restart the application.

Total downtime: ~10 seconds. Credentials never leave the engine — Launchverse fetches them server-side and only displays them to authenticated team members.

7. Common errors

Validation failed - clickhouse_db — historically caused by mis-routed payload fields when provisioning Postgres. Fixed in May 2026; if you hit it, refresh and retry.
Connection refused — the most common cause is using the public URL when public access is off. Switch to the internal URL.
role "postgres" does not exist — your default database name and user got mismatched. Run CREATE USER ... against the database from the Shell tab.