Self-hosting Future AGI

In this page

Future AGI is open source. Self-hosting runs the whole platform on machines you control, so your traces, datasets, and evaluations stay in your network. The backend is Django, the UI is React and Vite, and the LLM gateway and trace collector are written in Go. You can run it in three setups, and all three run the same application code.

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
• Restricted networks: turn off the connections the platform makes on its own and block the rest at your network; on Helm, global.airgap turns off telemetry, the licence heartbeat, the price-list download and model downloads in one value. Restricted networks lists every setting
• 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. Standalone needs 2 vCPUs and 4 GB of memory given to Docker and runs 3 containers that you patch and back up yourself. Requirements has the sizing for every setup.

Choose a setup

	Standalone (default)	Distributed	Helm (Kubernetes)
Install	./bin/install	./bin/install --distributed	The signed chart oci://ghcr.io/future-agi/charts/futureagi; see Helm (Kubernetes)
Runs	3 containers: app, postgres, clickhouse. The optional ml and sandbox profiles add one container each	One container per service: 31, made of 22 services and 9 one-shot setup jobs	One Deployment per service and a bootstrap Job. Datastores are external, or bundled for evaluation
Workflows	Temporal dev server (SQLite) inside app; the worker runs in the API process	Temporal server on Postgres	Your Temporal server, or a bundled dev server for evaluation
Postgres to ClickHouse sync	In-process outbox	PeerDB	Outbox
Resources	2 vCPUs, 4 GB of Docker memory	4+ vCPUs, 12 to 16 GB of Docker memory	Evaluation: about 4 CPUs and 8 GiB free. Production: per sizing preset
Scaling	One machine	Per service, on one machine	Per service, across nodes
Use it for	Laptops, evaluation, a small team on one VM (one or two people working at once)	High volume on one large host, and production on Docker Compose with the production overlay	Kubernetes clusters, teams, and production

Standalone runs the API and the Temporal worker in one process, so it stays responsive for one or two people working at once. For more concurrent users or a steady evaluation load, use Distributed or Helm.

To work on Future AGI itself, Development (./bin/dev) runs your checkout with hot reload. See Other ways to run it.

What you deploy

Standalone

Everything that is not a database runs in the app container (image futureagi/standalone) under a process supervisor: nginx serving the UI, the API with the Temporal worker in the same process, a Temporal dev server, Redis, object storage, the trace collector (fi-collector), the LLM gateway (agentcc-gateway), and the code-eval sandbox. Postgres and ClickHouse run in their own containers and publish no host ports. The collector (ports 4317 and 4318) and object storage (port 9005) listen on 127.0.0.1 only. Browsers download stored files from object storage through MINIO_URL, so a browser on another machine needs a route to it: see Public URLs.

%%{init: {"flowchart": {"curve": "linear"}}}%%
flowchart LR
  accTitle: The containers a Standalone install runs
  accDescr: Browsers reach the UI on port 3000 and the API on port 8000 of the app container, and download stored files from object storage on 127.0.0.1 port 9005. Your agents send traces to the collector on 127.0.0.1 ports 4317 and 4318, and LLM clients reach the gateway on port 8090. The app container also runs a Temporal dev server, Redis, object storage and the code-eval sandbox. The app stores data in Postgres and ClickHouse, and the gateway calls your model providers. The optional ml and sandbox profiles add a serving container and a code-executor container.
  subgraph APP["app container: futureagi/standalone"]
      UI["UI (nginx)"]
      API["API with the Temporal worker"]
      TMP["Temporal dev server (SQLite)"]
      RDS["Redis"]
      OBJ["Object storage"]
      COL["fi-collector"]
      GW["agentcc-gateway"]
      SBX["Code-eval sandbox"]
  end
  B["Browser"] -->|"3000"| UI
  B -->|"8000"| API
  B -->|"127.0.0.1:9005, file downloads"| OBJ
  AG["Your agent"] -->|"OTLP, 127.0.0.1:4317 and 4318"| COL
  LC["LLM clients"] -->|"8090"| GW
  API --> PG[("postgres")]
  API --> CH[("clickhouse")]
  COL --> CH
  GW --> MP["Model providers"]
  API -.->|"ml profile"| SRV["serving"]
  API -.->|"sandbox profile"| CEX["code-executor"]

The ml profile adds serving, the model server for embedding-based evals and knowledge bases. The sandbox profile adds code-executor, an nsjail sandbox that needs privileged containers and gives each code eval run its own jail. Without it, code evals run in the sandbox built into app, which runs Python only and shares the app’s network: on a Docker host with a kernel older than Linux 6.7, or without Landlock, eval code can reach the Temporal dev server, Postgres and ClickHouse. Use the built-in sandbox only where everyone who can write a code eval is trusted with the data. For an install shared by people who must not trust one another, set COMPOSE_PROFILES=sandbox in .env, not only --profile on the command line. Profiles covers both.

Distributed

Distributed runs one container per service: frontend, backend, the Temporal workers, agentcc-gateway, fi-collector, Postgres, ClickHouse, Redis, MinIO, and a Temporal server on Postgres. PeerDB mirrors Postgres tables into ClickHouse, and Kafka carries the observed-attribute suggestions used in filters. serving and the privileged code-executor always run. That makes 31 containers, 9 of them one-shot setup jobs. The workers, observability, and peerdb profiles each add one group; all adds every group, 10 more containers: per-queue workers, the Temporal UI and admin tools, and the PeerDB UI. See Profiles.

Helm

The Helm chart runs the Distributed topology on Kubernetes, with one Deployment each for the backend, the Temporal workers, the frontend, the collector, and the gateway, plus optional serving and code sandbox Deployments. A bootstrap Job sets up the database schema and seed data, the ClickHouse schema, and the Temporal schedules. Postgres changes reach ClickHouse through the outbox, so there is no PeerDB. The datastores are external by default; for an evaluation the chart can run each of them itself. See Helm (Kubernetes).

What leaves your network

Connection	On by default	How to control it
Model calls through the LLM gateway	Only to the providers you configure	The provider keys you add
Deployment telemetry to api.futureagi.com	Yes	./bin/install --no-telemetry, or FUTURE_AGI_TELEMETRY_DISABLED=true; on Helm, config.telemetry=false
Enterprise licence activation, and a licence heartbeat every 24 hours, to api.futureagi.com	Only with an Enterprise licence (EE_LICENSE_KEY)	FUTURE_AGI_ENTERPRISE_HEARTBEAT_DISABLED=true stops the heartbeat; on Helm, license.heartbeat=false or global.airgap
HubSpot, Slack, Mixpanel, PostHog, reCAPTCHA, Sentry, Mailgun	No	Each stays off until you set its key
Model price list from raw.githubusercontent.com, at each API and worker start	Yes	LITELLM_LOCAL_MODEL_COST_MAP=True uses the list bundled in the image
Model downloads from the Hugging Face Hub by serving, the first time each model loads	When serving runs: always on Distributed, with the ml profile on Standalone, with serving.enabled on Helm	Pre-seed the model cache, then set HF_HUB_OFFLINE=1 and TRANSFORMERS_OFFLINE=1; on Helm, global.airgap
Fonts, icons, a code editor, document previews, videos and logos, loaded by users’ browsers from public hosts	Yes: fonts and icons on every page, the rest on the screens that use them	Not switchable. Without cdn.jsdelivr.net the code editor does not load, so code evals cannot be written

Deployment telemetry registers the install once, with the email addresses of its owner, admin, staff and superuser accounts, then sends usage counts every 6 hours, never traces, prompts or other content. With it off, one minimal registration without email addresses still goes out. Telemetry covers exactly what is sent and how to turn it off or block it.

Where to go next