Cómo instalar Authentik para SSO auto-alojado

Probado con authentik 2026.8.2 · PostgreSQL 16 · Traefik 3.7 · Docker Compose 2.40 · verificado 2026-09-16

Actualizado: 2026-09-16

Instalar Authentik con Docker Compose despliega un IdP (identity provider: verifica quién eres y qué permisos tienes) que centraliza el inicio de sesión único, SSO: un solo login para todas las aplicaciones conectadas. Usa OAuth2, OIDC, SAML y LDAP, los protocolos estándar de autenticación y directorio del software empresarial. El stack mínimo son tres contenedores (PostgreSQL, servidor y worker), sin Redis desde la versión 2025.10, y la versión estable actual es la 2026.8.2. En una tarde se tiene login web y forward auth (autenticación delegada: un proxy inverso como Traefik consulta a Authentik antes de dejar pasar cada petición) funcionando en un par de servicios.

Esta guía también está disponible en inglés: How to Install Authentik for Self-Hosted SSO.

Puntos clave

• Desde la versión 2025.10, Authentik elimina por completo la dependencia de Redis: el stack mínimo es PostgreSQL + servidor + worker (tres contenedores en lugar de cuatro).
• Guía probada el 16 de septiembre de 2026 con Authentik 2026.8.2, la etiqueta que fija hoy el compose.yml oficial. El asistente inicial pide ahora también la URL base de la instancia.
• El forward auth con Traefik es el caso de uso más común: proteger servicios web internos sin modificar cada aplicación.
• Tres problemas clásicos de primera instalación: configuración de dominio/URLs, manejo de cookies en subdominios y volúmenes persistentes para PostgreSQL.
• Encaja bien para organizaciones pequeñas y medianas; para miles de usuarios o políticas complejas, Keycloak sigue siendo más potente.
• Nunca saltar versiones major.minor en las actualizaciones: desde la 2026.8, Authentik se niega a migrar si lo intentas. El paso de 2026.5.7 a 2026.8.2 falla hoy por un error conocido, así que pasa antes por la 2026.8.0.

Qué ha cambiado desde la 2025.10

Esta guía se escribió sobre la rama 2025.10, la primera sin Redis. La rama actual es la 2026.8: la 2026.8.0 salió el 18 de agosto de 2026 y la 2026.8.1, el 1 de septiembre. La 2026.8.2 salió el 9 de septiembre de 2026 y es la etiqueta que fija hoy el compose.yml oficial.

Según las notas de la versión 2026.8^[1], la 2026.8.2 incluye cinco parches de seguridad. El SECURITY.md del proyecto^[2] solo da soporte de seguridad a las ramas 2026.5.x y 2026.8.x, así que una instalación que siga en 2025.10 ya no recibe parches. Lo revisamos el 16 de septiembre de 2026 contra las releases del repositorio^[3], y en esta máquina (linux/arm64) repetimos la instalación desde cero y la actualización completa desde la 2025.10.4.

Cada rama intermedia trae algo que tienes que hacer tú al actualizar:

Entre las novedades de la 2026.8 están el cambio entre cuentas abiertas a la vez, los atributos de objeto tipados y los vínculos de políticas con caducidad. En OAuth 2.0 y OpenID Connect, el proyecto obtiene la certificación OpenID Certified y añade intercambio de tokens y registro dinámico de clientes. La gestión de accesos privilegiados, las cuentas de agente, la baja programada de usuarios y los mapas de eventos autoalojados son funciones Enterprise. Por dentro, el servidor y el outpost de proxy pasan de Go a Rust, sin mejoras todavía según las notas.

Cómo actualizar de 2025.10 a 2026.8 sin saltarte ramas

La subida de 2025.10 a 2026.8 pasa por cuatro ramas, y la guía oficial de actualización^[4] pide llegar al último parche de cada una antes de saltar a la siguiente. Hoy eso significa 2025.10.4, 2025.12.6, 2026.2.7, 2026.5.7 y 2026.8.2. Antes de empezar, haz una copia de PostgreSQL: Authentik no admite volver a una versión anterior.

Desde la 2026.8, el propio Authentik bloquea los saltos. Al arrancar la 2026.8.2 sobre una base de datos de la 2025.10.4, el servidor se detuvo antes de migrar nada. El error fue Major version skips are not allowed, con un enlace a la guía de actualización. La base de datos quedó intacta.

El paso a 2025.12 es el que más trabajo manual lleva, porque los ficheros cambian de sitio. Las notas de esa versión lo resuelven así:

docker compose down
mkdir -p ./data
mv ./media ./data/media
wget -O docker-compose.yml \
  https://goauthentik.io/version/2025.12/docker-compose.yml
docker compose up -d

Desde la 2026.2 la descarga cambia de ruta y de nombre. Pasa antes tus cambios del docker-compose.yml antiguo al nuevo compose.yml y borra el antiguo: si conviven los dos, Compose usa compose.yml y avisa con Found multiple config files with supported names. Para la 2026.5, descarga igual el fichero con 2026.5 en la URL y vuelve a ejecutar docker compose up -d.

wget -O compose.yml \
  https://goauthentik.io/version/2026.2/lifecycle/container/compose.yml
rm docker-compose.yml
docker compose up -d

El último salto tiene hoy una trampa. La 2026.5.7 (9 de septiembre de 2026) aplica una migración de índice, authentik_core.0064, que en la rama 2026.8 depende de otra que la 2026.5 no tiene. Al subir de la 2026.5.7 a la 2026.8.2, el servidor entró en un bucle de reinicios con este error (partido en cuatro líneas para que quepa):

django.db.migrations.exceptions.InconsistentMigrationHistory:
Migration authentik_core.0064_user_authentik_c_usernam_2f0e4b_idx
is applied before its dependency authentik_core.0063_actor
on database 'default'.

El fallo está confirmado en la incidencia 25996^[5], abierta el 10 de septiembre de 2026 y todavía sin corregir el 16 de septiembre. La comprobación falla antes de migrar, así que la base de datos no cambia. El desarrollador que introdujo el error remite ahí a la alternativa más simple: pasar por la 2026.8.0, que aún no incluye esa migración, y luego a la 2026.8.2.

El compose.yml oficial lee la etiqueta de AUTHENTIK_TAG. Fíjala en .env, arranca, espera a que servidor y worker estén healthy y quítala:

echo 'AUTHENTIK_TAG=2026.8.0' >> .env
docker compose up -d
sed -i '/^AUTHENTIK_TAG=/d' .env
docker compose up -d

En nuestra prueba, el paso por la 2026.8.0 aplicó las migraciones pendientes y dejó los contenedores healthy en 48 s. La subida final a la 2026.8.2 tardó 29 s, sin reinicios, con una carga media de entre 4 y 7 en una máquina de 18 núcleos compartida.

Por qué Authentik y no otra cosa

La decisión entre Authentik, Keycloak, Zitadel y soluciones comerciales como Auth0 depende del contexto, pero para auto-alojado pequeño y medio la elección tiene matices claros:

• Keycloak^[6]: potente pero pesado. Interfaz administrativa con curva de aprendizaje que frena a equipos sin dedicación de tiempo.
• Zitadel: elegante pero más joven y con ecosistema menor.
• Auth0: excelente pero dejó de ser opción realista para quien quiere auto-alojar.

Authentik ocupa el hueco intermedio. Es suficientemente completo para casos reales, con buen soporte de SAML y OAuth2, con forward auth útil para proteger servicios detrás de Traefik o Nginx, y con consumo de recursos manejable. La guía de instalación con Docker Compose^[7] pide al menos 2 núcleos y 2 GB de RAM. En nuestra prueba, en reposo, el servidor ocupaba unos 400 MiB, el worker unos 265 MiB y PostgreSQL unos 56 MiB.

La arquitectura desde 2025.10

Un cambio importante que conviene entender antes de instalar: en la versión 2025.10, Authentik eliminó Redis del todo, no lo hizo opcional. Durante años la arquitectura mínima era PostgreSQL + Redis + servidor + worker.

El proceso empezó en la versión 2024.6, sustituyendo los locks de Redis por locks consultivos de PostgreSQL. La cola de tareas pasó a PostgreSQL en la 2025.8, y en la 2025.10 lo hicieron la caché, las sesiones del outpost embebido y las conexiones WebSocket. Estas últimas usan NOTIFY/LISTEN en lugar del pub/sub de Redis. El propio equipo de Authentik documenta el cambio en su blog técnico^[8].

Esta simplificación tiene efectos prácticos, con matices:

1. El stack baja de cuatro contenedores a tres, reduciendo superficie de configuración y de fallos.
2. Quien instala por primera vez no tiene que explicar por qué hay un Redis colgando del servicio de identidad.
3. A cambio, Authentik consume aproximadamente un 50% más de conexiones a PostgreSQL que antes, porque absorbe el trabajo que hacía Redis. En instancias con límites de conexión ajustados conviene revisar max_connections en PostgreSQL antes de actualizar. Nuestra instancia de prueba tenía 12 conexiones abiertas en reposo, frente al límite de 100 que trae la imagen de PostgreSQL.
4. Si PostgreSQL exige TLS, Authentik desde 2025.10 requiere TLS 1.3 o la extensión Extended Master Secret para conectar.

El despliegue básico

El despliegue parte del compose.yml oficial, que se llama así desde la 2026.2 (antes era docker-compose.yml). Descárgalo y genera en .env la contraseña de PostgreSQL y la clave secreta con las órdenes de la guía oficial:

mkdir authentik && cd authentik
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

El fichero define tres servicios:

• Un servicio postgresql con la imagen postgres:16-alpine (PostgreSQL 16.15 en nuestra prueba) y un healthcheck con pg_isready.
• Un servicio server con la imagen ghcr.io/goauthentik/server y comando server.
• Un servicio worker con la misma imagen, comando worker y el socket de Docker montado.

El servidor escucha en los puertos 9000 (HTTP) y 9443 (HTTPS), que son los que Traefik o Nginx usan para forward auth. Si ya están ocupados en el host, cambia los puertos publicados con COMPOSE_PORT_HTTP y COMPOSE_PORT_HTTPS en .env. En nuestra prueba usamos 22900 y 22943.

El worker monta /var/run/docker.sock para gestionar outposts en Docker, lo que le da control sobre el Docker del host; la documentación propone un proxy del socket o quitar el montaje. Lo quitamos en nuestra prueba, en una máquina compartida, y el outpost embebido funcionó sin él.

Las variables de entorno mínimas son:

• AUTHENTIK_SECRET_KEY: cadena aleatoria larga usada para firmar tokens.
• AUTHENTIK_POSTGRESQL__HOST: apunta al servicio de base de datos.
• AUTHENTIK_POSTGRESQL__USER, AUTHENTIK_POSTGRESQL__NAME, AUTHENTIK_POSTGRESQL__PASSWORD.

En despliegues serios, sacar la contraseña y el secret a un gestor de secretos o a un archivo .env ignorado por git (ver nuestra guía de variables de entorno y secretos en Docker Compose).

El servicio server del fichero oficial queda así, con la etiqueta fijada y límites de recursos añadidos. El env_file es lo que hace llegar al contenedor las variables que añadas a .env:

services:
  server:
    image: ghcr.io/goauthentik/server:2026.8.2
    command: server
    env_file:
      - .env
    environment:
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__NAME: authentik
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
    ports:
      - "${COMPOSE_PORT_HTTP:-9000}:9000"
      - "${COMPOSE_PORT_HTTPS:-9443}:9443"
    shm_size: 512mb
    volumes:
      - ./data:/data
      - ./custom-templates:/templates
    depends_on:
      postgresql:
        condition: service_healthy
    deploy:
      resources:
        limits: {memory: 768M, cpus: "1.5"}

La etiqueta fijada arriba es la 2026.8.2 (9 de septiembre de 2026), la misma que usa el compose.yml oficial de la rama 2026.8; cuando se escribió esta guía era 2025.10. Desde la 2025.12 los ficheros subidos viven en ./data, montado en /data. Si Authentik va detrás de Traefik o Nginx, revisa también AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS (detalle en la sección sobre el forward auth tras actualizar).

Un detalle útil: poner límites de memoria y CPU desde el principio. El servidor puede tener picos durante logins masivos o sincronizaciones LDAP, y sin límite declarado puede afectar a otros servicios en el mismo host. Con 768 MiB y 1,5 núcleos, una instalación nueva completó sus migraciones sin que el kernel matara el proceso, y el servidor ocupaba 460 MiB tras un login por forward auth.

Con el .env listo, descarga las imágenes y arranca:

docker compose pull
docker compose up -d

El primer arranque y las migraciones

Cuando el servidor arranca por primera vez, ejecuta las migraciones de base de datos. En nuestra prueba pasaron 69 s desde docker compose up -d hasta tener servidor y worker healthy, con una carga media de entre 35 y 43 en una máquina de 18 núcleos compartida. No hace falta arrancar los servicios uno a uno: Compose espera al healthcheck de PostgreSQL antes de arrancar servidor y worker.

Servidor y worker intentan migrar a la vez, pero el script de arranque toma antes un lock consultivo de PostgreSQL (pg_advisory_lock), así que solo migra uno. Este extracto de docker compose logs --no-log-prefix server muestra el inicio y el final de las migraciones:

2026-09-16 21:13:12 [info     ] waiting to acquire database lock
2026-09-16 21:13:12 [info     ] applying django migrations
System check identified no issues (4 silenced).

Mientras tanto, el worker registra waiting to acquire database lock. Cuando el servidor suelta el lock, el worker lo toma, comprueba que no queda nada pendiente y registra No migrations to apply. Las actualizaciones siguen el mismo proceso. Aun así, nunca se pueden saltar ramas major.minor: hay que ir una a una (de 2026.5 a 2026.8, no directo de 2025.10 a 2026.8).

Tras las migraciones, abre http://tu_servidor:9000/, con el puerto que hayas publicado. En la 2026.8 la raíz redirige a /setup y de ahí a /if/flow/initial-setup/. Si entras en esa ruta sin pasar por la raíz, el flujo deniega el acceso con el mensaje Access the authentik setup by navigating to seguido de la URL raíz.

El asistente pide el correo y la contraseña del usuario akadmin y, como novedad de la 2026.8, la URL base de la instancia (por ejemplo https://authentik.ejemplo.com). Usa un correo real y guarda la contraseña en un gestor.

Justo cuando los contenedores pasaron a healthy, /if/flow/initial-setup/ devolvió 404: el worker tardó unos 12 s más en crear los flujos por defecto. Si el flujo no aparece tras reiniciar los contenedores, la guía de problemas de login^[9] propone docker compose exec server ak changepassword akadmin.

Forward auth con Traefik

El caso de uso más común al adoptar Authentik es proteger servicios web internos detrás de un proxy inverso (el componente que recibe todas las peticiones HTTP y las reparte hacia el contenedor correcto). El patrón se llama forward auth: Traefik recibe la petición, la redirige a Authentik para verificar que hay sesión válida, y si no la hay envía al usuario al login. Si ya tienes Traefik desplegado, nuestra guía de instalación de Traefik con Docker Compose cubre el proxy inverso desde cero.

La configuración en Authentik sigue estos pasos:

1. Crear un proxy provider con forward auth single application o forward auth domain.
2. Crear una aplicación asociada.
3. Asignar la aplicación a un outpost de proxy. El outpost embebido, que corre dentro del servidor, basta para despliegues pequeños y no necesita otro contenedor.

Del lado de Traefik, se define un middleware de tipo forwardAuth^[10] apuntando al outpost, y se aplica ese middleware a cualquier router que quiera quedar protegido. Este es un extracto del fichero dinámico que probamos con Traefik 3.7.13 y su proveedor de ficheros, con Traefik en la misma red de Compose que Authentik:

http:
  middlewares:
    authentik:
      forwardAuth:
        address: http://server:9000/outpost.goauthentik.io/auth/traefik
        trustForwardHeader: true
        authResponseHeadersRegex: "(?i)^x-authentik-"
  routers:
    app:
      rule: Host(`app.localhost`)
      middlewares: [authentik]
      service: whoami
    app-outpost:
      rule: Host(`app.localhost`) && PathPrefix(`/outpost.goauthentik.io/`)
      priority: 1000
      service: authentik

El router app-outpost manda las rutas /outpost.goauthentik.io/ del dominio de la aplicación al servicio authentik, que apunta a http://server:9000/outpost.goauthentik.io. El servicio whoami es la aplicación protegida. Una petición sin sesión devolvió 302 hacia /application/o/authorize/ de Authentik; tras el login, la aplicación recibió X-Authentik-Username, X-Authentik-Groups y X-Authentik-Email.

Un patrón que uso es tener dos cadenas de middlewares predefinidas:

• chain-base: para servicios públicos sin autenticación.
• chain-oauth: para servicios protegidos que pasan por Authentik.

Esta separación hace que añadir o quitar protección de un servicio sea cambiar una etiqueta, no rehacer la configuración.

Puntos de fricción típicos

Hay tres problemas que casi todo el mundo encuentra la primera vez:

1. Configuración de dominio y URLs. Authentik necesita saber desde qué dominio se le accede para generar correctamente las redirecciones. Desde la 2026.8 eso empieza por la URL base (en el asistente inicial, en System > Settings o con AUTHENTIK_WEB__BASE_URL), que será obligatoria a partir de la 2026.11. El outpost tiene además su propio host de Authentik: AUTHENTIK_HOST si lo despliegas aparte, o authentik_host en la configuración del outpost embebido. En nuestra prueba, con ese campo vacío, la redirección del forward auth apuntaba a http://localhost sin el puerto publicado; al rellenarlo con http://localhost:22900, el login se completó.
2. Manejo de cookies en subdominios. Para que una sesión de Authentik proteja servicios en subdominios distintos, las cookies tienen que estar configuradas con el dominio padre. La solución es usar el modo forward auth domain con la opción de cookie domain apuntando al dominio raíz (por ejemplo ejemplo.com para app1.ejemplo.com y app2.ejemplo.com, como en la documentación).
3. Almacenamiento de datos. La base de datos de PostgreSQL es crítica y debe ir a un volumen persistente (revisa nuestra guía de volúmenes y bind mounts en Docker) con copias de seguridad configuradas, por ejemplo con Restic. Más de un equipo ha perdido la configuración entera de Authentik por tener el volumen en un tmpfs o por eliminar el volumen al hacer compose down -v por error. Incluye también el directorio ./data, donde viven los ficheros subidos.

Forward auth que deja de funcionar tras actualizar: cabeceras y proxies de confianza

Si el forward auth te funcionaba y deja de hacerlo justo después de actualizar Authentik, lo más probable es que no hayas roto la configuración: han cambiado las cabeceras que Authentik acepta. Hay dos cambios, y afectan de forma distinta a Traefik y a Nginx.

El primero llegó con la 2026.8: el servidor solo usa X-Forwarded-Proto, X-Forwarded-Host y X-Forwarded-For si la conexión llega desde una red de confianza. Según la documentación de proxy inverso^[11], la lista por defecto cubre 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fe80::/10 y ::1/128, y AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS la sustituye. Nuestro Traefik conectaba desde la red de Compose 172.31.0.0/16, dentro de esa lista, y funcionó sin tocar nada.

Con AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS=127.0.0.0/8, que deja fuera esa red, Authentik registró las comprobaciones como dirigidas a server:9000 y cada petición protegida devolvió 404 Not Found. Al añadir 172.31.0.0/16 a la lista, el forward auth volvió a redirigir al login.

El segundo, solo para el forward auth de Nginx, llegó con Authentik 2025.12.5 y 2026.2.3, que corrigieron el aviso GHSA-5wcc-hf24-rf5h^[12] (12 de mayo de 2026). El outpost leía la cabecera X-Original-URI, que Nginx no fija y que un cliente podía inyectar para saltarse la autenticación. Desde esas versiones lee X-Original-URL, que la configuración de Nginx de la documentación envía. Traefik, Caddy y el modo proxy quedan fuera del aviso; con Traefik, el outpost construye la URL a partir de X-Forwarded-Uri.

Dos comprobaciones más que evitan sustos

• Limpia las cabeceras X-Authentik-* entrantes. Si un cliente puede enviarlas y tu proxy las deja pasar hasta la aplicación, puede suplantar identidad. En Traefik, authResponseHeaders solo sustituye las cabeceras de su lista: en nuestra prueba, una cabecera inventada X-Authentik-Role-Override llegó intacta a la aplicación. Con authResponseHeadersRegex: "(?i)^x-authentik-", Traefik borra antes todas las que coinciden, la cabecera falsa desapareció y las de Authentik llegaron igual; sin el (?i), la aplicación no recibió ninguna.

• AUTHENTIK_POSTGRESQL__CONN_OPTIONS está deprecada desde la rama 2026.5 y en 2026.8 sigue marcada para eliminarse «en una versión próxima». Si la tienes en tu .env, quítala ahora y no en mitad de una actualización urgente.

Nota sobre Redis, porque genera confusión al leer guías antiguas: desde 2025.10 no hace falta. La caché, el outpost embebido y los WebSocket se movieron a PostgreSQL, y los ajustes de Redis se pueden borrar de la configuración.

Preguntas frecuentes

¿Hace falta instalar Redis para usar Authentik?

No, desde la versión 2025.10 no. Authentik movió la cola de tareas a PostgreSQL en la 2025.8, y la caché, las sesiones del outpost embebido y las notificaciones WebSocket en la 2025.10. El stack mínimo son tres contenedores: PostgreSQL, servidor y worker. En versiones anteriores a 2025.10, Redis sí era obligatorio.

¿Es Authentik mejor que Keycloak?

Depende del tamaño. Para equipos pequeños o medianos, Authentik suele instalarse y mantenerse más rápido gracias a una interfaz más simple. Para organizaciones grandes con miles de usuarios, federación compleja o requisitos estrictos de cumplimiento, Keycloak ofrece más políticas y una comunidad más veterana.

¿Puedo actualizar directamente de 2025.10 a 2026.8?

No. La 2026.8 solo migra bases de datos que vengan de la 2026.5 o de la propia 2026.8, y en cualquier otro caso se detiene con el error Major version skips are not allowed antes de tocar nada. Pasa por 2025.12.6, 2026.2.7 y 2026.5.7, y de ahí a la 2026.8.0 antes de la 2026.8.2. El salto directo desde la 2026.5.7 falla mientras siga abierta la incidencia 25996.

Conclusión

Authentik ofrece la mejor relación entre esfuerzo de instalación y capacidades obtenidas en el espacio de identidad auto-alojada. Una tarde basta para tener una instancia funcional con login web y forward auth en un par de servicios. Si estás evaluando identidad auto-alojada y no tienes requisitos extremos de escala o cumplimiento específicos, Authentik es el primer candidato a probar.

Donde pausar y pensar: si tu organización tiene usuarios externos, partners o clientes que también se van a autenticar. Los requisitos de disponibilidad y de identidad federada cambian mucho cuando el SSO deja de ser interno. La buena noticia es que esa revisión puede hacerse con Authentik ya funcionando en tareas internas, sin necesidad de elegir la herramienta final desde el día uno.

Fuentes: documentación oficial de Authentik^[13], instalación con Docker Compose^[7], guía de actualización de Authentik^[4], notas de la versión 2026.8^[1], documentación de proxy inverso de Authentik^[11], repositorio de Authentik en GitHub^[14], incidencia 25996 sobre la actualización de 2026.5.7 a 2026.8.2^[5], aviso de seguridad GHSA-5wcc-hf24-rf5h^[12], blog técnico de Authentik sobre la eliminación de Redis^[8], documentación de Traefik sobre el middleware ForwardAuth^[10].

Fuentes

1. notas de la versión 2026.8
2. SECURITY.md del proyecto
3. releases del repositorio
4. guía oficial de actualización
5. incidencia 25996
6. Keycloak
7. guía de instalación con Docker Compose
8. su blog técnico
9. guía de problemas de login
10. middleware de tipo forwardAuth
11. documentación de proxy inverso
12. GHSA-5wcc-hf24-rf5h
13. documentación oficial de Authentik
14. repositorio de Authentik en GitHub

Ruta: Self-hosting con Docker: de cero a producción