In development at AIVCCheck out the GitHub

paas is AIVC's agent-first PaaS: one binary, any provider, and every project live on aivc.dev.

Coding agents drive it over MCP, the CLI or HTTP, all generated from one tool registry. Humans review what they did.

Check out the GitHubRead the spec

Built for

  • Claude Code
  • Cursor
  • Codex
  • MCP
clearlinks/spec.yaml → web-production-clearlinks.aivc.dev 
version: 1
project: clearlinks
lifecycle: persistent          # or: scratch
budget: { monthly_usd: 400, alert_at: 0.8 }

environments:
  production:
    placement: { region: us-east, providers: [hetzner, aws] }
  staging:
    from: production             # fork: inherits services and variables
    overrides:
      web: { replicas: 1 }

services:
  web:
    kind: app
    source: { repo: github.com/zach/clearlinks, branch: main, path: apps/web }
    build: railpack               # default; also: dockerfile, image
    port: 3000
    replicas: 2
    env: { DATABASE_URL: ${{ db.connection_url }} }

  db:
    kind: database
    engine: postgres@16
    branching: true               # copy-on-write forks for scratch envs
An example project spec: one YAML document across all environments. Its web service is served at web-production-clearlinks.aivc.dev.

paas is the control plane Railway would build if it started today, with agents as the first user and any provider as the compute. It is one open-source Go binary; the compute is any mix of Hetzner, AWS, bare metal or a laptop, joined into one pool, and every service gets its own subdomain of aivc.dev.

Self-hosted PaaS tools reproduce Railway's surface, not its architecture.

Railway's product model is right, but it is locked to Railway's own hardware. The experience is not portable; the builder is, so paas builds with Railpack by default.

So the data model changes. Projects are persistent by default, with a first-class scratch mode, budgets on every principal, and the primitives agents actually need built into the core rather than added later.

Every capability ships first as a tool: declarative apply, calls that block until something meaningful has happened, compact outputs, dry-run by default and scoped per-agent credentials. The dashboard is where humans review what the agents did.

mcp cli http tool calls paas server spec + audit v14 status · diff · coststatus · cost schedule over mesh node pool *.aivc.dev
Figure 1. Agents call one tool registry over MCP, the CLI or HTTP. paas server plans, applies, places and meters against the spec, bumps its version, and schedules onto a node pool that spans providers, where each service is served at its own aivc.dev subdomain. Every response carries status, a diff and cost.

How it works

The spec is the product.
A project is one declarative document across all its environments. The HTTP API, the MCP server and the CLI are generated from the same tool registry, so nothing exists in one transport and not the others.
Tools close the loop.
A deploy returns when the new deployment is healthy, has failed, or runs out of time, and says which. Errors carry what was observed and a suggestion, and outputs stay small enough to fit in an agent's context.
Agents are principals, not tokens.
Every agent run gets its own short-lived, scoped grant with a spend ceiling. Destructive operations need a confirmation token, and every mutation lands in an append-only audit log with the task it was for.

Deliberately not in v1: GPU scheduling beyond label-based placement, managed vector databases (Postgres with pgvector covers it), serverless functions and a template marketplace. See what's built.

See an example spec

Status

v1 is done when our agents deploy without a human in the loop for a month.

Time to resultv1 targets · scratch mode, cached framework
Target times for three operations
Operation Target
Healthy URL <60s
Sandbox exec <5s
Node joined <10min
Tools liveon main · over MCP, the CLI and HTTP25
Service kindsapp · database · cron · bucket · queue · webhook · sandbox7
Why the control plane moves outCoolify disclosure · January 2026

Panels that SSH into the host leave the control plane holding root on every box. Coolify's January 2026 disclosure listed 11 vulnerabilities, three at CVSS 10.0.

Our node securitySource

Where v1 engineering goesPRD estimate · share of the v1 build60% See what's built
On mainone Go module · October 2026
Packages
33under internal/
Test files
111go test -race
Binaries
1CGO_ENABLED=0
Browse the code

“Railway's experience, your providers' prices, built for your agents.”

The positioning, in one line · PRD v1

Run it anywhere. Every project lands on aivc.dev.

One Go binary runs the control plane. Nodes from Hetzner, AWS, bare metal or a laptop join one pool over a WireGuard mesh, and each service is served at service-env-project.aivc.dev.

How nodes join

  1. On bare metal

    001

  2. In any cloud

    002

  3. On your laptop

    003

Outbound-only by design.

Each node runs paas node, which dials out over mTLS with a short-lived certificate from the control plane's own CA. The control plane never holds SSH keys or root on a node, so compromising it yields the ability to schedule workloads, not root on the fleet.

  • 01Outbound-only mTLS
  • 02Scoped, expiring grants
  • 03Append-only audit log
How grants workBuild decisions

Progress

Built in waves by agents working in parallel on separate branches, each merged once its packages pass their tests. Oldest first.

  1. 01Network · mesh, ingress, DNS, network policy
  2. 02Scheduler · placement, rollouts, reconcile, cost
  3. 03LLM gateway · Anthropic and OpenAI-compatible, metered
  4. 04Cloud APIs · SigV4, S3, provider adapters
  5. 05Spec · parse, validate, fork, diff, etag
  6. 06Foundation · store, auth, tools, HTTP API
  7. 07Kinds · all seven v1 service kinds
  8. 08Builds · Railpack, Dockerfile, embedded OCI registry
  9. 09Transports · MCP server and generated CLI
  10. 10Metering, logs, lifecycle and GC
  11. 11Fleet · node agent, PKI, runtimes, paas dev
  12. 12Engine · plan, apply, deploy, rollback
  13. 13Agent tools · exec, migrations, sandboxes, database forks, webhooks
  14. 14Dashboard and GitHub · review feed, push-to-deploy, PR environments
  15. 15Our agents in production · 30 days, >70% of mutations
  • Merged on main
  • Next

Contribute

Start with docs/PRD.md for the product, docs/ARCHITECTURE.md for packages and contracts, and docs/DECISIONS.md for what's settled. Agents work in parallel on separate branches, each inside the packages its brief assigns.

from the repo root
go build ./...
go test -race ./internal/<pkg>/...
go build -o paas ./cmd/paas
./paas dev   # control plane + local node, services on *.localhost
Check out the GitHub