---
title: "Deploy Metabase Encryption Key"
description: "stable MB_ENCRYPTION_SECRET_KEY on Railway"
category: "Analytics"
url: https://railway.com/deploy/metabase-encryption-key
---

# Deploy Metabase Encryption Key

stable MB_ENCRYPTION_SECRET_KEY on Railway

**[Deploy Metabase Encryption Key on Railway](https://railway.com/template/metabase-encryption-key)**

Machine-readable deploy manifest (JSON, validated by TemplateCI): https://railway.com/deploy/metabase-encryption-key/manifest.json

- **Creator:** onepush
- **Category:** Analytics

## Template content

### Postgres https://devicons.railway.app/i/postgresql.svg

- **Image:** ghcr.io/railwayapp-templates/postgres-ssl:18

### metabase/metabase

- **Image:** metabase/metabase
- **Public domain:** Yes

## Documentation

# 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:

1. Back up the app DB with `pg_dump`.
2. Take Metabase offline so nothing writes mid-rotation.
3. 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.
4. Update the Railway variable to the new key and redeploy.
5. 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.


## Similar templates

- [Typesense PHP](https://railway.com/deploy/typesense-php) — official PHP client against Railway
- [Typesense vs Meilisearch](https://railway.com/deploy/typesense-vs-meilisearch) — self-hosted Typesense vs Meilisearch
- [Matomo Analytics + MariaDB](https://railway.com/deploy/matomo-analytics-mariadb) — Privacy-friendly analytics with MariaDB and persistent volumes.

Open this page in a browser: https://railway.com/deploy/metabase-encryption-key