Deploy and Host Chatwoot on Railway

Chatwoot is an open-source customer engagement platform — a self-hosted alternative to Intercom, Zendesk and Freshdesk. It gives your team one shared inbox for live chat, email, WhatsApp, Instagram, Facebook, SMS, Telegram and API channels, with contact records, canned responses, labels, automations, macros, campaigns and reporting on top.

This template deploys Chatwoot v4.17.1 as three services — the Rails app with its Sidekiq worker in one container, PostgreSQL with pgvector, and Redis — and seeds the administrator account for you at deploy time.

About Hosting Chatwoot

A stock Chatwoot production deploy has no user account and no way to make one. Chatwoot creates its first user through POST /api/v1/accounts, which is registered only while public sign-ups are enabled; with sign-ups off the route raises a routing error and returns 404, and with sign-ups on the same route is open to any stranger who finds the URL. The seed data that creates a sample administrator runs in the development environment only. So a deployer either faces a login page they can never pass, or a public registration form on their own support desk.

This template closes that gap. On every boot, before the port opens, the entrypoint waits for Postgres, runs rails db:chatwoot_prepare (create, schema load, migrate) and then seeds a super administrator from CHATWOOT_ADMIN_EMAIL and CHATWOOT_ADMIN_PASSWORD, both generated per deploy. The password is re-applied on each boot, so a redeploy is a working password reset — useful because Chatwoot's own reset path is an emailed link, and a fresh deploy has no SMTP provider yet. Public sign-ups stay closed (ENABLE_ACCOUNT_SIGNUP=false), so POST /api/v1/accounts answers 404 to the internet while you log in normally.

Rails and Sidekiq run in one container on purpose. Chatwoot stores attachments on local disk by default, and Railway volumes cannot be shared between services — two services mounting the same path get two separate volumes. Split across a web service and a worker service, the worker writes uploads the web service cannot read. One container, one volume at /app/storage, and the entrypoint stops the container if Sidekiq dies rather than leaving a healthy-looking app whose background jobs are gone.

Postgres uses the pgvector image because Chatwoot's Captain AI features need the vector extension, and Redis persists with an append-only file so queued jobs survive a restart. Sizing: the app service is the memory-hungry one (~1–1.4 GB with the worker in-process), Postgres and Redis are small.

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.

You can actually log in — the administrator account is created during the deploy and its credentials are in your Railway variables, not behind a registration form that returns 404.
Nothing to fill in — every variable arrives with a generated value; the deploy form has no blank required fields.
Background jobs actually run — Sidekiq ships in the same container, so email notifications, campaigns, IMAP inboxes and automations work the day you deploy.
Attachments survive — one volume at /app/storage, held by the process that both writes and serves uploads.
Pinned, not floating — v4.17.1, so a redeploy is not an unrequested upgrade of an app that migrates its schema forward on boot.

Common Use Cases

Customer support inbox — a shared team inbox over live chat, email and WhatsApp, replacing a per-seat Intercom or Zendesk subscription.
Sales and lead capture — put the chat widget on your marketing site, route conversations to agents, and track contacts through their whole history.
Support for an internal or regulated product — self-host the transcripts and contact data on infrastructure you control instead of a third-party SaaS.

Dependencies for Chatwoot Hosting

PostgreSQL with pgvector (included in this template) on a volume at /var/lib/postgresql.
Redis (included) on a volume at /data, for the Sidekiq queues and the app cache.
An SMTP provider — Chatwoot needs outbound email for agent invitations, password resets and notifications. Set SMTP_ADDRESS, SMTP_PORT, SMTP_USERNAME, SMTP_PASSWORD and MAILER_SENDER_EMAIL on the chatwoot service after deploying.

Deployment Dependencies

Chatwoot — upstream customer engagement platform (MIT for the community edition)
Chatwoot self-hosted documentation — configuration and environment variable reference
chatwoot/chatwoot Docker image — the upstream image this template pins (v4.17.1-ce)
bon5co/chatwoot-railway — the open-source Railway wrapper image (Dockerfile + entrypoint) this template deploys

Implementation Details

After the deploy finishes, read CHATWOOT_ADMIN_EMAIL and CHATWOOT_ADMIN_PASSWORD from the chatwoot service's variables and sign in at your Railway domain. To change the password later, edit CHATWOOT_ADMIN_PASSWORD and redeploy — the entrypoint re-applies it. Chatwoot's password policy requires an upper-case letter, a lower-case letter, a digit and a special character.

Verify the stack is healthy at any time:

curl https:///api
# {"version":"4.17.1","timestamp":"...","queue_services":"ok","data_services":"ok"}

queue_services: ok means Redis and the worker path are wired, data_services: ok means Postgres is. Both are checked by the template's healthcheck on /api.

To add the chat widget to a site, create an Inbox of type Website in the dashboard and paste the generated script tag. To open public sign-ups, set ENABLE_ACCOUNT_SIGNUP=true on the chatwoot service. Attachments are stored on the app's volume by default; for larger installs point ACTIVE_STORAGE_SERVICE at S3 so uploads live in object storage instead.