Netclode
Run cloud coding agents in isolated microVMs on your own infrastructure and control them from native Apple clients.
- Source repo
- angristan/netclode
- Stars
- ★ 262
- Last updated
- 3mo ago
- Primary language
- Swift
- FA score
- 51/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code · OpenAI API · Claude API
- Cost
- Free software; you pay for model usage
- Setup effort
- High · needs real infrastructure
- You'll need
- Typical use
- An individual developer who wants to work on repositories from an iPhone or Mac without placing the execution environment on a third-party coding-agent service.
- Not a fit if
- Individuals or teams without a nested-virtualization Linux VPS
- Users who want a one-command or hosted-service quick start
- Users who need a web, Windows, or Android client
- Source review
- 51/100 · Major gaps
What does this agent do, and when should you use it?
Netclode is a self-hosted cloud coding-agent system that assigns each session an isolated microVM built with Kata Containers and Cloud Hypervisor. Its Go control plane runs on k3s, allocates sandboxes from a pre-booted pool, and forwards prompts over Connect RPC to a TypeScript/Node.js SDK runner inside the sandbox. The runner supports Claude Code, OpenCode, Copilot, and Codex SDKs with providers including Anthropic, OpenAI, Mistral, and Ollama. Redis Streams retains reconnectable session events, while JuiceFS persists workspaces, installed tools, Docker images, and SDK sessions to S3 for pause, resume, snapshot, and rollback workflows. Users interact through a native SwiftUI iOS/macOS application or a Go debugging CLI, with access to diffs, a live terminal, and Tailscale-backed port previews. The deployment boundary is a self-managed Linux VPS with nested virtualization, provisioned through Ansible and operated with k3s, Tailscale, S3, and the required credentials.
The client reaches the Go control plane through Tailscale Ingress and Connect RPC. The control plane allocates a Kata VM from the agent-sandbox warm pool and sends prompts to a Claude Code, OpenCode, Copilot, or Codex SDK running inside it. Within the sandbox, the agent can work on repository files, install software, run commands with root access, use Docker, and call either configured model APIs or local Ollama inference. Responses stream back to the client, while Redis Streams persists events so a disconnected client can reconnect without losing the session. On pause, the VM is deleted and JuiceFS retains the workspace, installed tools, Docker images, and SDK session in S3; resume mounts that storage again. Netclode also records a snapshot after each turn and can roll both the workspace and chat back to an earlier point. Its GitHub integration clones private repositories, pushes commits, and creates pull requests, while the GitHub Bot handles @mentions on issues or PRs and reviews Dependabot or Renovate updates. A separate secret-proxy injects API keys for allowed hosts without placing the real credentials inside the sandbox.
- An individual developer who wants to work on repositories from an iPhone or Mac without placing the execution environment on a third-party coding-agent service.
- A team that needs agents to run Docker, install arbitrary software, and use root privileges while containing each session in a separate microVM.
- A developer with a local GPU who wants to run models through Ollama so inference does not leave the machine.
- A user maintaining many long-lived project sessions who wants paused sessions to retain state in S3 without keeping their VMs running.
- A repository maintainer who wants an @mention on a GitHub issue or pull request to launch a sandbox, or wants automated review of Dependabot and Renovate pull requests.
- A Tailscale user who needs private access to sandbox web previews, internal infrastructure, and a live terminal.
How do you install or deploy this agent?
The supplied material documents a deployment sequence but no complete copyable command set. The stated process is to provision a Linux VPS with nested virtualization, run the repository's Ansible playbooks, configure model API keys plus S3 credentials and Tailscale OAuth, deploy the Kubernetes manifests, and connect through Tailscale. The resulting installation also uses k3s, Kata Containers, Cloud Hypervisor, Redis, JuiceFS, and S3. The source does not provide the VPS sizing, exact playbook invocation, manifest deployment command, environment-variable names, or iOS/macOS client installation steps, so a complete first-run procedure cannot be reproduced from the supplied material alone.
How do you use this agent?
After deployment and Tailscale connectivity are in place, create or resume a session from the native iOS/macOS app. The control plane allocates a warm sandbox and passes prompts to the selected SDK; the app can display streamed responses and multi-repository Git diffs, open a live shell, accept speech input, and expose sandbox ports to the tailnet. Pause a session to remove its VM while retaining state through JuiceFS and S3, then resume it with the same workspace and SDK session. Per-turn snapshots can restore both the workspace and conversation to a previous point. For GitHub workflows, mention the bot on an issue or pull request to start a sandbox and receive its response as a comment. A Go debugging CLI is present, but its build, authentication, and first-invocation commands are not included in the supplied source.
What are this agent's strengths and limitations?
- Kata Containers and Cloud Hypervisor isolate every session in a microVM, allowing root access, Docker, and arbitrary tool installation inside the sandbox.
- The runner supports Claude Code, OpenCode, Copilot, and Codex across multiple remote providers, with Ollama available for local GPU inference.
- A pre-booted sandbox pool targets immediate starts, while Redis Streams preserve session events across client reconnections.
- JuiceFS-backed S3 persistence lets paused sessions release their VM while retaining the workspace, tools, Docker images, and SDK state.
- Automatic snapshots after each turn support coordinated rollback of both repository state and conversation history.
- The external secret-proxy injects API credentials only for allowed hosts, keeping real keys out of the sandbox.
- Adopters must operate a nested-virtualization Linux VPS plus k3s, Kata Containers, Cloud Hypervisor, Redis, JuiceFS, S3, and Tailscale, creating a substantial infrastructure burden.
- Deployment requires model API keys, S3 credentials, and Tailscale OAuth; private-repository and bot workflows additionally depend on GitHub App integration.
- The primary graphical client is a SwiftUI iOS 26 application that also targets macOS; no web, Windows, or Android client is documented.
- The quick-start material gives only high-level stages and omits directly executable Ansible, Kubernetes, and client-installation commands.
- The repository license is unknown, so adopters must establish their rights to use, modify, or redistribute it.
- The claim that paused sessions cost practically nothing beyond storage is not accompanied by capacity guidance, benchmarks, recovery objectives, or measured cost data.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Netclode This agent | 51 · Major gaps | Self-hosted serviceFree + model costs | ★ 262 | 3mo ago | Swift | Codex · Claude Code · OpenAI API · Claude API |
| Omnigent | 68 · Some gaps | CLIFree + model costs | ★ 11k | today | Python | ChatGPT · Codex · Claude Code · Claude.ai · OpenAI API · Claude API |
| Skybridge MCP Apps Framework | 63 · Some gaps | CLIFreemium | ★ 2.2k | 10d ago | TypeScript | ChatGPT · Claude.ai |
| OpenChamber | 71 · Some gaps | Desktop appFree + model costs | ★ 13k | today | TypeScript | — |
How does FollowAgents rate this agent?
Why each dimension lost points
The docs describe Kata microVMs, network policies, a secret proxy restricted by SDK and destination host, and a repository permission gate for GitHub Bot triggers. The proxy source also shows token reads from a mounted file and request forwarding. Deductions: bot comments, pushes, and automated dependency reviews have external effects, but the materials do not describe per-action confirmation; GITHUB_TOKEN is explicitly listed as a direct value outside the proxy, so sensitive-data handling is not comprehensive; the limited CI material does not establish a broad dependency security policy; contributor guidance does not clearly establish product security responsibility or attribution.
The README, architecture doc, and proxy source are broadly consistent, and the code includes reconnect retries and proxy error responses. Deductions: some architecture and security assurances are documented claims not fully corroborated by the supplied source; availability, upgrade, and recovery details are limited; error logging and responses exist, but the evidence does not show comprehensive failure handling.
The project identifies self-hosted cloud coding agent users and documents iOS/macOS, CLI, local inference, Tailnet, and multiple SDK scenarios; it also describes network scope, infrastructure requirements, and GPU setup. Deductions: capability boundaries and deployment conditions are described but do not cover every scenario, and there is no full non-goals or suitability matrix; trigger and configuration guidance is useful but does not detail every trigger boundary.
The README organizes architecture, deployment, operations, and feature docs, and provides setup steps, commands, CLI examples, and some limitations. Naming is generally consistent. Deductions: license metadata is unknown and no license text is supplied; version history and changelog evidence is limited; maintenance responsibility and support channels are unclear; limitation coverage is incomplete.
The product combines remote sessions, microVM isolation, persistent storage, session recovery, mobile clients, and multiple SDK integrations, with actionable deployment and usage examples. Deductions: the value claims are primarily asserted in the README and lack independent quantitative support in the supplied materials; the self-hosted stack spans k3s, Kata, storage, Redis, Tailnet, and optional GPU components, while operational cost and tradeoffs are not adequately assessed.
The README architecture and feature claims can be partially compared with the sandbox architecture doc, proxy source, and CI workflows; the supplied source supports token reading, authorization header addition, and request forwarding. Deductions: many security, performance, and product-effect claims remain documentation assertions; CI workflows show test steps but are not evidence of executed results in this review; facts, design intent, and inference are not always clearly separated.
- This is a static review with low confidence; security and performance assurances in the docs were not independently verified.
- Before deployment, review GitHub Bot write permissions, direct use of GITHUB_TOKEN, and the secret proxy's allowed destination hosts.
- Deployment requires a host with nested virtualization and several infrastructure components; license information is unknown.
Maintain this project? Add the FARS badge to your README
[](https://followagents.com/en/agents/netclode)<a href="https://followagents.com/en/agents/netclode"><img src="https://followagents.com/badge/netclode.svg" alt="FARS review"></a>FAQ
What survives when a session is paused?
How much privilege does the agent receive?
Do model API keys enter the sandbox?
Can inference remain on local hardware?
What should be validated before adoption?
Thanks — we use this to improve the page.