The Chatwoot Railway template with 618 recent deploys ships without a background worker (here's what that silently breaks)

#selfhosted #railway #docker #opensource

If you've deployed Chatwoot (the open-source Intercom/Zendesk alternative) with a one-click Railway template, there's a good chance you got the popular one — the bare "Chatwoot" listing, 618 of the category's 750 recent deploys. It looks healthy. It serves the dashboard. And it silently never sends a notification email, never runs a campaign, never polls an IMAP inbox, and never fires an automation.

Here's why, and what to check if that's you right now.

Why it looks fine and isn't

Chatwoot's web process (rails/puma) only handles requests. Everything asynchronous — outbound email, scheduled campaigns, IMAP polling for email-channel inboxes, automation rules, webhooks — runs on Sidekiq, a separate worker process reading off Redis. Ship web + Postgres + Redis with no worker service, and there's nothing wrong at the HTTP layer: /api still returns 200, the UI still loads, agents can still reply to live-chat conversations. The failure is invisible until someone asks "why didn't the password reset email arrive" or "why hasn't this campaign sent in three days."

Quick way to check if this is you: open the Sidekiq admin at /rails/sidekiq (or just check whether you have a second service running bundle exec sidekiq). If there's no worker process anywhere in your deploy, none of the background jobs are running — full stop.

Two more things worth checking on the popular listing while you're in there:

2FA. Chatwoot.mfa_enabled? requires three ACTIVE_RECORD_ENCRYPTION_* keys to be set. Without them, the two-factor toggle in account settings is either missing or silently doesn't do anything, depending on version.

Sign-ups. ENABLE_ACCOUNT_SIGNUP defaults open in the stock image. On a public Railway domain, that means anyone who finds the URL can register an account on your instance unless you've explicitly turned it off.

None of this is a bug in Chatwoot — it's a bug in shipping the full stack minus one service and calling it done.

The template I maintain fixes this by default

Full disclosure up front: I maintain a Railway template for Chatwoot and get a kickback if you deploy through it. Here's what it actually does differently, checkably, not just as a claim:

Four services, not three: chatwoot (web), worker (bundle exec sidekiq -C config/sidekiq.yml, same image), postgres (pgvector-flavored — Chatwoot's Captain AI features run CREATE EXTENSION vector), redis.
2FA works out of the box — all three encryption keys generated per deploy as Railway secrets.
Sign-ups closed by default — ENABLE_ACCOUNT_SIGNUP=false baked into the image. You still create the first administrator normally at /installation/onboarding, strangers just can't self-register.
Zero blank required fields on the deploy form — every variable is either an auto-generated secret or a cross-service reference, so there's nothing to fill in to get a working instance.

Deploy link (disclosure: kickback applies): https://railway.com/deploy/chatwoot-or-intercom-alternative-sidekiq?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=inventory

If you'd rather not go through a referral link, the wrapper image is open source: ghcr.io/bon5co/chatwoot-railway (source at github.com/bon5co/chatwoot-railway), wraps stock chatwoot/chatwoot:v4.16.2-ce. Nothing in it is Railway-specific except the entrypoint waiting for Postgres/Redis over private-network DNS — the same four-service layout runs fine under docker-compose.

Honest caveats before you commit to it

Attachments and self-hosted storage. ACTIVE_STORAGE_SERVICE=local writes to each service's own disk. Railway volumes aren't shared between services, so a file the worker writes isn't visible to the web service's disk. Fine for chat transcripts stored in Postgres, not fine if you're relying on local file storage for attachments at any real scale — point ACTIVE_STORAGE_SERVICE at S3 (or a MinIO service) once you're past testing.
SMTP isn't included. Agent invitations and password resets need an outbound mail provider; that's a Railway limitation (no email sending built in), not something a template can bake in.
Cold start takes a few minutes. First boot runs rails db:chatwoot_prepare (creates + seeds the DB, migrates thereafter) before the health check passes — budget ~4 minutes, not seconds.
This doesn't beat the popular listing on deploy count, and it's not trying to. 618 of 750 recent deploys are on the one that's missing the worker — if you already have the popular listing deployed and just found this because something wasn't sending, the fix is adding a Sidekiq service pointed at your existing Postgres/Redis, not necessarily migrating.