SSO seguro com VPS para Keycloak

Resposta direta

Para hospedar Keycloak em produção, uma VPS para Keycloak deve começar com pelo menos 2 vCPUs, 4 GB de RAM, 40 a 80 GB de SSD e PostgreSQL como banco persistente. Esse perfil atende ambientes pequenos com poucos realms, logins moderados e integrações OIDC ou SAML sem carga pesada. Para times, SaaS ou SSO corporativo, o caminho mais seguro é usar 4 vCPUs, 8 GB de RAM, PostgreSQL separado, HTTPS via proxy reverso, firewall restritivo, backups testados e monitoramento de CPU, heap JVM, latência de login e conexões do banco. Alta disponibilidade exige mais do que subir duas VPS: é preciso balanceador, banco resiliente, configuração correta de proxy, estratégia de cache e testes de failover antes de depender do ambiente para autenticação crítica.

Resumo rápido

• Keycloak em produção deve usar PostgreSQL, não banco em memória ou configuração de laboratório.
• Um ponto de partida seguro é 2 vCPUs, 4 GB de RAM e 40 a 80 GB de SSD para ambientes pequenos.
• Para SaaS, times internos ou clientes reais, 4 vCPUs e 8 GB de RAM reduzem risco em picos de autenticação.
• HTTPS precisa ficar bem configurado no proxy reverso, com headers corretos e renovação automática de certificado.
• Firewall, SSH por chave, atualizações e secrets fora do repositório são parte do projeto, não acabamento.
• Backups só contam se a restauração foi testada em outro servidor ou ambiente isolado.
• Alta disponibilidade pede balanceador, PostgreSQL confiável e validação prática de failover.

Quando faz sentido hospedar Keycloak em uma VPS

Keycloak é uma peça central de autenticação. Ele concentra login, federação de identidade, emissão de tokens, integração com provedores externos, regras de acesso e SSO para aplicações que antes teriam autenticação própria. Em uma VPS ou Cloud Server, você ganha controle sobre versão, configuração, extensões, logs e integração com a sua rede. Isso costuma fazer sentido quando a empresa quer evitar dependência total de um serviço gerenciado, precisa customizar temas de login, usa múltiplos clientes OIDC ou SAML, ou quer manter dados de identidade sob uma infraestrutura mais controlada.

O ponto sensível é que autenticação não é um serviço qualquer. Se uma API de relatórios fica lenta, usuários reclamam. Se o Keycloak cai, o login de todas as aplicações conectadas pode parar. Por isso, a decisão de usar VPS para Keycloak deve vir junto com uma arquitetura simples, mas disciplinada: banco PostgreSQL persistente, proxy HTTPS, logs acessíveis, backups e política de atualização. Um ambiente de teste pode rodar em 1 vCPU e 2 GB de RAM. Produção não deveria começar por aí, porque a JVM, o cache, as conexões com PostgreSQL e os picos de login consomem memória rápido.

O papel do Keycloak no SSO

Em um cenário comum, Keycloak recebe o login do usuário, valida senha, MFA ou identidade federada, emite tokens JWT e redireciona o usuário para aplicações internas. Um SaaS pequeno pode ter painel web, API, app mobile e área administrativa usando o mesmo realm. Uma escola pode integrar portal do aluno, ambiente EAD e sistema financeiro. Uma consultoria pode oferecer SSO para vários clientes usando realms separados. Cada caso muda o volume de sessões, a quantidade de clientes configurados e o risco operacional.

VPS tradicional, Cloud Server e instância cloud

VPS tradicional costuma ser uma máquina virtual em um host físico com recursos definidos. Cloud Server e instâncias cloud geralmente oferecem provisionamento mais flexível, rede privada, snapshots, resize e integração com balanceadores, dependendo do provedor. Para Keycloak, o nome comercial importa menos do que quatro itens verificáveis: recursos estáveis, disco confiável, rede previsível e recuperação rápida. Provedores como DigitalOcean, Vultr, Linode, AWS Lightsail, Hetzner, Contabo e LetsCloud podem entrar no estudo, mas preço, localidade, tipo de disco, backup e bandwidth precisam ser confirmados nas páginas oficiais na data de publicação.

Dimensionamento de CPU, RAM, disco e rede

O dimensionamento de Keycloak deve considerar picos, não apenas média diária. Login acontece em rajadas: começo do expediente, troca de turno, campanha de marketing, abertura de aula online ou deploy de uma aplicação que força renovação de sessão. Uma VPS com 2 vCPUs e 4 GB de RAM é um ponto de partida prudente para produção pequena, com poucos realms, até algumas centenas de usuários ativos por dia e integrações bem comportadas. Abaixo disso, o sistema até sobe, mas sobra pouca margem para JVM, sistema operacional, proxy reverso, agente de monitoramento e conexões com o banco.

Para produção intermediária, 4 vCPUs, 8 GB de RAM e 80 GB de SSD criam uma folga melhor. Esse perfil atende times internos, SaaS em estágio inicial e ambientes com MFA, login social ou federação LDAP leve. Se o PostgreSQL estiver no mesmo servidor, a RAM precisa ser dividida com cuidado. Por exemplo, em uma VPS de 8 GB, reservar algo como 3 a 4 GB para heap do Keycloak, 1 a 2 GB para PostgreSQL e o restante para sistema, cache de disco e processos auxiliares evita swap em operação normal. Swap pode existir como rede de segurança, mas não deve virar extensão permanente da memória.

Configuração mínima realista

Para um ambiente pequeno, use 2 vCPUs, 4 GB de RAM, 40 GB de SSD, Ubuntu LTS ou Debian estável, Docker Compose ou instalação via systemd, Nginx ou Caddy como proxy e PostgreSQL 15 ou superior. Em disco, 40 GB bastam para começar se logs forem rotacionados e backups forem enviados para fora do servidor. Com uploads de temas, exportações de realm e retenção longa de logs, 80 GB dá mais conforto. NVMe ajuda em latência de I/O, mas não compensa banco mal configurado, backup ausente ou memória insuficiente.

Como estimar sessões, tokens e picos de login

Uma regra prática é separar usuários cadastrados de usuários ativos. Dez mil usuários no diretório não significam dez mil logins simultâneos. Se uma empresa tem 800 funcionários e 300 fazem login entre 8h e 9h, o pico é essa janela. Se um SaaS tem 20 mil contas, mas apenas 500 usuários ativos por hora, a carga muda bastante. Monitore tempo de resposta do endpoint de token, consumo de heap, GC da JVM, conexões do PostgreSQL e erros 5xx. Quando a autenticação passa de 100 a 200 logins por minuto, já vale testar carga com ferramenta adequada antes de escolher o próximo plano.

PostgreSQL, persistência e backups sem improviso

Keycloak precisa de um banco relacional persistente em produção. PostgreSQL é uma escolha comum e bem suportada, mas precisa ser tratado como parte crítica da autenticação. Nele ficam realms, usuários locais, credenciais, clientes, roles, configurações de federação, eventos, sessões persistentes quando aplicável e histórico operacional conforme a configuração. Perder esse banco pode significar perder o estado de identidade do ambiente. Por isso, rodar Keycloak com configuração de desenvolvimento ou banco local descartável é aceitável em laboratório, não em produção.

A primeira decisão é manter PostgreSQL na mesma VPS ou separar em outra instância. No mesmo servidor, a operação fica mais barata e simples: menos rede, menos firewall entre componentes, menos máquinas para atualizar. Funciona para dev solo, MVP e ambientes pequenos. O custo aparece quando Keycloak e PostgreSQL competem por CPU, RAM e disco. Em uma VPS de 4 GB, por exemplo, um pico de autenticação pode pressionar a JVM enquanto o banco precisa responder consultas de sessão e atualização de eventos. Em uma VPS de 8 GB, dá para ajustar melhor, mas ainda há um ponto único de falha.

Banco no mesmo servidor ou separado

Separar PostgreSQL em uma VPS própria, instância gerenciada ou serviço cloud melhora isolamento e facilita upgrade do Keycloak sem mexer no banco. Também permite políticas de backup e retenção mais maduras. Para planejar essa camada, o artigo sobre VPS para banco PostgreSQL aprofunda CPU, RAM, disco, conexões e práticas de operação para bancos em produção. Para Keycloak, uma configuração intermediária seria 2 vCPUs e 4 GB de RAM para o banco, com SSD confiável, backups diários e acesso liberado apenas pela rede privada ou IPs específicos.

Backups testados e restauração

Backup não é um arquivo gerado por cron. Backup é a capacidade de restaurar. Uma rotina mínima inclui dump lógico com pg_dump, retenção de 7 a 14 dias, cópia fora da VPS, criptografia do arquivo e teste mensal de restauração em outro ambiente. Em cargas maiores, avalie backup físico, WAL archiving e réplica. Também exporte realms antes de mudanças grandes, como alteração de fluxo de login, configuração de LDAP ou migração de versão. O export não substitui o backup do PostgreSQL, mas ajuda em recuperação seletiva e auditoria de configuração.

HTTPS, proxy reverso e hardening do servidor

Keycloak deve operar atrás de HTTPS em produção. O login trafega credenciais, cookies, tokens e redirecionamentos sensíveis. Uma arquitetura comum usa Nginx, Caddy ou Traefik na porta 443, certificado TLS emitido por ACME e Keycloak escutando em uma porta interna, como 8080. O proxy precisa encaminhar headers corretamente para que o Keycloak saiba o host público, o esquema HTTPS e o IP do cliente. Erros nessa camada geram sintomas chatos: redirect loop, URL de issuer incorreta, cookies inseguros, falha em callback OIDC e problemas com console administrativo.

Uma configuração prática começa com DNS apontando auth.exemplo.com para a VPS, firewall liberando apenas 80, 443 e SSH restrito, proxy com renovação automática de certificado e Keycloak configurado com hostname público. Se estiver em container, evite expor a porta 8080 para a internet. Publique apenas o proxy. Em ambientes com Docker Compose, coloque Keycloak e PostgreSQL em uma rede interna, exponha somente Nginx ou Caddy e mantenha volumes persistentes para banco e logs. Secrets, senhas de admin, credenciais SMTP e chaves de integração devem ficar em variáveis de ambiente seguras ou cofre, nunca em repositório público.

TLS na borda

O TLS pode terminar no proxy reverso ou em um load balancer externo. Para uma única VPS, Nginx ou Caddy simplificam bastante. Caddy automatiza certificados por padrão, enquanto Nginx costuma ser usado com Certbot. Em ambos os casos, configure redirecionamento HTTP para HTTPS, HSTS após validar tudo, limites básicos de tamanho de requisição e timeouts compatíveis com o fluxo de autenticação. Um timeout agressivo demais pode quebrar login federado lento. Um timeout frouxo demais facilita conexões penduradas.

Firewall, SSH e variáveis sensíveis

Hardening precisa entrar antes do primeiro usuário real. Use SSH por chave, desative login root direto quando possível, mantenha pacotes atualizados, aplique fail2ban ou proteção equivalente, restrinja portas e registre logs de autenticação. O guia de VPS com firewall e hardening de segurança detalha medidas que combinam bem com Keycloak, especialmente regras de entrada, acesso administrativo e redução de superfície exposta. No painel do Keycloak, proteja a conta admin com MFA, crie usuários administrativos nominais e evite compartilhar credenciais entre equipe.

Alta disponibilidade e failover para Keycloak

Alta disponibilidade em Keycloak só faz sentido quando o básico já está estável. Subir duas instâncias sem banco resiliente, sem balanceador configurado e sem teste de failover pode criar uma falsa sensação de segurança. O desenho mínimo envolve pelo menos duas instâncias de Keycloak, um balanceador na frente, PostgreSQL com estratégia de alta disponibilidade ou serviço gerenciado, rede privada entre componentes e monitoramento que retire nós problemáticos do tráfego. Em ambientes menores, talvez seja melhor ter uma única VPS bem configurada, backup testado e restauração rápida do que um cluster improvisado.

Em cluster, o balanceador precisa preservar comportamento correto para OIDC e SAML. Keycloak moderno usa cache distribuído e comunicação entre nós, então versões, configuração de hostname, proxy headers e rede interna precisam estar alinhados. Se uma instância responde com issuer diferente da outra, clientes podem rejeitar tokens. Se o proxy não informa o esquema HTTPS, callbacks podem quebrar. Se o banco vira gargalo, adicionar nós de aplicação não resolve. A arquitetura precisa ser testada com login, refresh token, logout, troca de senha, MFA e falha forçada de um nó.

Cluster, balanceador e sessões

Um exemplo intermediário usa duas VPS de aplicação com 2 vCPUs e 4 GB de RAM cada, um balanceador cloud ou Nginx dedicado, PostgreSQL separado e backups fora do ambiente. Para produção mais crítica, suba para 4 vCPUs e 8 GB por nó, use banco gerenciado ou cluster PostgreSQL com réplica e defina health checks reais. Health check que só verifica porta aberta é fraco. Prefira endpoint que confirme que a aplicação responde e que o nó não está travado em inicialização.

O que não colocar em HA cedo demais

Não tente tornar tudo distribuído no primeiro dia. Comece medindo. Se o ambiente tem 50 usuários internos e duas aplicações, uma VPS bem operada pode ser suficiente. Se o Keycloak atende clientes externos, contratos com SLA ou login de várias unidades de negócio, a conversa muda. O conteúdo sobre VPS para alta disponibilidade e failover ajuda a separar redundância útil de complexidade cara. O melhor teste é simples: desligue uma instância em horário controlado e veja se usuários continuam autenticando sem erro visível.

Tabela comparativa de perfis de hospedagem

A tabela abaixo organiza perfis práticos. Ela não é uma comparação de preço entre provedores, porque valores, promoções, regiões, bandwidth, snapshots e tipo de disco mudam com frequência e precisam de revisão humana antes de publicação. O objetivo é ajudar a escolher tamanho e arquitetura. Para provedores, confirme páginas oficiais de DigitalOcean, Vultr, Linode ou Akamai, AWS Lightsail, Hetzner, Contabo e LetsCloud. No caso da LetsCloud, recursos como localidade, NVMe, snapshots, backup e suporte devem ser validados por plano e região antes de qualquer afirmação específica.

Perfil	Recursos sugeridos	Banco de dados	Uso típico	Risco principal	Próximo upgrade
Laboratório ou homologação	1 a 2 vCPUs, 2 a 4 GB RAM, 30 GB SSD	PostgreSQL local ou container isolado	Testes de realm, tema, OIDC e integração interna	Configuração virar produção sem hardening	Separar banco e subir para 4 GB RAM
Produção pequena	2 vCPUs, 4 GB RAM, 40 a 80 GB SSD	PostgreSQL local com backup externo	Até algumas centenas de usuários ativos por dia	Ponto único de falha e disputa por RAM	Banco separado e 8 GB RAM
Produção intermediária	4 vCPUs, 8 GB RAM, 80 GB SSD ou NVMe	PostgreSQL separado, 2 vCPUs e 4 GB RAM	SaaS inicial, times internos, MFA e login social	Banco ou proxy virar gargalo	Balanceador e segundo nó Keycloak
Produção crítica	2 ou mais nós, 4 vCPUs e 8 GB RAM por nó	Banco gerenciado ou HA com backups e réplica	SSO corporativo, clientes externos, SLA interno	Cluster mal testado e failover incompleto	Testes de carga e automação de recovery

Essa tabela também mostra por que a pergunta certa não é apenas quanto custa uma VPS. Keycloak depende de memória previsível, latência baixa entre aplicação e banco, disco confiável e operação segura. Um plano barato com CPU compartilhada agressiva pode funcionar em teste e sofrer em pico de login. Um plano maior, mas sem backup e sem firewall, continua frágil. O equilíbrio muda conforme o impacto de uma indisponibilidade: se dez pessoas ficam sem acessar um painel interno, o risco é administrável. Se milhares de clientes não conseguem entrar no produto, a arquitetura precisa de redundância e processo.

Operação diária, monitoramento e troubleshooting

Depois que o Keycloak entra em produção, a rotina operacional pesa tanto quanto o dimensionamento inicial. Comece com logs centralizados ou, no mínimo, rotação de logs local com retenção definida. Acompanhe CPU, memória livre, uso de swap, disco, I/O, conexões do PostgreSQL, latência do endpoint de token e erros HTTP 4xx e 5xx. Monitore também certificados TLS e validade do domínio. Um certificado expirado derruba login de forma tão efetiva quanto uma falha de servidor. Para alertas, um conjunto simples já ajuda: uso de disco acima de 80%, swap recorrente, erro 5xx por mais de 2 minutos, latência de token acima do normal e falha no health check.

Atualizações exigem cautela. Keycloak evolui rápido e mudanças de versão podem alterar comportamento de configuração, imagens de container, temas, extensões e providers customizados. Antes de atualizar produção, clone o ambiente, restaure uma cópia recente do banco, suba a nova versão e teste login, logout, refresh token, reset de senha, MFA, federação LDAP, login social e clientes SAML se existirem. Também valide temas customizados, porque um detalhe visual quebrado na tela de login pode parecer menor, mas bloqueia usuários quando envolve campos ou scripts.

Métricas que merecem alerta

Em uma VPS de 4 GB, swap usado de forma contínua é sinal de alerta. Ajuste heap, reduza processos no servidor ou aumente RAM. CPU em 100% por segundos durante pico pode ser normal, mas CPU saturada por minutos tende a afetar login. No PostgreSQL, conexões no limite, queries lentas e crescimento rápido de eventos indicam necessidade de ajuste. Se eventos de login forem retidos por muito tempo, o banco cresce e consultas administrativas ficam lentas. Defina retenção compatível com auditoria, não infinita por descuido.

Problemas comuns em produção

Redirect loop quase sempre aponta para hostname, proxy headers ou HTTPS mal configurado. Erro de invalid redirect uri costuma ser configuração de client, não falha da VPS. Login lento pode vir de LDAP externo, SMTP, banco pressionado ou falta de CPU. Falhas intermitentes em cluster sugerem balanceador, cache ou divergência entre nós. Um bom procedimento é registrar o horário do erro, usuário afetado, client usado, endpoint, código HTTP e estado de recursos do servidor naquele minuto. Sem esses dados, troubleshooting vira tentativa e erro.

Recomendações por perfil

Dev solo ou laboratório sério

Se você está validando Keycloak para um produto próprio, comece simples, mas não descuidado. Uma VPS com 2 vCPUs, 4 GB de RAM e 40 GB de SSD permite testar realms, clientes OIDC, temas, SMTP e login social com folga razoável. Use Docker Compose ou systemd, PostgreSQL persistente e proxy HTTPS desde o início. Mesmo em laboratório, evite banco em memória, senha admin fraca e porta 8080 aberta para a internet. Esse ambiente pode virar homologação e poupar retrabalho quando o projeto crescer.

Time pequeno com clientes reais

Para uma equipe que já atende usuários externos, o melhor ponto de partida é 4 vCPUs, 8 GB de RAM e PostgreSQL separado ou, no mínimo, muito bem configurado. Tenha backup diário fora da VPS, teste restauração mensal, monitore latência de login e documente como recriar o servidor. Se houver integrações com API, app mobile e painel web, padronize clients, redirect URIs e rotação de secrets. Também defina janela de manutenção para upgrades. Keycloak não deve ser atualizado no improviso em uma tarde de pico.

Produção crítica com SSO corporativo

Quando Keycloak autentica várias aplicações críticas, clientes pagantes ou operação interna de grande porte, trate-o como infraestrutura de identidade. Use pelo menos dois nós de aplicação, balanceador, PostgreSQL resiliente, backups com retenção adequada, monitoramento com alertas e plano de recuperação documentado. Teste failover de verdade, desligando nó, simulando falha de banco e validando login durante a troca. Antes de contratar planos maiores, faça teste de carga com cenário realista: login, refresh token, logout, MFA e chamadas simultâneas ao endpoint de token. O objetivo não é ter uma arquitetura bonita, é manter autenticação funcionando quando algo falha.