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.

Quanto de RAM cada um realmente precisa?

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 outubro 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. Esse valor para o host tem de cobrir os três, incluindo a base de dados.

O Keycloak publica o valor mais específico dos 3. O seu 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 correspondem ao servidor Keycloak com essas caches. O guia dimensiona a base de dados separadamente, portanto o PostgreSQL precisa de memória própria além desse valor. 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 utiliza aproximadamente 300 MB adicionais de memória non-heap. No exemplo apresentado, os 1250 MB de base resultam num limite de memória de 1360 MB. Com 1 GB atribuído ao contentor, o sistema calcula um heap de aproximadamente 717 MB. Os cerca de 300 MB de memória non-heap elevam o total para aproximadamente 1017 MB. Isso deixa quase nenhuma margem dentro do limite, enquanto o valor base indicado pelo próprio guia, com caches de realms e 10.000 sessões, é 1250 MB.

A página do compose do Zitadel também pede 2 GB, os mesmos 2048 MB, indicados como pré-requisito para todo o guia, desde o quickstart até à fase de homelab ou semiprodução. Para dimensionamentos maiores, consulte a página de produção. O processo do Zitadel precisa de “aproximadamente 512 MB 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 4 GB de RAM por núcleo”. O hashing de palavras-passe também precisa de “4 núcleos de CPU disponíveis para este fim”, porque um pico de logins se transforma num pico de utilização do 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 interface Login 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 margem para as aplicações que está a proteger. O Zitadel arranca com 2 GB, mas passa a disputar memória com o seu próprio PostgreSQL a cada login. Eu não executaria o Zitadel com menos de 4 GB. Num servidor que também aloje aplicações, escolheria 8 GB.

O que cada um executa na sua máquina

authentik é composto por PostgreSQL e duas cópias da mesma imagem: um servidor e um worker. O servidor responde a pedidos HTTP e contém um outpost incorporado. O worker executa tarefas em segundo plano, como sincronização 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. O primeiro acesso à porta 9000 inicia o fluxo de configuração inicial, onde define a palavra-passe para o utilizador predefinido akadmin. Coloque um reverse proxy com um certificado válido à frente antes de tornar essa porta acessível a partir da internet.

Keycloak é um processo único mais uma base de dados fornecida por si. O quickstart é 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.8.1 start-dev

start-dev serve para exploração. Executa com uma base de dados de desenvolvimento local e sem TLS (transport layer security), por isso, um contentor iniciado desta forma e posteriormente removido levará o seu realm consigo. Produção significa usar start, com um PostgreSQL real através de KC_DB e um hostname público através de KC_HOSTNAME. O guia de produção do Keycloak também estabelece que toda a comunicação de e para o servidor requer um canal seguro, pelo que HTTPS não é opcional nesse cenário.

Zitadel é a stack de quatro contentores descrita anteriormente.

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. É a chave de 32 caracteres que o Zitadel utiliza para encriptar segredos na base de dados; perdê-la significa perder o acesso a esses segredos. Se não tem experiência a executar stacks deste tipo, os fundamentos de Docker Compose para uma VPS cobrem as escolhas de volumes e políticas de reinício que determinam se o seu fornecedor de identidade sobrevive a um reboot.

Que protocolos cada um suporta?

Os três suportam OpenID Connect (OIDC), a camada de início de sessão sobre OAuth 2.0 usada pelas aplicações modernas. Os três também suportam SAML 2.0 (security assertion markup language), o padrão mais antigo que o software empresarial ainda distribui. A diferença principal está no LDAP (lightweight directory access protocol), em que um único termo abrange duas funções opostas.

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

Servir LDAP significa que uma aplicação que só suporta LDAP pode fazer bind contra o servidor SSO como se este fosse a diretoria. Apenas o authentik suporta esta função. O seu fornecedor LDAP permite que "todos os utilizadores e grupos na base de dados do authentik sejam pesquisáveis através da diretoria LDAP" por meio de um LDAP outpost dedicado, com LDAPS disponível na porta 636. Por predefinição, um utilizador autenticado só pode pesquisar os próprios dados e grupos. Por isso, a conta de serviço usada pela aplicação para fazer bind precisa da permissão "Search full LDAP directory" para consultar todos os utilizadores. A documentação abrange apenas operações de bind e pesquisa e não descreve operações de escrita. Trate-o, portanto, como uma diretoria apenas de leitura. Um código de utilização única é acrescentado à palavra-passe com um ponto e vírgula, como em password;123456. Os autenticadores por 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. Nesse caso, teria de executar uma segunda diretoria 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 é um caso que um servidor self-hosted encontra constantemente. O reverse proxy pergunta ao servidor SSO se um pedido é permitido antes de o encaminhar para o serviço upstream. A aplicação que está por trás não sabe nada sobre o SSO. Recebe pedidos que o proxy já validou, normalmente com o nome de utilizador num cabeçalho.

O provider de proxy do authentik suporta isto com três modos documentados. O modo "Proxy" faz com que o outpost do authentik encaminhe o tráfego diretamente 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 a verificação da autenticação. O modo "Forward auth (domain level)" protege todas as aplicações de um mesmo domínio principal com um único provider. O modo ao nível do domínio é o mais conveniente, mas tem uma limitação documentada: "cannot enforce different application-level authorization rules for each protected application"; por isso, 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, mudou de nome para Louketo Proxy, chegou ao fim de vida em November 2020 e foi arquivado no GitHub em December 2020. Para proteger uma aplicação sem suporte para OIDC, é necessário executar um componente separado à frente dela, normalmente o oauth2-proxy, configurado para um client do Keycloak. O Zitadel também não tem um modo próprio de autenticação delegada, pelo que a solução é instalar, monitorizar e atualizar o mesmo componente adicional.

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

Como é o processo de atualização?

Em 25 October 2026, as versões atuais são Keycloak 26.8.1, authentik 2026.8.5 e Zitadel v4.20.0. 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. Este 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 avance diretamente de uma versão principal mais antiga para a versão mais recente." Atualize para o último patch de cada versão antes de passar à seguinte, e "o authentik não suporta downgrade". Ficar um ano atrasado num projeto com versões baseadas no calendário transforma uma atualização numa cadeia de atualizações, cada uma com a sua própria migração da 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, em seguida, atualize os adapters. A migração da base de dados é executada automaticamente, mas também pode exportá-la e aplicá-la manualmente. Isto é útil quando pretende ler a alteração antes de esta ser aplicada. 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 init e setup do servidor em execução. As orientações para produção recomendam mantê-las separadas para que o scaling não repita o trabalho de setup. Num único VPS, isto significa sobretudo que o passo de setup tem de terminar antes de a API indicar um estado saudável. Por isso, o ficheiro compose inclui health checks e o comando de arranque usa --wait.

Para quem cada projeto foi criado e onde cada um fica aquém

Keycloak é o servidor de identidade da Red Hat, criado para organizações com realms, grupos, mapeamentos de funções e um diretório corporativo existente. É a implementação mais completa dos padrões entre os três. Fica aquém num VPS de 2 GB que execute quatro aplicações self-hosted, quando metade delas não tem suporte para OIDC. São consumidos 1250 MB pelo servidor Keycloak antes de contabilizar a base de dados, é necessário aprender um modelo de realm concebido para uma empresa e, ainda assim, instalar o oauth2-proxy para as aplicações que realmente interessavam.

authentik foi criado para o público de self-hosting, 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 aquém quando é necessário suporte do fornecedor sem um orçamento empresarial ou um ciclo de releases que não avance a cada poucas semanas. O suporte só está disponível com uma subscrição paga: suporte por tickets nas subscrições Enterprise acima de $1k e suporte dedicado com SLAs no Enterprise Plus, que começa em $20k por ano. O versionamento baseado no calendário, sem possibilidade de downgrade nem de saltar 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 integram autenticação num produto que distribuem, com uma API robusta e multi-tenancy como funcionalidades de primeira classe. Fica aquém exatamente neste caso. Quatro contentores, sem forward auth e uma base de dados dimensionada para 4 GB por core não são adequados para um único VPS com um gestor de palavras-passe e uma wiki protegidos por autenticação.

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 das três opções é adequada 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. O guia de dimensionamento do Keycloak indica 1250 MB de memória base para o servidor, sem contar a base de dados. As duas opções ficam no limite com 2 GB depois de adicionar as aplicações que pretende proteger. Considere 4 GB como o mínimo confortável. O guia do Zitadel para compose também indica 2 GB e apresenta uma configuração de homelab ou semiprodução com essa capacidade. No entanto, as recomendações para produção pedem 4 CPU cores para o hashing de palavras-passe e 4 GB de RAM por core da base de dados. Espere que 2 GB fiquem insuficientes quando houver tráfego real de autenticação.

O Keycloak ou o Zitadel podem proteger uma aplicação que não tem autenticação própria?

Não por si só. Nenhum dos dois inclui um componente de forward auth. O antigo proxy complementar do Keycloak, Louketo Proxy, chegou ao fim de vida em novembro de 2020, e o respetivo repositório no GitHub está arquivado desde dezembro de 2020. Por isso, não deve usá-lo como base. Coloque oauth2-proxy ou um componente semelhante entre o reverse proxy e a aplicação. Aponte esse componente 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 delas pode funcionar como servidor LDAP para uma aplicação que só suporta 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. A documentação abrange apenas operações de bind e pesquisa. Considere-o, portanto, como somente leitura. Keycloak e Zitadel funcionam no sentido inverso: ambos leem dados de um diretório LDAP existente como fonte de utilizadores, e nenhum dos dois responde a um bind LDAP iniciado por uma aplicação.

Posso ignorar 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. Não deve passar diretamente de uma versão principal antiga para a versão mais recente. Primeiro, atualize para a versão de patch mais recente dentro de cada versão. Depois, avance uma versão de cada vez. Faça uma cópia de segurança do PostgreSQL antes de cada etapa, porque o authentik não suporta downgrade e as migrações só avançam.