colonizer run it locally

open source · local-first · kvm microvms

colonize your backlog.

colonizer sends coding agents out to settle your issues. each one lands in its own microvm with a fresh worktree, stays linked to home over a private mesh, and returns with a pull request you can trust.

scripts/install.sh
view source →

linux x86_64 with kvm · nothing downloaded at runtime

01 / the colony

watch every settler work. answer in one click.

a chat and a terminal for each colony, side by side. when an agent needs you it asks with concrete choices, never a wall of text.

3 colonies active · 1 waiting on you

127.0.0.1:7878 · colonizer/issue-142-3f9a1c2e illustration

frontier

Add passkey login
settling · 4m
Flaky CI on arm64
waiting on you
Migrate to sqlx 0.8
settling · 11m
Rate limit /api/events
returned · PR #139
you
Settle issue #142: add passkey login to the web UI.
settler · claude-code
Read the issue and web/src/auth. There are two ways to do WebAuthn here. I need one decision before I write code.

which auth library should i use?

terminal · colonizer-3f9a1c2e
$ git status --short
M web/src/auth/login.tsx
?? web/src/auth/passkey.ts
$ npm test
42 passing
$ git commit -am "passkeys"
# read-only git metadata: the mothership commits

isolation

a kvm microvm per colony

not a shared-kernel container. the agent can do anything inside it; if it goes rogue it wrecks its own worktree, and that is all.

mesh

one hop from home

every colony joins a private tailscale-compatible network with the mothership. never your own tailnet, and colonies cannot reach each other.

decisions

multiple choice, always

questions arrive as cards with an “other…” answer. if an agent slips into a plain-text question, it is asked to try again as a card.

return

the host publishes

the vm is gone before git commits, pushes and opens the pull request. what the colony left behind is untrusted until sanitized.

02 / the router planned

the right model for every step.

the router would read each request and send it to the model that fits: frontier reasoning for the plan, a fast model for edits, a cheap one for logs and lint. one budget per colony, one place to change your mind.

not built yet. today a colony runs the model you set in the claude code settler’s settings.

  • classify the intent, size and risk of each request
  • route across claude, gpt, deepseek and local models
  • per-colony budgets with a hard cap the settler cannot lift

03 / settlers

bring the agent you already trust.

every settler speaks the same runner protocol inside the colony: json lines on stdio, so a settler can be written in anything. switch in settings → modules; the mesh, the sandbox and the publish step stay the same. claude code ships today.

~/.config/colonizer/modules.json
{
"source": { "provider": "github" },
"sandbox": { "provider": "microsandbox" },
"mesh": { "provider": "headscale" },
"agent": { "provider": "claude-code" },
"interfaces": { "provider": "default",
"settings": { "chat": true, "terminal": true } },
"publish": { "provider": "github-pr" }
}

a valid modules.json. settings → modules writes the same file.

Claude Code

shipping

the first settler. it runs through the claude agent sdk inside the colony, with your native claude code binary mounted read-only. log in with your claude subscription and the token stays on the host.

  • claude setup-token login, run on the host
  • the vm holds a placeholder; the tls proxy swaps in the real token for api.anthropic.com only
  • questions arrive as multiple-choice cards through the runner protocol

codex, opencode and a deepseek harness are planned behind the same runner protocol.

04 / many llms, your keys

credentials never enter a colony.

bring your own keys or subscriptions. tokens live on the host; the guest sees a placeholder and the sandbox’s tls proxy swaps in the real value at the network edge, for one host, on the way out. a colony only ever holds placeholders.

anthropic works today, with a claude subscription or an api key. the github token stays home too: commit, push and the pull request run on the host after the vm is gone.

  • Anthropic
    api.anthropic.com shipping
  • OpenAI
    api.openai.com planned
  • DeepSeek
    api.deepseek.com planned
  • Google
    generativelanguage.googleapis.com planned
  • OpenRouter
    openrouter.ai planned
  • Local / Ollama
    host.microsandbox.internal planned

05 / quickstart

one script. nothing downloaded at runtime.

the installer bundles headscale, tailscale, the agent daemon, the settler modules and the web ui into one self-contained app directory. run colonizer and open the mothership.

  1. 1

    install microsandbox

    curl -fsSL https://get.microsandbox.dev | sh, plus git, gh, node ≥ 20, a rust toolchain and a native claude code install.

  2. 2

    build the harness

    clone Colonizer-dev/harness and run scripts/install.sh. everything lands in dist/; add --install to copy it to ~/.local/share/colonizer/app.

  3. 3

    open the mothership

    run dist/bin/colonizer, open 127.0.0.1:7878, connect github and claude in settings, then launch a colony on an issue.

06 / open by default

a rust harness, a react cockpit, all on your hardware.

read the trust model, audit the publish step, add a settler. everything is a module behind a small contract.

harness
rust
isolation
kvm
runtime downloads
0
license
mit

what it does not do yet

  • one machine: linux x86_64 with kvm. no macos, no remote hosts.
  • one agent and one forge: claude code and github.
  • no login on the web ui. it binds to loopback and should stay there.
  • not yet run end to end: opening a pull request from a colony, and install.sh --install. both are implemented.
  • no ci, no releases, nothing on crates.io or npm.

07 / pricing

the mothership is free. outposts are coming.

remote outposts planned

fleet

not built

other machines would join the mesh and host colonies: a gpu box, a home server, a cloud vm. there is no price, published or estimated.

  • a fleet view: every colony, what it waits on, what it costs
  • per-colony budgets and network policy
  • dev-server previews over the mesh
join the waitlist

teams planned

teams

email us

for a team that wants colonizer on its own terms. tell us what you would need; none of this is built yet.

  • gitlab, linear and jira as frontiers
  • approval rules and guardrails as modules
  • review comments as follow-up tasks
contact@colonizer.dev

fleet waitlist

one email when remote outposts can host colonies. nothing else, and the address is not shared.

email contact@colonizer.dev and we will add you by hand.