Deploy and Host Bytebase on Railway

Built for an LLM agent to deploy and use. The deploy form has nothing to fill in: the administrator password and the database password are generated, the administrator account is created at first boot, and the database that holds every project, instance, issue and review survives redeploys. Bytebase is the open-source database DevOps and schema change tool: it reviews SQL, runs approval workflows, rolls schema changes out across PostgreSQL, MySQL, Oracle, SQL Server and other databases, and keeps the history.

About Hosting Bytebase

This template runs two services on one public domain. bytebase is the upstream Bytebase 3.24.1 image pinned by digest. postgres is PostgreSQL 17 with a volume at /var/lib/postgresql, holding Bytebase's metadata: users, projects, instances, issues, SQL review policies and audit history. Bytebase's embedded database is not used, because upstream documents it as unsuitable for production.

No default login. The workspace administrator is admin@example.com, created at first boot from the generated ADMIN_PASSWORD. The wrapper refuses to start with an empty or short password. First boot also turns off Bytebase's anonymous usage-metrics report.

One limit, stated plainly. On the free plan Bytebase cannot turn self-service signup off (it is a paid-plan setting, measured: the settings API refuses it). Anyone who reaches the URL can still register an account. A self-registered account is a workspace member with no project or instance permissions, and it can see the user list. The administrator is created by the wrapper within seconds of the server answering, before a deployer has the URL, so nobody else can claim it first. If open registration is not acceptable, put the domain behind an access proxy or upgrade the plan and switch signup 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, listens on Railway's injected PORT, and sets the external URL from the generated domain so links, webhooks and the SQL review CI point at the right address.

Using it. Sign in at https://YOUR_DOMAIN/ with admin@example.com and ADMIN_PASSWORD, add an instance (the database you want to manage), create a project, then submit schema changes as issues. The same works over the API.

Agent contract

Public URL: https://RAILWAY_PUBLIC_DOMAIN (the generated domain of the bytebase service)
Private URL: http://bytebase.railway.internal:8080
Credentials: the variable ADMIN_PASSWORD on the bytebase service (the password of the fixed user admin@example.com, which is not a template variable)
Auth: POST /v1/auth/login with JSON email and password returns a bearer token valid for one hour; every other /v1 call sends it as Authorization: Bearer TOKEN. A request with no token or a wrong one answers 401.
Health: GET /healthz returns 200

#!/bin/sh
# needs: RAILWAY_PUBLIC_DOMAIN, ADMIN_PASSWORD (variables of the bytebase service); also curl.
R="https://$RAILWAY_PUBLIC_DOMAIN"; J="Content-Type: application/json"; B=$(mktemp)
n=0; until [ "$(curl -s -o /dev/null -w '%{http_code}' "$R/healthz")" = 200 ]; do n=$((n+1)); [ "$n" -le 60 ] || break; sleep 5; done
curl -s -o /dev/null -w "health: %{http_code}\n" "$R/healthz"
# sign in as the fixed workspace admin admin@example.com; the answer carries a bearer token (valid one hour)
curl -s -o "$B" -w "login: %{http_code}\n" -H "$J" -d "{\"email\":\"admin@example.com\",\"password\":\"$ADMIN_PASSWORD\"}" "$R/v1/auth/login"
T=$(sed -n 's/.*"token":"\([^"]*\)".*/\1/p' "$B"); A="Authorization: Bearer $T"
curl -s -o /dev/null -w "read with token: %{http_code}\n" -H "$A" "$R/v1/projects"
curl -s -o /dev/null -w "write with token: %{http_code}\n" -H "$A" -H "$J" -d '{"title":"railway-check"}' "$R/v1/projects?projectId=railway-check"
curl -s -H "$A" "$R/v1/projects" | grep -c '"projects/railway-check"' | sed 's/^/project found after write: /'
curl -s -o /dev/null -w "delete with token: %{http_code}\n" -X DELETE -H "$A" "$R/v1/projects/railway-check?force=true"
curl -s -o /dev/null -w "read without token: %{http_code}\n" "$R/v1/projects"
curl -s -o /dev/null -w "write without key: %{http_code}\n" -H "$J" -d '{"title":"anonymous"}' "$R/v1/projects?projectId=anonymous"
curl -s -o /dev/null -w "write wrong token: %{http_code}\n" -H "Authorization: Bearer wrong" -H "$J" -d '{"title":"anonymous"}' "$R/v1/projects?projectId=anonymous"

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

Why Deploy Bytebase 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 Bytebase 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, 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.
Data survives redeploys - Bytebase's metadata sits in a Postgres service on a volume, not in an embedded database.
Works behind the Railway edge - the listen port follows PORT and the external URL is set from the generated domain.
Pinned - the upstream image is pinned by digest and the wrapper by tag and digest.

Common Use Cases

SQL review before production - lint every schema change against rules, and block risky statements before they run.
Approval workflows for schema changes - route a change through reviewers, then roll it out across dev, staging and production databases in order.
Database change history and audit - keep who changed what and when, with drift detection against the expected schema.
Database change automation for AI agents - an agent signs in, creates projects and issues, and reads rollout status over the REST API.

Dependencies for Bytebase Hosting

The bytebase and postgres services, created by the template. The databases you want to manage are separate; you add each one to Bytebase as an instance.

Deploy Bytebase | (Just Updated) Database Schema Change And SQL Review Tool With REST API, Admin Password Generated