Deploy and Host Multica on Railway

Multica is an open source issue tracker whose assignees can be AI coding agents. File an issue, assign it to Claude Code, Codex, Cursor, Copilot CLI, OpenCode, Qwen Code or one of a dozen more, and the agent picks up the work on a machine you control. This template runs the project's own prebuilt images, pinned to release v0.4.20, so a deploy takes about a minute instead of compiling a Go server and a Next.js app from source.

About Hosting Multica

Multica is three pieces: a Go API and live-updates server, a Next.js web app, and PostgreSQL with the vector extension. This template runs each as its own service and wires them together over Railway's private network.

The web service forwards API, sign-in, attachment and live-update traffic to the backend internally, so your browser only ever talks to one address. That choice is load bearing rather than cosmetic. Sign-in cookies cannot be scoped across two separate railway.app subdomains, so the alternative layout fails every write with a security error. Attachments are written to a disk attached to the API service, and the database keeps its own disk, so nothing is lost between deploys.

Everything is generated per deploy: the database password and the session signing key are both random and unique to your instance.

Common Use Cases

Running a private, self-hosted issue tracker where AI coding agents are first class assignees alongside humans.
Giving a small team one shared board that dispatches work to whichever agent each person has installed locally, without sending code through a vendor.
Keeping issue data, attachments and agent activity on infrastructure you control, for teams that cannot use the hosted version.

Dependencies for Multica Hosting

PostgreSQL 17 with the pgvector extension, included in this template.
The multica command line helper installed on each person's own machine, plus at least one AI agent on their path. The agents run locally, not on Railway.

Deployment Dependencies

Upstream project: https://github.com/multica-ai/multica
Self-hosting guide: https://github.com/multica-ai/multica/blob/main/SELF_HOSTING.md
Command line helper: brew install multica-ai/tap/multica

Implementation Details

Signing in the first time. Open the web address and enter your email. The app asks for a 6 digit code. Unless you supplied an email provider key, that code is printed to the API service's logs, on a line reading [DEV] Verification code for you@example.com: 123456. Open that service in Railway, read the logs, enter the code, and you are the first user.

To get codes by email instead, set RESEND_API_KEY and RESEND_FROM_EMAIL on the API service and redeploy. Full SMTP is supported too via SMTP_HOST, SMTP_PORT, SMTP_USERNAME, SMTP_PASSWORD and SMTP_FROM_EMAIL.

Lock it down once you are in. Signups are open by default so you can create your account. After that, set ALLOWED_EMAILS to your own address, or ALLOW_SIGNUP=false, or DISABLE_WORKSPACE_CREATION=true so new people can only join by invitation. Do not set MULTICA_DEV_VERIFICATION_CODE on a public instance: it makes one fixed code work forever for every account.

Connecting your machine. Install the helper and point it at your two addresses:

multica setup self-host --server-url https://YOUR-API-ADDRESS --app-url https://YOUR-WEB-ADDRESS

Then check Settings, then Runtimes in the web app. Your machine should appear.

Optional extras, all on the API service. Google sign-in via GOOGLE_CLIENT_ID, GOOGLE_CLIENT_SECRET and GOOGLE_REDIRECT_URI. GitHub via GITHUB_APP_SLUG and GITHUB_WEBHOOK_SECRET. Object storage instead of local disk via S3_BUCKET, S3_REGION and the matching credentials. Sign-in rate limiting by adding Redis and setting REDIS_URL.

Self-hosted Gitea, Forgejo or GitLab needs MULTICA_VCS_INTEGRATION_ENABLED=true plus MULTICA_VCS_SECRET_KEY, which must be exactly 32 random bytes in base64. Generate it with openssl rand -base64 32. It ships off because that format cannot be produced by a template generated value.

Expected first boot behaviour. The API service stays in Deploying for a couple of minutes while it runs database migrations, and does not answer its health check until they finish. Log lines reading "no email backend configured", "rate limiting disabled" and "vcs integration disabled" are all informational, and each corresponds to an optional feature above.

Limits worth knowing. One instance of each service. Attachments live on the API service's disk, so adding replicas means moving to object storage first. The database has no automatic backups. To upgrade, set both image tags to the same newer release and redeploy; migrations run on start, and the two tags must match.

Why Deploy Multica on Railway?

Railway gives this stack the two things it actually needs and would otherwise cost you an afternoon: a private network so the web app can reach the API and the database without any of it being exposed, and persistent disks so attachments and your database survive redeploys. Both public addresses come with TLS already terminated, which matters because the app refuses to mint correct callback and webhook URLs without a real HTTPS origin.

Because this template ships the project's official prebuilt images rather than building from a source checkout, a deploy is a container pull, not a Go and Node compile. Upgrading is a tag change on two services.