Operations: CLI, backup, and updates

The aptabit CLI installs, updates, backs up, restores, and diagnoses the Aptabit Platform from a single configuration file, config.yaml.

CLI commands

Advanced commands, listed by aptabit help --all, include logs, doctor, init, self-update, recover-root, and uninstall. uninstall is the only command that deletes data: it asks you to type the installation path to confirm.

Frequent options: --config selects the installation when there is more than one (in most commands also as --instance); --dry-run shows what would be done in install, up, down, uninstall, and backup rollback; --yes skips confirmation; --lang pt-BR or --lang en selects the language in any command.

Updates

aptabit update --check   # only checks whether a new release exists
aptabit update           # updates to the latest stable release

An update:

1. Creates a safety backup.
2. Downloads the new images.
3. Updates api, worker, and web one at a time, waiting for each one's health check, and only then recreates the proxy.
4. If the new release does not come up, rolls back automatically to the backup made in step 1.

Database migrations run automatically when the API starts. To pin a release, use aptabit update:<version>; aptabit update --latest removes the pin. aptabit self-update updates the CLI itself, checking the manifest signed by Aptabit.

Backup and restore

aptabit backup
aptabit backup list
aptabit backup rollback <id>

A backup is a local restore point with the configuration files and the stack's PostgreSQL, MinIO, Milvus, and etcd volumes. The platform stops for a few moments to keep the copy consistent.

• External dependencies (managed PostgreSQL, Redis, S3, or Milvus) are not part of the CLI backup; use those services' own tools.
• The identity/ folder is not copied, because it holds the installation's private key.
• The backup is written to local disk, unencrypted; copy it to your organization's backup system.

External dependencies

Each dependency can point to a service your organization already operates. The advanced aptabit init command generates the configuration:

aptabit init \
  --config /opt/aptabit/production/config.yaml \
  --database external \
  --database-url postgres://user:password@db.example.com:5432/aptabit \
  --redis external \
  --redis-url redis://redis.example.com:6379 \
  --storage s3-external \
  --storage-endpoint https://s3.example.com \
  --storage-bucket aptabit-prod \
  --storage-access-key <access-key> \
  --storage-secret-key <secret-key> \
  --vector external \
  --vector-endpoint http://milvus.example.com:19530 \
  --force

The generated docker-compose.yml leaves out the corresponding local services and volumes. To validate without starting containers:

docker compose -f /opt/aptabit/production/docker-compose.yml config --quiet
aptabit up --config /opt/aptabit/production/config.yaml --dry-run

Several installations on one server

Each installation has its own folder, Compose project, container names, and network, and can be named with aptabit install --name <name>. Without --config, commands act on the current installation; the CLI lists the others when they exist.

Diagnostics

aptabit status --json
aptabit logs --service api --service worker --follow --tail 100
aptabit support-bundle

• Every command writes a run log to ~/.aptabit/logs/, with secrets replaced by <redacted>; the 50 most recent are kept.
• A failure ends with a stable code, an ID, and the path of the log. Quote the ID to support.
• The support bundle gathers the machine check, the configuration, the containers' state with their last 300 log lines, the setup and license status, and the recent run logs, without passwords, keys, or tokens.

Observability

• Structured JSON logs.
• /health and /ready endpoints for availability checks.
• Export of traces and logs over OpenTelemetry to your organization's collector, configured in Settings > Logs.
• Settings > System shows the machine's CPU, memory, disks, and GPUs.

Current limits

• Each installation runs on a single server; high availability depends on externally managed dependencies.
• The proxy serves HTTP; TLS is terminated in your organization's infrastructure.
• The guided installer uses Docker; Podman support is partial.
• An initial Helm chart exists, but the CLI does not operate Kubernetes installations.