All guides
Tutorial/ 9 min read/

How to Provision and Manage a Database on Launchverse

Step-by-step guide to provisioning a managed database on Launchverse — Postgres, MySQL, MariaDB, MongoDB, Redis, KeyDB, DragonFly, Clickhouse — connecting it to your app, toggling public access, and running backups, restores, and credential rotation.

Every non-trivial app needs a database. The bad news is that running one yourself — disk growth, replication, version upgrades, nightly backups, on-call when storage fills at 3 AM — is a full-time distraction from shipping product. The good news is that Launchverse runs all of that for you. This guide walks through the full lifecycle: provisioning, connecting, exposing publicly, backing up, restoring, rotating credentials, and tearing down — for every engine the platform supports.

What you can provision

Launchverse provisions any of these as a one-click managed resource:

  • PostgreSQL — the default for transactional workloads.
  • MySQL / MariaDB — drop-in for legacy apps and Wordpress / Ghost / Plausible.
  • MongoDB — document store for unstructured payloads.
  • Redis / KeyDB / DragonFly — caching, queues, sessions.
  • Clickhouse — columnar OLAP for analytics.

Every engine gets the same operational surface: lifecycle controls, scheduled backups, point-in-time restore, encrypted credentials, and an internal hostname that Launchverse-deployed apps can reach without a public hop.

1. Provision a database

Open any project and click the Resources tab, then Provision Resource. Pick an engine from the picker.

You'll be asked for three things:

  • Name — internal identifier; this becomes the hostname on the project's private network. Use lowercase letters and hyphens (e.g. app-prod-db).
  • Default database name (SQL engines only) — the database created on first boot. Leave blank to use the engine default (postgres, mysql, mariadb, mongo).
  • Public access — leave off for production. Toggle on later from the management page if you need to connect from your laptop or DataGrip.

Submit. Provisioning takes 30–60 seconds while the engine pulls the image and runs first-boot. The button resets automatically; the page redirects to Resources where the new database shows a Provisioning pill.

You'll know it's ready when the pill flips to Healthy and a credentials block appears under the row. The Resources page polls status every 3 seconds while a resource is provisioning, so there's nothing to refresh manually.

It also lands in the dashboard. The team-wide list at /dashboard/databases shows every provisioned database across every project, with the same status pill and a Manage → button that opens the rich management page.

2. Connect from a deployed app

Once healthy, two URLs appear in Resources:

  • Internal URL, e.g. mysql://mariadb:••••••@app-prod-db:3306/Testing_db. Use this from any application deployed on Launchverse — traffic stays on the project's private network, no NAT, no public exposure, no extra latency.
  • External URL — only present after you flip Public Access on. Use this from your laptop, migration scripts, or external clients.

Add the internal URL to your application's environment variables under the standard name your ORM expects. Most ORMs read DATABASE_URL automatically:

DATABASE_URL=mysql://mariadb:••••••@app-prod-db:3306/Testing_db

For Postgres apps with Prisma, Drizzle, TypeORM, or Knex, the same pattern works with the postgres:// scheme. For Redis, set REDIS_URL. For MongoDB, MONGODB_URI.

Redeploy. The app picks up the env var on the next build and connects internally.

3. Manage from the dashboard

The management page (/dashboard/databases/{id}) is the single source of truth for an existing database. It exposes:

  • Connection details — host, port, database name, username, password (one-click copy), and a pre-built URI.
  • Public Access toggle — flip exposure on/off without leaving the dashboard. When you toggle on, the engine assigns a public port and the host swaps to the engine's external FQDN; when you toggle off, the database falls back to the private hostname only.
  • Lifecycle actions — Start, Stop, Restart. Stopping suspends the container and disk; storage is preserved so you can resume cleanly.
  • Backup schedule — Off / Hourly / Daily / Weekly presets, plus a custom-cron field for anything else. Retention can be capped by either number of files or number of days.
  • Backup history — list every snapshot with size, status, and timestamp; click Restore on any row to roll back.

4. Toggle public access

By default, every managed database is private to the project network. Apps deployed on Launchverse can reach it on the internal hostname; nothing outside the engine can.

To connect from outside (DataGrip, TablePlus, psql on your laptop, an external CI runner running migrations):

  1. Open the management page for the database.
  2. Find the Public Access card at the top of Connection Details.
  3. Click the toggle.

The engine assigns a public port within seconds. The Connection Details refresh automatically and the host/port now point to the engine's public FQDN. Use the External URL from any client.

Hardening tip. Public means publicly addressable, not publicly trusted. Restrict by source IP via the engine's firewall before pointing production traffic at the public URL, and rotate the password the first time you flip exposure on.

Toggle off when you're done — the database returns to internal-only.

5. Schedule backups

By default Launchverse takes a daily snapshot at 03:00 UTC. To change the cadence:

  1. Open the management page.
  2. In Backups, pick a preset (Hourly / Daily / Weekly) or paste a cron expression in the custom field. Standard 5-field cron, UTC.
  3. Set retention. Files caps the number of snapshots kept; Days ages anything older out. We keep whichever bound the user crosses first.

Trigger a manual backup any time with Backup now. The backup runs on the engine and shows up in the history table with size and finish time.

6. Restore from a snapshot

Restore is a one-click operation:

  1. Open the management page.
  2. Scroll to Backup History.
  3. Click Restore on the snapshot you want.
  4. Confirm.

The engine spins up a new instance from the snapshot. Your application's DATABASE_URL doesn't change — Launchverse re-points the hostname so apps reconnect automatically. Total restore time depends on snapshot size; expect 30 seconds to a few minutes for small to mid-sized databases.

For tighter recovery objectives (Pro+), enable Point-in-Time Recovery from the database management page — see the Database Backups and PITR guide for the full breakdown.

7. Rotate credentials

Credentials never leave the engine — Launchverse fetches them server-side, gates by RBAC (Owner / Developer can read, Viewer cannot), and writes every read to an audit log for SOC2 evidence. To rotate:

  1. Stop the application(s) connected to the database.
  2. From the management page, click Restart — Launchverse regenerates the root password on the next boot.
  3. Copy the new password from Connection Details.
  4. Update the DATABASE_URL env var on the application(s).
  5. Restart the application(s).

Total downtime: ~10 seconds. The audit-log entry pins exactly who pulled credentials and when, so you can reconstruct an exposure timeline if you ever need to.

8. Tear down

Open Resources, find the database, click the trash icon, and confirm. The engine destroys the container and reclaims the disk; the corresponding row is removed from /dashboard/databases and the database tile on the overview decrements.

Want to keep the data but stop the bill? Use Stop instead of delete — the snapshot history and disk are preserved indefinitely and you can resume with a single click.

9. Troubleshooting

  • "Provisioning" pill never flips to Healthy. The Resources page polls every 3 seconds while provisioning, so this is rare. If it persists, open the management page once — the page kicks the engine status sync on mount and the dashboard list updates via realtime within a second.
  • Connection refused from your app. Almost always a public/private URL mismatch. Apps inside Launchverse should use the Internal URL. The public URL only works when Public Access is on, and it requires the engine's FQDN, not the internal short hostname.
  • role "postgres" does not exist. The default database name and user got mismatched at provision time. Easiest fix is to destroy the resource and re-provision with the default database name left blank — Launchverse will create the correct admin role on first boot.
  • The provision button used to spin forever. Fixed in May 2026. The credential lookup that ran inline with provisioning now has a 5-second timeout, so the button always returns within ~10 seconds; credentials hydrate from Resources after that. If you hit it on an older deployment, refresh and the resource will already exist.

Further reading

Ready to deploy?

Start free in Naira — no card required, no FX surprises.

Start deploying free See pricingFAQ

Have feedback or a topic to suggest? Talk to us.