In development Community beta target Q1 2027 View roadmap
ANDIPDistributed infrastructureJoin Beta
Home/Docs/System Architecture
Architecture specification · not released product behavior

System Architecture

A system-level view of the proposed control plane, scheduler, worker fleet, storage, policy and observability boundaries.

Architecture baseline · subject to change

At a glance

ANDIP is specified as a control layer over already-provisioned worker servers. A user-facing request passes through authentication, project policy and workflow planning. A scheduler selects a compatible worker, reserves its capacity and issues a fenced lease. The worker prepares an isolated environment and runs an adapter; artifacts and state return to durable storage.

Proposed central control plane, distributed worker VPS instances, durable task state, artifacts and signals.
System overview. Architecture baseline, not a live deployment.

Major components

  • API gateway and identity: validate requests, authorization, idempotency and rate policy.
  • Project/workflow/task managers: own task definitions, dependencies and state transitions.
  • Distributed scheduler: filter, score, reserve and assign work based on worker capacity and policy.
  • VPS registry and worker runtime: enroll machines, track heartbeat, execute bounded attempts and reconcile.
  • Durable state: PostgreSQL is the proposed source of truth for tasks, attempts, leases and outbox events.
  • Execution sandbox: isolate workspaces and process/container environments, with limits and policy.
  • Artifact storage and observability: persist outputs/checksums and collect logs, metrics and audit events.

Trust and ownership boundaries

The control plane owns authoritative workflow state; a worker's local process does not. Agent adapters run inside a task-scoped boundary. Secrets are represented by references and delivered for a short duration, not stored in plaintext task records. High-risk actions may require human approval.

MVP deployment direction

The architecture source proposes a single control VPS with PostgreSQL and TLS reverse proxy, plus Linux worker VPS instances running a worker service and rootless container runtime. An object store may be external. HTTPS long-poll and heartbeat is favored initially so workers need not expose an inbound public port.

Kubernetes, multi-region high availability, hard multi-tenancy, automated cloud provisioning and billing are future scope—not MVP requirements.

All documentation · Full architecture page · Roadmap