Deploy Metabase v0.63 | Open Source BI, Encrypted Credentials + Tuned JVM

Deploy and Host Metabase on Railway

Metabase is the open-source BI tool that lets anyone on your team ask questions of your data and build dashboards without writing SQL — the self-hosted alternative to Looker, Tableau and Power BI. This template runs the pinned v0.63.2.7 release with its own PostgreSQL application database on a volume, and it deploys with an empty form: every value is filled in for you.

Three things it does that the other Metabase listings on this marketplace do not:

• Your data-source credentials are encrypted at rest. MB_ENCRYPTION_SECRET_KEY is generated per deploy. Metabase stores the password for every warehouse you connect — Postgres, MySQL, Snowflake, BigQuery service-account JSON — inside its own application database. Without that key they are stored in plaintext. Checked on 2026-08-01: none of the five Metabase listings holding 271 of this category's 283 recent deploys sets it. It has to be right on the first deploy, because Metabase encrypts credentials when they are written — anything saved before the key exists stays readable.
• The version is pinned. Everyone else ships metabase/metabase:latest. Metabase's application-database migrations run one way; with a floating tag an ordinary redeploy can migrate your app DB onto a new major with no supported way back.
• The JVM gets the RAM you are paying for. Java defaults to a heap of 25% of the container limit. Measured on Railway: 1.86 GiB by default against 5.22 GiB with this template's -XX:MaxRAMPercentage=70. Metabase's own launcher sets -XX:+CrashOnOutOfMemoryError, so a dashboard that outgrows the heap does not get slower — it kills the container.

About Hosting Metabase

Metabase is a Clojure/JVM application. It keeps its own state — users, dashboards, questions, permissions and saved data-source credentials — in an application database, separate from whatever data you point it at. It ships with an embedded H2 file so it can start with no configuration, and that default is the most common way a self-hosted Metabase is lost: H2 writes to the container filesystem, so on a platform that replaces containers on every deploy it takes your dashboards with it.

Running it properly means giving it a real PostgreSQL app DB on persistent storage, sizing the JVM heap for the container it runs in, and setting an encryption key before any warehouse credential is saved. This template does all three. Railway provisions two services — Metabase and a PostgreSQL 17 app DB with a volume attached — wires the connection over Railway's private network, generates the encryption key and session secrets, and gives Metabase a public HTTPS domain. First boot runs the schema migrations and takes about a minute (41 s measured); after that the container starts in seconds.

Why Deploy Metabase on Railway?

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 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.

Metabase specifically benefits: the app DB lives on a Railway volume rather than an ephemeral H2 file, the private network keeps that database off the public internet, and the heap scales with whatever plan you move to because it is expressed as a percentage rather than a fixed -Xmx.

Common Use Cases

• Self-hosted business intelligence — dashboards and SQL questions over your production database, without handing it to a third-party SaaS
• A shared metrics layer for a team that does not write SQL, using the query builder
• Scheduled email or Slack digests of key numbers via dashboard subscriptions
• Embedding charts in an internal tool or a customer-facing app
• Replacing a Looker or Tableau per-seat bill on a small team

Dependencies for Metabase Hosting

• PostgreSQL 17 — Metabase's application database (included in this template, on a volume)
• A JVM runtime — included in the image
• One or more databases of your own to connect and analyse

Deployment Dependencies

• Metabase GitHub repository — upstream project (AGPL-3.0 for the open-source edition)
• Metabase documentation
• Environment variable reference
• Wrapper image source — ghcr.io/bon5co/metabase-railway, built from metabase/metabase:v0.63.2.7

Environment Variables

Every one of these is filled in automatically. Nothing is required from you at deploy time.

Baked into the image, overridable from the Railway variables panel: MB_DB_TYPE=postgres, MB_DB_USER=postgres, MB_DB_DBNAME=postgres, MB_DB_PORT=5432, MB_JETTY_HOST=::, MB_ANON_TRACKING_ENABLED=false, MB_PASSWORD_COMPLEXITY=strong, JAVA_TIMEZONE=UTC, and JAVA_OPTS=-XX:MaxRAMPercentage=70 (your own JAVA_OPTS with -Xmx or MaxRAMPercentage wins).

Implementation Details

Two services on Railway's private network:

Watch first-boot readiness at:

curl https:///api/health

{"status":"ok"} means migrations finished and the app DB is connected.

After deploying

1. Open the public domain and complete the setup wizard — the first account you create is the admin. There are no default credentials.
2. Connect your data sources from Admin settings → Databases. Credentials saved from here on are encrypted with the generated key.
3. The bundled PostgreSQL service is Metabase's own storage. It is not the data you analyse, and there is no reason to point Metabase at it.

Persistence and upgrades

The PostgreSQL service mounts a volume at /var/lib/postgresql, so dashboards, questions and users survive redeploys. To move to a newer Metabase, change the image tag on the Metabase service — take a backup first, because the app-DB migration that runs on the next boot is not reversible.