Deploy and Host Budibase on Railway

Built for an LLM agent to deploy and use. The deploy form has one generated field and nothing to fill in: the administrator password is generated, the first administrator is created at boot, the platform secrets are minted once on the volume, and applications, data and files survive redeploys. Budibase is an open-source, self-hosted low-code platform for building internal tools, forms, portals and automations on top of SQL databases, REST APIs and its own built-in database, with a public REST API.

About Hosting Budibase

This template runs one service, budibase, on one public domain with a volume at /data. It is the upstream all-in-one image: nginx, the app server, the worker, CouchDB, Redis, MinIO and the LiteLLM AI gateway with its own PostgreSQL run inside the container, so there is nothing else to wire. Apps, users, files and settings are stored on the volume. Budibase uses about 2.2 GiB of memory at rest, so choose a plan with at least 4 GB.

No sign-up race, no default login. Upstream's single image is usually deployed and then claimed by whoever opens the page first. This template creates the administrator admin@example.com at boot from the generated BB_ADMIN_USER_PASSWORD (32 characters), so the instance is never reachable unclaimed. The wrapper refuses to start without a password. The healthcheck is /health, which answers 200 only once the worker is running.

What the wrapper fixes for Railway. nginx is moved onto Railway's injected PORT (upstream listens on 80, so the healthcheck and the edge never reach it). AWS_REGION is set, because without it the app server crashes with Region is missing the first time an application is created, and every request until it restarts is a 502. The platform URL is derived from the public domain, so links in invitation and reset emails use https. Upstream is Budibase 4.0.0, pinned by digest. The free plan allows 2 applications; a license key lifts that.

Using it. Sign in at https://YOUR_DOMAIN/ as admin@example.com with BB_ADMIN_USER_PASSWORD. To send email, add SMTP settings under Settings, Email in the builder. External databases (PostgreSQL, MySQL, MongoDB and others) are added as data sources from inside an app.

Agent contract

Public URL: https://RAILWAY_PUBLIC_DOMAIN (the generated domain of the budibase service; the public REST API is under /api/public/v1)
Private URL: http://budibase.railway.internal:8080
Credentials: the variable BB_ADMIN_USER_PASSWORD on the budibase service, for the fixed email admin@example.com (the email is not a template variable)
Auth: sign in with POST /api/global/auth/default/login (JSON username and password, returns a session cookie), then POST /api/global/self/api_key with that cookie returns an apiKey, which the public API takes in the x-budibase-api-key header (each call mints a new key and invalidates the previous one). A write with no session answers 401, a write with a wrong key answers 401; the public API with no key header at all answers 400.
Health: GET /health returns 200 once the worker is up (a few minutes on the first boot, while CouchDB, MinIO and the app server start)

#!/bin/sh
# needs: RAILWAY_PUBLIC_DOMAIN, BB_ADMIN_USER_PASSWORD (variables of the budibase service); also curl. Creates one throwaway application and deletes it again (the free plan allows 2).
R="https://$RAILWAY_PUBLIC_DOMAIN"; J="Content-Type: application/json"
# first boot starts CouchDB, Redis, MinIO and the app server (a few minutes); wait for the worker
n=0; until [ "$(curl -s -o /dev/null -w '%{http_code}' "$R/health")" = 200 ]; do n=$((n+1)); [ "$n" -le 120 ] || break; sleep 5; done
curl -s -o /dev/null -w "health: %{http_code}\n" "$R/health"
curl -s -c jar.txt -o /dev/null -w "login: %{http_code}\n" -X POST "$R/api/global/auth/default/login" -H "$J" -d "{\"username\":\"admin@example.com\",\"password\":\"$BB_ADMIN_USER_PASSWORD\"}"
KEY=$(curl -s -b jar.txt -X POST "$R/api/global/self/api_key" -H "$J" -d '{}' | sed -n 's/.*"apiKey":"\([^"]*\)".*/\1/p')
H="x-budibase-api-key: $KEY"
curl -s -o /dev/null -w "read with key: %{http_code}\n" -X POST "$R/api/public/v1/applications/search" -H "$H" -H "$J" -d '{}'
NAME="agent$(date +%s)"
curl -s -X POST "$R/api/public/v1/applications" -H "$H" -H "$J" -d "{\"name\":\"$NAME\"}" -o app.json -w "write with key: %{http_code}\n"
APP=$(sed -n 's/.*"_id":"\([^"]*\)".*/\1/p' app.json)
curl -s -X POST "$R/api/public/v1/applications/search" -H "$H" -H "$J" -d '{}' | grep -c "$NAME" | sed 's/^/application found after write: /'
curl -s -o /dev/null -w "delete with key: %{http_code}\n" -X DELETE "$R/api/public/v1/applications/$APP" -H "$H"
curl -s -o /dev/null -w "write without key: %{http_code}\n" -X POST "$R/api/applications" -H "$J" -d '{"name":"anonymous"}'
curl -s -o /dev/null -w "write with wrong key: %{http_code}\n" -X POST "$R/api/public/v1/applications" -H "x-budibase-api-key: wrong-key" -H "$J" -d '{"name":"anonymous"}'

A fresh deploy prints health: 200, login: 200, read with key: 200, write with key: 200, application found after write: 1, delete with key: 200, write without key: 401 and write with wrong key: 401.

Why Deploy Budibase 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 Budibase 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 - one generated variable, a contract block and one script that proves the platform is up, an authenticated read, write and delete over the public REST API, and the refusal of a write with no session or a wrong key.
No sign-up race and no default login - the administrator is created at boot from a generated password.
Data survives redeploys - CouchDB, files, Redis and the generated platform secrets all sit on one volume.
Creating an app does not crash it - the missing region setting that takes the upstream single image down is set.
Pinned - the upstream image is pinned by digest and the wrapper by tag and digest.

Common Use Cases

Internal tools - admin panels, dashboards and CRUD apps over your PostgreSQL, MySQL or REST data.
Forms and approval workflows - intake forms, ticketing and multi-step approvals with automations.
Customer and partner portals - role-based portals on your own domain with your own data.
Agent-driven app building - give an agent the public REST API to create applications, tables and rows.

Dependencies for Budibase Hosting

The budibase service with its volume, created by the template. A custom domain and an SMTP account are optional.

Deploy Budibase | (Just Updated) Low-Code Internal Tools Builder With REST API, Admin Password Generated