Self-hosted security checklist

This checklist is for the operator of a self-hosted aiAxonIQ deployment. It lists the security properties to confirm, why each matters, and how to tell it is in place. If you use aiAxonIQ Cloud, these are aiAxonIQ’s responsibility and you can skip this page.

​

The checklist

​

1. Strong, unique secrets

Every signing and encryption secret — session signing, license validation, internal service authentication, the notification-channel keyring and the rest — must be at least 32 characters and not a known placeholder. The services check this when they start and refuse to start if any is missing, too short, or a value published in example configuration. A missing secret is always fatal.

• Generate each value independently, from a cryptographic source — for example openssl rand -hex 32 — rather than deriving one from another.
• Never reuse a secret between environments. A staging secret that also works in production makes staging’s weakest point production’s.
• Keep the environment file readable only by the account that runs the stack, and out of version control.
• Escrow a copy somewhere that does not depend on the host. The notification-channel keyring in particular decrypts every saved channel credential; if it is lost, those channels must be re-entered.

​

2. Only the reverse proxy faces the network

In the supported deployment, the application services publish their ports on the host’s loopback interface only, and the data stores — the relational database, the analytical store, the search index, the message queue, the cache and the vector store — publish none at all. Everything external arrives through the reverse proxy. Verify it from another machine: only the proxy’s HTTPS port (and its HTTP port, which should only redirect) should answer on the host’s public address.

​

3. Keep the AI service private

The AI service holds the credential for your model provider and reads telemetry on the API’s behalf. It refuses any request that does not carry the API’s service credential, and it takes each request’s organization from a binding the API issues rather than from the request. Keep it that way: do not publish its port, and do not add a proxy route to it. Nothing but the API should call it. If you use AI features that call a model provider, the AI service will only send to hosts on its allow-list. Pointing it at a self-hosted model, or at a provider outside the defaults, needs that host added deliberately — which is the point. See Data handling.

​

4. TLS at the edge

TLS terminates at the reverse proxy. The proxy configuration supplied with the deployment:

• accepts TLS 1.2 and 1.3 only;
• redirects plain HTTP to HTTPS;
• sends Strict-Transport-Security, X-Frame-Options: DENY and X-Content-Type-Options: nosniff.

Session cookies are always marked Secure in a production environment, so sign-in will not persist over plain HTTP. If users are signed out on every page load, check that they reached the product over HTTPS before anything else. Renew certificates before they expire — an expired certificate stops every collector sending telemetry at once, and most will not tell you why.

​

5. Decide who can sign up

Self-service sign-up is open unless it is explicitly turned off. That default is deliberate — a mistyped setting must not lock a product out of its own front door — and it means a deployment that never mentions the setting accepts registrations from anyone who can reach it. If only invited people should have accounts, turn self-service sign-up off and confirm it: the sign-up page should say registration is closed, and the “Create one” link on the sign-in page should be gone. The setting is read at runtime, so changing it needs a restart, not a rebuild. Invitations, email verification, password resets and one-time codes all need an SMTP server configured. Without one they fail with an explicit error rather than appearing to succeed.

​

6. Remove the search index’s default accounts

The log search index runs the stock OpenSearch image with its security plugin enabled. On first start that image creates a set of built-in accounts, several of whose passwords are published in upstream documentation. The deployment procedure removes them on every deploy, leaving a single account whose password comes from your environment file. It refuses to proceed if the password in the environment does not match the running cluster, rather than guessing which is right.

​

7. Backups you can restore

The deployment runs scheduled backups of the control-plane database and the telemetry store. Two further properties are settings you choose, and both are off until you set them:

• Off-host copies. Backups can be copied to any S3-compatible object store. Until they are, a backup lives on the same host as the data it protects.
• Encryption. Backups can be encrypted with age to a public key you supply, before they leave the host. Without it, backup files are plaintext on the host and in the object store.

Then restore one. Restoring into a scratch environment, on a schedule, is the only evidence a backup works. Erasing an organization does not edit backups taken before the erasure, so your backup retention decides how long a deleted organization’s data survives in them — choose it deliberately.

​

8. Rotate credentials

Rotate on a schedule, and immediately after anyone with access to the environment file leaves. Each key and channel change is recorded in the Audit log, which is also where to look first after a suspected leak.

​

Next