Authentik em VPS: vale a pena para login único em apps self-hosted?

Authentik em VPS vale a pena quando você já mantém três ou mais apps internos e consegue tratar identidade como infraestrutura. Ele centraliza login, grupos e políticas, mas também cria uma dependência crítica de banco, proxy, DNS e recuperação. Para um único painel, a economia de senhas raramente compensa a operação extra.

O apelo é claro: menos credenciais espalhadas entre Nextcloud, Gitea, Grafana, Portainer e outros serviços. O ponto menos óbvio é que o login único não elimina trabalho. Ele desloca esse trabalho para uma camada que passa a decidir quem entra em vários sistemas.

Essa é a decisão real. O Authentik não é uma compra de segurança nem um container decorativo. É uma escolha de arquitetura. Se você já opera uma VPS com Docker, domínio e rotina de manutenção, ele pode organizar acessos. Se ainda não tem backup restaurável ou rota para recuperar o administrador, pode ampliar o estrago de uma falha simples.

Resposta curta: vale para quem já administra 3 ou mais apps internos

O Authentik é um provedor de identidade open source. Na prática, ele pode concentrar autenticação, grupos, MFA e políticas para aplicações que hoje têm logins separados. Isso reduz a repetição de usuários e regras entre painéis.

A recomendação do Runzos é condicional. Ele faz sentido para um Solo Builder com vários apps internos, um domínio próprio e disposição para manter a camada de identidade. Três apps não são uma regra técnica do projeto. São um limiar editorial útil: abaixo disso, o ganho de organização costuma ser pequeno perto do custo de operar mais serviços.

A instalação oficial por Docker Compose é indicada para testes e produção de pequena escala. O requisito publicado é um host com ao menos 2 vCPU e 2 GB de RAM. Esse é um ponto de partida, não uma promessa de folga para a sua VPS, o proxy e todos os apps protegidos. Consulte os requisitos oficiais do Compose antes de tratar esse mínimo como dimensionamento final.

Também não é uma aplicação isolada. O Compose oficial inclui PostgreSQL, server e worker. A documentação informa que o PostgreSQL guarda dados da aplicação, configurações, sessões e coordenação de tarefas em segundo plano. Isso explica por que o projeto exige uma rotina de manutenção mais séria do que um container sem estado.

Para um único app administrativo, duas opções podem ser mais proporcionais: manter o login nativo bem configurado ou restringir o acesso pela rede privada. Para uma pilha que já virou um pequeno ambiente interno, centralizar identidade passa a ter valor prático.

O que o Authentik centraliza e o que continua fora dele

Authentik centraliza identidade e os controles que você modela dentro dele. Ele pode atuar com OAuth 2.0 e OpenID Connect (OIDC), SAML e LDAP/LDAPS. OIDC é um padrão para um app delegar a autenticação ao provedor de identidade. SAML e LDAP atendem outros modelos de integração e diretórios.

Isso não significa que ele resolve conectividade, exposição de rede ou recuperação por conta própria. VPN, firewall, DNS, TLS, backup e atualização continuam sendo camadas diferentes. MFA também é uma proteção de acesso, não uma restauração de banco, certificado ou rota administrativa.

A documentação do provider OAuth 2.0 informa que o Authentik pode operar como OpenID Provider ou Relying Party. Ela também alerta que clientes podem precisar alcançar endpoints como descoberta, JWKS e token diretamente. Um CDN ou WAF não deve bloquear essas rotas sem critério, pois a integração pode falhar.

Cloudflare Access é outro exemplo de camada diferente. A documentação da Cloudflare descreve a publicação de um app self-hosted com autenticação entre usuário e origem. Isso pode ser útil para controlar acesso na borda, mas não transforma a ferramenta em um IdP local sob sua operação.

A separação evita uma expectativa errada: SSO administra quem se autentica e sob quais regras. Uma rede privada limita quem consegue alcançar o serviço. As duas abordagens podem coexistir.

A arquitetura real: protocolo nativo primeiro, proxy quando necessário

A decisão de integração mais importante não é escolher uma tela de login bonita. É entender como cada app fala de identidade.

Quando o app suporta OIDC, SAML ou LDAP, o caminho preferível é integrar pelo protocolo nativo. Isso preserva um modelo explícito entre aplicação e provedor de identidade. A documentação do Authentik cobre OAuth 2.0/OIDC, SAML2 com metadata e requisições assinadas, além de LDAP com LDAPS e MFA baseada em código.

O proxy provider existe para o caso diferente: proteger aplicações que não suportam OIDC, SAML ou LDAP. Ele pode funcionar como proxy completo ou como forward-auth ao lado de um proxy reverso já existente. Forward-auth significa que o proxy consulta a decisão de autenticação antes de enviar a requisição ao app.

Há ainda os outposts. Eles são necessários para providers LDAP, Proxy, RADIUS e RAC. A documentação informa que um outpost pode ficar onde tenha conexão com a API do Authentik, evitando que esses componentes precisem de acesso amplo à internet.

Essa arquitetura pode ser chamada de SSO de dois trilhos: protocolo nativo onde existe compatibilidade e proxy apenas como ponte para o restante. O conceito central deste artigo, porém, é outro: a Taxa de Dependência de Login. Cada app atrás do IdP reduz uma senha isolada, mas aumenta o impacto de uma indisponibilidade no IdP, proxy ou DNS.

A documentação oficial também alerta para o Docker socket usado na gestão automática de outposts. Montar esse socket tem riscos. O projeto oferece gestão manual ou proxy de socket como alternativas. Não é motivo para abandonar a ferramenta; é motivo para decidir conscientemente como essa parte será operada.

Requisitos de VPS e operação antes de começar

O mínimo oficial de 2 vCPU e 2 GB de RAM serve para um setup pequeno. Não há benchmark oficial universal de RAM por aplicativo protegido. Por isso, qualquer número fixo por app seria uma estimativa sem base suficiente. Planeje monitoramento e folga, em vez de comprar a promessa de que o mínimo atenderá toda a stack.

A VPS precisa acomodar mais do que o Authentik. Você terá Compose, PostgreSQL, serviços server e worker, além do reverse proxy e dos apps existentes. Domínio, DNS e TLS também entram na operação, porque o fluxo de autenticação depende de URLs e redirecionamentos corretos.

O guia de reverse proxy informa que o Authentik usa WebSockets com outposts e requer HTTP/1.1 ou superior. A documentação também limita cabeçalhos encaminhados a redes de proxy confiáveis. Uma configuração errada pode gerar URLs HTTP, conteúdo misto, loops ou erros de autenticação, além de registrar o IP do proxy nos logs.

SMTP merece a mesma atenção. O e-mail global pode atender alertas administrativos, avisos de configuração e releases, verificação e recuperação. Alguns provedores bloqueiam portas SMTP de saída. Portanto, deixar SMTP para depois pode comprometer um caminho de recuperação que você só perceberá quando precisar dele.

Se a sua stack já pede containers, acesso privado e backup fora da máquina, uma VPS Linux estável pode ser a base adequada. Antes de contratar, compare a página de oferta da Hostinger VPS, a Servla VPS e a Turbo Cloud. A escolha deve suportar a sua operação inteira, não apenas iniciar o Authentik.

O risco que decide a maturidade: lockout e recuperação

Centralizar login transforma o Authentik em uma dependência de acesso. Um erro em fluxo, segredo, DNS, certificado ou proxy pode bloquear o operador junto com os usuários. Esse é o custo da Taxa de Dependência de Login: mais governança em condições normais, mais impacto quando a camada central falha.

O banco é a prioridade. O guia oficial de backup e restore afirma que o PostgreSQL contém usuários, políticas, fluxos e configurações. A recomendação é manter o backup fora do host do banco e restaurar o banco antes de reconectar o Authentik.

Isso muda o significado de “tenho backup”. Uma cópia que nunca foi restaurada é uma hipótese, não um plano de recuperação. O teste mínimo é restaurar em ambiente controlado e confirmar que uma conta administradora consegue voltar a entrar. Sem esse teste, não há base para afirmar que o caminho de recuperação funciona.

A interpretação do Runzos adiciona nuance à documentação oficial. O projeto fornece componentes e procedimentos, mas não pode decidir se a sua operação aguenta ser dependente deles. A recomendação prática é só colocar o primeiro app atrás do SSO depois de validar backup externo, restore, SMTP e uma rota administrativa privada. Essa rota pode usar rede privada, desde que você a documente e não a confunda com substituta do IdP.

Atualizações também entram na conta. Como há aplicação, worker, banco, segredos e integrações, uma atualização deve ser tratada como mudança de infraestrutura. Leia as notas de versão aplicáveis, preserve o backup e planeje rollback antes de alterar uma instância que já autentica vários serviços.

Authentik, Authelia, Keycloak, VPN ou Cloudflare Access?

Não existe vencedor abstrato. Cada opção resolve uma parte diferente do problema e exige um modelo operacional próprio.

A documentação do Keycloak mantém guias separados para início, instalação e configuração de servidor, imagem de container, segurança de serviços e administração. Isso aponta para um produto amplo de IAM. Não prova que seja errado para um solo builder, nem autoriza uma comparação de desempenho sem workload reproduzível.

Authelia merece a mesma honestidade. Ele é uma alternativa possível, mas este artigo não usa métricas verificadas para decretar qual consome menos recursos ou é mais fácil. Escolha depois de validar o protocolo exigido, o proxy existente, o modelo de usuários e a recuperação.

A melhor alternativa para um app isolado talvez seja nenhuma nova plataforma de SSO. Se a dor é apenas impedir que o painel fique público, uma VPN ou Headscale pode resolver o alcance de rede com menos mudança no login. Se a dor é autenticação consistente em vários apps, Authentik passa a ter uma proposta mais direta.

Discurso oficial versus evidência operacional

A documentação do Authentik diz que o Compose atende testes e produção pequena com pelo menos 2 vCPU e 2 GB de RAM. Ela também diz que o PostgreSQL é a parte mais importante do backup e que sua perda representa perda total dos dados da aplicação.

Essas duas afirmações não se contradizem. O erro é transformar o mínimo de instalação em promessa de capacidade e disponibilidade. A stack real inclui banco, proxy, DNS, TLS, SMTP e, em alguns providers, outposts. O número mínimo não mede os seus apps, seus picos ou a qualidade da recuperação.

A reconciliação prática do Runzos é objetiva: o Authentik simplifica a governança quando você consegue centralizar também o plano de falha. Sem backup fora da VPS, restore testado, segredos preservados e rota de resgate, a conveniência do login único vem acompanhada de risco concentrado.

Checklist antes de colocar o primeiro app atrás do SSO

Use esta lista como condição de entrada, não como decoração de projeto:

1. Confirmar que o app suporta OIDC, SAML ou LDAP antes de recorrer ao proxy.
2. Reservar a VPS partindo do mínimo oficial, com monitoramento e margem para a stack inteira.
3. Identificar onde ficam PostgreSQL, segredos, volumes e arquivos de configuração.
4. Criar backup do PostgreSQL fora do host que executa o banco.
5. Restaurar o banco em ambiente controlado antes de migrar usuários reais.
6. Configurar SMTP e validar uma entrega de e-mail de recuperação.
7. Configurar DNS, TLS e URLs públicas que os fluxos de login usarão.
8. Validar HTTP/1.1, WebSockets e proxies confiáveis no reverse proxy.
9. Manter uma rota administrativa privada, documentada e acessível em caso de erro público.
10. Verificar se WAF ou CDN não bloqueia endpoints OIDC necessários.
11. Registrar a sequência de atualização, backup e rollback antes de fazer upgrades.
12. Proteger primeiro um app não crítico e testar login, logout e recuperação.

Se qualquer item ainda for uma intenção vaga, adie a migração. O melhor momento para descobrir um lockout não é depois que todos os painéis internos dependem do mesmo login.

FAQ sobre Authentik em VPS

Authentik substitui uma VPN?

Não. Authentik centraliza identidade e políticas de autenticação. Uma VPN ou Headscale restringe o acesso à rede e pode impedir que pessoas não autorizadas alcancem o app. Os dois podem coexistir: rede privada para reduzir a exposição e Authentik para organizar identidade nos serviços que precisam dela.

Quantos recursos uma VPS precisa para rodar Authentik?

A documentação oficial do Compose informa ao menos 2 vCPU e 2 GB de RAM para testes e produção de pequena escala. Não existe, nesta pesquisa, um número oficial por app protegido. Considere também PostgreSQL, reverse proxy e os demais containers antes de dimensionar a máquina.

Quais apps self-hosted funcionam com Authentik?

Apps com OIDC, SAML ou LDAP podem integrar pelo protocolo nativo. Para aplicações sem esses protocolos, o Authentik oferece proxy provider e forward-auth. A compatibilidade concreta depende do app e do método de integração escolhido; não presuma que qualquer painel terá o mesmo fluxo.

Authentik precisa de PostgreSQL e Redis?

O Compose oficial inclui PostgreSQL, server e worker. A documentação de configuração destaca o PostgreSQL como armazenamento dos dados e da coordenação de tarefas. Este artigo não afirma requisito de Redis, porque a base de pesquisa não o documenta como parte do Compose oficial citado.

O que fazer se eu perder o acesso de administrador?

A resposta deve existir antes do incidente: restaurar o banco a partir de backup externo conforme o procedimento oficial, preservar segredos e manter uma rota administrativa privada documentada. SMTP pode apoiar recuperação e alertas, mas não substitui backup nem restore. Teste o processo em ambiente controlado antes de depender dele.

Veredito: centralize login apenas se puder centralizar recuperação

Authentik em VPS é uma escolha sólida para quem já opera uma coleção de apps internos e quer reduzir identidades dispersas. Ele não é uma escolha automática para todo projeto self-hosted. Um único app, uma operação sem backup testado ou uma VPS sem espaço para a stack inteira são sinais para simplificar primeiro.

A Taxa de Dependência de Login resume a decisão: quanto mais serviços usam o IdP, maior é o ganho de governança e maior é o custo de uma falha central. Se você aceita essa responsabilidade operacional, comece com um app pouco crítico, valide recuperação e avance por etapas. Se não aceita, resolva primeiro a rede privada ou o login nativo. Isso é mais seguro do que instalar SSO apenas porque a arquitetura parece profissional.