Qual é a configuração mínima de VPS para Ruby on Rails em produção?

Para produção real, o ponto de partida mais seguro é 2 vCPUs, 4 GB de RAM e 60 GB de SSD. Dá para subir Rails em 1 GB ou 2 GB, mas a margem fica pequena quando Puma, PostgreSQL, Redis e Sidekiq rodam juntos. Em aplicações simples, use 1 ou 2 workers do Puma, poucas threads e Sidekiq com concorrência baixa. Se houver uploads, relatórios, webhooks ou muitos jobs, considere 4 vCPUs e 8 GB antes que swap e I/O virem gargalos.

Posso rodar PostgreSQL no mesmo servidor da aplicação Rails?

Sim, especialmente em MVPs, sistemas internos e SaaS no começo da operação. O cuidado é reservar memória para PostgreSQL, limitar workers e manter backups fora da VPS. Quando relatórios, importações, crescimento de dados ou consultas lentas começam a afetar o tempo de resposta, separar banco e aplicação passa a ser uma decisão saudável. A separação também facilita manutenção, restore e upgrades. Para produção crítica, PostgreSQL isolado costuma reduzir risco operacional.

Redis é obrigatório para Ruby on Rails?

Redis não é obrigatório em toda aplicação Rails, mas aparece com frequência em produção. Ele pode ser usado para cache, Action Cable, Sidekiq, rate limiting e armazenamento temporário. Se a aplicação usa Sidekiq, Redis entra como dependência central. Em VPS pequena, configure limite de memória e política de eviction para evitar que Redis cresça sem controle. Se jobs não são críticos, Solid Queue pode ser alternativa em algumas versões, mas a decisão depende da arquitetura e do volume de tarefas.

Nginx é melhor que Caddy ou Traefik para Rails?

Nginx é a opção mais comum para Rails porque é estável, bem documentado e funciona muito bem como reverse proxy para Puma. Caddy simplifica TLS automático e pode ser excelente para times menores que querem configuração mais curta. Traefik faz mais sentido em ambientes com Docker, múltiplos serviços e roteamento dinâmico. A melhor escolha depende da operação. Para uma aplicação Rails clássica em VPS, Nginx continua sendo uma escolha previsível e fácil de auditar.

Datacenter no Brasil sempre melhora uma aplicação Rails?

Datacenter no Brasil pode melhorar a latência para usuários brasileiros, principalmente em sistemas interativos, painéis, APIs internas e aplicações usadas muitas vezes ao dia. Ainda assim, ele não resolve gargalos de banco, falta de cache, assets pesados ou jobs mal configurados. Uma região fora do Brasil com boa rota e CDN pode funcionar bem para alguns casos. O ideal é medir latência a partir das redes dos usuários, observar tempo de resposta no Rails e comparar antes de migrar.

Quando devo separar Sidekiq, PostgreSQL e Redis em servidores diferentes?

Separe quando os componentes começam a competir por recursos ou quando o risco operacional aumenta. Sinais comuns incluem swap frequente, filas crescendo, CPU alta durante relatórios, banco lento em horários de importação e dificuldade para restaurar backups sem parar tudo. Um passo intermediário é manter Rails e Sidekiq juntos, mas mover PostgreSQL para outra VPS. Em ambientes mais críticos, Redis também pode ficar separado. A decisão deve considerar tráfego, volume de dados, receita impactada e capacidade do time de operar mais servidores.

Rails em produção: VPS para Ruby on Rails no Brasil

Resposta direta

Para hospedar Ruby on Rails em produção, uma VPS no Brasil costuma começar bem com 2 vCPUs, 4 GB de RAM, 60 GB de SSD ou NVMe, Ubuntu LTS, Nginx como reverse proxy, Puma como servidor de aplicação, PostgreSQL e Redis bem configurados. Projetos pequenos podem rodar banco, aplicação e filas no mesmo servidor, desde que haja swap controlado, backup externo e monitoramento. Para SaaS, e-commerce, APIs com muitos jobs ou aplicações com tráfego nacional constante, o caminho mais seguro é separar PostgreSQL e Redis, usar pelo menos 4 vCPUs e 8 GB de RAM, automatizar deploys e manter snapshots ou backups testados. A localização no Brasil ajuda na latência para usuários locais, mas não substitui bom dimensionamento, índices no banco, cache e configuração correta de workers.

Resumo rápido

Uma VPS para Ruby on Rails no Brasil deve ser dimensionada olhando Puma, PostgreSQL, Redis, jobs em background e volume de acessos, não só visitas mensais.
Para produção básica, considere 2 vCPUs, 4 GB de RAM e 60 GB de SSD como ponto de partida mais confortável que planos de 1 GB.
PostgreSQL no mesmo servidor funciona em MVPs e aplicações pequenas, mas exige memória reservada, backup externo e índices bem cuidados.
Redis é útil para cache, Action Cable e Sidekiq, mas precisa de limite de memória e política de persistência alinhada ao risco do projeto.
Nginx continua sendo a escolha mais comum como reverse proxy para Puma, com TLS via Let’s Encrypt e compressão configurada.
Datacenter no Brasil pode reduzir latência percebida, principalmente em painéis administrativos, APIs e sistemas usados diariamente.
Comparações de provedores devem ser revisadas antes da publicação, pois regiões, storage, banda e recursos mudam com frequência.

O que muda ao rodar Ruby on Rails em uma VPS no Brasil

Ruby on Rails é uma stack muito produtiva, mas em produção ela cobra disciplina de infraestrutura. Em ambiente local, o desenvolvedor roda rails server, usa SQLite ou PostgreSQL em Docker, reinicia tudo sem impacto e raramente pensa em logs crescendo por semanas. Em uma VPS, a aplicação precisa responder 24 horas por dia, manter conexões com banco, processar filas, servir assets compilados, renovar SSL e reiniciar de forma previsível depois de uma atualização do sistema.

O primeiro ponto é entender que Rails não é apenas um processo web. Uma aplicação real costuma ter Puma para requisições HTTP, PostgreSQL como banco principal, Redis para cache ou filas, Sidekiq ou Solid Queue para tarefas em background, Active Storage para uploads e algum serviço de envio de e-mail. Mesmo um sistema simples de agendamento pode ter jobs para notificações, relatórios em PDF, webhooks e limpeza de registros antigos. Cada peça consome CPU, memória, disco e conexões.

Rails é produtivo, mas sensível ao ambiente

Rails usa bastante memória por processo, especialmente em aplicações com muitas gems, painel administrativo, Active Storage e bibliotecas de geração de documentos. Um processo Puma com app carregada pode consumir de 250 MB a 600 MB em projetos pequenos e médios. Se você usa 2 workers, 5 threads por worker e ainda roda Sidekiq com concorrência 5, um plano com 1 GB de RAM fica apertado rapidamente. O servidor pode até subir, mas vai começar a usar swap em horários de pico, criando respostas lentas e erros intermitentes.

VPS tradicional, Cloud Server e cloud instance

Também vale separar os nomes. VPS tradicional costuma ser uma máquina virtual dentro de um host físico com recursos definidos. Cloud Server ou cloud instance normalmente trazem provisionamento mais flexível, API, imagens prontas, redes privadas, snapshots e upgrades com menos atrito, dependendo do provedor. Para Rails, os dois modelos podem funcionar. O que muda é a operação. Se o projeto precisa escalar rápido, clonar ambiente de staging, recriar servidor via script e crescer disco ou CPU com menos janela de manutenção, Cloud Server tende a simplificar a rotina. Se o objetivo é hospedar um sistema interno pequeno, uma VPS bem configurada pode entregar ótimo custo operacional.

Como dimensionar CPU, RAM e disco para Rails

O dimensionamento de uma VPS para Ruby on Rails no Brasil começa pela pergunta certa: quantos processos vão rodar ao mesmo tempo? Não adianta contratar um plano olhando apenas tráfego estimado se a aplicação executa relatórios pesados, importa planilhas, processa imagens e mantém conexões WebSocket. Em Rails, CPU e RAM são afetadas pelo número de workers do Puma, quantidade de threads, tamanho do pool do Active Record, concorrência do Sidekiq, cache em memória, banco local e tarefas agendadas.

Para uma aplicação institucional com login, painel administrativo e até alguns milhares de acessos por dia, 2 vCPUs e 4 GB de RAM costumam ser uma base mais saudável que 1 vCPU e 1 GB. Um exemplo prático: 2 workers do Puma, 3 threads por worker, PostgreSQL local, Redis com limite de 256 MB e Sidekiq com concorrência 3. Essa combinação pode caber em 4 GB se a aplicação não tiver gems muito pesadas e se o banco estiver bem indexado. Em 2 GB, o mesmo desenho funciona apenas com ajustes mais conservadores, como 1 worker do Puma e Sidekiq com concorrência 2.

Puma, threads e workers

Puma trabalha com threads e, quando configurado em cluster, com múltiplos workers. Cada worker carrega a aplicação Rails na memória. Threads ajudam a lidar com I/O, mas não multiplicam CPU magicamente. Em uma VPS com 2 vCPUs, uma configuração inicial razoável seria WEB_CONCURRENCY=2, RAILS_MAX_THREADS=3 e DB_POOL=6 ou DB_POOL=8, sempre alinhando o pool do banco com a soma de threads e processos que realmente fazem consultas. Se o pool ficar menor que a demanda, usuários aguardam conexão. Se ficar grande demais, PostgreSQL consome memória sem necessidade.

Disco para uploads, logs e assets

Disco também merece atenção. Rails escreve logs, armazena assets compilados, pode salvar uploads locais e precisa de espaço para dumps de backup temporários. Em produção, 40 GB é o mínimo apenas para aplicações pequenas. Um ponto de partida mais confortável é 60 GB a 80 GB em SSD. NVMe ajuda em workloads com alto I/O, como banco local com muitas leituras e escritas, mas não corrige query ruim, falta de índice ou cache mal usado. Se a aplicação recebe anexos, imagens de usuários ou documentos fiscais, prefira armazenar arquivos em object storage e manter a VPS focada em aplicação, banco e jobs.

PostgreSQL, Redis e background jobs no mesmo servidor

Rails em produção quase sempre conversa com PostgreSQL. O banco é excelente para a maioria dos produtos web, mas pode se tornar o gargalo mais caro de corrigir quando roda sem planejamento na mesma VPS da aplicação. Uma consulta sem índice, um relatório que varre milhões de linhas ou uma importação grande pode consumir CPU, memória e I/O a ponto de derrubar o tempo de resposta do Puma. Por isso, antes de colocar tudo no mesmo servidor, olhe tamanho do banco, taxa de escrita, uso de relatórios, jobs programados e necessidade de restauração rápida.

Em projetos pequenos, banco e aplicação no mesmo servidor reduzem complexidade e custo. Um SaaS em fase inicial, com menos de 10 mil registros principais e tráfego previsível, pode começar com PostgreSQL local, desde que backups externos sejam automatizados. Nessa etapa, a configuração prática inclui shared_buffers entre 512 MB e 1 GB em uma VPS de 4 GB, work_mem conservador, autovacuum ativo e monitoramento de queries lentas. Se você está aprofundando o desenho do banco, o guia sobre VPS para banco PostgreSQL ajuda a pensar em I/O, conexões e estratégia de backup.

Quando separar banco e aplicação

A separação começa a fazer sentido quando o banco passa a competir com a aplicação. Sinais comuns: CPU alta durante relatórios, aumento de latência em horários de importação, uso frequente de swap, muitos locks, crescimento rápido do volume de dados e necessidade de restaurar backup sem parar o app inteiro. Uma arquitetura intermediária usa uma VPS para Rails e Sidekiq, outra para PostgreSQL e uma rede privada entre elas, quando o provedor oferece esse recurso. Assim, um pico de web requests não disputa disco diretamente com escrita do banco.

Sidekiq, Solid Queue e filas em produção

Background jobs são parte central de muitas aplicações Rails. Sidekiq usa Redis, enquanto Solid Queue pode usar banco relacional, dependendo da versão e da escolha do time. Sidekiq é muito usado para e-mails, webhooks, geração de PDFs, integrações com ERPs e importações. O erro comum é deixar concorrência alta em servidor pequeno. Em uma VPS com 4 GB, sidekiq -c 3 ou -c 5 pode ser suficiente. Em 8 GB, dá para testar concorrência 8 ou 10, desde que PostgreSQL e APIs externas suportem. Redis, por sua vez, precisa de limite de memória, persistência adequada e política de eviction clara. O artigo sobre VPS para Redis e cache entra nos detalhes de memória, latência e persistência.

Deploy com Nginx, reverse proxy e SSL sem improviso

O deploy de Ruby on Rails em VPS costuma seguir um desenho simples e robusto: Nginx recebe as conexões HTTP e HTTPS, encaminha para Puma via socket Unix ou porta local, serve assets estáticos quando configurado e aplica compressão, limites e headers. Puma roda como serviço systemd, com variáveis de ambiente em arquivo protegido. O código é publicado por GitHub Actions, GitLab CI, Capistrano, Kamal ou um script controlado. O ponto não é usar a ferramenta mais moderna, mas evitar deploy manual cheio de comandos soltos.

Um fluxo básico começa com um usuário Linux sem root direto, diretório da aplicação em /var/www/app, Ruby instalado por asdf, rbenv ou pacote, PostgreSQL protegido por senha forte e firewall permitindo apenas 22, 80 e 443. Depois vêm bundle install, rails assets:precompile, rails db:migrate e restart do serviço Puma. O Nginx aponta para algo como unix:/var/www/app/shared/tmp/sockets/puma.sock. Essa configuração reduz exposição, evita abrir a porta do Puma para a internet e simplifica logs.

Fluxo típico com Puma e systemd

Um serviço systemd de Puma deve reiniciar automaticamente em falhas, carregar variáveis como RAILS_ENV=production, apontar para o diretório correto e rodar com usuário dedicado. Uma configuração prática define Restart=always, WorkingDirectory=/var/www/app/current e ExecStart chamando bundle exec puma -C config/puma.rb. Em deploys com Capistrano, o symlink current muda a cada release, o que facilita rollback. Em deploys com Kamal, containers entram na conversa, mas a lógica continua parecida: reverse proxy na frente, aplicação isolada e logs observáveis.

Caddy e Traefik também entram no jogo

Nginx não é a única opção. Caddy simplifica TLS automático e configuração enxuta, o que ajuda times menores. Traefik é forte quando há Docker, múltiplos serviços e roteamento dinâmico. Para entender quando cada proxy faz sentido, o conteúdo sobre VPS para reverse proxy com Nginx, Caddy e Traefik compara cenários com mais profundidade. Em Rails clássico, Nginx ainda é previsível, documentado e fácil de auditar. Em ambientes com vários apps no mesmo servidor, Caddy pode reduzir atrito. Em stacks containerizadas, Traefik costuma encaixar melhor.

Latência, provedores e tabela de perfis de VPS

A escolha de uma VPS para Ruby on Rails no Brasil não deve começar por preço, mas por localização, previsibilidade e operação. Uma aplicação usada por clientes brasileiros em horário comercial sente diferença entre datacenter nacional e servidor distante, especialmente em telas com muitas requisições, dashboards, uploads e APIs chamadas por sistemas internos. Em conexões reais, a latência dentro do Brasil pode ficar na casa de poucos milissegundos a algumas dezenas de milissegundos, enquanto tráfego para regiões nos Estados Unidos frequentemente passa de 100 ms, dependendo da rota, operadora e cidade do usuário.

Isso não significa que todo Rails precisa obrigatoriamente ficar em datacenter brasileiro. Se o sistema usa CDN, tem público internacional ou depende de serviços hospedados fora do país, uma região em Miami, Virgínia ou São Paulo pode ter equilíbrio diferente. O ponto é medir. Use ping, mtr, logs de tempo de resposta, métricas do Rails e testes a partir de redes brasileiras. A latência do datacenter é apenas uma parte da experiência. Query lenta de 800 ms no PostgreSQL pesa mais que economizar 30 ms de rede.

Por que a localização pesa para o público brasileiro

Painéis administrativos, CRMs, ERPs web, marketplaces B2B e sistemas de atendimento têm interação constante. O usuário clica, filtra, salva, anexa arquivo e espera resposta imediata. Nesses casos, latência menor melhora a sensação de fluidez. APIs internas também se beneficiam quando clientes, parceiros e integrações estão no Brasil. Já blogs com cache agressivo, landing pages e aplicações muito estáticas podem compensar distância com CDN e edge cache.

Comparação prática por cenário

A tabela abaixo não publica preço e não substitui validação humana de planos. Ela serve para orientar perfis técnicos. Regiões, armazenamento, banda e recursos de backup mudam com frequência e precisam ser conferidos nas páginas oficiais antes de qualquer comparação comercial.

Cenário de Rails	Recursos sugeridos	Banco e cache	Deploy recomendado	Observações operacionais
MVP ou sistema interno pequeno	2 vCPUs, 4 GB RAM, 60 GB SSD	PostgreSQL e Redis locais, Redis limitado a 256 MB	Nginx + Puma + systemd	Backup externo diário, Sidekiq com concorrência 2 ou 3
SaaS inicial com jobs frequentes	4 vCPUs, 8 GB RAM, 80 a 120 GB SSD ou NVMe	PostgreSQL local otimizado ou separado, Redis local	Nginx ou Caddy, deploy via CI ou Capistrano	Monitorar pool do banco, jobs lentos e uso de swap
Produção com tráfego nacional constante	4 a 8 vCPUs, 16 GB RAM, disco rápido e backup testado	PostgreSQL separado, Redis separado ou gerenciado	Reverse proxy dedicado, staging e rollback	Rede privada quando disponível, restauração testada e alertas
Multiapp ou stack com Docker	4 vCPUs, 8 GB RAM como base	Banco preferencialmente separado	Traefik ou Caddy, containers versionados	Cuidado com logs, volumes persistentes e limites de memória

Entre provedores conhecidos, DigitalOcean, Vultr, Linode/Akamai, AWS Lightsail, Google Cloud, Azure, Hostinger, Locaweb e LetsCloud aparecem com propostas diferentes de simplicidade, região, painel e recursos. LetsCloud pode fazer sentido quando o projeto busca contexto brasileiro, possíveis localidades próximas ao público e pagamento local, mas detalhes como NVMe, snapshots, backups e regiões disponíveis devem ser verificados por plano e localidade antes da publicação.

Segurança, backups e observabilidade para não operar no escuro

Uma VPS Rails em produção precisa ser tratada como ambiente crítico desde o primeiro deploy. Segurança básica não é instalar um firewall e esquecer. Começa pelo acesso SSH com chave, login root desabilitado, usuário com sudo, atualizações automáticas de segurança, fail2ban ou mecanismo equivalente, portas mínimas expostas e secrets fora do repositório. Em Rails, RAILS_MASTER_KEY, credenciais de banco, tokens de APIs e chaves de serviços externos devem ficar em variáveis de ambiente ou arquivos protegidos, nunca no Git.

O firewall pode permitir 22, 80 e 443, mas o ideal é restringir SSH por IP quando a rotina do time permite. PostgreSQL e Redis não devem ficar públicos na internet. Se estiverem no mesmo servidor, escute em 127.0.0.1. Se estiverem em outra máquina, use rede privada, regras de firewall específicas e autenticação. Redis sem senha e exposto é um risco grave. PostgreSQL aberto para qualquer origem aumenta muito a superfície de ataque.

Hardening básico de uma VPS Rails

Um checklist inicial inclui Ubuntu LTS atualizado, usuário deploy, chaves SSH, ufw allow 80, ufw allow 443, SSH controlado, Nginx com TLS forte, headers básicos e logs rotacionados. Também faz sentido limitar tamanho de upload no Nginx, como client_max_body_size 20M, para evitar que um endpoint mal usado consuma disco e memória. Em Rails, configure config.force_ssl = true, revise cookies seguros, proteja Active Storage e valide permissões de diretórios compartilhados.

Logs, métricas e rotina de restauração

Backups precisam ser restauráveis, não apenas existentes. Um dump diário do PostgreSQL enviado para storage externo é o mínimo para projetos pequenos. Para produção mais séria, combine dump lógico, snapshot do volume ou backup do provedor, retenção de 7 a 30 dias e teste mensal de restore em staging. Logs também precisam de rotação. Um arquivo production.log sem controle pode ocupar dezenas de gigabytes com o tempo.

Observabilidade fecha o ciclo. Monitore CPU, memória, swap, disco, tempo de resposta, erros 5xx, jobs mortos, tamanho das filas e queries lentas. Ferramentas como Prometheus, Grafana, Netdata, Uptime Kuma, Sentry e APMs comerciais podem ajudar. Mesmo um setup simples com alertas de disco acima de 80%, swap constante e fila Sidekiq crescendo por mais de 10 minutos evita incidentes caros. Rails dá bons sinais, mas alguém precisa coletar e olhar esses sinais antes que o cliente reclame.

Recomendações por perfil

Dev solo ou freelancer

Para um dev solo hospedando um sistema de cliente, portal administrativo ou MVP validando mercado, a melhor estratégia é reduzir complexidade sem cair no improviso. Comece com 2 vCPUs, 4 GB de RAM e 60 GB de SSD, rodando Rails, PostgreSQL e Redis no mesmo servidor. Use Nginx com Puma, backups diários externos e deploy automatizado por script, Capistrano ou CI simples. Configure Sidekiq com concorrência baixa, algo entre 2 e 3, e monitore swap. Esse perfil não precisa de arquitetura distribuída no primeiro dia, mas precisa de restauração testada, documentação básica e um plano claro para upgrade.

Time pequeno com produto em crescimento

Um time pequeno com SaaS em tração, integrações e jobs frequentes deve pensar em 4 vCPUs, 8 GB de RAM e disco de 80 GB a 120 GB. Ainda pode manter tudo na mesma VPS em fases iniciais, mas já deve preparar separação do PostgreSQL. Use staging, deploy com rollback, logs centralizados e alertas de filas. Sidekiq com concorrência 5 a 8 pode funcionar, desde que o pool do banco acompanhe e as APIs externas não sejam sobrecarregadas. Nesse perfil, a economia de uma VPS muito pequena costuma sair cara em horas de diagnóstico, lentidão percebida e deploys tensos.

Produção crítica ou SaaS com receita recorrente

Quando Rails sustenta receita recorrente, contratos com SLA interno ou operação diária de clientes, trate infraestrutura como produto. Use aplicação em uma VPS ou Cloud Server, PostgreSQL separado, Redis separado, backups com retenção, monitoramento ativo e processo de restore validado. Uma base comum começa em 4 a 8 vCPUs para aplicação, 16 GB de RAM no conjunto principal e disco rápido onde houver banco. Para público majoritariamente brasileiro, teste regiões nacionais ou próximas com dados reais de latência. Também considere rede privada, snapshots antes de deploys críticos, deploy blue-green quando fizer sentido e runbooks para incidentes. O objetivo não é montar arquitetura cara, é reduzir pontos únicos de falha que o negócio já não aceita.