Deploy and Host self hosted Metabase Encryption Key (Encrypted BI Settings) on Railway

MB_ENCRYPTION_SECRET_KEY is one environment variable that quietly guards every warehouse password Metabase stores. Set it once, before the first data source, and nobody thinks about it again. Change it on a whim and Monday starts with every dashboard throwing connection errors. This template is about keeping that key boring.

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

Metabase keeps the connection details for every database you add inside its own application database. With a key set, those fields are encrypted with AES256 + SHA512 when saved and decrypted on the fly when a query runs. Without a key, anyone holding a pg_dump of the app DB holds your Snowflake and Postgres credentials in plain text.

The trap on Railway is human, not technical. A teammate tidying variables clicks regenerate, someone duplicates the project for staging and gets a fresh key, or a backup gets restored into a new project that never had the old value. In every case the dashboards and questions survive, but each saved connection has to be re-entered in Admin until the original key comes back.

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

On Metabase Cloud the key is handled for you and you never see it. That is lovely until a security review asks where credentials live and who can read them. Self-hosting the AGPL OSS build on Railway puts the app DB in your Postgres and the key in your own service variables, without per-user fees. The cost is that key hygiene becomes your job.

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 Encryption Key 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 Encryption Key self hosting

The key is just a string, so the real difference between hosts is where that string lives and how easy it is to lose.

Provider	Where the key lives	Postgres app DB	Gotcha
Railway	Service variable on Metabase	Companion Postgres on the private network	Duplicated or redeployed projects can get a new key
DigitalOcean	.env on a Droplet or App Platform variable	Managed Postgres, wired by hand	Rebuilt Droplets forget hand-edited .env files
AWS	Secrets Manager or SSM injected into ECS	RDS	Most setup, best audit trail
Hetzner	A file you own on the box	Self-managed Postgres	Your backups must include the key too

Common Use Cases for hosted Metabase Encryption Key

A startup connects production Postgres, a read replica, and BigQuery, and wants the answer to "are stored credentials encrypted at rest?" to be a plain yes for the compliance questionnaire. Agencies running one Metabase per client keep a separate key per project so one leaked dump never exposes another client. Teams with staging and production keep a dedicated app DB and key in each, and know that moving a dump between them means moving its key too.

Dependencies for Metabase Encryption Key Docker hosted on Railway

The hard dependencies are the metabase/metabase container and a Postgres app database. The key is a variable on the Metabase service, not another service. Skip Postgres and Metabase falls back to an H2 file the next redeploy wipes, encrypted connections and all.

Deployment Dependencies for Managed Metabase Encryption Key Service (Business Intelligence)

Set MB_DB_TYPE=postgres plus MB_DB_HOST, MB_DB_PORT, MB_DB_USER, MB_DB_PASS, and MB_DB_DBNAME against the companion Postgres (ghcr.io/railwayapp-templates/postgres-ssl, 17 is fine). Set MB_ENCRYPTION_SECRET_KEY to at least 16 characters; openssl rand -base64 32 gives 44. Set MB_SITE_URL to the public HTTPS URL for links, embeds, and emails.

Implementation Details for Metabase Encryption Key (Using Metabase official docker image)

Pin a tag such as v0.63.x; the UI listens on port 3000 and GET /api/health gates deploys. Order matters: key first, then first boot (migrations plus the setup wizard), then data sources under Admin > Databases. Each connection you add after that is stored encrypted. Adding a key to an instance that already has data is a deliberate one-time step: current docs say Metabase won't start until you run the enable-encryption command with the key set, and it never encrypts old rows on its own.

How does Metabase Encryption Key compare against other self-hosted BI platforms

Every self-hosted BI tool stores warehouse credentials somewhere. What differs is the key, and how painful it is to rotate.

Metabase Encryption Key vs Metabase Cloud (Metabase Cloud Alternative)

Cloud manages the key and the app DB for you, which wins outright if nobody on the team wants to own secrets. Self-hosting wins when you need the app DB in your own infrastructure or simply want to skip per-user pricing.

Metabase Encryption Key vs Apache Superset (Apache Superset Alternative)

Superset encrypts saved credentials with its SECRET_KEY, and rotation works much like Metabase's: set PREVIOUS_SECRET_KEY, then run superset re-encrypt-secrets. Superset has more chart types; Metabase is one container and friendlier for non-SQL users.

Metabase Encryption Key vs Redash (Redash Alternative)

Redash (BSD-2) encrypts data source settings with REDASH_SECRET_KEY, falling back to the cookie secret if unset, and rotates with manage database reencrypt old new. It is a fine SQL runner, but Metabase has the query builder.

Metabase Encryption Key vs Lightdash (Lightdash Alternative)

Lightdash (MIT) needs a fixed LIGHTDASH_SECRET that encrypts data at rest; its docs warn that losing it locks you out of that data. Lightdash shines if dbt is your source of truth. Without dbt, Metabase is simpler.

How to use Metabase Encryption Key (the OSS Business Intelligence)?

Day to day the key is invisible. The work happens on the rare day you rotate it:

Back up the app DB with pg_dump.
Take Metabase offline so nothing writes mid-rotation.
With the current key set as MB_ENCRYPTION_SECRET_KEY, run the same Metabase version's rotate-encryption-key NEW_KEY against the app DB.
Update the Railway variable to the new key and redeploy.
Open a dashboard on each data source to confirm queries run.

Rotating to an empty string turns encryption off.

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

The pattern is identical anywhere Docker runs: one Metabase, one Postgres, one key you never lose.

Clone the Repository

There is nothing to clone; you pull the official image. If you keep a compose file in git, keep the key out of it. A key in git history is a key you have to rotate.

Install Dependencies

Install Docker and the Compose plugin, then pull metabase/metabase:v0.63.x and postgres:17. The image bundles its own Java runtime.

Configure Environment Variables

Put the MB_DB_* block, MB_ENCRYPTION_SECRET_KEY, and MB_SITE_URL in a .env outside the repo. Copy the key into a password manager now, not after the first incident.

Start the Metabase Encryption Key Application

Run docker compose up -d, wait for /api/health to return ok, then add data sources. Inside a container, localhost is the container itself, so point MB_DB_HOST at the Postgres service name.

Official Pricing of Metabase Encryption Key (Metabase Encryption Key pricing)

Metabase OSS is free under the AGPL, and the key costs nothing. You pay for compute and Postgres. Cloud Starter is about $85/month plus per-user fees; Pro adds SSO, row-level permissions, and interactive embedding.

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

Cloud hides the app DB, the key, and the upgrades. Self-hosting hands you all three plus the bill savings. If no one wants to own a secret, pick Cloud.

Monthly cost of self hosting Metabase Encryption Key on Railway

A small Metabase plus Postgres typically runs about $5-15/month on Hobby. Backups add a little storage and are worth every cent. The $5 GitHub trial covers a test deploy.

System Requirements for Hosting Metabase Encryption Key on a VPS

Give Metabase at least 1 GB RAM (2 GB is comfortable) and Postgres 512 MB plus a few GB of disk. Encryption overhead is negligible.

Frequently Asked Questions (FAQs)

What happens if I lose or change MB_ENCRYPTION_SECRET_KEY?

Metabase can't decrypt the stored connection details. Dashboards and questions survive, but each encrypted connection must be re-entered in Admin unless you recover the original key.

Can I rotate the key without downtime?

Not quite. Rotation runs with Metabase stopped, so plan a short maintenance window. With a backup taken first, it is a few minutes. Use the same Metabase version as the running instance so the CLI matches the app DB schema.

I already have data sources and no key. What now?

Back up, stop Metabase, run enable-encryption with the new key set, then start Metabase with that same key.

Do I need the key to restore a backup into a new Railway project?

Yes. Restore the dump and set the same key on the new Metabase service, or every connection breaks.

Should staging use the same key as production?

Use separate keys and separate app DBs. Only share a key if you plan to move dumps between them.

How long should the key be?

At least 16 characters. openssl rand -base64 32 is a good default.