Solidaridad con Ucrania. Servicio gratuito para empresas ucranianas mientras dure la guerra. Solicitar acceso gratuito
01 / Despliegue · Autoalojamiento

Autoalojamiento ARDNTECH
libre, completo, documentado.

ARDNTECH se entrega bajo un código fuente único AGPL-3.0, ejecutable tanto en la infraestructura de ARDNTECH como en la suya. El modo self-host cubre la totalidad de las funcionalidades Team, Business y Enterprise sin restricción : RBAC granular, SCIM 2.0, SSO SAML 2.0 y OIDC, audit log de larga duración. Usted opera su instancia en el datacenter de su elección, en Docker Compose, en Kubernetes gestionado en un operador cualificado SecNumCloud o en despliegue air-gap estricto.

Leer la documentación técnica en GitHub Ver la instalación en 5 minutos
AGPL-3.0 Docker Compose Kubernetes Air-gap soportado Sin telemetría saliente
02 / Motivaciones

¿Por qué autoalojar un gestor de contraseñas ?

Cuatro motivaciones distintas llevan a una organización a operar ella misma su almacén de secretos B2B en lugar de suscribirse al SaaS Cloud ARDNTECH. Todas siguen siendo compatibles con un cambio posterior en caso de evolución de las restricciones internas.

Control radical de los datos

Air-gap posible, aislamiento de red estricto, DMZ interna, ausencia total de telemetría saliente. Los datos cifrados nunca abandonan el perímetro que usted define. Ningún tercero puede requerir el acceso a su instancia.

Conformidad sectorial facilitada

Despliegue en un proveedor de alojamiento ya cualificado SecNumCloud, HDS, o con las exigencias NIS2 y OIV. La capa de la aplicación permanece idéntica, la conformidad del alojamiento la aporta la infraestructura de su elección.

Código AGPL-3.0 verificable

El repositorio público cubre la totalidad del código de la aplicación, hasta las primitivas criptográficas. OpenPGP.js v6, Argon2id, AES-256-GCM SEIPDv2, HMAC-SHA-256 : cada elección de algoritmo es legible y auditable.

Coste de software nulo

La licencia AGPL-3.0 es gratuita. Usted solo paga la infraestructura (compute, almacenamiento, ancho de banda) y el tiempo interno de operación. Para las estructuras cuyo equipo ops ya está dimensionado, el TCO se vuelve competitivo a partir de unas pocas decenas de puestos activos.

03 / Comparativa

Self-host vs SaaS Cloud ARDNTECH.

Ninguna funcionalidad de software está reservada al modo Cloud. Lo que difiere es quién explota la infraestructura y quién asume las garantías contractuales. La tabla siguiente resume las quince dimensiones que estructuran la decisión.

Dimensión Self-host SaaS Cloud ARDNTECH
Código fuente AGPL-3.0, acceso completo, fork autorizado AGPL-3.0, acceso completo, fork autorizado
Tarifa de software 0 € De 0 € a 7 €/puesto/mes según el plan
Alojamiento Cliente (infraestructura propia, IaaS de su elección, datacenter dedicado) ARDNTECH (alojador soberano europeo)
Configuración inicial A cargo del cliente (Docker Compose o Kubernetes) Incluida, automatizada (aprovisionamiento en unos minutos)
Mantenimiento del OS y del runtime A cargo del cliente Incluido
Copias de seguridad A cargo del cliente (procedimiento documentado) Incluidas, snapshots diarios cifrados
Actualizaciones A cargo del cliente (imagen Docker etiquetada, plan de actualización proporcionado) Incluidas, ventana de mantenimiento anunciada
SLA de disponibilidad Ninguno (el cliente opera su infraestructura) Best effort (Free), 99,5 % (Business), negociado (Enterprise)
Soporte Comunitario (foro, issues GitHub) Comunitario + correo electrónico en J+1 laborable (Business) + teléfono (Enterprise)
Multiorganización Sí (cuenta-pivote, RBAC granular) Sí (cuenta-pivote, RBAC granular)
DPA No aplicable (el cliente es responsable del tratamiento) DPA estandarizado (Business) o negociado (Enterprise)
Conformidad A cargo del cliente Alojador cualificado, trayectoria SecNumCloud aspirada
Objetivo típico Despachos de ciberseguridad con ops maduras, OIV, organizaciones que ya cuentan con un equipo de ops dimensionado Microempresas, pymes, empresas medianas, despachos sin equipo de ops dedicado, estructuras que prefieren pagar para no operar
Coste total de propiedad Variable : 0 € de licencia + tiempo interno + infraestructura Previsible : suscripción por puesto, todo incluido
Air-gap Soportado (sin telemetría saliente por defecto) No aplicable (instancia operada por ARDNTECH)

Lectura de la tabla. Para un equipo de menos de cincuenta puestos activos sin equipo de ops dedicado, el SaaS Cloud suele ser la opción racional. Por encima de ese umbral, o si la soberanía de la infraestructura es una exigencia reglamentaria o contractual, el self-host resulta pertinente. Ambas migraciones están previstas y documentadas.

04 / Requisitos previos

Requisitos técnicos.

Tres requisitos previos solamente, todos estándar en un entorno de servidor moderno. Ningún servicio de terceros obligatorio en ejecución, ningún puerto saliente no estándar, ningún protocolo propietario.

Servidor Linux y runtime container

Un servidor Linux x86_64 o ARM64 con Docker 24 o superior y Docker Compose v2. Debian, Ubuntu LTS, Red Hat Enterprise Linux y sus derivados se prueban de forma continua. El runtime container funciona tanto en máquina virtual dedicada como en Kubernetes gestionado.

Dimensionamiento

2 vCPU y 4 GB de RAM bastan para cincuenta usuarios activos. Para quinientos usuarios, prevea 8 vCPU y 16 GB de RAM. El almacenamiento depende del número de secretos : cuente aproximadamente 100 MB de base por cada mil secretos, más la retención de los logs de auditoría según su plan.

Nombre de dominio y certificado TLS

Un nombre de dominio y un certificado TLS válido. Let's Encrypt está documentado y funciona sin configuración específica. No se requiere ningún puerto saliente no estándar. Un despliegue air-gap es posible sin modificación del código de la aplicación : la instancia no consulta ningún servicio externo en runtime.

05 / Instalación

Instalación en cinco minutos.

Tres variantes de despliegue soportadas, desde el POC de un despacho independiente hasta la producción multi-AZ de un operador de importancia vital. El mismo código, tres orquestaciones.

Variante 1 - Docker Compose

Recomendado para los POC, los equipos pequeños y los entornos de desarrollo. Una sola máquina, persistencia local o volumen de red, despliegue en un solo comando. 

git clone https://github.com/aegirex/aegirex.git
cd aegirex
make install
# genera los secretos, construye la imagen desde el Dockerfile del repo,
# aplica las migraciones e inicia todos los servicios.
# La instancia está disponible en http://localhost:8280

Build desde el código fuente por defecto. Lo que se ejecuta en producción es exactamente lo que se encuentra en git log : sin caja negra de registry, sin dependencia de una cuenta Docker Hub de terceros. Los ficheros composer.lock e importmap.lock fijan las versiones y las huellas SHA de las dependencias ; un Packagist o un CDN comprometido rompería el build en lugar de introducir silenciosamente un payload. Para los ops con prisa, una variante make install-from-registry descarga la imagen pre-construida firmada por nuestra CI.

Variante 2 - Kubernetes

Recomendado en producción, en clúster gestionado o autogestionado. Manifiestos oficiales y chart Helm proporcionados. Compatible con los clústeres Kubernetes de los operadores cualificados SecNumCloud (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

Variante 3 - Air-gap

Recomendado para entornos de soberanía radical : OIV, defensa, investigación clasificada. Sin conexión saliente, copias de seguridad manuales, actualizaciones mediante registro espejo interno. 

# en equipo conectado
docker pull ghcr.io/aegirex/aegirex:v1.4.2
docker save ghcr.io/aegirex/aegirex:v1.4.2 -o aegirex-v1.4.2.tar
# transferencia física a la red air-gap (USB sellado, diodo de red)
# en instancia air-gap
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 / Arquitectura

Arquitectura técnica del stack.

Un stack PHP moderno, sin SPA, sin npm, sin dependencia runtime de un servicio de terceros. Cada bloque está documentado y es auditable de forma independiente.

Backend

PHP 8.4, Symfony 7.4, Doctrine ORM 3, MariaDB 11. FPM o FrankenPHP a elección. Ninguna extensión PHP propietaria. Migraciones Doctrine versionadas, rollback probado.

Frontend

Twig del lado del servidor + Stimulus del lado del cliente. AssetMapper para la entrega (sin npm, sin bundler de terceros). CSS custom modular. Sin SPA, sin framework JavaScript propietario.

Criptografía del lado del cliente

OpenPGP.js v6 con X25519, Ed25519 y AES-256-GCM SEIPDv2. Derivación Argon2id de la contraseña maestra (RFC 9106, 5 pasadas, 256 MiB, paralelismo 4). Las claves privadas nunca abandonan el navegador.

Audit chain HMAC-SHA-256

Cadena de auditoría sellada y encadenada criptográficamente mediante HMAC-SHA-256. Verificación independiente mediante un comando CLI público de control de la cadena. Detección de toda tentativa de falsificación retroactiva, oponible ante el juez como ante el RSSI.

Autenticación

Symfony Security + scheb/2fa-bundle : correo electrónico, TOTP (RFC 6238), códigos de recuperación. SSO SAML 2.0 y OIDC (RFC 6749 y RFC 7519). Passkeys WebAuthn (W3C WebAuthn Level 2) opcionales.

Almacenamiento y cola de espera

Todo en MariaDB 11 : esquema relacional, blobs limitados a 1 MB. Sin almacenamiento de objetos externo requerido. Cola de espera mediante Symfony Messenger + transporte Doctrine, sin dependencia de Redis para la V1.

07 / Operaciones

Copias de seguridad, mantenimiento, actualizaciones.

Tres procedimientos industrializados y documentados. El modo self-host transfiere la responsabilidad operativa al cliente, sin convertirla en una carga : los comandos son scriptables, idempotentes y probados en integración continua.

Copia de seguridad cifrada

Un comando CLI de copia de seguridad produce un archivo exportable cifrado en formato OpenPGP, con rotación automática. El destinatario de la copia de seguridad es configurable (clave de archivado organizacional). La restauración está documentada y probada en cada release.

Actualizaciones blue-green sin downtime

Imagen Docker etiquetada en semantic versioning en ghcr.io/aegirex/aegirex. Todas las migraciones Doctrine están estructuradas en tres etapas (ADD nullable, backfill, ALTER NOT NULL) para permitir un despliegue blue-green sin interrupción del servicio incluso en bases de datos voluminosas. Los cambios breaking se anuncian al menos una versión menor por adelantado.

Rollback en menos de cinco minutos

La combinación de snapshot de base de datos más imagen Docker anterior permite una vuelta atrás en menos de cinco minutos. Las migraciones Doctrine proporcionan su método down() probado. No se requiere ninguna intervención manual sobre el esquema SQL.

Worker asíncrono resiliente

Los correos electrónicos salientes y los webhooks de auditoría se despachan de forma asíncrona mediante Symfony Messenger. Si un proveedor externo cae (correo electrónico, webhook destinatario), las solicitudes HTTP nunca se bloquean : los jobs se reintentan con backoff exponencial, luego se almacenan en cola persistente si el fallo persiste. El worker se ejecuta en servicio systemd o contenedor dedicado, reinicio automático sin pérdida.

Endpoints de salud listos para LB y Kubernetes

GET /health en público para las sondas de liveness (load balancer, UptimeRobot, sondas Kubernetes). GET /health/deep protegido por una allowlist de direcciones IP, para los controles en profundidad desde su stack de monitorización interno (ping base de datos, caché, cola de espera). Ninguna información sensible expuesta.

07bis / Observabilidad soberana

Un stack de monitorización 100 % europeo.

La soberanía no se detiene en el proveedor de alojamiento de la aplicación. ARDNTECH emite sus logs en formato JSON estructurado y expone métricas Prometheus estándar, para integrarse en un stack de observabilidad totalmente europeo o autoalojado. Ningún SDK propietario obligatorio, ninguna telemetría saliente por defecto.

Tracking de errores soberano

Compatible con Bugsink (Países Bajos, MIT, autoalojable en su instancia SecNumCloud), GlitchTip (EE. UU., MIT, autoalojable) o Sentry self-host. El SDK Sentry estándar de Symfony es compatible con estos tres backends sin modificación de código. Sus errores nunca abandonan su infraestructura.

Logs y métricas gestionados en Francia

Logs JSON ingestables por Loki + Grafana autoalojado, OVHcloud Logs Data Platform (Graylog gestionado, Francia) o Scaleway Cockpit (Loki, Mimir, Tempo gestionados, Francia). Métricas Prometheus exponibles en un endpoint dedicado, restringido por allowlist de direcciones IP.

Verificación de integridad diaria

Un comando CLI público permite verificar la integridad de la cadena de auditoría HMAC-SHA-256. Planificable en cron diario, desencadena una alerta (PagerDuty, webhook interno, Slack soberano) si la cadena está corrupta. Toda alteración retroactiva del registro se detecta en O(1), sin depender de un binario externo.

Geolocalización IP local (soberano UE)

Los correos electrónicos «Nueva conexión detectada» se enriquecen con el país y la ciudad gracias a la base DB-IP Lite (editor belga, licencia CC-BY 4.0), resuelta localmente en su instancia : la dirección IP del usuario nunca se transmite a un servicio de terceros. La base se actualiza automáticamente cada mes mediante cron.

08 / Conformidad

Conformidad sectorial facilitada.

El modo self-host le permite trasladar la conformidad al nivel del alojador que usted haya elegido. A continuación se documentan cuatro regímenes habituales, sin comprometer a ARDNTECH más allá del código de la aplicación bajo AGPL-3.0.

SecNumCloud

Desplegable en OVHcloud Hosted Private Cloud, Outscale 3DS, Cloud Temple o NumSpot, operadores cualificados por la ANSSI. La trayectoria SecNumCloud sigue siendo un objetivo aspirado para el SaaS Cloud ARDNTECH ; en self-host, la cualificación efectiva depende de su alojador.

HDS · salud

Desplegable en un alojador certificado HDS para los operadores sanitarios. El código de la aplicación se integra en la cadena HDS de extremo a extremo siempre que la infraestructura subyacente esté cualificada. El audit log de larga duración está disponible de forma nativa.

OIV y NIS2

Despliegue air-gap soportado. Código AGPL-3.0 auditable por su RSSI, hasta las primitivas criptográficas. La audit chain HMAC-SHA-256 produce una trazabilidad oponible ante las autoridades de control sectoriales.

RGPD

En modo self-host, usted sigue siendo el único responsable del tratamiento. Ningún subcontratista de ARDNTECH interviene en el flujo de datos. ARDNTECH nunca es subcontratista en el sentido del RGPD : la relación se limita a la puesta a disposición del código fuente AGPL-3.0.

09 / Objetivos

Casos de uso típicos.

Tres perfiles de organizaciones eligen frecuentemente el modo self-host. El punto en común : un equipo ops Linux ya dimensionado y capaz de operar un servicio Symfony con base relacional en producción.

Perfil 1

Despachos de ciberseguridad con operaciones maduras

ESN seguridad, despachos de consultoría de ciberseguridad, equipos de pentest internalizados. Ya operan un SI endurecido, disponen de un equipo ops senior y quieren aplicar internamente los criterios que auditan en sus clientes. El self-host les permite probar la coherencia entre el discurso y las herramientas.

Perfil 2

Sector público de soberanía radical

Entidades públicas, agencias, operadores esenciales en el sentido de NIS2, organizaciones bajo tutela. Política interna de rechazo de todo SaaS, incluso francés cualificado. El self-host garantiza que el dato cifrado y su audit chain permanezcan estrictamente dentro del perímetro administrativo deseado.

Perfil 3

ESN integradores y revendedores gestionados

ESN que revenden a sus propios clientes una instancia ARDNTECH gestionada por ellos mismos. El modo self-host se convierte en un bloque de su oferta comercial : operan la plataforma, facturan a sus clientes y conservan la relación. La licencia AGPL-3.0 autoriza expresamente este uso comercial.

10 / FAQ técnica

Preguntas frecuentes de los equipos de ops.

Ocho preguntas recurrentes planteadas por los RSSI y los equipos DevOps durante la evaluación del modo self-host. Si falta la suya, escríbanos.

¿Es el código realmente idéntico entre Self-host y Cloud ?

Sí. El repositorio aegirex/aegirex contiene la totalidad del código de la aplicación bajo AGPL-3.0. Ninguna funcionalidad Team, Business o Enterprise está reservada al modo Cloud. Las únicas diferencias residen en la configuración del runtime (variables de entorno, secrets ANSSI-track, parametrización del alojador) y en la vinculación de la instancia Cloud a la infraestructura de supervisión y de facturación explotada por ARDNTECH. No se añade ningún módulo de software propietario en el lado Cloud.

¿Cómo migrar mi self-host al SaaS Cloud (y a la inversa) ?

La migración se basa en la exportación completa de la bóveda mediante las herramientas integradas (exportación JSON descifrada del lado del usuario, conforme a los artículos 17 y 20 del RGPD) y la importación en una organización de destino nueva. La migración no preserva el historial de auditoría tal cual : la audit chain se reinicia en la fecha de importación, el registro de origen se conserva en un archivo descargable. La rotación de las claves HMAC de auditoría del lado de la instancia de destino inicia una nueva cadena. Como el código es idéntico, la compatibilidad de esquema está garantizada.

¿Cuál es el coste total anual típico de un self-host (infraestructura + ops) ?

La licencia de software AGPL-3.0 es gratuita. Para un despacho de treinta personas con tres servidores Linux internos, cuente normalmente con 50 a 150 € al mes de alojador soberano para el compute y el almacenamiento, más 500 a 2 000 € al mes de coste operativo marginal (0,1 a 0,3 ETC para actualizaciones, copias de seguridad y supervisión). El self-host resulta económicamente interesante a partir de plantillas en las que el coste de ops marginal se vuelve insignificante y en las que el equipo de ops ya está dimensionado. Por debajo de cincuenta puestos activos, el Cloud es muy a menudo la opción racional, salvo una exigencia estricta de soberanía de la infraestructura.

¿Cómo integrar el SSO LDAP, Keycloak o Authentik ?

El bundle Symfony Security expone SAML 2.0 y OpenID Connect. La configuración se realiza mediante variables de entorno, sin recompilación. Un conector OIDC válido para Keycloak, Authentik o cualquier proveedor conforme a las RFC 6749 y RFC 7519. Para LDAP, el binding directo está documentado con mapeo de los grupos a los roles RBAC. El SCIM 2.0 (RFC 7644) está disponible en Business para el aprovisionamiento automatizado.

¿Funciona ARDNTECH en Kubernetes gestionado (EKS, GKE, AKS, Kapsule) ?

Sí, el despliegue Kubernetes está documentado para las distribuciones estándar. Los manifiestos incluyen los Deployment, Service, Ingress, PersistentVolumeClaim y ConfigMap necesarios. Se proporciona un chart Helm oficial con valores por defecto adaptados a los clústeres gestionados. Para la soberanía de los datos, se recomienda el uso de Kubernetes gestionado en un operador cualificado SecNumCloud (OVHcloud, Outscale, Cloud Temple, NumSpot) ; los clústeres gestionados extraeuropeos siguen siendo técnicamente compatibles, pero quedan fuera del marco de las recomendaciones soberanas.

¿Qué monitorización se recomienda (Prometheus, OpenTelemetry, ELK) ?

La instancia expone métricas compatibles con Prometheus en un endpoint dedicado, y emite trazas OpenTelemetry sobre las peticiones críticas. Los logs de la aplicación se emiten en formato JSON estructurado, ingeribles directamente por ELK, Loki o cualquier colector Syslog estándar. Los eventos de auditoría son exportables en los formatos CEF, LEEF y OCSF para los SIEM Splunk, Elastic, QRadar y Microsoft Sentinel. No se envía ninguna telemetría a un servicio de terceros por defecto.

¿Cuál es el plan de soporte comunitario frente al de pago ?

El soporte comunitario se canaliza a través del foro público y de las issues GitHub : sin compromiso de plazo, animado por los contribuidores y el equipo ARDNTECH. Hay disponible un acompañamiento de pago para las organizaciones que deseen un despliegue auditado, una integración SSO compleja, la puesta en marcha de un clúster de alta disponibilidad o una revisión de arquitectura antes de la puesta en producción. Ningún SLA está vinculado al modo self-host : por construcción, es el cliente quien opera la infraestructura.

¿Cómo pasar a air-gap tras una instalación estándar ?

El air-gap consiste en suprimir toda conectividad saliente de la instancia ARDNTECH. Los requisitos previos son : un registro Docker espejo interno para las actualizaciones de imágenes, un repositorio de paquetes espejo para las dependencias del OS, un canal manual de exportación e importación de las copias de seguridad cifradas. Como no se emite ninguna telemetría por defecto, la propia aplicación no tiene ninguna dependencia de runtime de un servicio externo. Los webhooks salientes pueden desactivarse por configuración, o enrutarse hacia un relé interno. El procedimiento completo está documentado en la guía air-gap del repositorio.

11 / Para ir más allá

El modo self-host se inscribe en una arquitectura de producto coherente con las demás páginas de referencia del sitio. Los recursos siguientes detallan cada uno un aspecto particular.

Seguridad y criptografía

El whitepaper criptográfico detallado : OpenPGP.js v6, Argon2id, AES-256-GCM SEIPDv2, HMAC-SHA-256.

Sectores de actividad

Los cinco verticales B2B prioritarios : ESN seguridad, abogados, salud, defensa, energía y OIV.

Confianza y transparencia

Estatuto jurídico de ARDNTECH, jurisdicción, cadena de subcontratación, DPA estandarizado.

Planes y tarificación SaaS

Comparativa Free, Team, Business, Enterprise para el SaaS Cloud ; recordatorio de la gratuidad del software en self-host.

Almacén de secretos alojado en Francia

Detalle de la elección de alojamiento en París para el SaaS, alternativa al self-host para los equipos sin ops dedicado.

Alternativa al Cloud Act

Por qué un editor de derecho francés fuera de jurisdicción extraeuropea cambia la matriz de análisis del RSSI.
12 / Empezar

Self-host ARDNTECH,
su infraestructura, su perímetro.

Lea la documentación técnica completa en GitHub o solicite un acompañamiento auditado para un despliegue en producción. Sin seguimientos comerciales agresivos : un intercambio técnico sobre la pertinencia de la solución en su contexto.

Leer la documentación técnica Solicitar un acompañamiento auditado
Código AGPL-3.0, acceso completo, fork autorizado
Docker Compose en menos de cinco minutos
Kubernetes gestionado en un operador cualificado SecNumCloud
Air-gap soportado, sin telemetría saliente
Audit chain HMAC-SHA-256 verificable de forma independiente