[{"data":1,"prerenderedAt":244},["ShallowReactive",2],{"seo-verification":3,"blog-instalar-zitadel-vps-iam-codigo-abierto-desarrolladores-ma-es":6,"promo-bar-likely":243},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-instalar-zitadel-vps-iam-codigo-abierto-desarrolladores-ma-es",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":33,"intro":36,"sections":37,"ctaTitle":197,"ctaBody":198,"ctaButton":199,"ctaUrl":200,"relatedPosts":201},351,"instalar-zitadel-vps-iam-codigo-abierto-desarrolladores",{"fr":12,"en":13,"ar":14,"es":10},"deployer-zitadel-vps","self-host-zitadel-vps-open-source-iam-developers","zitadel-vps-iam-maftouh-almassdar-lilmutatawireen","ZITADEL en VPS: IAM de código abierto para desarrolladores","Despliegue ZITADEL self-hosted en un VPS: OIDC, OAuth 2.0, passkeys y multi-tenancy nativo con Docker Compose en menos de 5 minutos.",11,0,false,"2026-01-08T00:00:00+00:00","2026-11-04T16:30:27+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},7,"Autoalojamiento","self-hosting","bg-indigo-500\u002F10 text-indigo-400","cloud",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fdeployer-zitadel-vps-poster.svg",{"categorySlug":34,"appSlug":35},"security","zitadel","ZITADEL es una plataforma IAM de código abierto escrita en Go: SSO OIDC\u002FOAuth 2.0, passkeys y multi-tenancy nativo, en self-hosted. Esta guía la despliega en un VPS de ServOrbit con Docker Compose, corrige cifras que la versión anterior repetía sin fuente y documenta lo que aún no funciona: el descubrimiento de dominio, un bug abierto en la v4 desde septiembre de 2025. Guía proporcionada, sin soporte incluido.",[38,41,44,46,55,57,70,72,74,76,83,85,87,89,91,97,99,101,105,107,109,117,119,121,153,155,157,175,182,184,190,193,195],{"type":39,"title":40},"h2","¿Por qué elegir ZITADEL frente a Authentik o Keycloak?",{"type":42,"body":43},"p","ZITADEL ocupa un nicho preciso entre las plataformas de autenticación de código abierto. A diferencia de **Authelia** (proxy de autenticación sin gestión de usuarios propia) o **Authentik** (IdP full-stack rico en funcionalidades), se dirige a equipos de desarrollo que quieren un IAM de nivel empresarial desde el principio: multi-tenancy nativo, APIs gRPC + REST completas y un proveedor Terraform oficial (`zitadel\u002Fzitadel` en el registro de Terraform).\n\nCon la memoria, conviene ser prudente. La documentación de operación indica que el propio ZITADEL necesita unos 512 MB de RAM y menos de un núcleo de CPU, sin contar la base de datos, con picos de CPU al calcular el hash de las contraseñas. La versión anterior de este artículo anunciaba «menos de 100 MB»: esa cifra no figura en la documentación, no dimensione su VPS con ella. La comparación de recursos con Keycloak no se cuantifica aquí por falta de una medición con fuente.",{"type":39,"title":45},"Requisitos previos cuantificados",{"type":47,"items":48},"ul",[49,50,51,52,53,54],"**VPS**: 2 vCPU y 2 GB de RAM (la guía de Docker Compose del proyecto pide al menos 2 GB), Ubuntu 24.04. Prevea más cuando la base crezca: el proyecto cuenta unos 4 GB de RAM por núcleo de base de datos.","**Docker**: Docker Engine 24 o superior con Compose v2; el antiguo binario `docker-compose` (v1) no es compatible.","**PostgreSQL**: se admiten las versiones 14 a 18. La plantilla de ServOrbit despliega PostgreSQL 16.","**Puertos**: ZITADEL escucha internamente en `8080`. Solo `443` debe ser público (más `80` si deja que Let's Encrypt emita el certificado). La plantilla enlaza `8080` a `127.0.0.1` y deja que nginx sirva el exterior.","**Dominio**: un nombre o subdominio que apunte a la IP del VPS, por ejemplo `auth.your-domain.com`, en HTTPS.","**Masterkey**: `ZITADEL_MASTERKEY` debe tener exactamente 32 caracteres y no puede cambiar tras la inicialización sin perder el acceso a los datos cifrados. La plantilla la genera; guárdela fuera del VPS.",{"type":39,"title":56},"Instalar ZITADEL desde el Marketplace",{"type":58,"title":59,"steps":60},"steps","Instalación en 3 pasos",[61,64,67],{"title":62,"body":63},"Crear el VPS","Desde su área de cliente de ServOrbit, elija la gama VPS y haga clic en **Configurar**. En el campo Aplicación, seleccione **ZITADEL**. Introduzca su dominio (p. ej. `auth.your-domain.com`).\n\nSi no tiene dominio, el subdominio gratuito de ServOrbit está disponible inmediatamente, HTTPS incluido.",{"title":65,"body":66},"Inicio automático","El script de instalación genera el `MASTERKEY`, la contraseña de PostgreSQL y la contraseña de administrador, luego lanza PostgreSQL 16 y ZITADEL mediante Docker Compose. Duración habitual: 2 a 4 minutos.",{"title":68,"body":69},"Acceder a la consola","Una vez completada la instalación, sus credenciales se muestran en el área de cliente.\n- URL: `https:\u002F\u002F\u003Csu-dominio>\u002Fui\u002Fconsole`\n- Usuario: `admin`. Si la página lo rechaza, pruebe `admin@zitadel.\u003Csu-dominio>`: ZITADEL compone los nombres de inicio de sesión como usuario@organización.dominio, como en el ejemplo `zitadel-admin@zitadel.localhost` del proyecto.\n- Contraseña: la generada\n\nInicie sesión y cámbiela de inmediato.",{"type":39,"title":71},"Qué despliega la plantilla",{"type":42,"body":73},"La plantilla es un archivo Docker Compose de dos servicios: `db` (PostgreSQL 16) y `zitadel`, lanzado con `start-from-init --tlsMode disabled --masterkeyFromEnv`. El TLS lo termina, por tanto, nginx y no ZITADEL. La imagen seguida es la etiqueta `stable` de `ghcr.io\u002Fzitadel\u002Fzitadel`, lo que significa que la versión realmente en marcha depende del día en que se descargó la imagen: compruébela con `docker compose images` (véase la sección sobre actualizaciones).\n\nEl dominio se pasa a `ZITADEL_EXTERNALDOMAIN`, con `ZITADEL_EXTERNALPORT=443` y `ZITADEL_EXTERNALSECURE=true`. La plantilla considera el dominio fijo desde el primer arranque: elija el correcto desde el principio.",{"type":39,"title":75},"Dominio externo, TLS y reverse proxy",{"type":47,"items":77},[78,79,80,81,82],"**Tres valores que alinear** — `ZITADEL_EXTERNALDOMAIN`, `ZITADEL_EXTERNALPORT` y `ZITADEL_EXTERNALSECURE` deben describir la URL pública real. ZITADEL solo atiende las peticiones enviadas al protocolo, host y puerto esperados; si no, obtiene «Instance not found».","**Cambiar de dominio** — el proyecto documenta que estas opciones pueden modificarse en cualquier momento, siempre que se repita la fase de setup. No es imposible, como afirmaba la versión anterior, pero tampoco es un gesto trivial: toda aplicación cliente referencia la URL antigua.","**Host conservado** — el reverse proxy debe transmitir la cabecera `Host` original y `X-Forwarded-Proto: https`. El ejemplo de nginx del proyecto termina el TLS y habla con ZITADEL en HTTP\u002F2 sin cifrar (h2c) con `grpc_pass`.","**HTTP\u002F2 de extremo a extremo** — la consola exige HTTP\u002F2 hasta ZITADEL. Los proxys probados por el proyecto son Traefik v3, NGINX 1.x estable, Caddy v2 y Apache httpd 2.4.","**CDN o WAF por delante** — la documentación precisa que un proxy, WAF o CDN situado delante de ZITADEL también debe admitir HTTP\u002F2. Pruebe la consola tras cualquier cambio de DNS a un modo con proxy.",{"type":39,"title":84},"Crear su primera aplicación OIDC",{"type":42,"body":86},"Una vez conectado a la consola de ZITADEL:\n\n1. Vaya a **Projects** y luego **Create**\n2. Asigne un nombre a su proyecto (p. ej. `My App`)\n3. Haga clic en **Add Application**\n4. Elija el tipo: **Web** (aplicaciones servidor), **Native** (móvil\u002Fescritorio) o **API** (machine-to-machine)\n5. Para una app Web, seleccione **PKCE** (recomendado) e introduzca sus **Redirect URIs**\n\nZITADEL genera el **Client ID**. Anote el discovery endpoint OIDC: `https:\u002F\u002F\u003Csu-dominio>\u002F.well-known\u002Fopenid-configuration`.",{"type":39,"title":88},"Integrar ZITADEL con sus aplicaciones self-hosted",{"type":42,"body":90},"Cualquier aplicación que hable OIDC puede apoyarse en ZITADEL: basta con el Client ID, el secreto si lo hay y el discovery endpoint. Ejemplos comunes:",{"type":47,"items":92},[93,94,95,96],"**Gitea**: Administración del sitio, Autenticación, añadir una fuente OAuth2 de tipo OpenID Connect e introducir Client ID, secreto y discovery endpoint","**Grafana**: sección `[auth.generic_oauth]` de `grafana.ini` con las URL de autorización, token e información de usuario de ZITADEL","**Nextcloud**: aplicación `Social Login` u `OpenID Connect user backend`","**Cualquier otra aplicación OIDC**: indique el discovery endpoint, el Client ID y las Redirect URIs declaradas en el proyecto; consulte la documentación de la aplicación para los ajustes exactos",{"type":39,"title":98},"Gestión multi-tenant: organizaciones y proyectos",{"type":42,"body":100},"ZITADEL se basa en un modelo multi-tenant nativo: puede crear varias **Organizaciones** (por ejemplo una por cliente de su SaaS), cada una con sus usuarios y sus políticas de inicio de sesión. Cada organización puede tener sus **Proyectos** y **Roles**.\n\nAtención: los roles no se incluyen automáticamente en los tokens, al contrario de lo que afirmaba la versión anterior. Hay que marcar **Assert Roles on Authentication** en el proyecto para obtenerlos mediante userinfo, o **User Roles Inside ID Token** en la aplicación, y solicitar el scope de roles `urn:zitadel:iam:org:project:{projectId}:roles`. Añada también `urn:zitadel:iam:org:project:id:{projectId}:aud` si obtiene «Invalid audience».",{"type":102,"title":103,"body":104},"tip","Consejo: activar passkeys desde el principio","En la configuración de la instancia, active la autenticación Passkey\u002FWebAuthn. Sus usuarios se autentican sin contraseña desde su navegador.",{"type":39,"title":106},"Descubrimiento de dominio: lo que debería funcionar",{"type":42,"body":108},"El descubrimiento de dominio (Domain Discovery) dirige al usuario a la organización correcta según el dominio de su dirección de correo. En el escenario que describe el proyecto, un usuario de `alice@alpha.com` es redirigido al proveedor de identidad de su empresa, un usuario de `bob@beta.com` ve una página de inicio de sesión con contraseña y MFA, y un dominio desconocido cae en la organización por defecto.\n\nLas condiciones descritas en la guía del proyecto son:",{"type":47,"items":110},[111,112,113,114,115,116],"**Instancia** — en Login Behavior and Security, la opción «Domain discovery allowed» está activada","**Organización por defecto** — recibe a todos los usuarios sin coincidencia","**Dominio verificado** — cada dominio se verifica en las Organization Domains de la organización, mediante registro DNS TXT o desafío HTTP; conserve el registro DNS, porque ZITADEL revalida periódicamente","**Política de inicio de sesión de la organización** — «External IDP allowed» activado y, para una organización puramente federada, «Username Password allowed» desactivado","**Proveedor de identidad** — configurado y asociado a esa organización; con un solo proveedor la redirección es automática, con varios el usuario elige","**Inicio de sesión por correo** — el nombre de inicio de sesión introducido debe poder ser una dirección de correo cuyo dominio coincida",{"type":39,"title":118},"Límites conocidos: la incidencia n.º 10662 de zitadel\u002Fzitadel",{"type":42,"body":120},"En ZITADEL v4.1.2 autoalojado, el descubrimiento de dominio no funciona en algunos despliegues pese a tener organizaciones con dominio verificado y un proveedor de identidad configurado. La incidencia n.º 10662 («Domain Discovery doesn't work») se abrió en septiembre de 2025 y sigue abierta al redactar este artículo. La tabla separa lo que el equipo o la documentación establecen de lo que los usuarios reportan.",{"type":122,"title":123,"headers":124,"rows":128},"comparison","Incidencia n.º 10662: confirmado y reportado",[125,126,127],"Punto","Confirmado (equipo o documentación)","Reportado por usuarios, sin confirmar",[129,133,137,141,145,149],[130,131,132],"Síntoma","La incidencia está abierta, con prioridad media en octubre de 2026 y las etiquetas area\u002Fconsole, area\u002FloginV1 y ng-v4-legacy","Mensaje «User not found in the system» para una dirección del dominio verificado, en v4.1.2, idéntico en OKD y en Docker",[134,135,136],"Corrección anunciada","Un mantenedor indicó en octubre de 2025 que la PR n.º 10729 la corregía y después la incidencia se reabrió","El fallo persiste en v4.3.1 y después, en Login V1, en v4.5.0, v4.6.3, v4.7.0 y v4.11.0",[138,139,140],"Causa","No hay ninguna causa establecida públicamente","Ninguna hipótesis verificada",[142,143,144],"Alcance","Existen subincidencias (estado a 16 de julio de 2026: una terminada, dos en curso, una sin empezar), vinculadas al trabajo padre n.º 12337","Reproducido en Login V2 (informe inicial) y luego en Login V1; el caso de varios dominios en una misma organización sigue sin respuesta",[146,147,148],"Consola","El 27 de julio de 2026 una colaboradora indica que la Consola se deprecará en 12 meses y que no se prioriza ninguna corrección hasta entonces; la incidencia se mantiene abierta","Nada que señalar",[150,151,152],"Solución provisional","El hilo no documenta ninguna solución provisional","Ningún participante ha probado ninguna",{"type":42,"body":154},"En la práctica: no construya una arquitectura SSO empresarial únicamente sobre el descubrimiento de dominio mientras esta incidencia siga abierta. Prevea una segunda vía (un enlace de inicio de sesión por proveedor, véase más abajo) y pruebe el enrutamiento con un usuario real antes de producción. El 27 de octubre de 2026 un miembro del equipo pidió verificar el estado de la incidencia: siga la incidencia, y no este artículo, para saber cómo termina.",{"type":39,"title":156},"Solución de problemas del inicio de sesión SSO y del dominio verificado",{"type":58,"title":158,"steps":159},"Diagnóstico en 5 pasos",[160,163,166,169,172],{"title":161,"body":162},"Comprobar la instancia","En la configuración de la instancia, sección Login Behavior and Security, compruebe que «Domain discovery allowed» está activado. Sin él no se consulta ninguna regla de organización.",{"title":164,"body":165},"Comprobar el dominio","En la organización afectada, abra Organization Domains: el dominio debe figurar como verificado. Si la verificación falla, restablezca el registro TXT o el desafío HTTP solicitado y no elimine nunca el registro después.",{"title":167,"body":168},"Comprobar la política de inicio de sesión","En la misma organización, «External IDP allowed» debe estar activado y el proveedor de identidad activo. Si «Username Password allowed» sigue activado, el usuario puede acabar en la solicitud de contraseña en lugar de ser redirigido, síntoma descrito en la incidencia.",{"title":170,"body":171},"Probar el nombre de inicio de sesión","En una ventana privada, introduzca una dirección completa cuyo dominio sea exactamente el verificado. Un error en el dominio, un subdominio o un usuario ya existente en otra organización cambian el resultado.",{"title":173,"body":174},"Eludir el descubrimiento","Si todo es conforme y «User not found in the system» persiste, probablemente está en el caso de la incidencia n.º 10662. El scope `urn:zitadel:iam:org:idp:id:\u003Cidp_id>` redirige directamente al usuario al proveedor de identidad elegido: la documentación lo describe, pero no se ha probado con este fallo.",{"type":47,"items":176},[177,178,179,180,181],"**«User not found in the system»**: aplique los cinco pasos anteriores; si son conformes, es el fallo de la incidencia","**«Instance not found» (404)**: el host, puerto y protocolo recibidos no coinciden con `ZITADEL_EXTERNALDOMAIN`, `ZITADEL_EXTERNALPORT` y `ZITADEL_EXTERNALSECURE`; compruebe que nginx conserva la cabecera `Host`","**Consola en blanco o llamadas a la API que fallan tras un proxy o CDN**: compruebe HTTP\u002F2 de extremo a extremo","**Usuario `admin` rechazado**: pruebe la forma `admin@zitadel.\u003Csu-dominio>` indicada más arriba","**Verificación de dominio que falla**: la guía del proyecto señala que el desafío ACME de verificación puede desactivarse en los ajustes por defecto, pero hágalo solo con conocimiento de causa",{"type":39,"title":183},"Actualizaciones y seguridad",{"type":47,"items":185},[186,187,188,189],"**Versión actual** — al redactar, la última versión estable publicada es la v4.20.0, aparecida en octubre de 2026; lea las notas de versión antes de cada actualización","**Aviso GHSA-jh92-5mrj-p2w2** — toma de control de cuenta por identificadores de sesión predecibles en Login V2 (gravedad alta, sin identificador CVE indicado). Afecta a las versiones 4.0.0 a 4.19.1 y se corrige en la 4.19.2; un despliegue que solo usa Login V1 no está afectado","**Secreto de la cookie de sesión** — la corrección pide `ZITADEL_SESSION_COOKIE_SECRET` (al menos 32 caracteres, idéntico en todas las réplicas); los usuarios deben volver a iniciar sesión tras la actualización","**Rama 3.x** — llegó al final de su vida el 31 de agosto de 2026 y no recibirá corrección: migre a una 4.x reciente",{"type":102,"title":191,"body":192},"Antes de actualizar","Haga una copia de la base con `pg_dump` y de la masterkey, y después ejecute `docker compose pull` seguido de `docker compose up -d` desde la carpeta del Compose. Como la plantilla sigue la etiqueta `stable`, compruebe después la versión en marcha con `docker compose images`.",{"type":39,"title":194},"Instalar ZITADEL desde el Marketplace de ServOrbit",{"type":42,"body":196},"Puede instalar ZITADEL directamente desde el [Marketplace de ServOrbit](\u002Fapplications\u002Fsecurity\u002Fzitadel): VPS preconfigurado con Docker Compose, nginx, HTTPS y secretos generados automáticamente. La plantilla se ofrece como punto de partida, sin soporte para su configuración de identidad.","Desplegar ZITADEL en su VPS","IAM de código abierto, OIDC\u002FOAuth 2.0, passkeys y multi-tenancy nativo — preconfigurado con Docker Compose y HTTPS incluido.","Desplegar ZITADEL","\u002Fapplications\u002Fciberseguridad-bastion\u002Fzitadel",[202,225],{"id":203,"slug":204,"slugs":205,"title":209,"excerpt":210,"readTime":211,"views":18,"isPinned":19,"noindex":19,"publishedAt":212,"updatedAt":213,"category":214,"categories":219,"featuredImage":30,"bgImage":31,"posterImage":221,"relatedSolution":222},112,"desplegar-keycloak-sso-en-un-vps",{"fr":206,"en":207,"ar":208,"es":204},"keycloak-sso-vps","deploy-keycloak-for-sso-on-your-vps","نشر-keycloak-لتسجيل-الدخول-الموحد-sso-على-خادمك-vps","Desplegar Keycloak para el SSO en su VPS","Despliegue Keycloak en su VPS para un SSO de nivel empresarial: OIDC, SAML, realms y federación. Guía Docker completa y comparativa.",10,"2026-02-28T00:00:00+00:00","2026-11-04T16:30:25+00:00",{"id":215,"name":216,"slug":217,"color":218,"icon":34},8,"Seguridad y monitorización","securite-monitoring","bg-rose-500\u002F10 text-rose-400",[220],{"id":215,"name":216,"slug":217,"color":218,"icon":34},"\u002Fblog\u002Fcovers\u002Fkeycloak-sso-vps-poster.svg",{"categorySlug":223,"appSlug":224},"ciberseguridad-bastion","keycloak",{"id":226,"slug":227,"slugs":228,"title":232,"excerpt":233,"readTime":234,"views":235,"isPinned":19,"noindex":19,"publishedAt":236,"updatedAt":21,"category":237,"categories":238,"featuredImage":30,"bgImage":31,"posterImage":240,"relatedSolution":241},272,"authentik-authelia-o-keycloak-elegir-sso-en-vps",{"fr":229,"en":230,"ar":231,"es":227},"authentik-vs-authelia-keycloak-sso-vps-2026","authentik-authelia-or-keycloak-choosing-your-sso-on-vps","authentik-أو-authelia-أو-keycloak-اختيار-sso-على-vps","Authentik, Authelia o Keycloak: elegir su SSO en VPS","Authentik, Authelia o Keycloak en VPS: compare el consumo real de memoria, los protocolos cubiertos y las CVE de Keycloak 26.7.1 para elegir su SSO self-hosted.",6,3,"2026-08-16T00:00:00+00:00",{"id":215,"name":216,"slug":217,"color":218,"icon":34},[239],{"id":215,"name":216,"slug":217,"color":218,"icon":34},"\u002Fblog\u002Fcovers\u002Fauthentik-vs-authelia-keycloak-sso-vps-2026-poster.svg",{"categorySlug":223,"appSlug":242},"authentik",true,1794270614976]