Self-hosting Future AGI

Run the entire Future AGI platform on your own infrastructure with Docker Compose. Your traces, datasets, evaluations, and model calls stay inside your network

Future AGI is fully open-source. Self-hosting runs the entire stack on your own machines, so all traces, datasets, evaluations, and model calls stay within your network. The backend is Django, the frontend is React + Vite, and the LLM gateway is Go, all deployed together with Docker Compose.

When to self-host

The cloud hosted version is the easiest way to run Future AGI, with nothing to operate. Self-host when you need:

  • Data residency: keep all data inside your own network
  • Air-gapped environments: run with no outbound dependencies
  • Cost control at scale: own the infrastructure
  • Deep customization: modify the open-source stack to fit your needs

What it costs you is a host and the operating. Budget 4 CPU cores and 8 GB of RAM for a trial, more for real traffic, and expect to run 13 containers that you patch and back up yourself. Requirements has the sizing, then ./bin/install brings the stack up in one command.

What you deploy

A default install brings up 13 services, and that is already a complete instance: you can sign in, send traces, and run evaluations with nothing else enabled.

Browser
  └─ frontend (React/nginx)
       └─ backend (Django) ──── agentcc-gateway (Go) ──── OpenAI · Anthropic · Gemini · Bedrock
            ├── postgres        primary database
            ├── clickhouse      trace and analytics store
            ├── redis           cache / pub-sub
            ├── rabbitmq        task broker
            ├── minio           object storage
            ├── serving         built-in evals and guardrails
            ├── code-executor   sandbox for custom code evals
            └── temporal ──── worker   background jobs / eval pipelines

your agent ──OTLP──> fi-collector ──> clickhouse    spans, written directly
postgres ──── PeerDB CDC ──────────> clickhouse    mirrored tables, `full` profile only

Those 13 break down as:

  • Application: frontend, backend, worker, agentcc-gateway, serving, code-executor
  • Data: postgres, clickhouse, redis, rabbitmq, minio
  • Ingest: fi-collector, the OTLP receiver that writes spans straight to ClickHouse
  • Workflow: temporal

Another 18 services ship switched off, which is where the stack’s total of 31 comes from: six extra Temporal workers, two Temporal admin tools, and the ten PeerDB replication services that mirror Postgres tables into ClickHouse. You turn a group on with a profile, a named bundle you set once in .env, and Profiles covers what each one adds.

Everything runs on your machines, and nothing leaves your network apart from the model calls you configure the gateway to make.

Where to go next

Work these in order the first time through.

Was this page helpful?

Questions & Discussion