VPS para Odoo e ERP self-hosted no Brasil

Resposta direta

Para rodar Odoo ou um ERP self-hosted em VPS no Brasil, a escolha segura começa em 2 vCPUs, 4 GB de RAM, 80 GB de SSD ou NVMe e PostgreSQL bem configurado. Em produção, empresas com vários usuários simultâneos devem considerar 4 vCPUs, 8 GB de RAM, disco rápido, backup externo diário, snapshot antes de atualização e monitoramento de CPU, RAM, I/O e conexões do banco. Odoo depende bastante do PostgreSQL, então não adianta olhar só para preço ou quantidade de vCPU. Latência para usuários brasileiros, rotina de restauração, firewall, acesso SSH, atualizações e separação entre aplicação e banco pesam muito na estabilidade. LetsCloud, DigitalOcean, Vultr, Linode, AWS Lightsail e provedores nacionais podem atender cenários diferentes, mas recursos, regiões, backups e tipo de armazenamento precisam ser conferidos nas páginas oficiais antes da contratação.

Resumo rápido

Escolher VPS para Odoo é uma decisão de infraestrutura, não apenas de hospedagem. O ERP concentra vendas, estoque, financeiro, CRM, compras e processos internos. Quando ele fica lento, a empresa sente no atendimento, no faturamento e na operação diária.

• Para laboratório ou homologação, 2 vCPUs, 4 GB de RAM e 50 GB de SSD costumam ser um ponto de partida confortável.
• Para produção pequena, use pelo menos 4 vCPUs, 8 GB de RAM, 80 GB a 160 GB de disco rápido e backup fora da VPS.
• PostgreSQL precisa de RAM, I/O previsível e ajustes como shared_buffers, work_mem, effective_cache_size e limite de conexões.
• Datacenter no Brasil pode reduzir latência para equipes locais, principalmente em telas com muitas consultas e anexos.
• Backup automático não basta. É preciso testar restauração, medir tempo de recuperação e guardar cópias fora do provedor.
• VPS gerenciada ajuda empresas sem equipe Linux, enquanto a não gerenciada dá mais controle para consultores técnicos.
• Antes de migrar, faça teste com banco real, número aproximado de usuários e módulos que serão usados em produção.

Por que Odoo e ERP self-hosted exigem uma VPS bem dimensionada

Odoo parece, à primeira vista, uma aplicação web como qualquer outra. A interface roda no navegador, o usuário acessa por domínio, o servidor responde via HTTP e um proxy reverso como Nginx pode fazer TLS. Só que, na prática, um ERP self-hosted tem um padrão de carga bem diferente de um site institucional ou de um blog. Um clique em uma tela de vendas pode consultar clientes, produtos, impostos, estoque, regras fiscais, permissões e relatórios. Uma importação de planilha pode disparar milhares de gravações no PostgreSQL. Um fechamento contábil pode prender CPU e banco por vários minutos.

Esse comportamento muda a forma de escolher VPS. Um servidor com 1 vCPU e 1 GB de RAM até pode abrir o Odoo para testes, mas sofre rapidamente quando entram módulos de estoque, vendas, financeiro, automações e anexos. Em uma implantação pequena, com 5 a 10 usuários internos, 2 vCPUs e 4 GB de RAM funcionam melhor como ambiente de homologação do que como produção séria. Para produção inicial, 4 vCPUs e 8 GB de RAM dão margem para workers do Odoo, PostgreSQL, Nginx, logs, backups e atualizações sem transformar cada operação em gargalo.

Odoo não é só uma aplicação web

O Odoo usa Python, PostgreSQL e processos de background. Em instalações produtivas, é comum configurar workers = 3 ou mais, definir limit_memory_soft, ativar proxy_mode = True e colocar Nginx na frente da aplicação. Também entram tarefas agendadas, geração de PDF, envio de e-mail, importações CSV, integrações com marketplace e rotinas fiscais. Cada componente disputa CPU, memória e I/O. Se a VPS fica no limite o tempo todo, o usuário percebe em telas demoradas, erro 502 no proxy ou aumento de tempo em relatórios.

ERP parado vira problema operacional

Em um ERP self-hosted, indisponibilidade não significa apenas página fora do ar. Pode significar vendedor sem emitir pedido, estoque sem baixa, financeiro sem conciliação e equipe sem acesso a histórico do cliente. Por isso, o dimensionamento deve considerar horário comercial, picos de uso e janela de manutenção. Um consultor que atende três clientes pequenos pode usar VPS separadas para isolar riscos. Uma empresa com matriz e filiais talvez precise separar aplicação, banco e backup. A escolha mais barata no primeiro mês pode sair cara quando a restauração demora quatro horas em uma manhã de fechamento.

PostgreSQL, RAM e disco: o núcleo da decisão técnica

O PostgreSQL é o coração do Odoo. A aplicação armazena praticamente tudo no banco, incluindo cadastros, permissões, lançamentos, mensagens, logs de atividade, configurações e referências a anexos. Por isso, uma VPS para Odoo precisa ser avaliada com a mesma seriedade de uma VPS para banco de dados. Se você quer aprofundar esse lado, o guia de VPS para banco PostgreSQL ajuda a entender I/O, memória, conexões e persistência com mais detalhe. No contexto de ERP, esses pontos saem do campo teórico e aparecem em tarefas do dia a dia, como abrir uma lista com 50 mil produtos ou calcular disponibilidade de estoque.

Para uma instalação pequena, pense em 4 vCPUs, 8 GB de RAM e 80 GB de SSD como base realista. Em PostgreSQL, uma configuração inicial poderia usar shared_buffers = 2GB, effective_cache_size = 5GB, work_mem = 16MB, maintenance_work_mem = 512MB e max_connections = 100, sempre ajustando conforme carga real. Esses números não são receita universal. Eles servem como referência para uma VPS dedicada ao Odoo, sem outros serviços pesados rodando no mesmo host. Se a VPS também hospeda integração, BI, automação e proxy de outros sistemas, a conta muda.

Configuração inicial realista

Um cenário comum em consultorias é começar com aplicação e banco na mesma VPS. Isso simplifica instalação, reduz latência interna e facilita backup com pg_dump ou pg_basebackup. Para 10 a 20 usuários, 4 vCPUs e 8 GB de RAM podem atender bem se o banco ainda for pequeno, por exemplo até 20 GB, e se não houver muitos relatórios simultâneos. O disco deve ter folga. Se o banco ocupa 20 GB, anexos somam 30 GB e backups locais temporários ocupam mais 40 GB, uma VPS com 80 GB já fica apertada. Nessa situação, 160 GB entrega margem mais saudável.

Quando separar banco e aplicação

Separar PostgreSQL e Odoo faz sentido quando o banco passa a ser o principal gargalo ou quando a empresa quer manutenção independente. Um arranjo simples usa uma VPS de aplicação com 4 vCPUs e 8 GB de RAM, mais uma VPS de banco com 4 vCPUs, 16 GB de RAM e disco rápido. A rede privada entre as instâncias reduz exposição e melhora previsibilidade. Essa arquitetura também facilita escalar workers do Odoo sem mexer no banco. Em contrapartida, aumenta complexidade de firewall, backup e monitoramento. Para uma empresa sem equipe técnica, essa separação deve vir junto de documentação clara e plano de suporte.

Latência, datacenter no Brasil e arquitetura de rede

Datacenter no Brasil não deixa o Odoo automaticamente rápido, mas pode melhorar bastante a experiência de equipes que acessam o ERP todos os dias a partir de cidades brasileiras. Em sistemas administrativos, a latência aparece em detalhes repetidos. Abrir formulário, salvar pedido, consultar produto, anexar PDF, carregar kanban e mudar de menu são ações pequenas, mas acontecem centenas de vezes por usuário. Se cada interação cruza uma rota internacional com 140 ms a 180 ms de latência, a sensação de lentidão aumenta mesmo quando CPU e RAM estão sobrando.

Em uma VPS localizada no Brasil, a latência para usuários em grandes capitais pode ficar em uma faixa muito menor, dependendo do provedor, da operadora e da rota. Não publique promessa fixa sem medição, porque a rede do cliente pesa muito. Um teste prático antes da contratação deve incluir ping, mtr, acesso via navegador e uma base de homologação com dados parecidos com os reais. Se a empresa tem filiais no Nordeste, Sudeste e Sul, vale testar a partir de mais de uma localidade. Uma rota boa em São Paulo pode não ser a melhor para uma filial em Fortaleza.

Impacto para filiais e equipes remotas

Odoo também é usado por equipes externas, representantes comerciais e consultores. Nesse caso, a arquitetura precisa equilibrar latência, disponibilidade e segurança. Uma empresa com 30 usuários internos e 20 representantes pode usar HTTPS com Nginx, certificado TLS, compressão, limite de upload adequado e políticas de sessão bem definidas. Anexos grandes, como notas, contratos e imagens de produto, pedem atenção ao armazenamento. Se o filestore cresce 5 GB por mês, o planejamento de disco precisa olhar 12 meses à frente, não só a instalação inicial.

Arquitetura mínima para produção

Uma arquitetura produtiva simples pode ter DNS apontando para Nginx, Nginx encaminhando para Odoo em porta local, PostgreSQL acessível apenas internamente e backup enviado para armazenamento externo. Em provedores com rede privada, use IP privado para banco e restrinja portas públicas a 80, 443 e SSH com origem controlada. LetsCloud pode entrar no radar quando a empresa procura infraestrutura com presença ou foco no mercado brasileiro, mas disponibilidade de localidade, tipo de disco, backup, snapshots e recursos por plano deve ser confirmada no site oficial. DigitalOcean, Vultr, Linode, AWS Lightsail e outros provedores internacionais também são opções conhecidas, especialmente para equipes acostumadas a painéis cloud e documentação extensa.

Backups, snapshots e teste de restauração

Backup é o ponto em que muitos projetos de ERP self-hosted descobrem a diferença entre ter uma cópia e conseguir voltar a operar. No Odoo, você precisa proteger o PostgreSQL, o filestore, configurações, módulos customizados, arquivos de ambiente, certificados e, em alguns casos, integrações externas. Um snapshot da VPS pode ajudar antes de atualização, mas não substitui uma estratégia de backup consistente. Snapshot costuma capturar o estado do disco em um ponto no tempo. Se o banco estiver em escrita intensa, a consistência precisa ser tratada com cuidado. Backup lógico via pg_dump ou físico via pg_basebackup continua sendo peça central.

Para produção pequena, uma rotina prática pode combinar dump diário do PostgreSQL, compactação, envio para armazenamento externo e retenção de 7 cópias diárias, 4 semanais e 3 mensais. O filestore deve seguir a mesma janela, porque banco sem anexos pode restaurar cadastros, mas deixar documentos quebrados. Antes de confiar na rotina, faça um restore em ambiente separado. Meça quanto tempo leva para baixar o backup, restaurar o banco, reinstalar dependências, apontar domínio temporário e validar login. Se esse processo leva 3 horas, a empresa precisa saber disso antes do incidente.

Backup sem restore testado é aposta

Um erro comum é guardar backups na mesma VPS. Isso protege contra exclusão acidental de tabela, mas não contra falha de disco, invasão com exclusão de arquivos, bloqueio de conta ou perda total da instância. O ideal é manter cópia fora do servidor e, quando possível, fora do mesmo provedor. O artigo sobre VPS com backup automático aprofunda esse tema, especialmente a diferença entre backup do provedor, snapshot, cópia externa e restauração validada. Para ERP, essa diferença é decisiva.

Política prática de retenção

Uma política simples pode usar backup diário às 2h, snapshot antes de atualização de módulo, teste mensal de restauração e alerta quando o backup falhar ou ficar pequeno demais. Esse último detalhe parece estranho, mas ajuda a detectar arquivo corrompido ou dump incompleto. Use logs com data, tamanho, duração e destino. Em bases maiores, acima de 50 GB, avalie backup incremental ou físico para reduzir janela de execução. Também defina RPO e RTO em linguagem de negócio. RPO de 24 horas significa aceitar perder dados desde o último backup. RTO de 2 horas significa voltar a operar nesse prazo. A diretoria precisa entender esses números.

Segurança operacional para Odoo em produção

A segurança de um ERP self-hosted começa antes da instalação. Uma VPS nova deve receber atualização do sistema, usuário administrativo sem login direto como root, autenticação por chave SSH, firewall ativo e serviços mínimos expostos. Em Ubuntu, por exemplo, um ponto de partida comum é liberar 22 apenas para IPs administrativos quando possível, liberar 80 e 443 para web, bloquear acesso externo ao PostgreSQL e manter o Odoo ouvindo em localhost atrás do Nginx. Se o banco precisa ser acessado por uma ferramenta externa, prefira VPN, túnel SSH ou rede privada em vez de abrir a porta 5432 para a internet.

O Odoo também precisa de cuidados na camada da aplicação. Senhas fortes, política de usuários, permissões por grupo, auditoria de módulos instalados e atenção a customizações reduzem risco operacional. Módulos de terceiros podem resolver problemas de negócio, mas também introduzem código difícil de auditar. Em projetos com consultoria, mantenha repositório Git para módulos customizados e documente dependências. Se uma atualização quebrar um módulo fiscal ou um conector de marketplace, a equipe precisa conseguir voltar para a versão anterior ou aplicar correção com rapidez.

Acesso, firewall e atualizações

Uma rotina semanal de segurança pode incluir apt update, revisão de pacotes pendentes, checagem de logs em /var/log/nginx/, revisão de uso de disco com df -h, verificação de processos com htop e inspeção de conexões com ss -tulpn. Para monitoramento, CPU acima de 80 por cento por longos períodos, swap constante, disco acima de 85 por cento e muitas conexões no PostgreSQL são sinais de alerta. Não espere o usuário reclamar para descobrir que o filestore lotou a partição.

Separação de ambientes

Ambiente de produção não deve ser usado para testar módulo novo. Crie uma VPS menor para homologação ou clone temporário antes de atualizar Odoo, Python, dependências e módulos. Essa separação evita que uma alteração de layout, relatório ou regra de negócio trave a operação. A decisão entre cuidar disso internamente ou contratar suporte muda bastante o perfil de risco. Se a empresa não tem administrador Linux, leia o guia sobre VPS gerenciada ou não gerenciada antes de escolher. Para ERP, o custo de operação deve entrar na conta junto com CPU, RAM e disco.

Comparação prática de configurações para Odoo

A melhor configuração de VPS para Odoo depende de usuários simultâneos, tamanho do banco, quantidade de anexos, módulos ativos, integrações e tolerância a parada. Ainda assim, dá para organizar perfis técnicos úteis para compra e planejamento. A tabela abaixo não é uma comparação de preço. Ela usa recursos típicos de infraestrutura para orientar conversas com provedores, consultores e equipes internas. Antes de contratar, confirme no site oficial do provedor quais planos oferecem a combinação desejada de CPU, RAM, storage, região, backup, snapshot, IPv4, tráfego e suporte.

Perfil de uso	Usuários simultâneos	Configuração sugerida	Banco e disco	Backup recomendado	Observações operacionais
Homologação ou piloto	1 a 5	2 vCPUs, 4 GB RAM, 50 GB SSD	PostgreSQL local, base até 10 GB	Dump diário e snapshot antes de testes	Bom para validar módulos, não para operação crítica
Produção pequena	5 a 20	4 vCPUs, 8 GB RAM, 80 a 160 GB SSD ou NVMe	PostgreSQL local ajustado, base até 30 GB	Backup externo diário, retenção semanal e teste mensal	Recomendado para empresa pequena com uso diário
Produção em crescimento	20 a 60	4 a 8 vCPUs, 16 GB RAM, 160 a 320 GB SSD ou NVMe	Banco pode ficar separado, base acima de 30 GB	Backup físico ou lógico, snapshot pré-update, cópia fora do provedor	Exige monitoramento e janela de manutenção definida
Operação crítica	60 ou mais	Aplicação e banco separados, 8 vCPUs ou mais no banco, 32 GB RAM conforme carga	PostgreSQL dedicado, storage rápido e rede privada	Plano de desastre, restore ensaiado, retenção mensal	Precisa de suporte técnico, observabilidade e documentação

Perfis de recursos

Em homologação, a prioridade é flexibilidade. O consultor instala módulos, importa dados de teste e valida fluxos. Se a VPS cair, o impacto é baixo. Em produção pequena, a prioridade muda para estabilidade. A configuração precisa suportar expediente completo, emissão de documentos, anexos e relatórios sem swap constante. Já em produção em crescimento, o gargalo costuma migrar para banco e disco. Nesse estágio, o monitoramento mostra consultas lentas, aumento de I/O wait e crescimento do filestore. Separar banco pode ser a próxima etapa.

Como interpretar a tabela

Não use a tabela como promessa de capacidade exata. Dois clientes com 20 usuários podem ter cargas completamente diferentes. Um usa CRM e vendas simples. Outro roda estoque, manufatura, fiscal, integrações, anexos pesados e BI. O teste mais confiável usa cópia anonimizada do banco real, simulação de usuários e medição de tempo em telas críticas. Faça uma lista com 10 tarefas, como abrir pedido, confirmar venda, emitir relatório, importar produtos e gerar PDF. Se essas tarefas ficam lentas na homologação, aumentar RAM pode ajudar, mas talvez o problema esteja em consulta, módulo customizado ou disco saturado.

Recomendações por perfil

Dev solo ou consultor independente

Para um consultor que implementa Odoo para clientes pequenos, o melhor caminho costuma ser separar laboratório, homologação e produção. Uma VPS de 2 vCPUs, 4 GB de RAM e 50 GB de SSD atende bem testes, demonstrações e validação de módulos. Para cliente real, evite colocar vários ERPs de empresas diferentes na mesma instância sem isolamento claro. Mesmo quando o custo mensal parece atraente, um erro de configuração, pico de I/O ou falha de atualização pode afetar todos. Use Git para módulos customizados, script de backup padronizado e checklist antes de cada atualização. Se precisar economizar, economize em ambiente de teste, não no backup de produção.

Time pequeno com clientes ativos

Uma equipe interna ou consultoria com clientes ativos deve trabalhar com padrão mínimo repetível. Para produção pequena, 4 vCPUs, 8 GB de RAM, 80 a 160 GB de disco rápido, Nginx, TLS, PostgreSQL ajustado e backup externo diário formam uma base equilibrada. Documente portas abertas, usuários administrativos, cron de backup, local das cópias, versão do Odoo, versão do PostgreSQL e procedimento de restore. Se a equipe atende mais de um cliente, crie modelo de provisionamento. Isso reduz improviso e facilita suporte. Também vale manter uma VPS de homologação por cliente quando houver customização relevante, principalmente em módulos fiscais, vendas e estoque.

Produção empresarial com operação crítica

Empresas que dependem do Odoo para vender, faturar, comprar, controlar estoque ou atender filiais precisam tratar a VPS como parte da infraestrutura crítica. Nesse perfil, aplicação e banco separados podem fazer sentido, com PostgreSQL em servidor dedicado, 16 GB a 32 GB de RAM conforme base, storage rápido, rede privada e backup com restauração ensaiada. Monitoramento deve cobrir CPU, memória, disco, I/O, latência HTTP, conexões do banco, fila de e-mails e validade do certificado TLS. Também defina janela de manutenção e plano de rollback antes de atualizar. Se a empresa não tem equipe técnica, contrate operação gerenciada ou suporte especializado. O risco de uma parada longa costuma ser maior que a economia de uma VPS mínima.