Deployment Considerations

The supplied Compose service publishes only on 127.0.0.1, runs non-root, drops all capabilities, prevents privilege escalation, and uses a read-only root filesystem.

For team access, place a trusted TLS/SSO reverse proxy with rate limiting in front of Akritas. Set a long random inbound key even behind the proxy. Mount indexes and diagnostic workspaces read-only. Mount a workspace writable only when Apply is required.

Protect and back up the audit volume. Isolate MCP executables and external validators according to their real OS authority. In particular, go-test runs repository code and needs a container or VM boundary where that code is untrusted.

Notification configuration and every receiver URL are trusted operator configuration. Allow outbound network access only to selected hosts, keep bot, Bearer, and HMAC secrets in a secret-backed environment, and mount the JSON configuration read-only. A generic webhook receives the complete investigation result; Telegram and Mattermost receive a compact rendering. For guaranteed delivery, place a durable queue behind the generic webhook because the built-in dispatcher has no persistent retry.

Each alert source has its own authentication policy. Expose only configured /api/v1/alerts/*/webhook routes, preserve their authentication headers and exact request bodies through the reverse proxy, and apply request-rate limits. The provider payload limit is 1 MiB. Protect and back up both the Run audit journal and the separate alert/incident/job journal.

Telegram polling requires only outbound TLS access to the Bot API and no public route. For webhook mode, publish only the provider callback routes /api/v1/bots/telegram/*/webhook and /api/v1/bots/mattermost/*/webhook. The reverse proxy must preserve the Telegram secret header, limit the body to 64 KiB, and apply rate limiting without injecting the common Akritas API key. These endpoints verify their own provider secret and allowlists. Do not include secrets or complete request bodies in proxy logs.