> ## Documentation Index > Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt > Use this file to discover all available pages before exploring further. # Self-hosted security checklist > What to verify when you operate aiAxonIQ in your own environment: strong secrets, private internal services, TLS at the edge, secure sign-up settings, encrypted off-host backups and credential rotation. 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. **This page says what to check, not how to install.** The installation, upgrade, backup and restore procedures are delivered with your deployment, matched to the release you run — see [Onboarding: self-hosted](/onboarding/self-hosted). Where a step below needs a setting changed, those procedures name it for your release. ## The checklist | # | Check | Why | | :- | :----------------------------------------------------------------- | :----------------------------------------------------------------------------- | | 1 | Every secret is strong, unique and generated for this deployment | Services refuse to start otherwise, and a shared secret is a shared compromise | | 2 | Only the reverse proxy is reachable from outside the host | Internal services and data stores are not designed to face a network | | 3 | The AI service is reachable only by the API | It holds your model-provider credential and reads telemetry | | 4 | TLS terminates at the reverse proxy, and HTTP redirects to HTTPS | Session cookies are sent only over HTTPS | | 5 | Self-service sign-up is set the way you intend | It is open unless it is explicitly turned off | | 6 | The search index has one account, not the image's defaults | The stock image ships accounts with published passwords | | 7 | Backups run, leave the host, are encrypted, and have been restored | A backup that has never been restored is a hypothesis | | 8 | You have a rotation plan for every credential | Leaks are found late; rotation is how you recover | ## 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. **There is a development-only override that permits weak values. It has no effect in a production environment, and it must never be set on a real deployment.** If a service will not start and its log names a secret, fix the secret — do not look for a way around the check. * **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. **OTLP over gRPC is bound to loopback by default.** External ingest is OTLP over HTTP through the proxy, under the `/otlp` prefix. If you need gRPC from outside the host, route it through the proxy with TLS rather than publishing the listener directly. See [Endpoints and errors](/send-data/endpoints). ## 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](/security/data-handling#ai-features-and-model-providers). ## 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. **Recreating the search index's data volume re-creates the default accounts.** They are removed again by the next deploy. After any operation that recreates that volume, run the deploy — or its hardening step — before exposing the host to anything else. ## 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](https://age-encryption.org) 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. **Keep the age private key off the host.** A private key stored beside the backups it decrypts protects nothing. Keep it where your recovery plan can reach it when the host is gone. 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 | Credential | How to rotate | Effect | | :------------------------------- | :---------------------------------------------------------------------------------------------- | :------------------------------------------------------------------- | | License keys | Rotate or revoke from **Settings → API keys** (Admin) | A revoked key stops being accepted within seconds | | Service-account tokens | Rotate or revoke from **Settings → Service accounts** (Admin), where your release includes them | Rotation can overlap old and new tokens so automation is not cut off | | A user's sessions | **Sign out everywhere**, or change the user's role or remove them | Their existing sessions stop at the next request | | Notification-channel credentials | Edit the channel with the new webhook URL, routing key or API key | The old credential is no longer used | | The notification-channel keyring | Add a new key as the primary and keep the old one until every channel has been re-saved | Existing channels keep working throughout | | Session signing secret | Replace it and restart | **Every** session ends; everyone signs in again | 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](/guides/audit), which is also where to look first after a suspected leak. ## Next The controls this checklist is protecting. What differs when aiAxonIQ runs in your environment. Retention, erasure, backups and model providers.