Self-hosting

AI2IN runs as a single Node engine plus Docker with the gVisor runtime. You can run it on your own infrastructure — one node scales to many via a symmetric cluster.

Architecture

Browser / SDK ──HTTPS──▶ Caddy (:443, auto-TLS) ──▶ engine (:4000)
                                                      └─ Docker + gVisor (runsc)

• Engine — a Node service (no build step) that owns the sandbox containers and exposes the /v1 API.
• Caddy — terminates TLS for api.ai2in.dev and *.up.ai2in.dev and proxies to the engine + preview router.
• Supabase — Postgres for teams, sandboxes, usage, and (in a cluster) the node registry.

Single node

The reference Terraform provisions one right-sized EC2 node in ap-south-1 with Caddy, gVisor, and secrets pulled from SSM at boot. It fits comfortably under a modest monthly budget and requires no bare metal — gVisor runs on any instance type.

Scaling out

AI2IN scales as a symmetric cluster: every node runs the full engine and self-registers in a shared nodes table. Each sandbox records its node, so any node routes a request to the peer that owns it — no separate control plane, no load balancer. Adding a node is node_count = 2 in Terraform plus a DNS entry; the new node auto-joins.

Configuration

Key environment variables:

Var	Purpose
SUPABASE_URL / SUPABASE_SERVICE_ROLE_KEY	data + auth
AI2IN_RUNTIME=runsc	gVisor isolation (production)
AI2IN_PUBLIC_HOST	public host for preview URLs + DB connection strings
AI2IN_MAX_SANDBOXES	per-node running capacity
AI2IN_INTERNAL_TOKEN	shared secret for cluster peer routing (unset = single node)

See the infrastructure repo for the full Terraform and boot scripts.