Self-hosting

Self-hosting ALDO AI requires a commercial agreement with ALDO TECH LABS — contact us at info@aldo.tech. It is the canonical path for tenants that need the sensitive privacy tier or require their data and workloads to remain entirely inside their own infrastructure.

#Components

• apps/api — the control-plane HTTP API (Hono).
• apps/web — the control-plane UI (Next.js).
• platform/engine — runs the agent graph.
• platform/gateway — routes capability classes to concrete models.
• Postgres — durable store for agents, runs, and audit.
• Redis — pub/sub for the live event stream.

#Deploy

The reference deployment is a docker-compose file plus a Helm chart. Both are kept in infra/. The minimal footprint is:

• 1× api container (single replica is fine for hundreds of agents).
• 1× web container.
• 1× engine worker (scale horizontally per concurrent run).
• Postgres + Redis (your choice — managed or in-cluster).

#Local-models setup

Run the model backend of your choice on the same network as the gateway. The catalog file (gateway.models.yaml) tells the gateway where to find each backend.

For Apple Silicon, see MLX (Apple Silicon). For Linux, the openai-compat adapter against Ollama, vLLM, llama.cpp, or LM Studio is the path most operators take.

#Master key

The control plane needs a master key for the secrets store. Set ALDO_MASTER_KEY to a 32-byte base64 string in production. Dev gets an ephemeral key with a warning so you don't forget.

#Backups

Postgres is the durable store; back it up with the same cadence you'd use for any other tier-1 service. The audit log is append-only and is the canonical record of what happened — operators usually export it nightly to long-term storage.

#Upgrades

Releases ship a migration script that's safe to run against the live database — additive, never destructive. The CHANGELOG calls out anything that requires a maintenance window.