Run AI coding agents on your own server

A self-hosted AI coding agent runs on a machine you control, so repository clones, prompts, logs and provider credentials live on your infrastructure, and GitHub and the model provider each receive only what their role requires. ProPR ships that as Apache 2.0 software and published Docker images for one Linux host.

What self-hosting keeps on your infrastructure

Everything an agent run produces or touches sits in the stack you run:

Repository clones, Git worktrees and the indexes ProPR builds from them.
Plans, prompts, agent logs, task history and usage records.
Provider credentials, agent subscriptions and API keys, set by you.
The agent containers themselves, next to the app and the workers.

Two external systems take part, each in one role. GitHub receives branches, pull requests, review comments and status updates, because that is where your team reviews code. The agent provider you select receives the prompt and code context for that one plan, implementation, review or follow-up. Indexing and file summaries run on your host with the agent you configured. Who gets what, in full.

What it takes to run a self-hosted AI coding agent

A Linux amd64 host with Docker available to your user, Node.js 22+ and npm, a GitHub account, and an account with one supported agent provider. Allow 2 vCPU, 4 GB RAM and 20 GB of disk to evaluate, and 8 GB RAM for daily use. The host needs outbound HTTPS and WebSocket access and no inbound public port.

npm install -g propr-cli
propr setup

propr setup checks the host, signs in your agents, connects GitHub and starts the published images on your Docker daemon: the app, the web UI, the docs and one agent image with Claude Code, Codex, Antigravity, OpenCode and Mistral Vibe inside. Every generated file sits in the stack directory, ready to inspect or edit. The self-hosted stack.

Happening now: five runs in parallel, among them an implementation on storefront-web and a review on orders-api, each with its step and elapsed time — The dashboard of a self-hosted instance with tasks running.

How GitHub reaches a server with no public port

By default your stack opens an outbound connection to ProPR Connect and GitHub events flow back down it, so a laptop or an internal network needs no public ingress. Your stack holds a revocable relay credential and never the GitHub App's private key. Prefer direct webhooks? Register your own GitHub App with propr github-app create and skip the relay entirely. Polling works too.

Isolation inside the host

Each task gets its own Git worktree, branch and Docker container, and the agent holds a read-only GitHub token, so ProPR itself makes every branch, commit, push and pull request. The isolation model.

Containers have ordinary outbound access by default. Optional restricted network mode starts the container with no network and routes its traffic through a per-run allowlist proxy: the agent's provider API, GitHub, package registries and the hosts you list. Every denied host shows on the task timeline.

Timeline step for a restricted-network run: the allow list comes from .propr/workflow.yml and three hosts were denied — A task timeline in restricted network mode, with the hosts it denied.

Or let the ProPR team run it

ProPR Hosted runs the same open-source ProPR on a dedicated VM per customer, with the managed tunnel, Connect routing and encrypted backups included, on Solo, Team and Scale plans. Your AI usage still goes to your own provider.