Keycloak, authentik ou Zitadel: qual usar num VPS?

Qual servidor SSO é adequado para um VPS

Keycloak, authentik e Zitadel são servidores de single sign-on (SSO) autoalojados que surgem sempre que alguém quer usar um único login para todas as aplicações do servidor. Num VPS pequeno, não são equivalentes. O authentik é a opção padrão mais segura para um servidor com três ou quatro aplicações autoalojadas, porque é o único dos três que consegue colocar um ecrã de login à frente de uma aplicação sem autenticação própria. O Keycloak é a escolha certa quando todas as aplicações protegidas já suportam um protocolo padrão e há memória suficiente para uma máquina virtual Java (JVM). O Zitadel foi concebido para programadores que disponibilizam um produto através de uma API e é a opção que eu não tentaria usar com menos de 4 GB.

Escolha primeiro e instale depois. Depois de escolher, a instalação prática do authentik num VPS apresenta a configuração passo a passo.

De quanta RAM cada um precisa realmente?

Comece pelo mínimo de recursos, porque ele define a lista de opções antes de qualquer funcionalidade. Os números abaixo são os valores publicados pelos próprios projetos, consultados em agosto de 2026. São orientações dos fornecedores, não resultados de testes 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
  }
]

A página de instalação do authentik com Docker Compose pede "um host com pelo menos 2 núcleos de CPU e 2 GB de RAM", ou seja, 2048 MB, e o ficheiro compose publicado executa 3 contentores: PostgreSQL, o servidor e o worker.

O Keycloak publica o valor mais específico dos 3. O guia de dimensionamento afirma que "o uso base de memória de um Pod, incluindo caches de dados de Realm e 10.000 sessões em cache, é de 1250 MB de RAM". Esses 1250 MB abrangem apenas o processo Java, antes da base de dados. A mesma página explica por que o limite do contentor é tão importante: o Keycloak usa 70% do limite de memória como heap e precisa de aproximadamente 300 MB de memória non-heap adicionais. Se atribuir 1 GB ao contentor, ele calcula um heap de cerca de 717 MB e continua a precisar desses 300 MB de memória non-heap. Assim, o limite já está esgotado antes de quaisquer dados de sessão serem colocados na cache.

A página do compose do Zitadel também pede 2 GB, os mesmos 2048 MB, mas esse valor aplica-se à primeira execução. Deve consultar a página de produção. O processo do Zitadel precisa de "aproximadamente 512MB de RAM e pode funcionar com menos de um núcleo de CPU". A base de dados é a parte mais exigente: "cerca de um núcleo de CPU por 100 pedidos por segundo (req/s) e 4GB de RAM por núcleo". O hashing de palavras-passe precisa então de "4 núcleos de CPU disponíveis para esta finalidade", porque um pico de logins se transforma num pico de utilização da CPU. O compose oficial v4 executa 4 contentores antes de adicionar qualquer outro: Traefik como proxy, a API do Zitadel, um contentor separado para a Login UI e PostgreSQL. Redis e um coletor OpenTelemetry ficam atrás de perfis compose opcionais.

Assim, Keycloak e authentik cabem num VPS com 4 GB, deixando memória disponível para as aplicações que está a proteger. O Zitadel inicia com 2 GB, mas passa a competir com o seu próprio PostgreSQL pela memória em cada login. Eu não executaria o Zitadel com menos de 4 GB. Num servidor que também aloje aplicações, reservaria 8 GB.

O que cada um realmente executa no seu servidor

authentik é composto por PostgreSQL e duas cópias da mesma imagem: um servidor e um worker. O servidor responde por HTTP e inclui um outpost integrado. O worker executa tarefas em segundo plano, como sincronizações de diretórios e envio de e-mail. A instalação publicada é curta.

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

O servidor publica as portas 9000 e 9443. A primeira visita à porta 9000 inicia o fluxo de configuração inicial, no qual define a palavra-passe do utilizador akadmin predefinido. Coloque um reverse proxy com um certificado válido à frente dele antes de essa porta ficar acessível pela Internet.

Keycloak é composto por um processo e por uma base de dados fornecida por si. O início rápido usa um único contentor.

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 serve para explorar o produto. É executado com uma base de dados de desenvolvimento local e sem TLS (segurança da camada de transporte). Por isso, se iniciar um contentor dessa forma e o remover posteriormente, perderá o seu realm. Em produção, use start, com um PostgreSQL real através de KC_DB e um nome de anfitrião público através de KC_HOSTNAME. O guia de produção do Keycloak também indica que todas as comunicações de e para o servidor exigem um canal seguro. Por isso, HTTPS não é opcional nesse cenário.

Zitadel é a stack de quatro contentores descrita acima.

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

Defina ZITADEL_MASTERKEY em .env antes do primeiro arranque. Esta é a chave de 32 caracteres que o Zitadel usa para cifrar segredos na base de dados. Se a perder, perderá o acesso a esses segredos. Se ainda não estiver familiarizado com a execução de stacks deste tipo, os conceitos básicos do Docker Compose para um VPS explicam as escolhas de volumes e políticas de reinício que determinam se o seu fornecedor de identidade sobrevive a um reboot.

Quais protocolos cada um suporta?

Os três suportam OpenID Connect (OIDC), a camada de login sobre OAuth 2.0 que as aplicações modernas utilizam, e os três suportam SAML 2.0 (security assertion markup language), o padrão mais antigo que o software empresarial continua a lançar. A verdadeira diferença está no LDAP (lightweight directory access protocol), onde uma única palavra abrange duas funções opostas.

Ler a partir do LDAP significa que o servidor SSO valida as palavras-passe num diretório que já gere. O Keycloak faz isto através da federação de utilizadores. O Zitadel também: a documentação descreve como "ligar um servidor LDAP como fornecedor de identidade no ZITADEL".

Disponibilizar LDAP significa que uma aplicação que fala apenas LDAP pode fazer bind no seu servidor SSO como se este fosse o diretório. Apenas o authentik suporta esta função. O seu fornecedor LDAP torna "todos os utilizadores e grupos na base de dados do authentik pesquisáveis através do diretório LDAP" por meio de um outpost LDAP dedicado, com LDAPS disponível na porta 636. O acesso é apenas de leitura, por isso o bind e a pesquisa funcionam, mas as operações de escrita não. Um código de utilização única é acrescentado à palavra-passe com um ponto e vírgula, como em password;123456, e os autenticadores SMS não são suportados durante o bind.

Se uma aplicação da sua lista suportar apenas LDAP, a comparação termina aí. O Keycloak e o Zitadel não conseguem responder a esse bind, por isso teria de executar um segundo diretório ao lado deles e manter duas listas de utilizadores sincronizadas.

E quanto às aplicações que não têm qualquer login?

A autenticação delegada é a resposta, e este é um caso frequente num servidor self-hosted. O reverse proxy pergunta ao servidor SSO se um pedido é permitido antes de o encaminhar para o upstream. A aplicação que está atrás dele não sabe nada sobre o SSO. Recebe pedidos que o proxy já validou, normalmente com o nome de utilizador num cabeçalho.

O proxy provider do authentik trata deste caso com três modos documentados. No modo "Proxy", o authentik outpost encaminha o tráfego para a aplicação upstream. O modo "Forward auth (single application)" mantém o tráfego no reverse proxy existente e usa o authentik apenas para verificar a autenticação. O modo "Forward auth (domain level)" protege todas as aplicações num mesmo domínio principal com um único provider. O nível de domínio é o mais conveniente, mas tem uma limitação documentada: "não pode impor regras de autorização diferentes ao nível da aplicação para cada aplicação protegida", pelo que todas as aplicações desse domínio partilham o mesmo conjunto de políticas.

O Keycloak não tem nada equivalente. O seu proxy complementar, Keycloak Gatekeeper, foi renomeado para Louketo Proxy e depois arquivado no GitHub, com o último commit em agosto de 2023. Para proteger uma aplicação sem suporte de OIDC, é necessário executar um componente separado à sua frente, normalmente oauth2-proxy, configurado para um cliente do Keycloak. O Zitadel também não tem um modo próprio de forward auth, pelo que a solução é instalar, monitorizar e atualizar esse componente adicional.

É nesse salto adicional que a configuração do reverse proxy deixa de ser simples. Antes de configurar um middleware de autenticação, leia como o Traefik encaminha pedidos para várias aplicações Docker Compose.

Qual é o impacto do processo de atualização?

Em agosto de 2026, as versões atuais são Keycloak 26.7.1, authentik 2026.5.6 e Zitadel v4.16.3. Os três executam migrações de esquema no PostgreSQL, o que significa que cada atualização altera a base de dados. Faça primeiro uma cópia de segurança da base de dados, sempre. Esse hábito é mais importante do que qualquer funcionalidade desta comparação.

O authentik tem a regra mais rigorosa e declara-a claramente: "As atualizações devem seguir a sequência das versões principais; não salte diretamente de uma versão principal antiga para a versão mais recente." Atualize para o patch mais recente de cada versão antes de passar para a seguinte, e "o authentik não suporta downgrade". Ficar um ano atrás num projeto com versões baseadas no calendário transforma uma atualização numa sequência de várias atualizações, cada uma com a sua própria migração de base de dados.

O guia de atualização do Keycloak define uma ordem a seguir: reveja as alterações de migração da versão anterior, atualize o servidor e, depois, atualize os adaptadores. A migração da base de dados é executada automaticamente. Também pode exportá-la e aplicá-la manualmente, o que é útil quando pretende ler as alterações antes de serem aplicadas. No Keycloak, o custo está nessa leitura. As notas de versão incluem descontinuações e alterações de comportamento que são fáceis de ignorar e dispendiosas quando não são detetadas.

O Zitadel separa as fases de inicialização e configuração do servidor em execução. As orientações para produção recomendam mantê-las separadas para que o dimensionamento não repita o trabalho de configuração. Num único VPS, isto significa sobretudo que a etapa de configuração tem de terminar antes de a API indicar que está saudável. Por isso, o ficheiro compose inclui verificações de saúde e o comando de arranque usa --wait.

Para quem cada projeto foi criado e onde ficam as suas limitações

Keycloak é o servidor de identidade da Red Hat, criado para organizações com realms, grupos, mapeamentos de funções e um diretório empresarial existente. É a implementação mais completa dos padrões entre as três opções. Fica menos adequado num VPS com 2 GB que executa quatro aplicações autoalojadas, quando metade delas não tem suporte para OIDC. São consumidos 1250 MB pela JVM, é necessário aprender um modelo de realms concebido para uma empresa e ainda instalar o oauth2-proxy para as aplicações que realmente eram importantes.

authentik foi criado para o público de autoalojamento, como mostra a lista de funcionalidades. Inclui forward auth e um fornecedor LDAP, além de permitir criar fluxos de início de sessão num editor visual. Fica menos adequado quando é necessário um contrato de suporte do fornecedor ou um ciclo de releases que não muda a cada poucas semanas. O versionamento baseado em calendário, sem caminho para downgrade e sem possibilidade de ignorar versões, exige trabalho operacional real. O editor de fluxos também introduz todo um modelo que é necessário aprender quando o problema real é apenas um cliente OIDC.

Zitadel foi criado para programadores que incorporam a autenticação num produto que lançam, com uma API robusta e suporte nativo para multitenancy. Fica menos adequado exatamente neste caso. Quatro contentores, ausência de forward auth e uma base de dados dimensionada para 4 GB por core formam uma arquitetura inadequada para um único VPS com um gestor de palavras-passe e uma wiki atrás dele.

O que eu executaria num VPS e como

Para um VPS com três ou quatro aplicações autoalojadas, execute o authentik. As três opções apresentam um ecrã de início de sessão. O fator decisivo é que algumas das suas aplicações nunca suportarão OIDC, e o authentik resolve esse problema com forward auth integrado, sem precisar de outro componente ao lado.

Atribua 4 GB se possível e 2 GB apenas se as aplicações que partilham o VPS forem pequenas. Mantenha a porta 9000 fora da Internet pública e termine o TLS num reverse proxy à frente do serviço. Faça dumps noturnos do PostgreSQL e armazene-os fora do servidor, porque um fornecedor de identidade sem backup é um ponto único de falha para todas as aplicações que dependem dele. Execute a stack com uma conta dedicada sem privilégios, em vez de root: configurar utilizadores com privilégios mínimos num VPS explica a conta e a propriedade dos ficheiros necessárias neste caso.

Escolha o Keycloak quando todas as aplicações protegidas já suportarem OIDC ou SAML, ou quando precisar do modelo de funções detalhado disponibilizado pelos realms do Keycloak. Escolha o Zitadel quando estiver a criar uma aplicação na qual outras pessoas possam efetuar o registo e quiser utilizar a respetiva API e o seu modelo de tenants. Nenhuma destas opções corresponde ao caso de três aplicações num único servidor abordado neste artigo.

Os modos de falha que encontrará primeiro

O Keycloak não tem dados depois de um reinício. Iniciou-o com start-dev, que usa uma base de dados local para desenvolvimento. Num contentor sem um volume, remover o contentor remove o realm. Passe para start com KC_DB=postgres apontado para uma base de dados real.

O contentor worker do authentik desaparece numa máquina pequena. O worker e o servidor usam a mesma imagem e mantêm ambos processos Python, enquanto o PostgreSQL precisa da sua parte dos 2 GB do host. Execute docker compose ps para confirmar que serviço terminou e verifique dmesg para detetar uma terminação por falta de memória antes de procurar um erro na aplicação.

A Console do Zitadel não funciona atrás do seu proxy. A API do Zitadel usa gRPC, que precisa de HTTP/2 em todo o percurso até ao upstream. A página de requisitos pede um reverse proxy que suporte ligações HTTP/2 ao upstream e indica versões testadas do Traefik v3.x, NGINX v1.x, Caddy v2.x e Apache httpd 2.4.x. Um proxy que reduz a ligação ao upstream para HTTP/1.1 apresenta uma página de início de sessão que carrega, mas uma Console que falha.

Todas as aplicações redirecionam-no novamente para o ecrã de início de sessão. O URL público do servidor SSO e o URL configurado na aplicação têm de corresponder exatamente, incluindo o esquema e a porta. O Keycloak chama a isto a definição de hostname; o Zitadel chama-lhe domínio externo. Quando divergem, a aplicação redireciona para um início de sessão que o servidor não reconhece como sendo seu, e o browser alterna entre os dois.

FAQ

Qual dos três é adequado para uma VPS com 2 GB?

authentik e Keycloak. O requisito declarado do authentik é um host com pelo menos 2 CPU cores e 2 GB de RAM, e o guia de dimensionamento do Keycloak indica 1250 MB de memória base para o servidor, antes da base de dados. Ambos ficam limitados com 2 GB depois de adicionar as aplicações que pretende proteger, por isso considere 4 GB como o mínimo confortável. O Zitadel publica 2 GB para a primeira execução, mas as orientações para produção pedem 4 CPU cores para hashing de palavras-passe e 4 GB de RAM por core da base de dados, pelo que 2 GB não constituem uma implementação realista.

O Keycloak ou o Zitadel podem proteger uma aplicação que não tenha o seu próprio login?

Não por si só. Nenhum dos dois inclui um componente de forward auth. O antigo proxy complementar do Keycloak, Louketo Proxy, está arquivado no GitHub e teve o último commit em agosto de 2023, por isso não deve ser usado como base. Coloque oauth2-proxy ou um componente semelhante entre o reverse proxy e a aplicação e aponte-o para um cliente OIDC no servidor SSO. O authentik faz isto nativamente com o seu proxy provider, no modo "Forward auth (single application)" ou "Forward auth (domain level)".

Qual deles pode funcionar como servidor LDAP para uma aplicação que só comunica por LDAP?

authentik. O seu LDAP provider é executado num outpost e permite pesquisar por LDAP os utilizadores e grupos existentes no authentik, com LDAPS disponível na porta 636. O acesso é apenas de leitura, por isso bind e pesquisa funcionam, mas as operações de escrita não. Keycloak e Zitadel funcionam no sentido contrário: ambos leem de um diretório LDAP existente como fonte de utilizadores, e nenhum responde a um LDAP bind enviado por uma aplicação.

Posso saltar versões ao atualizar o authentik?

Não. A documentação indica que as atualizações devem seguir a sequência das versões principais e que não deve saltar diretamente de uma versão principal antiga para a mais recente. Atualize primeiro para a versão de patch mais recente dentro de cada versão e avance depois uma versão de cada vez. Faça uma cópia de segurança do PostgreSQL antes de cada passo, porque o authentik não suporta downgrade e as migrações só avançam.