Deploy and Host SlowBooks Pro on Railway

SlowBooks Pro 2026 is a full double-entry accounting system: customers and vendors, invoicing and payments, bills, banking, US payroll with tax tables, inventory, jobs and classes, and a report suite that includes profit and loss, balance sheet, trial balance, AR and AP aging, and printable PDFs. It is a source-available replacement for a desktop QuickBooks install, with no per-seat pricing, no transaction caps, and no vendor holding your ledger.

About Hosting SlowBooks Pro

The app is a FastAPI backend with a single-page frontend, served by uvicorn, backed by PostgreSQL. Upstream distributes it as a desktop app and a Docker Compose stack; this template runs the same container image on Railway, built from the upstream Dockerfile, next to a Railway PostgreSQL service with TLS enabled. Database migrations and the chart-of-accounts seed run automatically on every boot, so the instance is usable the moment the deploy turns green. Receipts, logos and other uploads live on a persistent volume; the database lives on its own volume.

Common Use Cases

A small business or contractor replacing a desktop QuickBooks install with something they host and own, reachable from any browser.
A bookkeeper running a private ledger per client, one Railway project each, with no per-seat license cost.
Invoicing with printable PDFs, customer statements, late fees and optional Stripe payment links, backed by real double-entry books rather than a spreadsheet.

Dependencies for SlowBooks Pro Hosting

PostgreSQL 17 with TLS, provisioned by this template.
A persistent volume for uploads and one for the database.

Deployment Dependencies

Upstream source: https://github.com/VonHoltenCodes/SlowBooks-Pro-2026
Upstream install docs: https://github.com/VonHoltenCodes/SlowBooks-Pro-2026/blob/main/INSTALL.md
Postgres image: ghcr.io/railwayapp-templates/postgres-ssl:17

Implementation Details

First boot. The build compiles the image from the upstream Dockerfile, which installs Cairo, Pango, Tesseract and Poppler for PDF and receipt handling. Expect four to seven minutes on the first deploy and well under a minute on later ones. On start, the container waits for PostgreSQL, runs Alembic migrations, then seeds a 57-account chart of accounts. That seed is idempotent, so redeploys never duplicate it.

First login. There are no default credentials to look up. Open the public URL and the app asks you to set an owner password on the spot, then logs you in. The default username for later multi-user work is admin. Set the password before sharing the URL: until it is set, anyone who reaches the instance can claim it.

Secrets that are generated for you. PAYROLL_ENCRYPTION_SECRET encrypts employee bank routing and account numbers at rest, and SESSION_SECRET_KEY signs login cookies. Both are generated per deployment. If you ever rotate the payroll secret, put the previous value in PAYROLL_ENCRYPTION_SECRET_PREV or existing bank details become unreadable. Do not set APP_DEBUG=true on a public instance: it disables the startup safety checks.

TLS settings. Railway's edge terminates HTTPS and its health prober runs before that, so FORCE_HTTPS is off in this template. An app-level HTTPS redirect would 301 the prober and every deploy would fail its healthcheck. SLOWBOOKS_PRIVATE_NETWORK=1 tells the app that its own hop is inside Railway's network, which is what lets it start with the redirect off. The connection to PostgreSQL is still encrypted, since DATABASE_URL carries sslmode=require against the TLS-enabled Postgres image.

Storage. The volume on the app service holds /app/app/static/uploads, which is where receipts, logos and attachments go. Compose upstream mounts a second volume at /app/backups; Railway allows one volume per service, so database backups you generate from the app are written to the container filesystem and should be downloaded right away. For durable backups, use the Postgres service's own backup features instead.

Company setup. COMPANY_NAME, DEFAULT_TERMS, DEFAULT_TAX_RATE, EMPLOYER_STATE, EMPLOYER_EIN and SUTA_RATE seed the invoice and payroll defaults, and all of them can be changed in the app afterwards.

Scaling. APP_WORKERS sets the number of uvicorn worker processes and defaults to 2. Raise it along with the service's memory if several people use the instance at once. Everything is one service, so scaling is vertical.

Troubleshooting. A deploy that stays unhealthy is almost always the database: check the Postgres service is up, since startup waits 30 seconds for pg_isready and then exits. If you change APP_PORT, change PORT and the public domain's target port to match, or the healthcheck will probe a port nothing is listening on.

Why Deploy SlowBooks Pro on Railway?

Railway gives this stack the two things a desktop accounting app cannot: a database with real durability and a URL that works from anywhere. The template wires the app to a TLS-enabled PostgreSQL service, mounts persistent volumes for both, generates the encryption and session secrets, and runs migrations on every deploy, so upgrading to a newer upstream commit is a redeploy rather than a maintenance window.