Deploy and Host Metabase on Railway

Metabase is an open-source business intelligence tool: connect a database, and anyone on the team can build dashboards, ask questions in a point-and-click editor or write SQL — without waiting on an analyst.

About Hosting Metabase

This template runs the official metabase/metabase image on a pinned stable tag, paired with a PostgreSQL 18 instance on a persistent Railway volume. Nothing is rebuilt or forked, so upstream releases and upstream security fixes are what you get.

The Postgres service is the part that matters. Metabase falls back to an embedded H2 file when no application database is configured, and on a platform with an ephemeral container filesystem that file disappears on every redeploy — dashboards, questions, users and permissions with it. Here Metabase is wired to Postgres from the first boot, so a redeploy is a redeploy and not a factory reset. That single detail is the most common defect in other Metabase templates, and it is worth checking for before you trust one.

Credentials for the data sources you connect are encrypted at rest with a key generated once at deploy time. Postgres itself is reachable only over Railway's private network and has no public endpoint.

Common Use Cases

Self-service dashboards: Give the team a place to answer their own questions instead of routing every metric through whoever writes SQL.
BI over your Railway databases: Point it at the Postgres, MySQL or ClickHouse already running in your project over the private network, with no egress and no public exposure.
Embedded analytics: Serve charts and dashboards inside your own product, on infrastructure you control and can put behind your own domain.

Dependencies for Metabase Hosting

Deployment Dependencies

Metabase 0.63 — the open-source edition
PostgreSQL 18 on a Railway volume — Metabase's own application database
A data source to analyse: any database Metabase supports, including ones running elsewhere in your Railway project

Implementation Details

MB_JETTY_HOST is set to ::. Railway's private network is IPv6-only, while healthchecks and the edge proxy arrive over IPv4; a JVM leaves the wildcard socket dual-stack, so one bind address covers both. The image's own default of 0.0.0.0 would make the container invisible to *.railway.internal.

PORT is set to 3000 even though Metabase never reads it — it reads MB_JETTY_PORT. Railway injects a PORT of its own and uses it to decide where to send traffic and healthchecks, so an app that ignores the variable has to be told the port explicitly. Without it every healthcheck attempt fails against a closed port while the server logs a perfectly healthy boot.

Postgres carries no healthcheck. Railway keeps the previous container running until a new one reports healthy, while Postgres holds an exclusive lock on its data directory — with both on the same volume that is a deadlock, and every redeploy would fail. The database is also the reason the volume is mounted at /var/lib/postgresql rather than deeper: the PostgreSQL 18 image places its cluster in /var/lib/postgresql/18/docker, a subdirectory, so initdb never trips over the lost+found entry Railway creates on a fresh volume.

MB_ENCRYPTION_SECRET_KEY encrypts the credentials of connected data sources inside the application database. It is generated once at deploy and must not be changed afterwards — rotating it makes every saved connection undecryptable, and Metabase only encrypts what is written after the key exists, which is why it is set from the very first boot rather than added later.

JAVA_OPTS caps the heap at 1 GB. Left alone the JVM sizes its heap from the container limit and a schema sync over a large warehouse walks into the memory ceiling instead of a GC pause. Raise it together with the service's memory, not on its own.

The first boot runs the full migration set against an empty database, which is why the healthcheck window is generous. After that Metabase 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.

Resources: around 2 GB RAM for Metabase and 512 MB for Postgres is a comfortable starting point, with a 1 GB volume that can be grown later without downtime. The JVM is the floor here — Metabase is not a service that idles cheaply, so size it for the memory rather than the traffic.