Deploy and Host Multica on Railway

Multica is an open-source issue tracker whose assignees can be coding agents. You file an issue, assign it to Claude Code, Codex, Cursor or any of twenty other agent CLIs, and it picks the work up, opens a pull request and reports back on the issue — the same loop you already run with human teammates.

About Hosting Multica

This template runs the full self-hosted control plane from the images the Multica team publishes to GHCR, pinned to an exact release. Nothing is built from source, so a deploy takes as long as a pull and a redeploy gives you back the version you were already running rather than whatever landed upstream this morning.

Four services and one bucket:

multica-api — the Go API and WebSocket server. Applies its database migrations on boot, waiting for PostgreSQL first so a cold project does not race itself.
multica-web — the Next.js application. It is the only host your browser talks to: it proxies /api, /auth, /uploads and /ws to the API over Railway's private network, which keeps the session cookie same-origin and avoids an upstream bug where split-origin deployments save a 401 body instead of your attachment.
Postgres — PostgreSQL 17 with the pgvector extension, on a persistent volume.
Valkey — a Redis-compatible cache. It is what enables Multica's per-IP rate limiting on the login endpoints; without it the middleware is a no-op and POST /auth/send-code is unmetered, which is both a brute-force surface and an open relay for mailing strangers. It also carries realtime fan-out, so you can scale the API past one replica.
Attachments bucket — Railway object storage, addressed path-style so presigned URLs work from a browser. Issue attachments and avatars live here rather than on a disk attached to the API, which keeps the application tier stateless.

The agents themselves do not run on Railway. Each person who wants to run one installs the multica CLI on their own machine, and the daemon there executes the work with their own agent credentials. What you are hosting is the tracker, the realtime layer and the coordination — not the compute.

Common Use Cases

A backlog your agents can work from: file issues the way you always have, and assign the mechanical ones to an agent instead of a person.
Keeping agent work off third-party servers: the tracker is yours, the repository connection is yours, and the agent runs on hardware you control.
Self-hosted Git shops: Forgejo, Gitea and GitLab integration is switched on and keyed in this template, so a repository that never touches github.com still works.

Dependencies for Multica Hosting

Deployment Dependencies

Multica — the upstream project, AGPL-licensed.
ghcr.io/multica-ai/multica-backend and multica-web — the official images.
pgvector — PostgreSQL 17 with vector search.
Valkey — the Redis fork used for rate limiting and realtime fan-out.
The multica CLI, installed on each machine that will run agents.

Implementation Details

Logging in the first time. No mail provider is configured out of the box, so the six-digit login code is printed to the multica-api service log. Open that service in Railway, enter your email on the login page, and read the line beginning [DEV] Verification code for. To get real emails instead, set RESEND_API_KEY, or fill in the SMTP_* variables — SMTP takes priority whenever SMTP_HOST is non-empty.

Lock the door behind you. ALLOW_SIGNUP ships as true so you can create that first account. Once you are in, set ALLOWED_EMAILS to a comma-separated list of the people who belong there, or set ALLOW_SIGNUP to false outright, and redeploy the API.

Connecting your machine. Install the CLI, then run it against this deployment:

multica setup self-host \
  --server-url https:// \
  --app-url    https://

The API's own domain is already published to the app as MULTICA_PUBLIC_URL, so Settings → Runtimes shows you the exact command with the URLs filled in.

Rate limits. RATE_LIMIT_AUTH (20/minute) and RATE_LIMIT_AUTH_VERIFY (60/minute) govern the login endpoints. Railway puts a CDN in front of your service, so the limiter's bucket is regional rather than per-visitor; the values are raised from upstream's 5 and 20 to account for that. On a small instance, setting them back to 5 and 20 is meaningfully tighter.

Integrations. Slack, self-hosted Git (Forgejo / Gitea / GitLab) and remote MCP plugin credentials each get their own generated at-rest encryption key, so those settings tabs work without any further setup. Lark/Feishu and WeCom are left off — set MULTICA_LARK_SECRET_KEY or MULTICA_WECOM_SECRET_KEY to a base64-encoded 32-byte key to enable them. Google sign-in needs GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET; the redirect URI is already pointed at your web domain.

Resources and cost. Measured on this template's own deployment: about 390 MB across the four services at rest, peaking near 510 MB during a deploy — roughly 265 MB of that is the Next.js frontend, 100 MB PostgreSQL, 35 MB the Go API and 5 MB Valkey. Expect somewhere around $10–15 a month at Railway's usage pricing, plus the volume and bucket. It climbs with the number of people connected over WebSocket and with how much your agents write back, but the agent execution itself bills to the machines running the daemon, not to this project.

Upgrading. The image tags are pinned deliberately. To move to a newer Multica release, change MULTICA_IMAGE_TAG-style values — the image field on multica-api and multica-web — to the same new vX.Y.Z on both services, and redeploy the API first so migrations run before the new frontend loads.

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