Deploy Metabase Backups

Deploy and Host self hosted Metabase Backups (Backup and Restore) on Railway

Metabase backups mean the Postgres app DB, the encryption secret, and a tested restore path. Railway volume backups plus pg_dump give you boring, reliable recovery. This guide covers what to back up, how to restore, and what to practice.

About Hosting Metabase Backups open-source software on Railway (self hosted Metabase template)

State lives in Postgres, not the container. The official image (metabase/metabase, pin v0.63.x) listens on 3000, health at /api/health. Back up the companion Postgres (ghcr.io/railwayapp-templates/postgres-ssl, 17) plus MB_ENCRYPTION_SECRET_KEY. H2 is wiped on redeploy, so never run production on it. Volume backups cover fast recovery on Railway; pg_dump gives you portable copies.

Why Deploy Metabase Backups, the Metabase Cloud alternative on Railway (Railway Free Trial)

Metabase Cloud manages backups for you, but it charges per user and you don't pick the retention. Self-hosting gives you the same AGPL OSS core with full control of schedule, retention, and keys. The $5 GitHub trial covers a restore drill; after that you pay only for compute and storage.

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Metabase Backups on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Railway vs Other Hosting Providers and VPS for Metabase Backups self hosting

Most VPS providers give you a box and a firewall; backup scripting is yours. Railway's Postgres volume can be backed up and restored from the dashboard, which is fast but tied to Railway. Other clouds offer point-in-time recovery (PITR) at a higher cost and setup.

Railway wins on low maintenance, DigitalOcean and AWS sell PITR for more money, and Hetzner is the budget pick if you script it yourself.

Common Use Cases for hosted Metabase Backups

• Upgrade rollbacks: dump before a new image, and restore the old DB if a migration breaks.
• Disaster recovery: a volume backup plus a logical dump after corruption or a stray DROP TABLE.
• Staging copies: restore the app DB to staging and test dashboard changes there.
• Moving hosts: pg_dump the old DB, pg_restore into the new one, update MB_DB_*.
• Audit snapshots: dated dumps give you queryable history of who had access when.

Dependencies for Metabase Backups Docker hosted on Railway

Production Metabase needs Postgres for its app metadata, which is the thing you back up. Analytics DBs (warehouse, product Postgres, Snowflake) are separate and need their own schedules. Set MB_DB_* to point at companion Postgres. Without a stable MB_ENCRYPTION_SECRET_KEY, encrypted fields break after restore.

Deployment Dependencies for Managed Metabase Backups Service (Business Intelligence)

• MB_DB_TYPE=postgres: Postgres, not H2.
• MB_DB_HOST, MB_DB_PORT: internal hostname and port via Railway variable references.
• MB_DB_USER, MB_DB_PASS, MB_DB_DBNAME: app DB credentials.
• MB_ENCRYPTION_SECRET_KEY: a long random string you generate once and never rotate casually.
• MB_SITE_URL: public HTTPS URL for links, embeds, and emails.

Implementation Details for Metabase Backups (Using Metabase official docker image)

Deploy a pinned metabase/metabase tag on port 3000 with health at /api/health. First boot migrates Postgres and shows the setup wizard, where you create the admin user. Connect analytics DBs in Admin → Databases.

Backup layers:

1. Railway volume backups on the Postgres volume, restored from the dashboard.
2. pg_dump -Fc -d $MB_DB_DBNAME -U $MB_DB_USER -h $MB_DB_HOST > metabase_$(date +%F).dump on a cron schedule, stored off Railway.

Pass --no-owner --no-acl to pg_restore so the dump lands in a fresh Postgres without recreating the source roles, and test an import before you trust the schedule.

Keep MB_ENCRYPTION_SECRET_KEY with the dump, in Railway variables and a password manager. When restoring, set the same value before first boot.

Restore drill: spin up a throwaway Metabase and Postgres, pg_restore, set the same secret, start, and click through dashboards.

How does Metabase Backups compare against other self-hosted BI platforms

Backup models vary a lot. Metabase's is one Postgres database plus one secret, and plain pg_dump handles it.

Metabase Backups vs Metabase Cloud (Metabase Cloud Alternative)

Cloud runs backups for you. You can't pg_dump it, though, and pricing scales per user. Self-hosting gives the same OSS with your own retention.

Metabase Backups vs Apache Superset (Apache Superset Alternative)

Superset also keeps metadata in Postgres (or MySQL) and has its own SECRET_KEY to protect, so the backup story is close to a tie.

Metabase Backups vs Redash (Redash Alternative)

Redash stores queries in Postgres and uses Redis for queues and cache, so there are more moving parts to think about. Metabase's single app DB makes a restore easier to reason about.

Metabase Backups vs Looker (Looker Alternative)

Looker is Google-hosted, and its modeling lives in LookML in Git, not a database you dump. Looker wins on governance; Metabase wins on portability and cost.

How to use Metabase Backups (the OSS Business Intelligence)?

Metabase Backups isn't a separate product—it's keeping your instance recoverable.

1. Schedule it: Railway volume backups plus a nightly pg_dump to S3.
2. Store the secret: Railway variables plus a password manager.
3. Write the runbook: stop Metabase, restore, check the secret, restart, hit /api/health.
4. Dump before upgrades: take a manual dump before each new image so rollback is one restore.

How to self host Metabase Backups on other VPS Services (Metabase Backups self hosting guide)

The same pattern works on any VPS: Docker or a Java runtime, Postgres, and cron for backups.

Clone the Repository

No repo needed; docker pull metabase/metabase with a pinned tag.

Install Dependencies

Docker and Compose, or Java 21 for the jar. Install Postgres and create a database and user.

Configure Environment Variables

Set the same variables: MB_DB_TYPE=postgres, MB_DB_HOST, MB_DB_PORT, MB_DB_USER, MB_DB_PASS, MB_DB_DBNAME, MB_ENCRYPTION_SECRET_KEY, MB_SITE_URL. Schedule pg_dump with cron and ship the dump off-server.

Start the Metabase Backups Application

docker run -d -p 3000:3000 --env-file .env metabase/metabase, then finish the setup wizard. Add a 2am cron entry that runs pg_dump -Fc into /backups and copies the file to S3.

Official Pricing of Metabase Backups (Metabase Backups pricing)

There's no separate backup product; OSS is free under AGPL. What you pay for:

• Metabase Cloud Starter: about $85/mo plus per-user, managed backups included.
• Metabase Cloud Pro: much higher, adding SSO, row-level permissions, interactive embedding, and serialization.
• Self-hosted on Railway: typically $5–15/mo for compute and Postgres, plus a little object storage for dumps.

Metabase Backups cloud vs self hosted comparison (Pricing, features, costs, and more)

Cloud takes the backup job off your plate but costs per user and limits retention control. Self-hosting on Railway gives the same OSS features at a flat infra cost, and you own the pipeline. For hands-off teams, Cloud is worth the premium. For operators who want portable dumps and a known secret, self-hosting wins.

Monthly cost of self hosting Metabase Backups on Railway

A Metabase container with about 1GB RAM and a small Postgres volume on Hobby typically lands at $5–15/mo. Dumps on S3 add a little.

System Requirements for Hosting Metabase Backups on a VPS

Minimum: 1 vCPU and 1GB RAM (2GB recommended), plus disk for the OS, Postgres, and local dumps. Backups are I/O-bound, not CPU-bound.

Frequently Asked Questions (FAQs)

Do I need to back up the Metabase application container itself?

No. The container is stateless; state lives in Postgres plus the secret. Pull a fresh image and point it at the restored DB with the same MB_ENCRYPTION_SECRET_KEY.

Can I restore a single dashboard or question from a backup?

Not easily, since pg_dump restores the whole DB. Restore to a temp instance and rebuild the item by hand. Pro adds serialization for this; OSS lacks it.

What happens if I lose MB_ENCRYPTION_SECRET_KEY?

Encrypted fields like DB passwords, SMTP, and Slack tokens become unreadable. Dashboards survive, but you re-enter every credential. Back up the key with the DB.

How often should I run pg_dump?

Daily for an active instance, plus one before every upgrade. Volume backups aren't portable; pg_dump is your off-site copy.

Can I use Railway's volume snapshots instead of pg_dump?

They're fast for recovery on Railway but tied to it, while pg_dump restores anywhere. Use both.

What's the best way to test a restore?

Restore the latest dump into a throwaway Metabase and Postgres with the same secret, then open a few dashboards and test a connection. Untested backups are wishes, not plans.