Skip to content

Operations

Running Axium day to day.

  • Health checks

    Which endpoint means what, and probes for Docker, Compose, Kubernetes and Cloud Run.

    Health checks

  • Upgrading

    Image upgrades, the schema migration policy, and update.sh on Google Cloud.

    Upgrading

  • Backup & restore

    The database and the master key, together.

    Backup

  • Scaling & sizing

    Horizontal scaling, memory drivers, connection budgets and a Kubernetes manifest.

    Scaling

  • Troubleshooting

    Symptoms, causes and fixes, from "the schema is not installed" to "the SDK gets a 404".

    Troubleshooting

Startup sequence

What the core does when it starts, in order. Useful for reading logs:

  1. License check against the Axium Lab service. Never blocks.
  2. Database connection, retried every second for 30 s, then the process exits.
  3. Schema: install, migrate or verify. A failed migration exits; a failed first install keeps the process up so /v1/install/status can be queried.
  4. Telemetry snapshot (once, in the background).
  5. Observability destination start (in the background; never delays the port).
  6. Listen on PORT.

Shutdown

SIGTERM or SIGINT: stop accepting connections, finish in-flight requests (streams included), close the database pool, flush the observability buffer, exit 0. After 10 s it forces exit 1. Give containers at least 15 s of grace.

Known limitations in this version

For planning, not surprises:

  • Rate limits (rate_limit_rpm, rate_limit_tpm), the fallback model, firewall.outbound, dlp_file and capture are stored but not enforced.
  • Observability traces have no built-in retention; batches are not retried.
  • Streamed responses and uploads are held in memory until complete.
  • No Anthropic dialect, no embeddings, images or audio endpoints.
  • The license is validated but not enforced.
  • Latency and error counters in daily statistics stay at zero; use traces.
  • POST /v1/install is public; restrict it at the ingress.