
Deploy TrailBase | (Just Updated) Rust Firebase Alternative, Admin Login Set From Boot, Data Survives Redeploys
TrailBase backend, admin login set from boot, data on a volume
trailbase
Just deployed
/app/traildepot
Deploy and Host TrailBase on Railway
TrailBase is an open-source application server in a single Rust binary: SQLite with auth, record APIs, realtime subscriptions, file storage, an admin UI and WASM or JS extensions. It is the self-hosted alternative to Firebase or Supabase for apps that want one small process and one database file.
This template runs TrailBase as a single service from a digest-pinned official image: the API and admin UI on a Railway domain, an admin login whose password exists from the first boot, and the whole depot (database, uploads, config) on a Railway volume.
About Hosting TrailBase
TrailBase serves a REST and realtime API, authentication and an admin dashboard from one Rust process backed by SQLite. It runs as one container with its data on a Railway volume.
Why Deploy TrailBase on Railway
TrailBase on Railway needs a few things handled for you, and this template does them:
- The admin password is set from boot. On first start TrailBase creates
admin@localhostwith a random password and prints it once in the logs. This template starts the server privately, replaces that password with the generatedTRAILBASE_ADMIN_PASSWORDvariable, and only then opens the public port, so the printed default never works on your domain. The old default is refused (measured). - Data survives redeploys. The depot is the Railway volume at
/app/traildepot. A user registered before a redeploy was still there afterwards (measured). - The volume is writable. Railway mounts volumes owned by root while the image runs as an unprivileged user. The start command fixes the ownership and then drops privileges, and logs the result so the deploy log shows it.
- It passes the health check.
/api/healthcheckanswers on the port Railway injects, so the deploy goes healthy without a manual port setting. - Nothing to fill in. The deploy form has no required fields; the admin password is generated for you.
Common Use Cases
- Backend for a web or mobile app: auth, records and realtime without running several services
- Self-hosted Firebase or Supabase replacement for small projects and prototypes
- Internal tools that need a database, an admin UI and an API from one process
- A SQLite-backed API where the whole state is one volume you can back up
Dependencies for TrailBase Hosting
- One Railway volume for the depot (created by the template)
Deployment Dependencies
- TrailBase documentation: https://trailbase.io/documentation
- Official image: https://hub.docker.com/r/trailbase/trailbase
Implementation Details
| Variable | Purpose |
|---|---|
TRAILBASE_ADMIN_PASSWORD | Password of admin@localhost, generated per deploy. Re-applied on every boot. |
PUBLIC_URL | Public address of the service, for links in auth emails. |
TRAILBASE_PRIVATE_URL | Address for services in the same Railway project. |
Open https:///_/admin/ and sign in as admin@localhost with the value of
TRAILBASE_ADMIN_PASSWORD. Changing the variable and redeploying changes the password. If you
rename or delete the admin@localhost account, the start command leaves your accounts alone.
Template Content
trailbase
trailbase/trailbase:0.34.4RAILWAY_RUN_UID