Introducing ReArch: Self-Hosted AI Coding Agents for Your Whole Team

Most teams have the same bottleneck. The backlog is full of small, well-understood work - a copy change, a missing validation, a flaky test, a refactor everyone agrees on - and none of it gets done, because the people who could describe the change aren’t the people who can open an editor and make it.

Meanwhile AI coding agents have gotten genuinely good. But running them well is still a developer’s privilege: you need the repo cloned, the runtime installed, the API keys configured, the right context loaded. The product manager who knows exactly what’s wrong with the checkout page can’t do any of that.

So I built ReArch.

What is ReArch?

ReArch is a self-hosted platform that connects your team to AI coding agents. Each agent runs inside its own isolated Docker container, with a full clone of the repository, the app’s runtime, a browser-based VS Code, and the coding agent itself. Someone describes what they want in plain language; the agent does the work; the change comes out the other end as a pull request in your normal review process.

The pitch on the site is short: a week’s backlog can ship overnight.

The important part is the last step. ReArch doesn’t deploy anything. It creates branches and pull requests that feed into the pipeline you already have. Nothing reaches production without a human approving it - the review process stays exactly where it was.

The workflow

Four steps, start to finish:

1. Connect a repository. Link a GitHub or Bitbucket account. ReArch imports the repo metadata and builds a Docker image for it.
2. Start a conversation. ReArch provisions a sandboxed container with VS Code, the AI agent, and your application’s runtime.
3. Describe the task. A bug, a feature, a refactor, a missing test. The agent reads the code, makes changes, runs things, and reports back.
4. Review and ship. Changes show up as diffs. Commit, push, and open a pull request without leaving the platform.

No container administration on your part. The lifecycle - created, starting, running, stopped - is handled for you.

Conversations are the unit of work

A conversation is a session tying one person to one agent working on one repository. It’s more than a chat log:

• Messages stream in real time over Server-Sent Events, so you watch the agent work rather than waiting on a spinner. It can ask clarifying questions inline, which you answer or dismiss.
• The sidebar shows every changed file with line counts, container status, context usage, and the running cost of the session.
• Full git diffs are reviewable before anything is committed. The “conclude change” flow stages, commits with your message, pushes the branch, and opens a PR with a title, description, and reviewers.
• Live previews and screenshots. Quick-access buttons open the containerized app itself and code-server. Visual verification matters a lot when the person requesting the change can’t read the diff.
• Multiplayer. Anyone who sends a message joins the conversation and appears as an avatar in the sidebar. Two people can work a problem in the same session.

MCP tools, through a proxy

Agents get more useful when they can reach the rest of your stack. ReArch supports MCP servers, but routes everything through a single MCP proxy rather than configuring each container separately.

The proxy aggregates the tools from every connected upstream server and exposes them at one endpoint, prefixing each tool with its server name to avoid collisions - search from brave-search becomes brave-search_search. Configuration changes hot-reload: affected servers reconnect while the rest stay up.

The gallery ships with the usual suspects pre-configured:

• Development: GitHub, Linear, Vercel, Sentry
• Infrastructure: Cloudflare, Neon, Supabase
• Search & browsers: Brave Search, Browserbase
• Productivity: Slack, Notion, Figma
• Commerce & docs: Stripe, Context7

Credentials live in one place instead of being duplicated into every container. Only admins can manage MCP servers, and every agent in the project shares the enabled toolset.

Bring your own models

ReArch is OpenAI-compatible and works with Anthropic, Google, and OpenAI providers - Claude, Gemini, GPT. You add your own API key, which is encrypted at rest with AES-256-GCM, and enable exactly the models you want available. Users pick a model per message.

Cost monitoring that actually answers the question

The question every team lead asks about AI tooling is “what is this costing me, and who is spending it?” So that’s a first-class dashboard, not an afterthought.

Tracked metrics:

• Total cost in USD across conversations
• Conversations created, and how many are active in the last 24 hours
• Average cost per conversation
• Pull requests generated, and what percentage of conversations produced one
• Cost broken down per user and per repository

Every time an agent finishes processing a prompt, ReArch reads the provider’s usage data - input tokens, output tokens, reasoning tokens - and stores the cost on the conversation record. Metrics are aggregated at query time from data that already exists, so there’s no separate analytics pipeline to run or break.

That “conversations with PRs” percentage turned out to be the number I care about most. It’s the closest thing to a signal that the tool is producing work rather than just producing tokens.

The architecture

For anyone who wants to know what they’d be running:

Frontend — React 18 with Material-UI Joy, built with Vite.

Backend — Bun with Elysia.js, handling the API, WebSocket connections, Docker orchestration, and the job queue.

Data — MongoDB 7 for application state (users, conversations, resources), Redis 7 for BullMQ job queues and scheduled tasks.

Auth — Keycloak 24 for optional SSO and role-based access, with four modes: LOCAL (email/password), OAUTH (generic OpenID Connect), KEYCLOAK_FIREWALL (production SSO), and NONE (development only).

Networking — Traefik v3 as reverse proxy and TLS terminator, routing by subdomain.

When a conversation starts, the backend enqueues a container-creation job in BullMQ. A worker pulls the pre-built image and starts a container running supervisor, which manages code-server, the coding agent, and any application runtimes. Traefik detects the new container through Docker labels and routes conv-<id>.<domain> to it. Agent output streams back over WebSocket.

Routing looks like this:

app.<domain>    → Frontend (React SPA)
api.<domain>    → Backend (API + WebSocket)
auth.<domain>   → Keycloak
conv-*.<domain> → Conversation containers

Production Swarm deployments run two overlay networks: an internal rearch network that keeps backend services and conversation containers off the internet, and traefik_network as the single external entry point, behind forward-auth.

Trying it locally

The fastest path is the development stack:

git clone https://github.com/rearch-engineer/rearch.git
cd rearch
./development.sh start

(development.cmd start on Windows.) That brings up MongoDB, Redis, the backend API, the MCP proxy, and the frontend dev server. You’ll need Bun 1.3.10+, Docker and Docker Compose, a GitHub or Bitbucket account with a repo, and an API key from Anthropic, Google, or OpenAI.

Then open http://localhost:4200, sign in with the default admin credentials, and change them immediately by editing ADMIN_EMAIL and ADMIN_PASSWORD in backend/.env. From there: add an LLM provider under Administration → Settings, connect a git provider under Resources, import a repository, build its Docker image (1-5 minutes), and start a conversation.

A good first prompt is something low-stakes that proves the agent can actually see your code: “Explain the structure of this project and list the main entry points.”

Self-hosting for real

Production wants a Linux server or cluster with Docker Engine 24+ and Swarm mode initialized, a domain, and Traefik v3 on an external overlay network. Because every conversation gets its own subdomain, you need four DNS records - app, api, auth, and a wildcard *.<domain>. The wildcard is the one people forget.

The full stack is eight services: frontend, backend, MCP proxy, Keycloak, PostgreSQL, OAuth2 Proxy, Redis, and MongoDB. There’s a self-hosting guide and a Keycloak setup guide in the docs.

What ReArch isn’t

Worth being explicit, because these questions come up:

• It isn’t a SaaS, unless you choose ReArch Cloud. The default is that you run it, on your infrastructure, with your code never leaving it.
• It isn’t your primary editor. It ships code-server for when you need to look at something directly, but you’re not moving your daily work into it.
• It isn’t a CI/CD replacement. It produces pull requests. Your existing pipeline takes it from there.

Who it’s for

• Developers delegating routine work and prototyping several things at once
• Product managers requesting features and fixes without writing code
• DevOps engineers deploying, configuring, and monitoring the platform
• Team leads watching costs, auditing output, and managing permissions

Get started

• Site: rearch.engineer
• Docs: docs.rearch.engineer
• Source: github.com/rearch-engineer/rearch

I built ReArch because I wanted the people who understand a problem best to be able to do something about it, without lowering the bar on review. The pull request is still the gate. What changes is how many people can walk up to it.

Feedback, issues, and contributions are all welcome.