Self-Hosting Apito

Build locally. Scale when you’re ready.

Self-host the Apito engine on infrastructure you control. Current engine and console releases are Fair Source (FSL-1.1-ALv2). They convert to Apache 2.0 two years after each release. They are not OSI open source. Tags through engine v1.8.25 stay Apache 2.0.

Apito Cloud is the managed place to run the same project: hosting, monitoring, collaboration, and built-in billing. Sync is the path between them. See Sync to Cloud.

What you run

• Engine — system GraphQL and project APIs on port 5050
• Console — port 4000 in the local stack. Review drafts and publish
• Your databases — you operate backups the same way you would for any self-hosted database

Path 1 — Local stack with the Apito CLI

Install the CLI, then bootstrap Docker Compose for Engine (+ Console):

# macOS
brew install apito-cli

# or Linux / macOS install script
curl -fsSL https://get.apito.io/install.sh | bash

apito init          # writes docker-compose.yml + config with pinned image tags
apito start         # pulls Engine/Console images and starts containers
# optional DBs:
# apito start --db system
# apito start --db project

Check health, then open Console and create a project. Point the CLI at your Engine:

apito account create local
# server URL = http://localhost:5050 (or the URL printed by apito start)
apito account test local
apito account select local

Pin or upgrade versions in config.yml, then re-run apito init / apito start. The CLI can pull updates such as ghcr.io/apito-io/engine:<tag>.

Details: CLI Sync and the CLI README.

Path 2 — Production Compose

A reference Compose file ships with this site at /docker-compose.yml (Engine + Console + ArangoDB + Redis + Traefik). Treat it as a template — replace domains, passwords, and image tags for your environment.

Typical shape:

services:
  apito:
    image: ghcr.io/apito-io/engine:<tag>
    environment:
      - CORS_ORIGIN=https://console.your-domain.com
      - COOKIE_DOMAIN=your-domain.com
      # SYSTEM_DB_* / PROJECT_DB_* / KV_HOST = your stores
    # expose / reverse-proxy to port 5050
  apito-console:
    image: ghcr.io/apito-io/console:<tag>
    environment:
      - VITE_REST_API=https://api.your-domain.com
      - VITE_GRAPH_API=https://api.your-domain.com/system/graphql
      - VITE_PUBLIC_GRAPH_API=https://api.your-domain.com/secured/graphql

Bring it up with Docker Compose v2, confirm Engine health and Console login, then create a project and Publish schema changes in Console.

Confirm current image registries and tags in Engine releases / your ops channel — do not invent alternate installers.

Schema workflow (same as Cloud)

apito sync --from filesystem --to local --type schema --dir blueprints/newspaper-cms --dry-run
apito sync --from filesystem --to local --type schema --dir blueprints/newspaper-cms --yes

1. Sync stages a draft only.
2. Console publishes.
3. Seed content with SDK / blueprint scripts after publish.

Experimental binary

Docker is the default. A local binary from the engine release zip listens on :5050 and expects the console on :4000. Plugins and a networked realtime bus are optional. The default binary uses an in-process realtime bus.

Networking checklist

• Separate hosts or paths for API vs Console
• CORS_ORIGIN = Console origin
• TLS in front of the engine for production
• Do not expose system GraphQL publicly without auth

Usage data

apito start asks once, on an interactive terminal, before it sends anonymous usage. The default is no. DO_NOT_TRACK=1, APITO_TELEMETRY=0, a CI job, or a non-interactive shell send nothing. apito telemetry status prints the last payload. The field list is Telemetry.

License

Self-hosted engine and console builds from current releases are Fair Source. They are not an OSI open source edition. Drivers, the CLI, and SDKs are Apache 2.0. Schema drafts and project SQL exploration work on the self-hosted engine. Apito Cloud adds managed hosting, collaboration, monitoring, and built-in billing.