Running a Multica agent runtime on Render

Multica runs coding agents on a "computer" that you register with it: a machine running the Multica daemon plus an agent CLI. Usually that is a developer laptop. multica-runtime packages the daemon and Claude Code into one Docker image so the same runtime can live on Render instead.

Why a background worker

The daemon only makes outbound connections. It has no port to expose, no URL and no health check. That makes it a fit for a Render background worker rather than a web service, and the included render.yaml Blueprint sets it up that way.

What is in the repo

The repo is small on purpose:

• Dockerfile starts from node:22-bookworm and installs the Multica CLI and Claude Code.
• entrypoint.sh logs in with a token, then runs multica daemon start --foreground, with daemon logs forwarded to stdout so they show up in Render's log view.
• A GitHub Actions workflow builds the image on every push to main and tags it :latest and with the commit SHA. It also smoke-tests the binaries in the image.
• render.yaml is the Render Blueprint for the worker.

Deploying is three steps: push to main, make the container package pullable by Render, and create a Blueprint in Render pointed at the repo, filling in the secrets it asks for.

Configuration

The worker needs a Multica login token and one Claude credential: either an OAuth token from claude setup-token, which uses a Claude subscription, or an Anthropic API key, which bills the API. Optional variables give git a credential for private GitHub repos (also exported for the gh CLI) and for Bitbucket repos, set the device name shown on Multica's Runtimes page, and point the daemon at a self-hosted Multica server.

Two details came out of running it. Without a Claude credential, the runtime still shows as online, because the daemon only version-checks the CLI, but every task then fails to authenticate. The entrypoint warns about this at startup. And MULTICA_TOKEN must not be set, because the CLI treats that variable as a task-scoped agent credential and refuses a personal token there.

Known limits

The README is direct about the tradeoffs:

• Ephemeral disk. Task workspaces are re-cloned after every deploy or restart. A Render disk mounted at /root/.multica avoids that.
• Memory. 512 MB on the starter plan is enough to idle and run small tasks. A real Claude Code run on a large repo wants the 2 GB standard plan.
• One runtime. Only Claude Code is installed. Adding another supported CLI to the Dockerfile registers it on the next boot. We briefly added a second runtime and then reverted to Claude Code only.
• Upgrades are a redeploy. The daemon's self-update is disabled on purpose, so the image is the single source of truth for what version is running.