Deploy and Host Apache Superset on Railway

Built for an LLM agent to deploy and use. The deploy form has nothing to fill in: the administrator password, the secret key and the database password are generated, the administrator account is created at first boot, and the metadata database that holds every dashboard, chart, dataset and saved query survives redeploys. Apache Superset is the open-source business intelligence and data exploration platform: it connects to your SQL databases, builds charts and dashboards, and runs SQL Lab queries.

About Hosting Apache Superset

This template runs two services on one public domain. superset is the upstream Apache Superset 6.1.0 image pinned by digest, with the Postgres driver the upstream image does not ship added. postgres is PostgreSQL 17 with a volume at /var/lib/postgresql, holding Superset's metadata: users, roles, databases, datasets, charts, dashboards and query history. Superset's default SQLite metadata database is not used, because it cannot be shared and does not survive a rebuilt container.

No default login. The administrator is the user admin, created at first boot from the generated ADMIN_PASSWORD; on every later boot the password is set back to the variable, so the variable stays the truth. The wrapper refuses to start with an empty or short password, and refuses to start with an empty or published-default SUPERSET_SECRET_KEY (Superset signs sessions and encrypts stored database connection passwords with it, so a generated key is kept stable across redeploys). Open registration is off.

What the wrapper fixes for Railway. It builds the metadata database URL from the postgres service's private host and password, waits for the database, runs superset db upgrade and superset init on every boot, listens on Railway's injected PORT, and trusts the edge proxy's forwarded headers so generated links use https.

Using it. Sign in at https://YOUR_DOMAIN/ with admin and ADMIN_PASSWORD, add a database under Settings, Database Connections (the data you want to analyse, reachable from Railway), create a dataset, then build charts and dashboards or run SQL in SQL Lab. The same works over the API.

Agent contract

Public URL: https://RAILWAY_PUBLIC_DOMAIN (the generated domain of the superset service)
Private URL: http://superset.railway.internal:8080
Credentials: the variable ADMIN_PASSWORD on the superset service (the password of the fixed user admin, which is not a template variable)
Auth: POST /api/v1/security/login with JSON username, password and provider set to db returns an access_token valid 15 minutes; every other /api/v1 call sends it as Authorization: Bearer TOKEN. A write also needs a CSRF token: GET /api/v1/security/csrf_token/ with the bearer token and a cookie jar, then send the result as X-CSRFToken with the same cookies and a Referer header. A request with no token answers 401.
Health: GET /health returns 200

#!/bin/sh
# needs: RAILWAY_PUBLIC_DOMAIN, ADMIN_PASSWORD (variables of the superset service); also curl.
R="https://$RAILWAY_PUBLIC_DOMAIN"; J="Content-Type: application/json"; B=$(mktemp); C=$(mktemp)
n=0; until [ "$(curl -s -o /dev/null -w '%{http_code}' "$R/health")" = 200 ]; do n=$((n+1)); [ "$n" -le 60 ] || break; sleep 5; done
curl -s -o /dev/null -w "health: %{http_code}\n" "$R/health"
# sign in as the admin user; the answer carries a bearer token (valid 15 minutes)
curl -s -o "$B" -w "login: %{http_code}\n" -H "$J" -d "{\"username\":\"admin\",\"password\":\"$ADMIN_PASSWORD\",\"provider\":\"db\"}" "$R/api/v1/security/login"
T=$(sed -n 's/.*"access_token":"\([^"]*\)".*/\1/p' "$B"); A="Authorization: Bearer $T"
curl -s -o /dev/null -w "read with token: %{http_code}\n" -H "$A" "$R/api/v1/dashboard/"
# writes need a CSRF token from the same session cookie, plus a Referer
X=$(curl -s -c "$C" -H "$A" "$R/api/v1/security/csrf_token/" | sed -n 's/.*"result":"\([^"]*\)".*/\1/p')
curl -s -b "$C" -o "$B" -w "write with token: %{http_code}\n" -H "$A" -H "$J" -H "X-CSRFToken: $X" -H "Referer: $R/" -d '{"dashboard_title":"railway-check"}' "$R/api/v1/dashboard/"
ID=$(sed -n 's/.*"id":\([0-9]*\).*/\1/p' "$B")
curl -s -H "$A" "$R/api/v1/dashboard/$ID" | grep -c '"railway-check"' | sed 's/^/dashboard found after write: /'
curl -s -b "$C" -o /dev/null -w "delete with token: %{http_code}\n" -X DELETE -H "$A" -H "X-CSRFToken: $X" -H "Referer: $R/" "$R/api/v1/dashboard/$ID"
curl -s -o /dev/null -w "read without token: %{http_code}\n" "$R/api/v1/dashboard/"
# no credential at all (a CSRF token is sent so the answer is the auth check, not the CSRF check)
curl -s -b "$C" -o /dev/null -w "write without key: %{http_code}\n" -H "$J" -H "X-CSRFToken: $X" -H "Referer: $R/" -d '{"dashboard_title":"anonymous"}' "$R/api/v1/dashboard/"
curl -s -b "$C" -o /dev/null -w "write wrong token: %{http_code}\n" -H "Authorization: Bearer wrong" -H "$J" -H "X-CSRFToken: $X" -H "Referer: $R/" -d '{"dashboard_title":"anonymous"}' "$R/api/v1/dashboard/"

A fresh deploy prints health: 200, login: 200, read with token: 200, write with token: 201, dashboard found after write: 1 and delete with token: 200. The refusals print read without token: 401, write without key: 401 and write wrong token: 422: a request with no token or a wrong one creates nothing.

Why Deploy Apache Superset 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 Apache Superset 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.

Agent-ready - generated secrets, a contract block and one script that proves health, sign-in, an authenticated write with CSRF, read-back and delete, and the refusal of a read and a write with no token or a wrong one.
No setup form and no default login - the administrator is created at boot from a generated password, and the secret key is generated, never the published default.
Data survives redeploys - Superset's metadata sits in a Postgres service on a volume, not in SQLite.
Works behind the Railway edge - the listen port follows PORT and proxy headers are trusted.
Pinned - the upstream image is pinned by digest and the wrapper by tag and digest.

Common Use Cases

Business intelligence dashboards - point Superset at a warehouse or application database and share dashboards without a SaaS BI licence.
SQL Lab for analysts - run, save and share SQL queries against any database Superset can connect to.
Embedded and scheduled analytics - build charts once and reuse them across dashboards, alerts and reports.
Dashboards driven by AI agents - an agent signs in, creates datasets and dashboards, and reads them back over the REST API.

Dependencies for Apache Superset Hosting

The superset and postgres services, created by the template. The databases you want to analyse are separate; you add each one to Superset as a database connection.

Deploy Superset | (Just Updated) Apache Superset BI Dashboards And SQL Lab With REST API, Admin Password Generated