# Keycloak, authentik ou Authelia: qual SSO usar em VPS em 2026?

**Autor:** Maicon Ramos
**Categoria:** Hospedagem & VPS
**Publicado:** 2026-10-01
**Atualizado:** 2026-10-01
**Canonical:** https://runzos.com/keycloak-authentik-authelia-vps-2026/

Para a maioria das stacks Docker em VPS, authentik é a escolha editorial porque combina OIDC, SAML, LDAP, SCIM e proxy auth. Keycloak é mais indicado quando SAML ou requisitos de IAM justificam a operação. Authelia serve melhor como camada de MFA no proxy. A ressalva: app sem integração nativa pode manter senha própria. Centralizar login pode reduzir contas duplicadas, mas também cria uma dependência crítica. Para a maior parte das stacks Docker com vários apps, authentik é o equilíbrio entre OIDC e proxy auth. Keycloak faz sentido quando SAML, LDAP ou fluxos de IAM justificam a operação. Authelia é uma boa camada no proxy. Se os painéis são só seus, VPN ou Headscale podem ser mais simples. A decisão não começa pela interface mais bonita. Ela começa pelos protocolos que seus aplicativos aceitam. Depois, vem o trabalho de manter esse login central disponível quando DNS, e-mail, banco ou proxy falharem. Antes da ferramenta: seu app fala OIDC, SAML ou nada? SSO não é uma propriedade mágica de qualquer painel. Um aplicativo precisa integrar um protocolo de identidade para delegar o login de verdade. Os três projetos entram em cenários diferentes, mas a pergunta inicial é sempre a mesma: cada app aceita OpenID Connect, SAML ou nenhum deles? OIDC costuma ser o caminho mais direto para aplicações modernas. Keycloak suporta OpenID Connect, OAuth 2.0 e SAML. O Keycloak funciona como servidor separado: a aplicação redireciona o navegador para ele durante a autenticação. Isso é útil quando a stack precisa centralizar usuários e clientes em torno de padrões abertos. O authentik oferece OAuth 2.0 e OIDC no provider OAuth2. A documentação também lista providers para SAML, LDAP, SCIM e proxy. Essa combinação explica por que ele costuma caber bem numa VPS com apps diferentes, desde que você aceite administrar seus componentes. Authelia se apresenta como servidor de autenticação 2FA e SSO, pensado como extensão de reverse proxies. Ele integra proxies como Caddy, Envoy, HAProxy, NGINX e Traefik, além de ter integração OIDC. Essa vocação o deixa muito atraente quando o objetivo principal é colocar MFA e uma porta de entrada diante dos painéis. Integração nativa não é a mesma coisa que proxy auth Aqui está a distinção que evita escolhas frustrantes. Com OIDC ou SAML, o app conhece o provedor de identidade. Ele delega o login e pode trabalhar com uma sessão integrada. Com proxy auth ou forward auth, o proxy barra o acesso antes do aplicativo. O proxy provider do authentik existe justamente para apps sem OIDC, SAML ou LDAP nativo. Isso é útil para reduzir exposição e aplicar autenticação antes da aplicação. Porém, o software protegido pode continuar pedindo sua própria senha depois. É o que chamamos de SSO de Fachada: há uma barreira extra na borda, mas não há garantia de que a credencial interna desapareceu. A documentação do Authelia também enquadra o projeto como extensão de reverse proxy. Portanto, chamar qualquer proteção no proxy de “login único universal” é exagero. A leitura correta é mais útil: controle de borda e MFA podem valer muito, mesmo sem integração nativa completa. O Mapa de Compatibilidade de Login Antes de instalar qualquer stack, faça um inventário curto. Liste cada serviço, o domínio usado, o tipo de usuário e o protocolo aceito. Esse é o Mapa de Compatibilidade de Login: uma forma de escolher a ferramenta pelo que seus apps suportam, não pela lista de recursos de uma landing page. Se a maioria fala OIDC, você tem terreno favorável para um IdP. Se um sistema corporativo exige SAML, esse requisito elimina Authelia como IdP para esse app, porque o provider SAML 2.0 ainda está no roadmap do projeto. Se os serviços não falam protocolo algum, proxy auth é uma possibilidade, mas não prometa a si mesmo que o login interno sumirá. Comparativo rápido: Keycloak vs authentik vs Authelia Critério Keycloak authentik Authelia OIDC e OAuth 2.0 Suporta Suporta Integração OIDC documentada SAML como IdP Suporta Suporta provider SAML Não escolher se SAML IdP for requisito Proxy ou forward auth Não confirmado nesta pesquisa Provider proxy com outposts ou forward auth Extensão de reverse proxy LDAP e SCIM Não confirmado nesta pesquisa Providers LDAP e SCIM documentados Não confirmado nesta pesquisa Estado e banco Banco relacional; PostgreSQL é suportado Sem PostgreSQL, não é possível restaurar a instância PostgreSQL, MySQL ou SQLite3; Redis recomendado para sessão em produção ou alta disponibilidade Melhor cenário IAM com requisitos mais exigentes Vários apps Docker com integração e proxy MFA e controle de acesso no proxy Quando evitar Quando a operação não justifica a complexidade Quando você não pode sustentar banco, backup e manutenção Quando SAML IdP é obrigatório A tabela não mede performance. As documentações consultadas não trazem benchmark comparável de RAM, CPU, throughput ou latência entre os três. Por isso, números de blogs não deveriam decidir uma arquitetura de acesso. Quando Keycloak justifica a complexidade Keycloak entra quando a compatibilidade vai além do OIDC mais comum. SAML, fluxos de IAM mais exigentes e uma necessidade real de centralizar clientes e usuários pesam a favor. Ele mantém dados de usuários, clients e realms em banco relacional, com PostgreSQL suportado. Esse desenho cobra disciplina. Se o banco é parte da identidade, o backup dele é parte do serviço. A documentação de produção também trata TLS como requisito importante, porque o sistema lida com dados sensíveis. A terminação TLS no reverse proxy precisa seguir a arquitetura escolhida, não um tutorial copiado sem contexto. Para uma VPS pequena com poucos painéis pessoais, Keycloak pode ser mais infraestrutura do que benefício. Há relatos de operadores que o consideram excessivo em ambiente familiar. Isso não é benchmark nem regra universal. Ainda assim, serve de lembrete: um sistema capaz de atender cenários maiores pode ser a escolha errada para uma necessidade simples. Onde authentik é o equilíbrio authentik reúne OIDC, SAML, LDAP, SCIM e proxy em uma proposta que conversa bem com stacks heterogêneas. Para Docker Compose em testes e produção de pequena escala, a própria documentação informa ao menos 2 CPUs e 2 GB de RAM no host. Não aplique esse mínimo automaticamente a Keycloak ou Authelia. A pesquisa não encontrou um requisito oficial equivalente para eles. A versão e o compose importam. A release 2025.10 removeu a necessidade de Redis para cache, outpost e WebSocket, migrando esses componentes para PostgreSQL. Assim, tutorial antigo que exige Redis não deve virar regra sem conferir a versão instalada. O ponto sensível é recuperação. A documentação de backup do authentik afirma que não é possível restaurar a instância sem PostgreSQL. O banco não é detalhe de implementação: ele entra no seu plano de queda. Onde Authelia é suficiente, e onde não é Authelia é direto para quem precisa de autenticação e 2FA diante de aplicações expostas por proxy. Ele se integra a vários proxies conhecidos e pode usar PostgreSQL, MySQL ou SQLite3 para armazenamento. Para sessão em produção ou alta disponibilidade, a documentação recomenda Redis. Isso não quer dizer que SQLite seja uma escolha para alta disponibilidade. Também não quer dizer que Authelia resolve uma exigência SAML. O roadmap oficial deixa claro que o provider SAML 2.0 ainda é planejamento. Escolha Authelia pelo seu papel de camada de acesso no proxy, não pela expectativa de virar um IAM corporativo completo. Infraestrutura mínima: o Imposto de Identidade Centralizar acesso cria o Imposto de Identidade. Não é uma cobrança financeira fixa. É o trabalho contínuo de DNS, hostname, TLS, e-mail, banco, backup, atualização e recuperação. O custo real não é apenas subir containers. É continuar capaz de entrar nos seus serviços depois de uma falha. Requisito comum Risco se faltar Evidência na stack Domínio e hostname definidos Redirecionamentos e cookies de login podem falhar Serviços de identidade dependem de URLs e fluxos de autenticação coerentes HTTPS e reverse proxy planejados Dados sensíveis expostos ou arquitetura TLS inconsistente Keycloak trata TLS como ponto de produção e documenta cenários de proxy Banco e volumes incluídos no backup Instância pode não voltar após incidente authentik depende de PostgreSQL para restauração; Keycloak usa banco relacional SMTP funcional Recuperação e fluxos de conta podem parar Validar no produto e no fluxo que você pretende usar Restore ensaiado Backup pode existir, mas não recuperar acesso É uma exigência operacional, não uma promessa de ferramenta Conta de emergência e caminho de manutenção Um erro de MFA, proxy ou DNS pode causar lockout Necessário porque o IdP central pode travar vários serviços DNS, hostname, proxy e TLS Não exponha um painel administrativo na Internet apenas porque ele abre no navegador. A pesquisa não valida uma configuração pronta e segura para cada proxy. O princípio é mais importante: publique somente o que precisa ser público, trate HTTPS como requisito de produção e mantenha a arquitetura do proxy documentada. No caso do Keycloak, consulte a documentação de produção do Keycloak e a documentação de reverse proxy antes de decidir onde termina o TLS. Para authentik e Authelia, siga a integração oficial do proxy que você realmente usa. Misturar snippets de NGINX, Traefik e Caddy costuma criar mais problema do que economia de tempo. Banco, volume, SMTP e backup restaurável Backup não é uma pasta compactada. É a capacidade de restaurar banco, volumes e configuração para recuperar acesso. No authentik, PostgreSQL é explicitamente indispensável para restaurar a instância. No Keycloak, o banco relacional guarda dados centrais do servidor. No Authelia, a decisão entre PostgreSQL, MySQL e SQLite3 precisa respeitar o modo de operação. Não há promessa honesta de tempo de restauração nesta comparação. Ele varia com o provedor, volume de dados, backup, procedimento e teste feito pelo operador. O que dá para afirmar é que um restore nunca testado não prova que sua rota de emergência funciona. Como não se trancar fora da própria stack Planeje uma conta administrativa de emergência e um caminho de manutenção antes de colocar todos os painéis atrás do mesmo controle. Proteja esse caminho com cuidado. Não publique credenciais, portas internas ou comandos de produção em documentação aberta. Também teste falhas previsíveis em ambiente descartável: certificado inválido, proxy indisponível, banco restaurado e MFA perdido. O objetivo não é provar que a ferramenta nunca falha. É saber qual parte da sua operação impede que uma falha vire bloqueio total. Quando não usar nenhum dos três SSO não substitui rede privada. Se os painéis são usados por uma pessoa ou poucos dispositivos próprios, uma VPN pode reduzir a exposição pública sem introduzir um IdP completo. O Headscale é uma implementação open source auto-hospedada do servidor de controle do Tailscale. Ele atende uma necessidade de rede privada, não federação de identidade web. Há também o Cloudflare Access para aplicações self-hosted publicadas na Internet. A documentação do Cloudflare Access descreve essa camada gerenciada para apps self-hosted. O aplicativo pode continuar na sua VPS, mas o controle de acesso depende da borda e do plano Cloudflare. A escolha mais simples não é automaticamente melhor. VPN, Headscale, proxy auth, IdP e acesso gerenciado resolvem problemas diferentes. O erro é trocar de ferramenta sem nomear o problema: integração de identidade, proteção de borda ou acesso privado à rede. Recomendação por cenário de VPS Escolha authentik se você opera vários apps Docker, encontra OIDC em parte da stack e quer uma opção que também cubra proxy auth. Comece pelo requisito oficial de 2 CPUs e 2 GB de RAM para seu Docker Compose. Depois dimensione com base na sua carga e na necessidade de banco, backup e e-mail. Não trate esse mínimo como capacidade garantida para qualquer conjunto de aplicações. Escolha Keycloak quando SAML ou integrações de IAM mais exigentes forem requisitos reais. A capacidade de usar OIDC, OAuth 2.0 e SAML é valiosa, mas ela traz uma plataforma central que merece banco, TLS, atualização e plano de recuperação coerentes. Escolha Authelia quando sua necessidade principal é adicionar autenticação forte na frente de painéis via reverse proxy. Ele não deve entrar numa arquitetura que exige SAML IdP. Também não deve receber a promessa de transformar cada login interno em SSO nativo. Para rodar essa infraestrutura, uma VPS é só a base. Se você já precisa de uma para apps internos, as rotas comerciais do Runzos estão disponíveis em Hostinger VPS e Servla VPS. Escolha o provedor pela sua operação, suporte e localização desejada. Nenhuma dessas ofertas transforma, por si só, uma configuração de IAM em algo simples ou seguro. FAQ Authelia substitui Keycloak? Não de forma geral. Authelia é voltado a autenticação, 2FA e integração com reverse proxy, além de OIDC. Keycloak suporta OpenID Connect, OAuth 2.0 e SAML. Se SAML IdP for requisito, Authelia não é a opção desta comparação, porque esse provider ainda está planejado no roadmap. authentik precisa de Redis? Depende da versão e do compose em uso. A release 2025.10 do authentik removeu a necessidade de Redis para cache, outpost e WebSocket, movendo esses componentes para PostgreSQL. Confira a documentação e o compose da versão instalada antes de seguir tutorial antigo. SSO elimina a senha de todos os apps? Não necessariamente. Apps com OIDC ou SAML podem delegar autenticação ao IdP. Já o proxy auth protege o acesso antes do app, mas o aplicativo ainda pode manter uma credencial própria. A proteção de borda continua útil, só não deve ser vendida como integração nativa garantida. Posso expor o painel de administração na Internet? A pesquisa não valida uma configuração universal para isso. O caminho prudente é limitar exposição, usar HTTPS e reverse proxy conforme a documentação oficial da ferramenta, além de manter recuperação e manutenção planejadas. Um painel aberto sem essa arquitetura aumenta o risco operacional. A escolha certa é a que você consegue recuperar authentik é a indicação editorial para a maioria das stacks Docker com apps variados e necessidade de OIDC ou proxy auth. Keycloak ganha quando SAML e IAM mais completo justificam a operação. Authelia resolve bem a camada de proxy e MFA, desde que você não dependa de SAML IdP. A recomendação final não é “centralize tudo”. Faça seu Mapa de Compatibilidade de Login, separe integração nativa de proteção de borda e desenhe o restore antes da migração. Um login central só ajuda quando continua acessível no dia em que sua VPS, proxy ou banco exige recuperação.

## Leia também

- [Chatwoot em VPS: vale a pena para atendimento e WhatsApp em 2026?](https://runzos.com/chatwoot-vps-atendimento-whatsapp-2026/)
- [OpenProject, Taiga ou Kanboard: gestão de projetos self-hosted em VPS vale a pena?](https://runzos.com/openproject-taiga-kanboard-vps-2026/)
- [Zammad, osTicket ou FreeScout: qual helpdesk usar na VPS?](https://runzos.com/zammad-osticket-freescout-vps-2026/)
- [BookStack, Outline ou Docmost: qual wiki privada subir na VPS?](https://runzos.com/bookstack-outline-docmost-vps-2026/)