Deploy and Host Multica on Railway

Multica is an open-source managed agents platform — it turns coding agents into teammates you assign work to, rather than tools you prompt one request at a time. Create tasks, route them to Claude Code, Codex, OpenClaw, or OpenCode, track progress, and build up reusable skills across a team. Think project management for human + agent teams, fully self-hosted.

This template deploys the three-tier stack: a Go backend, a Next.js frontend, and pgvector-enabled PostgreSQL.

What This Template Deploys

All three run on Railway's private network with credentials injected automatically. pgvector runs inside the same PostgreSQL instance, so there's no separate vector database to operate.

About Hosting Multica

One thing to understand before deploying: Multica on Railway is the control plane, not the execution environment. The server orchestrates tasks, stores state, and hosts the workspace UI — but agents run on machines you register as runtimes. Each team member installs the multica CLI locally, connects it to your Railway instance, and their machine appears under Settings → Runtimes.

That architecture is deliberate. Agents get real access to local repositories, tooling, and credentials without any of that being uploaded to a server. It also means a fresh deployment will sit idle until at least one runtime is registered — expected behaviour, not a broken install.

The other requirement is FRONTEND_ORIGIN. Multica's task updates stream over WebSockets, and for public deployments the backend must know your real frontend domain or the connection is refused. This is the most common failure on a hosted install: the UI loads, but nothing updates in real time.

Multica is fully open source, so you bring your own LLM provider, swap agent backends, and audit exactly how tasks are routed. Nothing leaves your infrastructure except the model calls your agents make.

Typical cost: ~$10–20/month on Railway across all three services, plus your LLM provider's usage. There is no per-seat licence for the self-hosted version.

How It Compares

Linear and Jira manage human work; raw agents execute but forget everything between sessions. Multica sits between them — a task layer where agent work is assigned, tracked, and compounds over time.

Deploy in Under 5 Minutes

1. Click Deploy on Railway — all three services build automatically (~4 minutes)
2. Set JWT_SECRET to a long random value (openssl rand -hex 32)
3. Set FRONTEND_ORIGIN to your frontend service's Railway domain — WebSockets fail without it
4. Open the frontend URL, register the first account, and create a workspace
5. Install the multica CLI on your machine and connect it — your runtime appears under Settings → Runtimes

Without a RESEND_API_KEY, verification codes won't be emailed. Retrieve them from the backend service logs in the Railway dashboard until you configure a verified sender.

Common Use Cases

• Agent task management for a team — assign work to coding agents the way you'd assign tickets, with progress visible to everyone
• Private AI teammates — persistent agents that work against your private repositories and internal tooling
• Security-sensitive agent work — code and credentials stay on registered local machines; the server holds only task state
• Compounding agent skills — reusable skills built once and applied across future tasks instead of re-prompting each session
• Multi-agent workflows — route different task types to Claude Code, Codex, OpenClaw, or OpenCode as suits the job
• Automated code review and testing — build specialised agents for review, test generation, or data processing pipelines

Configuration

FRONTEND_ORIGIN is not optional on a public deployment. Task updates stream over WebSockets, and the backend rejects connections from origins it doesn't recognise. If the UI loads but never updates live, this is why.

Agents run on registered runtimes, not on Railway. Install the multica CLI on each machine that should execute tasks. A deployment with no runtimes registered will accept tasks and never run them.

Dependencies for Multica Hosting

• Railway account — expect ~$10–20/month across the three services
• At least one machine running the multica CLI as a registered runtime
• An LLM provider account for whichever agent backend you use
• Optional: a Resend API key for emailed login codes
• Optional: Google OAuth credentials for social sign-in

Deployment Dependencies

• Multica GitHub Repository
• Multica Self-Host Quickstart
• Multica Self-Hosting Reference
• Railway Volumes Documentation

Implementation Details

The template runs Multica's official backend and frontend images against a pgvector/pgvector:pg17 PostgreSQL service — the same image combination used by Multica's own Docker Compose and Helm self-hosting paths, so behaviour matches the upstream project rather than a bespoke arrangement.

The Go backend handles the API, WebSocket streaming, and task orchestration; the Next.js frontend is the workspace UI. pgvector lives inside the primary PostgreSQL instance, providing long-term agent memory and semantic search without a fourth service.

Database migrations run automatically on backend startup, including the usage-rollup backfill, so a fresh install needs no operator intervention and the bundled pgvector image works unmodified. Usage and runtime dashboards read from a derived rollup table populated by an in-process scheduler on every backend replica.

Railway supplies automatic SSL and private networking between the three services. Persistent volumes hold agent logs and uploads across redeploys.

Frequently Asked Questions

Where do the agents actually run? On machines you register as runtimes, not on Railway. Each team member installs the multica CLI locally and connects it to your instance, so agents work against real local repositories and tooling.

Why does my deployment accept tasks but never run them? No runtime is registered. Install the CLI on at least one machine and check Settings → Runtimes to confirm it appears.

The UI loads but nothing updates live — why? FRONTEND_ORIGIN isn't set to your real frontend domain. WebSocket connections are refused from unrecognised origins, so task updates never stream.

Do I need Resend? No, but without it verification codes aren't emailed. Read them from the backend service logs in the Railway dashboard until you configure a verified sender.

Which coding agents are supported? Claude Code, Codex, OpenClaw, and OpenCode out of the box, with an extensible backend for adding others.

Why pgvector? Multica uses it for long-term agent memory and semantic search over past tasks. It runs inside the same PostgreSQL instance, so there's no extra service to operate.

Does my code leave my machine? No. Agents execute on registered runtimes, so repositories and credentials stay local. The server stores task metadata and coordination state.

Is the self-hosted version feature-limited? Multica is fully open source — self-host on your own infrastructure, bring your own LLM provider, and audit every line.

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 get a production-ready agent management layer without manual orchestration — Go backend, Next.js frontend, and pgvector PostgreSQL pre-wired over a private network, automatic SSL, and persistent volumes for logs and uploads. Assign work to your agents, keep your code on your own machines, and own the whole stack.