Deploy and Host Plane on Railway

Plane is an open-source project management tool — work items, cycles, modules, sub-projects and public roadmaps — and a self-hosted alternative to Jira and Linear. This template deploys the full production split that upstream recommends: eight application services, PostgreSQL, Valkey, RabbitMQ and managed object storage, wired to each other and reachable on one domain.

About Hosting Plane

Eleven services and a bucket, all from official upstream images, pinned to v1.4.1:

Proxy — Caddy, the only service with a domain. Plane is six HTTP apps sharing one origin by path, and Railway routes by service, so this is what puts them back together.
Web — the app itself. Space — public project boards. Admin — the instance console at /god-mode.
Live — collaborative page editing over WebSocket.
Api — Django and the REST API. Also runs the migration on boot, which is the job upstream gives to a one-shot migrator container that Railway has no equivalent for.
Worker and Beat — Celery. Notifications, webhooks, exports, and the daily cleanups.
Postgres — work items, projects, members and history, on a volume.
Valkey — cache, sessions and the live server's fan-out. Deliberately without a volume: nothing here is authoritative.
RabbitMQ — Celery's broker. Also without a volume; the queue is not a record of anything.
Bucket — Railway object storage for attachments, avatars and exports.

Every one of the 139 variables is filled in and described on the deploy screen. There is nothing you have to supply — open the URL, create your admin account, and the workspace is ready.

Four things this template does that are worth knowing about:

Uploads go to managed object storage, not to a MinIO container. Every other Plane template in this marketplace runs MinIO on a volume — a single-container object store holding all your attachments, that nobody backs up. Here they go to a Railway bucket. Getting that right took one measurement worth repeating: Railway's storage answers both S3 URL shapes, but only the host/bucket/key form sends CORS headers, so with the other one the browser silently refuses every upload and every image while curl reports 200. boto3 takes that choice from a config file rather than the environment, and this template writes it at boot.

The admin console does not send you to a dead port. Plane's web and admin images are static builds behind nginx, and nginx answers /god-mode with Location: http://your-host:3000/god-mode/ — a container-internal port that the browser then tries to open and hangs on. That is upstream issue #8814, open since March with two unmerged fixes. Both of them are four lines of nginx config, applied here at boot: the redirect comes back relative.

The background worker actually runs. RabbitMQ 4 refuses transient non-exclusive queues, and Celery's remote-control mailbox is exactly one of those — on a stock RabbitMQ 4 the worker cannot declare its queue and never executes a single job, while every service still reports healthy. Upstream and both competing templates avoid this by shipping RabbitMQ 3.13, which reached end of life in 2025. This template uses a supported broker and its own documented transition switch instead. Verified by creating a work item and watching the activity row the worker wrote for it.

The services can find each other. Every image here is Alpine, the private network is IPv6, and the frontend images listen on IPv4 only out of the box. Both halves of that are fixed in the template rather than discovered later, which is why the proxy reaches all five upstreams on the first deploy.

Common Use Cases

A Jira or Linear replacement you own: cycles, modules, work-item types and a backlog, with the data in your own database.
Public roadmaps and intake: publish a board to a URL so customers can follow progress or file requests without an account.
Docs next to the work: collaborative pages that several people edit at once, in the same workspace as the issues they describe.
A private workspace per client: one deployment per client, invited members only, nothing shared with a vendor.

Dependencies for Plane Hosting

Deployment Dependencies

Plane — the upstream project and its official images
PostgreSQL for work items, projects and membership
Valkey for cache, sessions and live-editing fan-out
RabbitMQ as Celery's broker
An S3-compatible bucket for attachments and exports

Implementation Details

First run is at /god-mode. Open the deployment, create the instance admin, and that account is also your first user. Authentication, SMTP, OAuth providers and whether new people may register are all edited there afterwards — the matching variables on the deploy screen are read once, on the very first boot, and stored in the database.
Signup is on by default, matching upstream. That means anyone who finds the URL can register. Turn it off in /god-mode → Authentication once your team has joined; changing the variable later does nothing.
Email is unconfigured, so invitations and notifications are queued and dropped. Add SMTP in /god-mode → Email to turn them on. Nothing crashes without it.
Migrations run in the API container, and the workers wait for them. On a cold deploy the API also waits for Postgres, Valkey and RabbitMQ before it starts — Railway starts services in parallel, so on a first deploy the race is the default rather than the exception.
FILE_SIZE_LIMIT is set in two places — on the API, which signs the upload, and on the proxy, which carries it. Raise both or uploads fail at whichever is lower.
The datastores are private. No public TCP proxy on Postgres, Valkey or RabbitMQ; they are reachable only from this project's private network.
Scaling is per service. The Worker is the one to add replicas to first; GUNICORN_WORKERS on the API is the second lever.

Resource Usage and Cost

Measured on an idle deployment: about 1.1 GB of RAM across all eleven services — the API, the worker and the scheduler are roughly 160–280 MB each, RabbitMQ about 140 MB, Postgres 50 MB at rest, the two nginx frontends under 5 MB — peaking around 1.6 GB while migrations and asset collection run on the first boot. Add 2 GB of volume and whatever the bucket holds. That is roughly $20–40/month for a small team, and it is a genuinely heavy stack: if you want the smallest possible Plane rather than the production topology, the all-in-one image is cheaper and this is not it.

Why Deploy Plane on Railway?

Plane in production is eight application processes, three stateful services and an object store, all of which have to agree on one public origin before the first work item exists. Railway gives it a private network between them, managed object storage that the browser can upload to directly, a domain with TLS, and a volume for the one service that actually needs one.

The alternative is a VM with a Compose file, where the certificates, the reverse-proxy path rules, the MinIO backups and the restart policy are all yours — and where the first thing you meet is an API container that exited because the database was not up yet.