Deploy and Host Discourse on Railway

Discourse is the leading open-source community forum platform — threaded discussions, trust levels, moderation tooling, and full-text search, powering communities for Rust, Netlify, and thousands of others. Unlike Discord, where conversations vanish into an endless scroll, Discourse produces organised, searchable, permanent threads. Unlike Reddit, you own the data and set the rules.

This template deploys the full four-service stack: Discourse, a Sidekiq background worker, PostgreSQL, and Redis.

What This Template Deploys

All four run on Railway's private network. Only Discourse is exposed publicly, and a persistent volume holds uploads and generated assets.

About Hosting Discourse

Discourse is a Ruby on Rails application, and hosting Rails properly means running more than one process. The web app serves requests; a separate Sidekiq worker handles everything asynchronous — sending registration emails, delivering notifications, optimising uploaded images, and running scheduled maintenance jobs.

That worker is not optional. Deploy Discourse without Sidekiq and the forum appears to work while silently doing nothing in the background: nobody receives a registration email, notifications never arrive, and uploaded images never finish processing. This template runs Sidekiq as its own service, connected to the same database and Redis instance, so background work actually happens.

The second non-negotiable is SMTP. Discourse requires a working mail provider before anyone — including you — can complete registration, because account activation runs by email. Configure Mailgun, SendGrid, Postmark, or similar before your first deploy.

Discourse is also genuinely resource-hungry. Rails plus Sidekiq plus Postgres idles around 1.4–1.8 GB of RAM and climbs during image processing and database migrations. Budget 2 GB minimum and 4 GB for a comfortable production forum.

Typical cost: ~$25–45/month on Railway across all four services, depending on RAM and storage. Discourse's own hosted plans start considerably higher, so self-hosting pays off quickly — and your community's data stays yours.

How It Compares

Discord wins on real-time chat and zero setup. Discourse wins when you want discussions that persist, rank in search, and belong to you — the difference between a conversation and a knowledge base.

Deploy in Under 5 Minutes

1. Click Deploy on Railway — all four services build automatically (~5 minutes)
2. Set DISCOURSE_HOST to your Railway public domain
3. Configure the DISCOURSE_SMTP_* variables with your mail provider's credentials
4. Set DISCOURSE_USERNAME, DISCOURSE_PASSWORD, and DISCOURSE_EMAIL for the admin account
5. Open your domain, sign in as admin, and run the setup wizard to name your community

Confirm Sidekiq is running before inviting users — check Admin → Dashboard for background job health.

Common Use Cases

• Product or open-source community — a searchable support forum where answers stay findable instead of scrolling away
• Discord replacement for lasting discussion — keep real-time chat elsewhere and give long-form conversation a permanent home
• Customer support knowledge base — user questions become indexed content that answers the next person automatically
• Paid or private community — invite-only forums with trust levels and granular moderation controls
• Internal team discussion — asynchronous, threaded conversation for distributed teams that outgrew a chat channel
• SEO-driven community content — public threads are crawlable and rank, unlike closed platforms

Configuration

SMTP is mandatory, not optional. Discourse activates accounts by email. Without working SMTP, no one can register — including your own admin account.

Sidekiq must stay running. If the worker service stops, the forum keeps serving pages while every background job silently queues forever. Check Admin → Dashboard for job health.

Dependencies for Discourse Hosting

• Railway account — expect ~$25–45/month across all four services
• An SMTP provider (Mailgun, SendGrid, Postmark, or similar) — strictly required
• A persistent Railway volume for uploads and assets (included)
• Optional: S3-compatible object storage for uploads on larger communities

Deployment Dependencies

• Discourse GitHub Repository
• Discourse Meta (Community Support)
• Discourse Install Documentation
• Railway Volumes Documentation

Implementation Details

Discourse's official installation uses the discourse_docker launcher, which builds a bespoke image per site — a pattern designed for a dedicated VPS rather than a container platform. This template instead uses a runnable Discourse image that supports external PostgreSQL and Redis through DISCOURSE_DATABASE_HOST and DISCOURSE_REDIS_HOST, which is what makes a managed-service deployment on Railway possible.

The web application and the Sidekiq worker run as two services from the same image with the same environment, differing only in start command — the worker launches Sidekiq directly. Both connect to the shared PostgreSQL and Redis services over Railway's private network, and both mount the shared data volume so uploads written by one are visible to the other.

Redis serves double duty as Sidekiq's job queue and as Discourse's cache, which is why it is a hard dependency rather than an optimisation. PostgreSQL holds all forum content; that database is your community, so schedule pg_dump backups accordingly.

Frequently Asked Questions

Why is there a separate Sidekiq service? Discourse offloads email, notifications, image processing, and scheduled jobs to a background worker. Without it the forum renders pages normally but performs no background work at all — the most common broken self-hosted Discourse setup.

Do I really need SMTP? Yes. Account activation runs by email, so without a working mail provider nobody can complete registration, including the admin account. Configure it before your first deploy.

How much RAM does it need? 2 GB is the practical minimum and 4 GB is comfortable for production. Rails and Sidekiq together idle around 1.4–1.8 GB and spike during image processing and migrations.

Why not use the official Discourse installer? The official ./launcher bootstrap flow builds a custom image on a dedicated host — it assumes a VPS you SSH into, not a managed container platform. This template uses a runnable image with external database support instead.

Do uploads survive a redeploy? Yes, on the mounted volume. For larger communities, configure S3-compatible object storage so uploads don't grow the volume indefinitely.

Is this cheaper than Discourse's hosted plans? Usually, yes — flat Railway infrastructure versus per-plan hosted pricing. You trade that saving for running upgrades, backups, and SMTP yourself.

Can I install plugins and themes? Themes and components install from the admin panel normally. Plugins requiring a rebuild are more involved on a container platform than with the official launcher, since they're compiled into the image.

Why Deploy Discourse 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 Discourse on Railway you get a complete community forum with the pieces that usually get forgotten — a real Sidekiq worker, PostgreSQL, Redis, private networking, automatic HTTPS, and a persistent volume for uploads. Own your community's archive, rank in search, and keep every discussion on infrastructure you control.