Keycloak vs authentik vs Zitadel en un solo VPS

Qué servidor SSO se adapta a un VPS

Keycloak, authentik y Zitadel son servidores de inicio de sesión único (SSO) autohospedados que suelen considerarse cuando se quiere usar una sola cuenta para todas las aplicaciones del servidor. En un VPS pequeño no son intercambiables. authentik es la opción predeterminada más segura para un equipo que ejecuta tres o cuatro aplicaciones autohospedadas, porque es el único de los tres que puede mostrar una pantalla de inicio de sesión delante de una aplicación que no tiene autenticación propia. Keycloak es la opción adecuada cuando todas las aplicaciones protegidas ya admiten un protocolo estándar y se dispone de memoria suficiente para una máquina virtual Java (JVM). Zitadel está diseñado para desarrolladores que distribuyen un producto mediante una API, y no intentaría ejecutarlo con menos de 4 GB.

Elija primero y después instale. Una vez elegido el producto, la instalación práctica de authentik en un VPS explica la configuración paso a paso.

¿Cuánta RAM necesita realmente cada uno?

Empiece por el mínimo de recursos, porque determina la lista de opciones antes que cualquier funcionalidad. Las cifras siguientes son los valores publicados por cada proyecto, consultados en agosto de 2026. Son recomendaciones del proveedor, no resultados de una prueba de carga.

[
  {
    "label": "authentik",
    "vendor_min_ram_mb": 2048,
    "base_containers": 3
  },
  {
    "label": "Keycloak",
    "vendor_min_ram_mb": 1250,
    "base_containers": 2
  },
  {
    "label": "Zitadel",
    "vendor_min_ram_mb": 2048,
    "base_containers": 4
  }
]

La página de instalación de authentik con Docker Compose solicita «un host con al menos 2 núcleos de CPU y 2 GB de RAM», es decir, 2048 MB, y el archivo compose publicado ejecuta 3 contenedores: PostgreSQL, el servidor y el worker.

Keycloak publica la cifra más específica de las 3. Su guía de dimensionamiento indica que «el uso de memoria base de un Pod, incluidos los cachés de datos de Realm y 10.000 sesiones en caché, es de 1250 MB de RAM». Esos 1250 MB cubren únicamente el proceso Java, antes de incluir la base de datos. La misma página explica por qué importa tanto el límite del contenedor: Keycloak usa el 70 % del límite de memoria como heap y necesita aproximadamente 300 MB de memoria no heap adicionales. Si asigna 1 GB al contenedor, calcula un heap de unos 717 MB y sigue necesitando esos 300 MB de memoria no heap, por lo que el límite ya está agotado antes de que los datos de sesión lleguen a la caché.

La página de compose de Zitadel también solicita 2 GB, los mismos 2048 MB, pero esa cifra corresponde a la primera ejecución. Debe consultar su página de producción. El proceso de Zitadel necesita «aproximadamente 512MB de RAM y puede funcionar con menos de un núcleo de CPU». La base de datos es la parte que más recursos consume: «aproximadamente un núcleo de CPU por cada 100 solicitudes por segundo (req/s) y 4GB de RAM por núcleo». El hashing de contraseñas requiere además «4 núcleos de CPU disponibles para este fin», porque un pico de inicios de sesión se convierte en un pico de CPU. El compose oficial de v4 ejecuta 4 contenedores antes de añadir nada: Traefik como proxy, la API de Zitadel, un contenedor independiente para la interfaz de Login y PostgreSQL. Redis y un collector de OpenTelemetry se ejecutan mediante perfiles de compose opcionales.

Por tanto, Keycloak y authentik caben en una VPS de 4 GB, con memoria disponible para las aplicaciones que está protegiendo. Zitadel arrancará con 2 GB, pero competirá con su propio PostgreSQL por la memoria durante cada inicio de sesión. No ejecutaría Zitadel con menos de 4 GB y, en un equipo que también aloje aplicaciones, preferiría 8 GB.

Qué ejecuta realmente cada uno en su servidor

authentik consta de PostgreSQL y dos copias de una misma imagen: un servidor y un worker. El servidor atiende HTTP e incluye un outpost integrado. El worker ejecuta tareas en segundo plano, como sincronizaciones de directorios y envío de correo. La instalación publicada es breve.

wget https://docs.goauthentik.io/compose.yml
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
docker compose pull
docker compose up -d

El servidor publica los puertos 9000 y 9443. La primera visita al puerto 9000 inicia el flujo de configuración inicial, donde se establece la contraseña del usuario akadmin predeterminado. Coloque un reverse proxy con un certificado válido delante del servicio antes de permitir que ese puerto sea accesible desde Internet.

Keycloak consta de un proceso y una base de datos que debe proporcionar. El inicio rápido utiliza un solo contenedor.

docker run -p 127.0.0.1:8080:8080 \
  -e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
  -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin \
  quay.io/keycloak/keycloak:26.7.1 start-dev

start-dev sirve para explorar el producto. Se ejecuta con una base de datos de desarrollo local y sin TLS (seguridad de la capa de transporte), por lo que un contenedor iniciado de esta forma y eliminado posteriormente también elimina su realm. En producción se utiliza start, con PostgreSQL real mediante KC_DB y un nombre de host público mediante KC_HOSTNAME. La guía de producción de Keycloak también indica que todas las comunicaciones hacia y desde el servidor requieren un canal seguro, por lo que HTTPS no es opcional en ese entorno.

Zitadel es la pila de cuatro contenedores descrita anteriormente.

mkdir zitadel-compose && cd zitadel-compose
curl -fsSLO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/docker-compose.yml
curl -fsSLO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/.env.example
cp .env.example .env
docker compose up -d --wait

Establezca ZITADEL_MASTERKEY en .env antes del primer arranque. Es la clave de 32 caracteres que Zitadel utiliza para cifrar los secretos en la base de datos, por lo que perderla implica perder el acceso a esos secretos. Si no tiene experiencia ejecutando pilas de este tipo, los conceptos básicos de Docker Compose para un VPS explican las opciones de volúmenes y políticas de reinicio que determinan si el proveedor de identidad seguirá disponible después de un reinicio.

¿Qué protocolos admite cada uno?

Los tres admiten OpenID Connect (OIDC), la capa de inicio de sesión basada en OAuth 2.0 que usan las aplicaciones modernas. También admiten SAML 2.0 (security assertion markup language), el estándar anterior que todavía incluyen muchos productos empresariales. La diferencia real está en LDAP (lightweight directory access protocol), porque el mismo término describe dos funciones opuestas.

Leer desde LDAP significa que el servidor SSO comprueba las contraseñas contra un directorio que ya administra. Keycloak lo hace mediante la federación de usuarios. Zitadel también lo permite: su documentación explica cómo «conectar un servidor LDAP como proveedor de identidad en ZITADEL».

Servir LDAP significa que una aplicación que sólo admite LDAP puede autenticarse contra el servidor SSO como si éste fuera el directorio. Sólo authentik ofrece esta función. Su proveedor LDAP permite «buscar todos los usuarios y grupos de la base de datos de authentik mediante el directorio LDAP» a través de un outpost LDAP dedicado, con LDAPS disponible en el puerto 636. Es de sólo lectura, por lo que la autenticación y las búsquedas funcionan, pero las escrituras no. Se añade un código de un solo uso a la contraseña mediante un punto y coma, como en password;123456, y los autenticadores SMS no son compatibles durante la autenticación LDAP.

Si una aplicación de la lista sólo admite LDAP, la comparación termina ahí. Keycloak y Zitadel no pueden responder a esa autenticación LDAP, por lo que tendría que ejecutar un segundo directorio junto a ellos y mantener sincronizadas las dos listas de usuarios.

¿Qué ocurre con las aplicaciones que no tienen ningún inicio de sesión?

La autenticación delegada es la respuesta. Es un caso muy habitual en un servidor autogestionado. El reverse proxy consulta al servidor SSO si una petición está autorizada antes de reenviarla al backend. La aplicación situada detrás no conoce ningún detalle del SSO. Recibe peticiones que el proxy ya ha comprobado, normalmente con el nombre de usuario en una cabecera.

El proveedor de proxy de authentik cubre este caso con tres modos documentados. En el modo "Proxy", el outpost de authentik reenvía directamente el tráfico a la aplicación backend. El modo "Forward auth (single application)" mantiene el tráfico en el reverse proxy existente y usa authentik sólo para comprobar la autenticación. El modo "Forward auth (domain level)" protege todas las aplicaciones de un mismo dominio principal con un solo proveedor. El nivel de dominio es el más práctico, pero tiene una limitación documentada: "cannot enforce different application-level authorization rules for each protected application", por lo que todas las aplicaciones de ese dominio comparten el mismo conjunto de políticas.

Keycloak no ofrece nada de esto. Su proxy complementario, Keycloak Gatekeeper, cambió de nombre a Louketo Proxy y después se archivó en GitHub; su último commit fue en agosto de 2023. Para proteger una aplicación sin compatibilidad con OIDC, debe ejecutar un componente independiente delante de ella, normalmente oauth2-proxy, configurado para usar un cliente de Keycloak. Zitadel tampoco tiene un modo propio de autenticación delegada. En ese caso, la solución es instalar, monitorizar y actualizar el mismo componente adicional.

Ese salto adicional es el punto en el que la configuración del reverse proxy deja de ser sencilla. Lea cómo Traefik publica varias aplicaciones de Docker Compose antes de conectar un middleware de autenticación.

¿Qué tan difícil es el proceso de actualización?

En agosto de 2026, las versiones actuales son Keycloak 26.7.1, authentik 2026.5.6 y Zitadel v4.16.3. Los tres ejecutan migraciones de esquema en PostgreSQL, por lo que cada actualización modifica la base de datos. Haga una copia de seguridad de la base de datos antes de cada actualización. Este hábito es más valioso que cualquier función de esta comparación.

authentik tiene la regla más estricta y la expone claramente: «Las actualizaciones deben seguir la secuencia de versiones principales; no salte directamente de una versión principal antigua a la versión más reciente». Debe actualizar a la última versión de corrección de cada versión antes de pasar a la siguiente, y «authentik no admite la degradación». Si un proyecto que usa versiones basadas en el calendario queda un año atrasado, una actualización se convierte en una cadena de actualizaciones, cada una con su propia migración de base de datos.

La guía de actualización de Keycloak indica un orden concreto: revise los cambios de migración de la versión anterior, actualice el servidor y, después, actualice los adaptadores. La migración de la base de datos se ejecuta automáticamente. También puede exportarla y aplicarla manualmente, lo que resulta útil si quiere revisar el cambio antes de aplicarlo. El coste de usar Keycloak está en esa revisión. Sus notas de versión incluyen funciones obsoletas y cambios de comportamiento que es fácil pasar por alto y costoso omitir.

Zitadel separa sus fases init y setup del servidor en ejecución. Su documentación para producción recomienda mantenerlas separadas para que el escalado no repita el trabajo de configuración. En un VPS único, esto significa principalmente que el paso de configuración debe terminar antes de que la API indique que está operativa. Por eso el archivo compose incluye comprobaciones de estado y el comando de inicio usa --wait.

Para quién está pensado cada proyecto y dónde presenta limitaciones

Keycloak es el servidor de identidad de Red Hat. Está pensado para organizaciones que trabajan con realms, grupos, asignaciones de roles y un directorio corporativo existente. Es la implementación más completa de estándares de las tres opciones. Presenta limitaciones en un VPS de 2 GB que ejecuta cuatro aplicaciones autohospedadas, cuando la mitad no admite OIDC. Se destinan 1250 MB a la JVM, hay que aprender un modelo de realms diseñado para una empresa y aun así hay que instalar oauth2-proxy para las aplicaciones que realmente se necesitaban proteger.

authentik está pensado para usuarios que autohospedan servicios, como demuestra su lista de funciones. Incluye forward auth y un proveedor LDAP, y permite crear flujos de inicio de sesión con un editor visual. Presenta limitaciones cuando se necesita un contrato de soporte del proveedor o un ciclo de versiones que no cambie cada pocas semanas. El versionado basado en el calendario, sin una ruta de downgrade ni posibilidad de omitir versiones, exige trabajo operativo real. Además, el editor de flujos introduce todo un modelo que aprender cuando el problema real es un solo cliente OIDC.

Zitadel está pensado para desarrolladores que integran la autenticación en un producto que distribuyen, con una API sólida y la multitenencia como funciones principales. Presenta limitaciones precisamente en este caso. Cuatro contenedores, ausencia de forward auth y una base de datos dimensionada a 4 GB por núcleo no son una configuración adecuada para un VPS que aloja un gestor de contraseñas y una wiki.

Lo que ejecutaría en un VPS y cómo

Para un VPS con tres o cuatro aplicaciones autogestionadas, ejecutaría authentik. Las tres opciones muestran una pantalla de inicio de sesión. El factor decisivo es que algunas de sus aplicaciones nunca admitirán OIDC, y authentik resuelve ese caso con forward auth integrado, sin añadir otro componente al lado.

Asígnele 4 GB si es posible, y sólo 2 GB si las aplicaciones que se ejecutan junto a él son pequeñas. Mantenga el puerto 9000 fuera de Internet pública y termine TLS en un reverse proxy situado delante. Cree volcados nocturnos de PostgreSQL y almacénelos fuera del servidor, porque un proveedor de identidad sin copias de seguridad es un único punto de fallo para todas las aplicaciones que dependen de él. Ejecute la pila con una cuenta dedicada sin privilegios, no como root: configurar usuarios con privilegios mínimos en un VPS explica la cuenta y la propiedad de los archivos que necesita.

Elija Keycloak cuando todas las aplicaciones que protege ya admitan OIDC o SAML, o cuando necesite el modelo detallado de roles que ofrecen los realms de Keycloak. Elija Zitadel cuando esté desarrollando una aplicación en la que otras personas puedan registrarse y necesite su API y su modelo de tenants. Ninguna de esas opciones corresponde al caso de tres aplicaciones en un solo servidor que trata este artículo.

Los primeros modos de fallo que encontrará

Keycloak no tiene datos después de reiniciar. Lo inició con start-dev, que usa una base de datos local para desarrollo. En un contenedor sin un volumen, eliminar el contenedor elimina el realm. Cambie a start con KC_DB=postgres apuntando a una base de datos real.

El contenedor worker de authentik desaparece en un equipo pequeño. El worker y el servidor usan la misma imagen y ambos mantienen procesos de Python. PostgreSQL también necesita su parte de los 2 GB del host. Ejecute docker compose ps para confirmar qué servicio se detuvo. Después, compruebe dmesg para detectar una terminación por falta de memoria antes de buscar un error en la aplicación.

La Console de Zitadel no funciona detrás del proxy. La API de Zitadel usa gRPC, que necesita HTTP/2 hasta el upstream. La página de requisitos solicita un reverse proxy compatible con conexiones HTTP/2 al upstream y menciona versiones probadas de Traefik v3.x, NGINX v1.x, Caddy v2.x y Apache httpd 2.4.x. Un proxy que degrada la conexión al upstream a HTTP/1.1 permite cargar la página de inicio de sesión, pero la Console falla.

Todas las aplicaciones le devuelven a la pantalla de inicio de sesión. La URL pública del servidor SSO y la URL configurada en la aplicación deben coincidir exactamente, incluido el esquema y el puerto. Keycloak denomina a esto la configuración de hostname. Zitadel lo denomina external domain. Cuando no coinciden, la aplicación redirige a un inicio de sesión que el servidor no reconoce como propio, y el navegador alterna entre ambos.

FAQ

¿Cuál de los tres es adecuado para un VPS de 2 GB?

authentik y Keycloak. authentik indica como requisito un host con al menos 2 núcleos de CPU y 2 GB de RAM, y la guía de dimensionamiento de Keycloak establece una memoria base de 1250 MB para el servidor, sin incluir su base de datos. Ambos quedan muy ajustados con 2 GB cuando se añaden las aplicaciones que se van a proteger, por lo que 4 GB es el mínimo razonable. Zitadel publica 2 GB para una primera ejecución, pero sus indicaciones para producción exigen 4 núcleos de CPU para el hash de contraseñas y 4 GB de RAM por núcleo de base de datos. Por tanto, 2 GB no permiten un despliegue real.

¿Keycloak o Zitadel pueden proteger una aplicación que no tiene autenticación propia?

No por sí solos. Ninguno incluye un componente de autenticación delegada. El antiguo proxy complementario de Keycloak, Louketo Proxy, está archivado en GitHub y su último commit fue en agosto de 2023, por lo que no conviene basar un despliegue en él. Debe colocar oauth2-proxy o un componente similar entre el reverse proxy y la aplicación, y configurarlo para usar un cliente OIDC en el servidor SSO. authentik lo hace de forma nativa con su proveedor de proxy, en modo "Forward auth (single application)" o "Forward auth (domain level)".

¿Cuál puede actuar como servidor LDAP para una aplicación que sólo admite LDAP?

authentik. Su proveedor LDAP se ejecuta en un outpost y permite buscar por LDAP los usuarios y grupos de authentik, con LDAPS disponible en el puerto 636. Es de sólo lectura, por lo que las operaciones de bind y búsqueda funcionan, pero las escrituras no. Keycloak y Zitadel funcionan en la dirección contraria: ambos leen de un directorio LDAP existente como fuente de usuarios, y ninguno responde a una operación de bind LDAP de una aplicación.

¿Puedo omitir versiones al actualizar authentik?

No. La documentación indica que las actualizaciones deben seguir la secuencia de versiones principales y que no se debe saltar directamente de una versión principal antigua a la más reciente. Primero actualice a la última versión de parche de la versión actual y después avance una versión cada vez. Haga una copia de seguridad de PostgreSQL antes de cada paso, porque authentik no admite degradaciones y las migraciones sólo se ejecutan hacia delante.