Deploy and Host Metabase on Railway

Metabase is an open-source business intelligence tool: connect a database, and your team asks questions of it through a point-and-click query builder, saved charts and shared dashboards — no SQL required, though SQL is there when you want it. It's the self-hosted answer to Looker, Tableau or Mode, and this template deploys it with its own Postgres already attached.

About Hosting Metabase

Metabase keeps two kinds of data apart, and getting that distinction right is most of what hosting it involves. The application database stores your questions, dashboards, users and permissions. The data sources are the databases you actually analyse, which you connect from the admin UI after first login.

Out of the box Metabase uses an embedded H2 file for its application database. That is fine on a laptop and a liability on a server: H2 corrupts under container restarts and cannot be backed up cleanly. This template provisions a real Postgres instance and points Metabase at it through MB_DB_TYPE, MB_DB_HOST, MB_DB_PORT, MB_DB_USER, MB_DB_PASS and MB_DB_DBNAME, all referencing the Postgres service over Railway's private network. Your dashboards survive every redeploy.

First boot takes a few minutes while Metabase initialises its schema. That is normal and happens once.

Common Use Cases

Give non-technical teammates a way to answer their own data questions without writing SQL.
Build and share dashboards over a production Postgres, MySQL or BigQuery without buying per-seat BI licences.
Put a read-only analytics layer in front of an application database for support or ops staff.
Schedule a dashboard to arrive in Slack or email every Monday morning.
Keep business data on infrastructure you control rather than uploading extracts to a hosted BI vendor.

Dependencies for Metabase Hosting

Postgres — Metabase's own application database: questions, dashboards, users, permissions. Provisioned by this template with a volume.
At least one data source to analyse. Metabase ships with a sample dataset so you can look around immediately, but it is not useful until you connect your own database.
Network reachability to that data source. Another Railway Postgres in the same project connects over the private network; anything external needs to accept connections from Railway's IP range.

Implementation Details

The application database connection is assembled from Railway variable references rather than a hard-coded URL, so the Postgres password is generated at deploy time and never appears in the image or the repo.

MB_JETTY_HOST is set to bind all interfaces and MB_JETTY_PORT follows Railway's assigned PORT, which is what lets the public domain route to the container.

Metabase runs its own schema migrations at startup, so upgrading the image is just a redeploy.

After You Deploy

Open the public URL and create the first admin account — the first person to sign up owns the instance.
Connect a data source under Admin settings, Databases. For another service in the same Railway project, use its private domain and the internal port.
Invite your team, and set up groups and data permissions before you share anything sensitive.

Scaling and Cost

Metabase is a JVM application and is memory-hungry by nature: give it headroom rather than the smallest plan, particularly if several people run large queries at once. Query performance is almost always bound by the database being analysed rather than by Metabase itself, so caching frequently-viewed questions is usually a better lever than a bigger container.

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.