Installation security

This page brings together the installation's security controls in version 3.7 and the current limits, for review by your information security team.

Isolation of the server's Docker

The API never receives the Docker socket. A separate service, docker-guard, with no network, is the only one with that access and allows nothing but the management of local models:

• Only this installation's containers, never those of another Compose project.
• Containers created only from the known runtime images, with this installation's labels and network and named volumes of their own.
• Device access limited to NVIDIA GPUs or /dev/dri, and only for model containers.
• No privileged mode, no host mounts, no host network, and no added capabilities.
• The platform's own containers cannot be stopped or removed through it.

Every refusal is recorded in the docker-guard log.

Secrets and credentials

• Each installation generates its own APP_SECRET and unique credentials for PostgreSQL, Redis, and MinIO. In production, short (fewer than 32 characters) or weak secrets are refused.
• Files generated by the installation are readable only by their owner.
• Provider keys and integration credentials are encrypted in the database with XChaCha20-Poly1305, bound to each secret's scope and name.
• Passwords are stored with an Argon2 hash.
• Secrets never reach the browser.

Authentication and sessions

• Local sign-in with a password of at least 12 characters and a temporary lockout after repeated failures.
• OIDC SSO with Microsoft Entra ID, Google Workspace, or any OIDC provider; multi-factor authentication is handled by the identity provider.
• A root account outside SSO, recoverable on the server with a single-use key verified offline.
• Sessions in HttpOnly, SameSite=Strict cookies, with Secure behind HTTPS.

See Users, roles, and access.

Outbound protection

URLs a user can influence go through SSRF protection: private, loopback, link-local, CGNAT, and cloud metadata addresses are blocked unless explicitly allowed in APTABIT_SSRF_ALLOWED_HOSTS. Integration calls do not follow redirects. See Integrations.

Network and TLS

The platform's proxy serves HTTP on a single port (8080 by default). TLS is terminated at the organization's load balancer or reverse proxy. The CLI trusts the system's certificate authorities, so it works behind corporate proxies that inspect HTTPS.

Distribution and integrity

• The install script checks the CLI against the release manifest signed by Aptabit (Ed25519). aptabit self-update runs the same check before replacing the binary.
• Images come from a private registry, with short-lived credentials that Aptabit Manager issues to an active license in response to a request signed with the installation's identity.
• Each image received carries a provenance statement signed by Aptabit Manager that identifies who received it.
• Each installation has an Ed25519 key pair generated on the machine itself; Aptabit Manager keeps only the public key.

Data at rest

Documents, tables, vectors, and files stay in the installation's PostgreSQL, MinIO (or S3 service), and Milvus. Secrets are encrypted by the platform; encryption of volumes and object storage is provided by your organization's infrastructure, on disk or in the S3 service.

Current limits

• Each installation runs on a single server. High availability depends on externally managed PostgreSQL, Redis, S3, and Milvus.
• Isolation between organizations is enforced by the application, with one organization per installation; the database does not use row-level security.
• The audit trail is not erased by purges and cannot be edited through the API, but the database does not enforce technical immutability.
• CLI backups are local and unencrypted. See Operations.