5 decisões de VPS para Discourse no Brasil

Resposta direta

Para hospedar Discourse no Brasil em produção, escolha uma VPS ou Cloud Server com pelo menos 2 vCPUs, 4 GB de RAM, 50 GB de SSD, IPv4 público, bom throughput de rede, backup testado e suporte a Docker. Essa configuração atende comunidades pequenas e médias com alguns milhares de usuários cadastrados, desde que o email transacional seja feito por um serviço externo e o servidor não acumule outras aplicações pesadas. Fóruns com alto volume de acessos, muitas buscas, uploads frequentes e moderação ativa devem partir de 4 vCPUs, 8 GB de RAM e disco SSD ou NVMe com I/O consistente. O ponto crítico não é apenas instalar o Discourse, mas manter PostgreSQL, Redis, Sidekiq, web, email e backups funcionando de forma previsível.

Resumo rápido

Escolher uma VPS para Discourse no Brasil não é igual contratar um servidor genérico para site institucional. Discourse combina Ruby on Rails, PostgreSQL, Redis, jobs em background, uploads, busca interna, notificações por email e atualizações frequentes. Quando tudo roda no mesmo servidor, CPU, RAM e disco precisam ter margem. Um fórum até pode iniciar pequeno, mas costuma crescer de forma irregular: um tópico viral, uma campanha por email ou uma migração de comunidade antiga pode multiplicar acessos em poucas horas.

• Para produção básica, use 2 vCPUs, 4 GB de RAM e 50 GB de SSD como piso mais seguro.
• Para comunidades ativas, 4 vCPUs, 8 GB de RAM e 80 a 160 GB de disco reduzem risco de gargalo.
• PostgreSQL e Redis não devem disputar memória com outras aplicações no mesmo servidor.
• Email transacional deve sair por provedor externo, como Amazon SES, Mailgun, Postmark ou equivalente.
• Backups precisam ser exportados, restaurados e testados, não apenas gerados automaticamente.
• Datacenter no Brasil tende a reduzir latência para usuários brasileiros, mas disponibilidade, I/O e operação também pesam.
• LetsCloud, DigitalOcean, Vultr, Akamai, AWS Lightsail e outros provedores podem fazer sentido, dependendo de região, orçamento, painel e recursos confirmados no site oficial.

Um bom plano inicial não precisa ser exagerado. O erro comum é economizar demais na RAM e descobrir, durante a primeira atualização do Discourse, que o servidor entra em swap, o banco fica lento e os jobs de email se acumulam. A escolha deve considerar o tráfego esperado, o tamanho dos anexos, o número de plugins, a política de backup e o nível de tolerância a indisponibilidade.

Por que Discourse exige mais cuidado que um fórum simples

Discourse parece simples para o usuário final: tópicos, respostas, curtidas, categorias, notificações e busca. Por baixo, ele é uma aplicação moderna com várias partes trabalhando juntas. O stack oficial usa Ruby on Rails, PostgreSQL, Redis, Nginx, Sidekiq e Docker. Isso muda completamente a forma de dimensionar o servidor. Não é um PHP antigo rodando em hospedagem compartilhada com MySQL básico. É uma aplicação viva, com processos web, workers de fila, cache, banco relacional e tarefas agendadas.

Discourse é uma aplicação Ruby on Rails em produção

Quem já dimensionou uma aplicação Rails sabe que RAM importa bastante. O processo web precisa manter workers, gems, cache de aplicação e conexões com banco. Se você está comparando Discourse com uma aplicação própria, o guia de VPS para Ruby on Rails no Brasil ajuda a entender por que 1 GB de RAM raramente é confortável em produção. No Discourse, a situação fica mais sensível porque PostgreSQL e Redis normalmente rodam no mesmo host em instalações pequenas.

Um fórum novo com 200 usuários cadastrados, 20 acessos simultâneos e poucos uploads pode rodar em 2 vCPUs e 4 GB de RAM. Já uma comunidade técnica com 20 mil usuários, busca frequente e moderação pesada pode precisar de 4 vCPUs, 8 GB de RAM e disco mais rápido. O salto não acontece apenas pelo número de usuários cadastrados. A métrica que pesa é atividade real: páginas vistas por minuto, posts criados, notificações enviadas, anexos processados e consultas no banco.

O papel do Docker no modelo oficial

O Discourse recomenda instalação via Docker. Isso facilita atualização e padroniza dependências, mas não elimina o custo operacional. Durante rebuilds, upgrades e tarefas de manutenção, o servidor usa CPU e RAM de forma mais intensa. Em um plano apertado, uma atualização pode ser mais pesada que o tráfego normal do fórum. Por isso, a VPS deve ter margem para momentos de pico administrativo, não apenas para a média diária.

Na prática, pense no servidor como um ambiente de aplicação completo. Você precisa monitorar uso de memória, carga de CPU, I/O de disco, tamanho do banco, fila do Sidekiq e entregabilidade de email. Se esses pontos ficam invisíveis, o fórum pode até funcionar no primeiro mês, mas a manutenção vira tentativa e erro.

CPU, RAM e disco: como dimensionar sem adivinhar

A pergunta mais comum é direta: qual VPS roda Discourse? A resposta curta é 2 vCPUs e 4 GB de RAM para começar com segurança. A resposta útil é um pouco mais cuidadosa. Discourse usa CPU em renderização de páginas, processamento de markdown, compressão de assets, busca, tarefas de email, uploads e atualizações. Usa RAM para Ruby, PostgreSQL, Redis, cache, processos em background e sistema operacional. Usa disco para banco, uploads, logs, backups locais temporários e imagens do Docker.

Configuração mínima realista

Para uma comunidade pequena em produção, uma configuração de 2 vCPUs, 4 GB de RAM e 50 GB de SSD é um ponto de partida sensato. Abaixo disso, especialmente com 2 GB de RAM, o fórum pode até instalar, mas a margem fica curta. O Linux, o Docker, o PostgreSQL, o Redis e a aplicação competem pelo mesmo espaço. Quando a memória acaba, o servidor começa a usar swap. Swap em SSD salva o processo de cair, mas deixa a resposta lenta e aumenta o desgaste de I/O.

Um exemplo prático: uma comunidade com 1.500 usuários cadastrados, 80 usuários ativos por dia, 5 mil páginas vistas diárias e uploads moderados de imagens deve ficar bem em 2 vCPUs e 4 GB, desde que não rode Matomo, WordPress, banco externo de outra aplicação e painel pesado no mesmo host. Se o servidor também hospedar site institucional, API e banco compartilhado, a conta muda. Nesse caso, separar workloads evita que um pico no site derrube o fórum.

Quando subir para 4 vCPUs e 8 GB

Suba para 4 vCPUs e 8 GB de RAM quando a comunidade tiver busca intensa, muitos plugins, moderação ativa, importação de base antiga ou tráfego simultâneo acima de 100 usuários. Plugins são um ponto subestimado. Cada plugin pode adicionar consultas, jobs, templates e consumo extra de memória. Não trate plugin como algo gratuito só porque instala com poucos comandos.

Disco também merece atenção. SSD comum é suficiente para fóruns pequenos. NVMe pode ajudar quando há muitas leituras e escritas no PostgreSQL, backups frequentes e uploads grandes, mas não corrige consulta mal planejada, falta de RAM ou servidor sobrecarregado. Para comunidades com anexos, comece com 80 GB, mesmo que o banco pareça pequeno no início. Backups locais temporários e logs crescem. Se o provedor cobra por upgrade de disco ou exige migração para expandir volume, planeje antes.

Uma prática simples é reservar 30% de folga. Se o fórum usa 3 GB de RAM em horário normal, 4 GB já está apertado. Se o disco chegou a 70%, limpe backups antigos, mova uploads para storage externo quando fizer sentido e revise logs. Operar no limite transforma qualquer manutenção em incidente.

PostgreSQL, Redis e email transacional no dia a dia

Discourse depende fortemente de PostgreSQL e Redis. Esses dois componentes não são acessórios. O PostgreSQL guarda usuários, tópicos, posts, permissões, configurações e histórico. O Redis acelera operações, cacheia dados e apoia filas e tarefas internas. O email transacional fecha o ciclo da comunidade, porque confirma contas, envia notificações, recupera senhas e avisa participantes sobre respostas. Se qualquer uma dessas partes falha, a experiência do usuário sofre rápido.

PostgreSQL é o coração do fórum

O banco precisa de disco confiável, baixa latência de I/O e backup consistente. Em uma VPS pequena, PostgreSQL roda no mesmo servidor da aplicação. Isso simplifica a instalação, mas cria disputa por RAM e disco. Configurações como shared_buffers, work_mem e checkpoint precisam respeitar a memória disponível. Não adianta copiar parâmetros de um servidor com 32 GB para uma VPS de 4 GB. Para entender melhor esse equilíbrio, o artigo sobre VPS para banco PostgreSQL aprofunda pontos como IOPS, backup lógico, restore e separação de banco em produção.

Em fóruns médios, monitore tamanho das tabelas, crescimento de uploads e tempo das consultas. Um banco de 5 GB pode ser tranquilo. Um banco de 40 GB com muitas buscas, anexos e histórico importado já exige mais cuidado. Antes de migrar, rode um teste de restauração em servidor separado. Backup que nunca foi restaurado é só uma hipótese otimista.

Redis precisa de folga e persistência controlada

Redis costuma parecer leve, mas fica sensível quando o servidor entra em pressão de memória. Em Discourse, ele participa de cache e filas. Se Redis reinicia ou perde dados voláteis, o fórum pode se recuperar, mas você pode notar atrasos, sessões afetadas e jobs reprocessados. O ideal é acompanhar uso de memória e evitar que Redis dispute os últimos megabytes com PostgreSQL. Para uma visão focada nesse componente, veja o guia de VPS para Redis e cache, que explica quando cache local resolve e quando separar Redis começa a fazer sentido.

Email transacional não é detalhe

Não use o próprio servidor da VPS como SMTP principal para produção, salvo em casos muito controlados. IP novo, reputação baixa, DNS mal configurado e bloqueios de porta podem jogar mensagens no spam ou impedir cadastro de usuários. Use um serviço transacional externo e configure SPF, DKIM e DMARC. Em comunidades pequenas, 5 mil emails por mês podem bastar. Em comunidades com notificações ativas, esse número cresce rápido. Um tópico popular com centenas de assinantes pode disparar muitos emails em minutos. Sem provedor transacional confiável, o fórum parece quebrado mesmo quando web e banco estão saudáveis.

Brasil, latência e escolha do provedor

Para uma comunidade brasileira, hospedar no Brasil pode reduzir latência percebida, principalmente em navegação autenticada, carregamento de páginas e interações frequentes. Um usuário em São Paulo acessando um datacenter nacional pode ver latências na casa de poucos milissegundos a algumas dezenas, dependendo da rota. Um servidor nos Estados Unidos pode ficar na faixa de 120 a 180 ms para boa parte do Brasil. Esses números variam por operadora, peering e região, então devem ser tratados como referência, não promessa.

Datacenter local ajuda, mas não substitui boa arquitetura

Latência menor melhora a sensação de resposta, mas não salva um fórum com banco saturado, swap constante ou email mal configurado. Se o PostgreSQL demora para responder, uma conexão de 10 ms não resolve. Se o Sidekiq acumula jobs, notificações atrasam mesmo com datacenter perto. O melhor cenário combina região adequada, CPU suficiente, RAM com folga, disco consistente e monitoramento básico.

Provedores como LetsCloud, Vultr, DigitalOcean, Akamai, AWS Lightsail, Hetzner, Contabo e outros aparecem com frequência em decisões de infraestrutura. Para o contexto brasileiro, avalie região disponível, latência medida a partir do público, método de pagamento, suporte, snapshots, backups, política de banda e tipo de armazenamento. LetsCloud pode entrar na lista quando a necessidade envolve presença ou foco no Brasil, mas recursos como NVMe, localização específica, snapshots e backups precisam ser confirmados por plano e localidade antes de qualquer decisão. Dados de preço, promoções e disponibilidade também exigem revisão humana antes de publicação comparativa.

VPS tradicional, Cloud Server e cloud instance

VPS tradicional geralmente significa recursos virtualizados em um host físico com planos mais fixos. Cloud Server ou cloud instance costuma oferecer provisionamento mais flexível, upgrades rápidos, snapshots e integração melhor com API, embora isso dependa do provedor. Para Discourse, a diferença prática aparece na hora de escalar, criar snapshot antes de atualização, aumentar disco e recuperar o serviço após falha.

Se a comunidade é pequena e o orçamento é limitado, uma VPS tradicional bem dimensionada pode funcionar. Se o fórum é parte de um produto, curso pago, comunidade corporativa ou suporte a clientes, um Cloud Server com snapshot, backup externo e possibilidade de upgrade rápido reduz risco operacional. Antes de escolher, faça testes simples: ping e traceroute a partir de redes brasileiras, instalação de staging, restore de backup, envio real de email transacional e simulação de atualização do Discourse. Esses testes dizem mais que qualquer página de marketing.

Backups, snapshots e restauração: o que testar antes do lançamento

Backup em Discourse precisa ser tratado como rotina de operação, não como checkbox de painel. O fórum concentra conteúdo produzido por usuários, mensagens, histórico de moderação, contas, categorias, permissões e anexos. Perder esses dados pode destruir a confiança da comunidade. O backup ideal combina exportação do próprio Discourse, cópia externa, retenção adequada e teste periódico de restauração. Se o backup fica apenas no mesmo disco da VPS, uma falha de volume pode levar produção e cópia embora juntas.

Backup do Discourse não é só copiar arquivos

Discourse possui mecanismo próprio de backup, que inclui banco e uploads conforme configuração. Ele pode gerar arquivos compactados e enviar para storage externo, dependendo do setup. Em uma instalação pequena, uma rotina diária com retenção de 7 a 14 dias pode ser suficiente. Em comunidade muito ativa, considere backups mais frequentes e estratégia de retenção maior. O ponto principal é medir o tempo de restauração. Um backup de 2 GB pode voltar rapidamente. Um backup de 80 GB, com muitos uploads, pode transformar recuperação em horas de trabalho.

Exemplo prático: antes de abrir o fórum ao público, crie um servidor de teste com a mesma versão do Discourse, restaure um backup real e valide login, tópicos, uploads, categorias, busca e envio de email. Depois documente o passo a passo. Em incidente, ninguém quer descobrir a ordem correta dos comandos sob pressão. Também vale testar espaço em disco durante o backup, porque a geração do arquivo pode consumir armazenamento temporário relevante.

Snapshots ajudam, mas não são plano de desastre completo

Snapshots são úteis antes de upgrades, mudanças de plugin e alterações de sistema. Se uma atualização quebra o ambiente, voltar o snapshot pode ser rápido. Só que snapshot não substitui backup lógico. Ele pode estar preso ao mesmo provedor, à mesma região ou ao mesmo volume. Também pode capturar um estado inconsistente se criado sem cuidado, dependendo da tecnologia usada.

Uma boa rotina combina três camadas: backup do Discourse exportado para fora do servidor, snapshot antes de mudanças arriscadas e documentação de restauração. Para comunidades críticas, inclua monitoramento de sucesso do backup e alerta de falha. Não basta agendar a tarefa. Verifique se o arquivo foi gerado, transferido e pode ser aberto. Operação madura é menos sobre ferramentas sofisticadas e mais sobre hábitos repetíveis.

Tabela de dimensionamento para Discourse

A tabela abaixo resume perfis realistas para escolher VPS para Discourse no Brasil. Ela não substitui teste de carga, mas ajuda a evitar dois erros comuns: contratar um plano fraco demais para produção ou pagar por recursos que o fórum ainda não usa. Os números assumem Discourse, PostgreSQL e Redis no mesmo servidor, email transacional externo e nenhum outro workload pesado rodando junto. Se você pretende hospedar landing page, analytics, API, automações ou banco de outra aplicação no mesmo host, suba um nível ou separe serviços.

Perfil de comunidade	Recursos sugeridos	Uso esperado	Pontos de atenção	Quando rever o plano
Comunidade nova ou beta privado	2 vCPUs, 4 GB RAM, 50 GB SSD	Até alguns milhares de usuários cadastrados, tráfego baixo a moderado	Evitar plugins em excesso, usar SMTP externo, acompanhar swap	RAM acima de 75%, disco acima de 70%, rebuilds lentos
Comunidade ativa em crescimento	4 vCPUs, 8 GB RAM, 80 a 160 GB SSD ou NVMe	Moderação diária, busca frequente, uploads e notificações constantes	Monitorar PostgreSQL, fila Sidekiq, tempo de backup e I/O	Picos acima de 100 usuários simultâneos ou backups demorados
Comunidade crítica ou produto pago	4 a 8 vCPUs, 16 GB RAM, disco rápido, backup externo	Suporte a clientes, comunidade paga, cursos, base importada grande	Staging, snapshots antes de update, restauração testada, alertas	Crescimento de banco, SLA interno, necessidade de separar banco ou storage
Migração de fórum antigo	4 vCPUs, 8 a 16 GB RAM, 160 GB ou mais	Importação de histórico, anexos, redirecionamentos e reindexação	Testar importador, validar encoding, medir tempo de rebuild	Antes de abrir ao público e após primeira semana de tráfego real

Em termos práticos, comece pelo perfil que representa os próximos 6 meses, não apenas o dia da instalação. Um fórum recém-lançado pode parecer leve, mas a primeira campanha de divulgação muda tudo. Se você vai importar 10 anos de posts de phpBB, vBulletin ou outro sistema, dimensione para a migração, não só para a operação depois dela. Importadores e reindexação consomem CPU e disco de forma concentrada.

Também faz sentido separar ambiente de produção e staging quando a comunidade passa a ter valor real. Um staging pequeno, mesmo com 2 vCPUs e 4 GB, permite testar atualização, plugin e tema antes de mexer no fórum público. O custo extra costuma ser menor que o prejuízo de uma atualização mal testada durante horário de pico.

Recomendações por perfil

Dev solo ou comunidade pequena

Se você administra uma comunidade própria, fórum de projeto open source, grupo de estudos ou beta privado, comece com 2 vCPUs, 4 GB de RAM e 50 GB de SSD. Essa configuração dá espaço para Discourse, PostgreSQL, Redis e Docker sem sufocar o sistema logo na primeira atualização. Use email transacional externo desde o início, configure backups diários e faça um teste de restauração antes de convidar usuários. Evite instalar muitos plugins na primeira semana. Primeiro valide cadastro, login, categorias, permissões, notificações e moderação. Depois personalize. Para economizar sem perder segurança, prefira um servidor simples com boa rotina de backup a um plano cheio de extras que você não sabe operar.

Time de produto ou comunidade em crescimento

Para times que usam Discourse como comunidade de clientes, suporte, educação ou relacionamento, o ponto de partida mais equilibrado é 4 vCPUs, 8 GB de RAM e 80 a 160 GB de disco. Esse perfil aguenta melhor notificações, busca, uploads, plugins e moderação ativa. Também permite rebuilds com menos sofrimento. Crie um ambiente de staging, mesmo que temporário, para testar upgrades e mudanças de tema. Monitore carga, memória, disco, fila Sidekiq e sucesso dos backups. Se a comunidade faz parte do funil de vendas ou suporte ao cliente, trate indisponibilidade como incidente de produto, não como problema lateral de hospedagem.

Produção crítica com moderação ativa

Quando o fórum sustenta uma comunidade paga, documentação colaborativa, suporte oficial ou base grande importada, pense em arquitetura mais conservadora. Use 4 a 8 vCPUs, 16 GB de RAM, disco rápido, backups externos, snapshots antes de mudanças e plano claro de restauração. Nesse nível, vale avaliar separação futura de banco, storage externo para uploads e monitoramento com alertas. Não precisa complicar tudo no primeiro dia, mas precisa saber o caminho de crescimento. Também é prudente manter janela de manutenção, changelog interno e acesso SSH restrito por chave. A operação deixa de ser apenas instalar Discourse e passa a ser cuidar de uma comunidade com dados valiosos.

Para todos os perfis, a escolha do provedor deve ser validada com dados atuais. Região, preço, banda, tipo de disco, backup, snapshot e suporte mudam com frequência. Use as páginas oficiais e registre a data de coleta antes de publicar qualquer comparativo. No contexto brasileiro, medir latência a partir das redes que seus usuários realmente usam pode ser mais útil que escolher apenas pelo nome do datacenter. Um fórum bom é aquele que responde rápido, envia email corretamente, recupera backup sem drama e continua simples de manter seis meses depois do lançamento.