THE TECHNICAL ARCHITECTURE
Engineering details.
If you’re going to deploy ClaudeAutonomous at your company, here’s how it actually works. No diagrams without code; no buzzwords without primitives.
THE FLEET MODEL
One Control node per user. Each runs the full stack.
Every user gets a Control node — currently a Mac Mini, soon also a Linux/AWS option. Each Control node runs Claude Desktop, a local HCL Domino server (for artifact replication), a web UI exposing chats + an Application Portal, an MCP bridge layer with per-user GitHub PAT, and a local SQLite cache for fast offline queries.
Plus each user has a paired Managed node — a sibling host for prototyping, testing, and running customer-impacting jobs without risking the Control node’s stability.
Above the fleet sits a central HA Postgres database (“autonomous schema”) for cross-node coordination: distributed-operation queue, fleet topology, MCP probe history, audit logs. Critical state lives there; per-user data stays local.
MCP BRIDGES
MCP bridges connect Claude to your stack
Model Context Protocol is how Claude reaches outside its chat window. A bridge is a small program (typically 100–300 lines of Python) that exposes one or more capabilities to the AI.
We have bridges for GitHub (repo ops, scoped to user PAT), Mac/Linux shell (file ops, process management), SSH Operations Manager (async SSH job queue across the fleet), HCL Domino (NSF read/write, agent runs), Postgres central DB, API Reference catalog, FortiNet (firewall + EMS + cloud inventory), and an External Bridges Gateway for caller-planned multi-step plans.
Each bridge is versioned in git, backed up on every change, and can be rolled back per host. Adding a new system means writing one bridge, not rebuilding a data pipeline.
IDENTITY
GitHub PATs are the identity primitive
Every user has a Personal Access Token. The PAT scopes which repositories Claude can read on their behalf, which it can push to, and which it can’t touch at all.
The same identity drives the layered access model. A marketing contractor’s PAT can see the marketing repos and the public website repo, nothing else. Internal developers see internal repos. The CFO sees the finance repos. Whoever has access to a repo, ClaudeAutonomous can act for them on that repo.
Token rotation is tracked centrally. Health checks fire warnings before expiry. The audit trail of “which PAT did which action when” lives in the central DB.
THE THREE UI TIERS
Three tiers of UI, one underlying system
Application Portal
The entry point. Apps grouped by department and function. Claude available in the corner but not in your face.
Chat + Projects
Real-time multi-party chat, artifact sharing, project organization. The team workspace.
Fleet Operations
MCP bridge versions, distributed-ops queue, API reference, certificate management, the full self-management view. Hidden from laypeople; the lifeline for developers.
SELF-MANAGING
Claude codes ClaudeAutonomous
The system is largely self-developed. Claude writes the MCP bridges, the LaunchAgents, the web UI, the schema migrations, the deployment scripts. Every change goes through git. Every deployment has rollback.
This isn’t a stunt. It’s the proof point. If ClaudeAutonomous can self-host itself — write its own code, deploy its own updates, manage its own infrastructure — it can certainly help your team manage theirs.
That said: humans are still the architects. Claude proposes, builds, tests, deploys. A human reviews and decides. The system is autonomous within bounds, not autonomous unsupervised.
KNOWN GAPS
What’s still ahead
Honest gaps the team is actively working on: TLS on the web UI (currently HTTP-only on local fleet), 2FA / push notification integration (in design), AWS-portable deployment (designed; not fully tested), an Android night-mode alert app (specced, not built), and a Domino certifier hardening pass.
We document the gaps because trust is earned, not granted. If you’re evaluating this for your org, you should know what’s solid and what’s still being built.