ARDNTECH | Self-hosting ARDNTECH · Docker, Kubernetes, air-gap

02 / Motivations

Why self-host a password manager ?

Four distinct motivations lead an organisation to operate its own B2B vault rather than subscribing to Cloud ARDNTECH SaaS. All remain compatible with a later switch should internal constraints evolve.

Radical data control

Air-gap possible, strict network isolation, internal DMZ, zero outbound telemetry. Encrypted data never leaves the perimeter you define. No third party can demand access to your instance.

Sectoral compliance made easy

Deploy at a hosting provider already qualified SecNumCloud, HDS, or meeting NIS2 and OIV requirements. The application layer stays identical; hosting compliance is carried by the infrastructure you choose.

Verifiable AGPL-3.0 code

The public repository covers the entire application codebase, down to the cryptographic primitives. OpenPGP.js v6, Argon2id, AES-256-GCM SEIPDv2, HMAC-SHA-256: every algorithm choice is readable and auditable.

Zero software cost

The AGPL-3.0 licence is free. You only pay for infrastructure (compute, storage, bandwidth) and internal operating time. For organisations whose ops team is already sized, TCO becomes competitive from a few dozen active seats.

03 / Comparison

Self-host vs Cloud ARDNTECH SaaS.

No software feature is reserved for Cloud mode. What differs is who operates the infrastructure and who bears the contractual guarantees. The table below summarises the fifteen dimensions that structure the decision.

Dimension	Self-host	Cloud ARDNTECH SaaS
Source code	AGPL-3.0, full access, fork permitted	AGPL-3.0, full access, fork permitted
Software price	€0	€0 to €7/seat/month depending on plan
Hosting	Client (own infra, IaaS of choice, dedicated datacentre)	ARDNTECH (sovereign European hosting)
Initial setup	Client's responsibility (Docker Compose or Kubernetes)	Included, automated (provisioning in minutes)
OS and runtime maintenance	Client's responsibility	Included
Backups	Client's responsibility (documented procedure)	Included, daily encrypted snapshots
Updates	Client's responsibility (tagged Docker image, upgrade plan provided)	Included, announced maintenance window
Availability SLA	None (client operates own infra)	Best effort (Free), 99.5 % (Business), negotiated (Enterprise)
Support	Community (forum, GitHub issues)	Community + email next business day (Business) + phone (Enterprise)
Multi-organisation	Yes (pivot account, granular RBAC)	Yes (pivot account, granular RBAC)
DPA	Not applicable (client is the data controller)	Standard DPA (Business) or negotiated (Enterprise)
Compliance	Client's responsibility	Qualified hosting, SecNumCloud trajectory targeted
Typical target	Cybersecurity firms with mature ops, OIV, organisations with a sized ops team	SMEs, mid-market, firms without a dedicated ops team, organisations preferring to pay rather than operate
Total cost of ownership	Variable: €0 licence + internal time + infra	Predictable: per-seat subscription, all-inclusive
Air-gap	Supported (no outbound telemetry by default)	Not applicable (instance operated by ARDNTECH)

Reading the table. For a team of fewer than fifty active seats without a dedicated ops team, Cloud SaaS is often the rational choice. Beyond that, or if infrastructure sovereignty is a regulatory or contractual requirement, self-hosting becomes relevant. Both migrations are planned and documented.

04 / Prerequisites

Technical prerequisites.

Three prerequisites only, all standard in a modern server environment. No third-party service required at runtime, no non-standard outbound ports, no proprietary protocol.

Linux server and container runtime

A Linux x86_64 or ARM64 server with Docker 24 or higher and Docker Compose v2. Debian, Ubuntu LTS, Red Hat Enterprise Linux and their derivatives are tested continuously. The container runtime works equally well on a dedicated virtual machine or on managed Kubernetes.

Sizing

2 vCPU and 4 GB of RAM are sufficient for fifty active users. For five hundred users, provision 8 vCPU and 16 GB of RAM. Storage depends on the number of secrets: allow roughly 100 MB base per thousand secrets, plus audit log retention according to your plan.

Domain name and TLS certificate

A domain name and a valid TLS certificate. Let's Encrypt is documented and works without specific configuration. No non-standard outbound port is required. Air-gap deployment is possible without modifying the application code: the instance consults no external service at runtime.

05 / Installation

Installation in five minutes.

Three supported deployment variants, from an independent firm's POC to multi-AZ production for a critical infrastructure operator. The same code, three orchestrations.

Variant 1 - Docker Compose

Recommended for POCs, small teams and development environments. A single machine, local persistence or network volume, deployment in a single command.

git clone https://github.com/aegirex/aegirex.git
cd aegirex
make install
# generates the secrets, builds the image from the repo's Dockerfile,
# applies the migrations and starts all the services.
# The instance is available at http://localhost:8280

Build from source by default. What runs in production is exactly what is in git log: no black-box registry, no dependency on a third-party Docker Hub account. The composer.lock and importmap.lock files pin the versions and SHA fingerprints of dependencies; a compromised Packagist or CDN would break the build rather than silently introducing a payload. For ops in a hurry, a make install-from-registry variant pulls the pre-built image signed by our CI.

Variant 2 - Kubernetes

Recommended in production, on managed or self-managed cluster. Official manifests and Helm chart provided. Compatible with Kubernetes clusters from SecNumCloud-qualified operators (OVHcloud, Outscale, Cloud Temple, NumSpot).

helm repo add aegirex https://charts.aegirex.eu
helm repo update
helm install aegirex aegirex/aegirex \
  --namespace aegirex --create-namespace \
  --values values.production.yaml
kubectl -n aegirex rollout status deployment/aegirex-app
kubectl -n aegirex exec deploy/aegirex-app -- bin/console doctrine:migrations:migrate

Variant 3 - Air-gap

Recommended for environments with radical sovereignty requirements: OIV, defence, classified research. No outbound connection, manual backups, updates via internal mirror registry.

# on a connected machine
docker pull ghcr.io/aegirex/aegirex:v1.4.2
docker save ghcr.io/aegirex/aegirex:v1.4.2 -o aegirex-v1.4.2.tar
# physical transfer to the air-gapped network (sealed USB, network diode)
# on the air-gapped instance
docker load -i aegirex-v1.4.2.tar
docker tag ghcr.io/aegirex/aegirex:v1.4.2 registry.internal/aegirex:v1.4.2
docker compose -f docker-compose.airgap.yml up -d
bin/console doctrine:migrations:migrate

06 / Architecture

Technical stack architecture.

A modern PHP stack, no SPA, no npm, no runtime dependency on a third-party service. Every component is documented and independently auditable.

Backend

PHP 8.4, Symfony 7.4, Doctrine ORM 3, MariaDB 11. FPM or FrankenPHP as preferred. No proprietary PHP extensions. Versioned Doctrine migrations, tested rollback.

Frontend

Twig server-side + Stimulus client-side. AssetMapper for delivery (no npm, no third-party bundler). Modular custom CSS. No SPA, no proprietary JavaScript framework.

Client-side cryptography

OpenPGP.js v6 with X25519, Ed25519 and AES-256-GCM SEIPDv2. Argon2id derivation of the master password (RFC 9106, 5 passes, 256 MiB, parallelism 4). Private keys never leave the browser.

HMAC-SHA-256 audit chain

Audit chain sealed and cryptographically chained by HMAC-SHA-256. Independent verification by a public CLI command for chain control. Detection of any retroactive tampering attempt, opposable to a judge or a CISO.

Authentication

Symfony Security + scheb/2fa-bundle: email, TOTP (RFC 6238), recovery codes. SAML 2.0 and OIDC SSO (RFC 6749 and RFC 7519). WebAuthn Passkeys (W3C WebAuthn Level 2) optional.

Storage and message queue

Everything in MariaDB 11: relational schema, blobs capped at 1 MB. No external object storage required. Message queue via Symfony Messenger + Doctrine transport, no Redis dependency for V1.

07 / Operations

Backups, maintenance, updates.

Three industrialised and documented procedures. Self-host mode transfers operational responsibility to the client, without making it a burden: commands are scriptable, idempotent and tested in continuous integration.

Encrypted backup

A CLI backup command produces an exportable file encrypted in OpenPGP format, with automatic rotation. The backup recipient is configurable (organisational archiving key). Restoration is documented and tested at each release.

Blue-green updates with zero downtime

Docker image tagged with semantic versioning on ghcr.io/aegirex/aegirex. All Doctrine migrations are structured in three steps (ADD nullable, backfill, ALTER NOT NULL) to enable blue-green deployment without service interruption even on large databases. Breaking changes are announced at least one minor version in advance.

Rollback in under five minutes

The combination of a database snapshot plus the previous Docker image allows a rollback in under five minutes. Doctrine migrations provide their tested down() method. No manual SQL schema intervention is required.

Resilient async worker

Outbound emails and audit webhooks are dispatched asynchronously via Symfony Messenger. If an external provider goes down (email, webhook recipient), HTTP requests are never blocked: jobs are retried with exponential backoff, then stored in a persistent queue if the failure persists. The worker runs as a systemd service or dedicated container, auto-restart without data loss.

Health endpoints ready for LB and Kubernetes

GET /health public for liveness probes (load balancer, UptimeRobot, Kubernetes probes). GET /health/deep protected by an IP allowlist, for in-depth checks from your internal monitoring stack (database ping, cache, message queue). No sensitive information exposed.

07bis / Sovereign observability

A monitoring stack 100% European.

Sovereignty does not stop at the application host. ARDNTECH emits its logs in structured JSON format and exposes standard Prometheus metrics, to integrate with a fully European or self-hosted observability stack. No mandatory proprietary SDK, no outbound telemetry by default.

Sovereign error tracking

Compatible with Bugsink (Netherlands, MIT, self-hostable on your SecNumCloud instance), GlitchTip (US, MIT, self-hostable) or Sentry self-host. The standard Symfony Sentry SDK is compatible with all three backends without code modification. Your errors never leave your infrastructure.

Logs and metrics managed in France

JSON logs ingestible by self-hosted Loki + Grafana, OVHcloud Logs Data Platform (managed Graylog, France) or Scaleway Cockpit (managed Loki, Mimir, Tempo, France). Prometheus metrics exposable on a dedicated endpoint, restricted by IP allowlist.

Daily integrity verification

A public CLI command verifies the integrity of the HMAC-SHA-256 audit chain. Schedulable as a daily cron, it triggers an alert (PagerDuty, internal webhook, sovereign Slack) if the chain is corrupted. Any retroactive journal tampering is detected in O(1), without relying on an external binary.

Local IP geolocation (EU sovereign)

"New connection detected" emails are enriched with country and city using the DB-IP Lite database (Belgian publisher, CC-BY 4.0 licence), resolved locally on your instance: the user's IP address is never transmitted to a third-party service. The database is refreshed automatically each month by cron.

08 / Compliance

Sectoral compliance made easy.

Self-host mode lets you carry compliance at the level of the hosting provider you have chosen. Four common regimes are documented below, without engaging ARDNTECH beyond the AGPL-3.0 application code.

SecNumCloud

Deployable at OVHcloud Hosted Private Cloud, Outscale 3DS, Cloud Temple or NumSpot, operators qualified by ANSSI. The SecNumCloud trajectory remains a targeted goal for Cloud ARDNTECH SaaS; in self-host, effective qualification depends on your hosting provider.

HDS · healthcare

Deployable at an HDS-certified host for healthcare operators. The application code fits into the end-to-end HDS chain as long as the underlying infrastructure is qualified. Long-retention audit log is natively available.

OIV and NIS2

Air-gap deployment supported. AGPL-3.0 code auditable by your CISO, down to the cryptographic primitives. The HMAC-SHA-256 audit chain produces traceability opposable to sectoral regulators.

GDPR

In self-host mode, you remain the sole data controller. No ARDNTECH sub-processor is involved in the data path. ARDNTECH is never a sub-processor under GDPR: the relationship is limited to making the AGPL-3.0 source code available.

09 / Targets

Typical use cases.

Three organisation profiles frequently choose self-host mode. The common denominator: an already-sized Linux ops team capable of running a Symfony service with a relational database in production.

Profile 1

Cybersecurity firms with mature operations

Security-focused IT services firms, cybersecurity consulting firms, internalised pentest teams. They already operate a hardened IT system, have a senior ops team, and want to apply internally the criteria they audit at their clients. Self-hosting lets them prove consistency between discourse and tooling.

Profile 2

Public sector with radical sovereignty requirements

Local authorities, agencies, essential operators under NIS2, supervised organisations. Internal policy of refusing any SaaS, even a qualified French one. Self-hosting guarantees that encrypted data and its audit chain remain strictly within the desired administrative perimeter.

Profile 3

Integrator IT firms and managed resellers

IT services firms that resell a managed ARDNTECH instance to their own clients. Self-host mode becomes a building block in their commercial offering: they operate the platform, bill their clients, and own the relationship. The AGPL-3.0 licence expressly permits this commercial use.

10 / Technical FAQ

Frequently asked questions from ops teams.

Eight recurring questions asked by CISOs and DevOps teams when evaluating self-host mode. If yours is missing, write to us.

Is the code really identical between Self-host and Cloud ?

Yes. The aegirex/aegirex repository contains the entire application codebase under AGPL-3.0. No Team, Business or Enterprise feature is reserved for Cloud mode. The only differences relate to runtime configuration (environment variables, ANSSI-track secrets, hosting settings) and the Cloud instance being tied to the supervision and billing infrastructure operated by ARDNTECH. No proprietary software module is added on the Cloud side.

How do I migrate my self-host to Cloud SaaS (and back) ?

Migration relies on a full vault export via the built-in tools (user-side decrypted JSON export, in accordance with GDPR articles 17 and 20) and import into a fresh target organisation. Migration does not preserve the audit history as-is: the audit chain restarts at the import date, the source log is kept as a downloadable archive. The HMAC key rotation on the target instance starts a new chain. Since the code is identical, schema compatibility is guaranteed.

What is the typical total annual cost of self-hosting (infra + ops) ?

The AGPL-3.0 software licence is free. For a thirty-person firm with three internal Linux servers, expect typically 50 to 150 € per month in sovereign hosting for compute and storage, plus 500 to 2,000 € per month in marginal operational cost (0.1 to 0.3 FTE for updates, backups and monitoring). Self-hosting becomes economically attractive once headcount makes the marginal ops cost negligible and the ops team is already sized accordingly. Below fifty active seats, Cloud is very often the rational choice unless there is a strict infrastructure sovereignty requirement.

How do I integrate LDAP SSO, Keycloak or Authentik ?

The Symfony Security bundle exposes SAML 2.0 and OpenID Connect. Configuration is done via environment variables, without recompilation. A valid OIDC connector for Keycloak, Authentik or any RFC 6749 and RFC 7519 compliant provider. For LDAP, direct binding is documented with group-to-RBAC-role mapping. SCIM 2.0 (RFC 7644) is available in Business for automated provisioning.

Does ARDNTECH run on managed Kubernetes (EKS, GKE, AKS, Kapsule) ?

Yes, Kubernetes deployment is documented for standard distributions. Manifests include the necessary Deployment, Service, Ingress, PersistentVolumeClaim and ConfigMap. An official Helm chart is provided with default values suited for managed clusters. For data sovereignty, using managed Kubernetes at a SecNumCloud-qualified operator (OVHcloud, Outscale, Cloud Temple, NumSpot) is recommended; extra-European managed clusters remain technically compatible but fall outside the sovereign recommendations.

What monitoring is recommended (Prometheus, OpenTelemetry, ELK) ?

The instance exposes Prometheus-compatible metrics on a dedicated endpoint, and emits OpenTelemetry traces on critical requests. Application logs are emitted in structured JSON format, directly ingestible by ELK, Loki or any standard Syslog collector. Audit events are exportable in CEF, LEEF and OCSF formats for Splunk, Elastic, QRadar and Microsoft Sentinel SIEMs. No telemetry is sent to a third-party service by default.

What is the community vs paid support plan ?

Community support goes through the public forum and GitHub issues: no SLA, maintained by contributors and the ARDNTECH team. Paid support is available for organisations wanting an audited deployment, complex SSO integration, high-availability cluster setup or an architecture review before going to production. No SLA is attached to self-host mode: by design, the client operates the infrastructure.

How do I switch to air-gap after a standard installation ?

Air-gap means removing all outbound connectivity from the ARDNTECH instance. Prerequisites are: an internal Docker mirror registry for image updates, a mirror package repository for OS dependencies, a manual channel for encrypted backup export and import. Since no telemetry is emitted by default, the application itself has no runtime dependency on an external service. Outbound webhooks can be disabled via configuration or routed to an internal relay. The full procedure is documented in the repository's air-gap guide.

11 / Go further

Self-host mode is part of a product architecture consistent with the other reference pages on the site. The resources below each detail a particular aspect.

Security and cryptography

The detailed cryptographic whitepaper: OpenPGP.js v6, Argon2id, AES-256-GCM SEIPDv2, HMAC-SHA-256.

Industry verticals

The five priority B2B verticals: security IT firms, lawyers, healthcare, defence, energy and OIV.

Trust and transparency

Legal status of ARDNTECH, jurisdiction, sub-processing chain, standard DPA.

SaaS plans and pricing

Free, Team, Business, Enterprise comparison for Cloud SaaS; reminder of zero software cost in self-host.

Vault hosted in France

Details of the Paris hosting choice for SaaS, alternative to self-hosting for teams without a dedicated ops function.

Alternative to the Cloud Act

Why a French-law publisher outside extra-European jurisdiction changes the CISO's analysis grid.

12 / Get started

Self-host ARDNTECH,
your infrastructure, your perimeter.

Read the full technical documentation on GitHub or request an audited deployment. No aggressive sales follow-up: a technical exchange on the solution's relevance in your context.

Read the technical docs Request an audited deployment

AGPL-3.0 code, full access, fork permitted

Docker Compose in under five minutes

Managed Kubernetes at a SecNumCloud-qualified operator

Air-gap supported, no outbound telemetry

HMAC-SHA-256 audit chain independently verifiable

Self-hosting ARDNTECHfree, complete, documented.