Por qué centralizar la autenticación en su VPS
Cuando acumula herramientas autoalojadas (Grafana, Nextcloud, Gitea, un dashboard interno), cada una aporta su propia base de usuarios y su propia política de contraseñas. Es una pesadilla de mantener y una superficie de ataque multiplicada. Authentik lo resuelve haciendo de proveedor de identidad (IdP): admite OAuth2/OIDC, SAML, LDAP y, sobre todo, el forward auth, que permite proteger cualquier aplicación detrás de un reverse proxy, incluso aquellas sin ninguna noción de login. El autoalojamiento en un VPS garantiza que sus credenciales nunca pasen por un servicio de terceros y que usted siga controlando el árbol de usuarios y las políticas MFA.
Lo que gana con Authentik
- Un único conjunto de credenciales para todas sus aplicaciones, con cierre de sesión centralizado.
- MFA (TOTP, WebAuthn/llaves FIDO2, códigos de respaldo) aplicado de forma uniforme mediante políticas.
- Forward auth para proteger apps "sin login", imposible con un IdP clásico.
- Flows totalmente personalizables (registro, recuperación, captcha, condiciones de acceso).
- Conectores OAuth2/OIDC, SAML y LDAP para integrar tanto apps modernas como heredadas.
- Aprovisionamiento y revocación de accesos inmediatos cuando un colaborador se va.
Requisitos con cifras antes de empezar
La documentación oficial de Authentik pide como mínimo 2 núcleos de CPU y 2 GB de RAM, con Docker Compose v2 (o Podman). En un VPS real recomendamos 2 vCPU y 4 GB de RAM: el servidor, el worker y PostgreSQL comparten la misma máquina, y con 2 GB no queda margen en cuanto se suma un pico de conexiones o un outpost. Prevea también unos veinte gigabytes de disco libre para imágenes, base de datos y algunas copias locales (estimación orientativa, no una cifra oficial). Authentik es una guía proporcionada sobre una plantilla VPS: ServOrbit no la soporta, usted conserva su administración.
Lista de control antes del primer docker compose up
- Un VPS Linux de 64 bits con Docker Engine y el plugin Compose v2: 2 vCPU y 4 GB de RAM recomendados, 2 núcleos y 2 GB como mínimo oficial estricto.
- Un subdominio dedicado, por ejemplo
auth.example.com, con un registro A (y AAAA si tiene IPv6) hacia la IP del VPS. - Los puertos 80 y 443 abiertos hacia el reverse proxy; los puertos 9000 y 9443 del contenedor server nunca expuestos públicamente.
- Un reverse proxy (nginx, Caddy o Traefik) capaz de obtener un certificado de Let's Encrypt.
- Una forma de recuperar la cuenta de administrador si pierde su segundo factor: códigos de respaldo guardados en un gestor de contraseñas.
- Un lugar de copia de seguridad fuera del VPS.
Desplegar Authentik con Docker Compose
Crear la carpeta y obtener el compose oficial
Cree una carpeta dedicada (
mkdir -p /opt/authentik && cd /opt/authentik) y descargue el archivo de referencia conwget https://docs.goauthentik.io/compose.yml. El archivo actual declara tres servicios:postgresql,serveryworker. Referencia la versión disponible en el momento de la descarga, así que hay que volver a descargarlo en cada actualización.Generar los secretos en el archivo .env
Ejecute
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .envy luegoecho "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env. La documentación indica que las contraseñas de PostgreSQL de más de 99 caracteres no son compatibles. Proteja el archivo (chmod 600 .env), no lo versione nunca y no reutilice jamás una clave de ejemplo.Vincular los puertos solo a localhost
Por defecto, el compose publica 9000 (HTTP) y 9443 (HTTPS) en todas las interfaces. Añada a
.envlas líneasCOMPOSE_PORT_HTTP=127.0.0.1:9000yCOMPOSE_PORT_HTTPS=127.0.0.1:9443: solo su reverse proxy local podrá alcanzarlos y el tráfico público pasará obligatoriamente por HTTPS.Arrancar la stack
Ejecute
docker compose pully luegodocker compose up -d. Compruebe condocker compose psque los tres contenedores están arrancados y quepostgresqlestáhealthy, y siga la inicialización condocker compose logs -f server. Las migraciones de la base pueden tardar unos minutos en el primer arranque.Finalizar la instalación mediante /if/flow/initial-setup/
En el primer arranque, vaya a
https://auth.example.com/if/flow/initial-setup/para definir la contraseña de la cuentaakadmin. Es su superadministrador: protéjalo de inmediato con MFA y cree después una cuenta de administrador nominativa para el uso diario.Crear un provider y una aplicación
En el admin, cree un Provider (OIDC para una app moderna, o Proxy para forward auth) y después la Application asociada. Para OIDC, recupere el
client_id/client_secrety la URL.well-known/openid-configurationpara pegarlos en la app cliente.
Reverse proxy y TLS
Authentik debe servirse obligatoriamente por HTTPS para que funcionen las cookies de sesión y WebAuthn. Con nginx, el vhost de auth.example.com hace un proxy_pass http://127.0.0.1:9000; y transmite las cabeceras Host, X-Forwarded-For y X-Forwarded-Proto, además de Upgrade y Connection para los WebSockets. El certificado se obtiene con certbot --nginx -d auth.example.com; Caddy y Traefik lo hacen automáticamente. Si el dominio pasa por Cloudflare en modo proxificado, ajuste el modo SSL/TLS de la zona a Full (strict): en Flexible, nginx redirige HTTP a HTTPS y se produce un bucle de redirección infinito.
Proteger una aplicación con forward auth en nginx
Crear el Proxy Provider
Cree un Proxy Provider en modo forward auth para una sola aplicación, con la URL pública de la app (
https://app.example.com) como External host. Asócielo a una Application y luego al outpost integrado en la sección Outposts.Conectar auth_request en el vhost de la app
En
location /, añadaauth_request /outpost.goauthentik.io/auth/nginx;y luegoerror_page 401 = @goauthentik_proxy_signin;. Copie también las cookies del outpost conauth_request_set $auth_cookie $upstream_http_set_cookie;yadd_header Set-Cookie $auth_cookie;. Copie el bloque completo de la página de nginx de la documentación correspondiente a su versión.Exponer la ruta del outpost sin autenticación
Añada una
location /outpost.goauthentik.ioque haga unproxy_passahttp://127.0.0.1:9000, conHostfijado al host original,X-Original-URLa la URL completa,proxy_pass_request_body off;y unContent-Lengthvacío. Esta ruta debe seguir accesible sin login; de lo contrario la redirección nunca funciona.Gestionar la redirección y las cabeceras grandes
Declare una
location @goauthentik_proxy_signinmarcada comointernalque devuelva un 302 hacia/outpost.goauthentik.io/start?rd=seguido de la URL de origen. Si ve el error "upstream sent too big header", añadaproxy_buffers 8 16k;yproxy_buffer_size 32k;. Las identidades llegan después a la app en las cabecerasX-authentik-username,X-authentik-groupsyX-authentik-email.
Copia de seguridad y restauración de Authentik
La base de datos PostgreSQL es la parte más importante de una copia: contiene usuarios, políticas, flows y configuración. Con los nombres por defecto del compose (usuario y base authentik), un volcado se hace con docker compose exec -T postgresql pg_dump -U authentik -d authentik -Fc > /var/backups/authentik-$(date +%F).dump. Para restaurar, detenga primero los contenedores de la aplicación con docker compose stop server worker, luego ejecute docker compose exec -T postgresql pg_restore -U authentik -d authentik --clean --if-exists < archivo.dump y reinicie. El orden recomendado por la documentación es: base primero, verificación, directorios estáticos y después arranque. Una copia nunca restaurada es solo una hipótesis: pruebe en una máquina desechable.
Qué respaldar
- La base PostgreSQL: indispensable, sin ella Authentik no puede volver a ponerse en marcha.
- El directorio
./data(iconos, fondos de flows, archivos subidos, informes CSV), salvo que use almacenamiento S3. - El directorio
./certssi se apoya en certificados del sistema de archivos; los certificados ya importados están en la base. - El directorio
./custom-templatessi ha cambiado la apariencia, y los blueprints personalizados si los hay. - El archivo
.env(clave secreta y contraseña de PostgreSQL), cifrado y guardado fuera del VPS. - Una copia de los volcados en un almacenamiento remoto, nunca solo en la máquina que aloja la base.
Actualizar sin romper el SSO
Authentik no admite volver atrás: respalde la base antes de cada actualización y lea las notas de versión del destino. Actualice de forma secuencial, pasando por el último parche de cada versión mayor.menor sin saltarse ninguna. Vuelva a descargar el compose (wget -O compose.yml https://docs.goauthentik.io/compose.yml), luego docker compose pull y docker compose up -d. Actualice todos los outposts a la vez: su versión debe coincidir con la del servidor. Después compruebe la versión en Dashboards > Overview; si no ha cambiado y los logs contienen migration inconsistency, restaure la copia y suba versión por versión.
Redis ya no forma parte de la stack
Muchos tutoriales antiguos, incluida la primera versión de este artículo, describen una stack de cuatro contenedores con Redis. Las notas de la versión 2025.10 indican que Authentik ya no usa Redis en absoluto: la caché, el outpost integrado y los WebSockets pasaron a PostgreSQL, y las tareas ya lo habían hecho en la 2025.8. El compose actual solo contiene postgresql, server y worker. Dos consecuencias: cuente con un 50 % más de conexiones a PostgreSQL aproximadamente y, si su PostgreSQL exige TLS, Authentik requiere TLS 1.3 o la extensión Extended Master Secret. Elimine los ajustes de Redis que queden en su configuración.
Solución de problemas: bucle de reinicio con AUTHENTIK_POSTGRESQL__USE_POOL
Síntoma reportado en la issue 14320 de goauthentik/authentik, abierta en mayo de 2025 sobre la versión 2025.4.0: con AUTHENTIK_POSTGRESQL__USE_POOL=true, el servidor se reinicia en bucle, con errores SSL como "decryption failed or bad record mac" o "SSL SYSCALL error: EOF detected", y después un worker de gunicorn que sale con código 3 ("Worker failed to boot"). La 2025.4.1, publicada en mayo de 2025, desactivó la opción por precaución, al no haber encontrado la causa. Estado real de la issue leída el 30 de octubre de 2026: sigue abierta, etiquetada como bug confirmado, sin PR de corrección vinculada, con un hito 2026.11.0 marcado como Required desde el 23 de octubre de 2026. Hipótesis de un mantenedor: el contexto SSL asíncrono compartido entre hilos, aunque no es thread-safe. Pista reportada, no oficial: un usuario indicó en septiembre de 2026 que AUTHENTIK_WEB__WORKERS=1 y AUTHENTIK_WEB__THREADS=1 eliminaban el problema; según las pruebas de un mantenedor, 1 worker y 1 hilo funcionan, y 2 o más workers lo reproducen. No es una corrección ni una garantía, y limita la capacidad de la interfaz. Lo más seguro es no activar el pool (elimine la variable de .env) y releer la issue antes de cualquier actualización.
Otras averías frecuentes
- Bucle de redirección tras Cloudflare: el modo SSL/TLS de la zona está en Flexible; pase a Full (strict) y compruebe que se transmite
X-Forwarded-Proto. - WebAuthn o cookies rechazados: la interfaz se sirve por HTTP o bajo otro nombre de host; imponga HTTPS en el dominio exacto de Authentik.
- Error 502 en la app protegida: busque "upstream sent too big header" en los logs de nginx y aumente
proxy_buffer_size. serveryworkerno arrancan:postgresqlno estáhealthy; leadocker compose logs postgresqly recuerde quePG_PASSyAUTHENTIK_SECRET_KEYson obligatorios.- Outpost inalcanzable tras una actualización: su versión ya no coincide con la del servidor; actualícelo.
- Contenedores terminados sin mensaje: con 2 GB de RAM actúa el OOM killer; compruébelo con
dmesg | grep -i oomy pase a 4 GB.
Active un Outpost integrado y aproveche los "property mappings" para inyectar cabeceras (X-authentik-username, X-authentik-groups) hacia sus aplicaciones con forward auth: muchas apps (Grafana, por ejemplo) saben leer estas cabeceras para aprovisionar usuarios y asignar roles automáticamente. Así obtiene no solo SSO, sino también un mapeo de grupos a roles totalmente automatizado, sin configuración manual en cada herramienta.
