Deploy and Host Chatwoot on Railway

Chatwoot, the open-source customer support desk, self-hosted as five pieces: the web app, a separate Sidekiq worker, Postgres with pgvector, Valkey and a Railway Bucket for files. Every image is pinned.

Nothing to fill in. Open the domain and create the first admin account.

About Hosting Chatwoot

Chatwoot is a Rails app with a Sidekiq worker next to it. Here they run as two services on the same official image:

Chatwoot: Puma serving the dashboard, the API and the live-chat widget (public)
Sidekiq: the background jobs: outgoing email, channel webhooks, attachments, scheduled tasks (private)
Postgres 16 with pgvector, on its own volume
Valkey, the Redis-compatible queue and cache, on its own volume with append-only persistence
Bucket: Railway object storage for every uploaded and downloaded file

The database is prepared before the web app takes traffic: the pre-deploy step waits for Postgres and runs db:chatwoot_prepare, which creates the schema on the first deploy and migrates it on later ones.

Common Use Cases

Live chat on your website with a shared inbox for the whole team.
One inbox for email, WhatsApp, Telegram, Facebook and Instagram, connected through each platform's official API.
A self-hosted alternative to Intercom or Zendesk, with conversations stored in your own database.

Dependencies for Chatwoot Hosting

Deployment Dependencies

Chatwoot chatwoot/chatwoot:v4.18.0-ce, the web app (public) and the Sidekiq worker (private)
Postgres pgvector/pgvector:0.8.7-pg16
Valkey valkey/valkey:8.1.10-alpine
A Railway Bucket
Chatwoot, by Chatwoot Inc., MIT for the community edition. This template only configures their published image.

Implementation Details

Web and worker are separate services. Packing Rails and Sidekiq into one container needs about 0.8 GB at idle, more than the 0.5 GB a service gets on the Free plan, and that container fails to start there. Split, each process stays under 0.5 GB.
sidekiq_alive is switched off. Chatwoot ships a Kubernetes liveness probe that forks a full second copy of the worker. On Railway it is not needed, and it alone takes the worker from about 0.33 GB to 0.49 GB.
Files live in a Bucket, not on a volume. Railway volumes belong to one service, and the worker writes files itself: attachments that arrive through channels, contact avatars. On a local disk the worker would save them where the web app cannot read them. With the bucket, both services see the same files; the web app hands out short-lived signed links to them.
Puma's pid file goes to /tmp. The image has no tmp/pids directory, and Puma started directly (rather than through rails s) fails on it.
Sign-up is closed. ENABLE_ACCOUNT_SIGNUP=false: the first account is created through the onboarding page, and nobody else can register on a public domain.

Configuration

SECRET_KEY_BASE, the Postgres password and the Valkey password are generated. The worker takes the secret and the frontend URL from the web service by reference, so the two always match. FRONTEND_URL follows the public domain.

To send email, add the SMTP_* and MAILER_SENDER_EMAIL variables from Chatwoot's documentation to both Chatwoot and Sidekiq.

Two Rails processes need about 0.9 GB together. That deploys on the Free plan, but its monthly credit runs out within days; for a support desk that stays up, use a paid plan.

Verification

Deployed from this template into an empty project, all services starting at once on fresh volumes: every service came up in under three minutes, the pre-deploy step created the schema, and /api reports queue_services: ok and data_services: ok, which Chatwoot only returns when both Postgres and Valkey answer. The web app and the worker resolve the same secret and the same bucket.

Redeployed with each of the web app and the worker capped at the Free plan's 0.5 GB and 1 vCPU, both stayed up without restarts. Under the same cap, the single-container packaging fails to start.

Locally, on the same image with the same variables and a real Railway Bucket: onboarding, sign-in, a file written by a separate process and served by the web app through a signed link, and a batch of avatar jobs processed by the worker, all within a 512 MB limit per container. The onboarding flow was not driven on the Railway deployment itself.

Why Deploy Chatwoot 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 Chatwoot 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.