ERPNext no Brasil: como escolher a VPS certa

Resposta direta

Para hospedar ERPNext self-hosted em uma VPS no Brasil, comece pensando em banco de dados, memória e rotina de backup, não apenas no preço mensal do servidor. Uma instalação pequena pode funcionar com 2 vCPUs, 4 GB de RAM e 60 GB de SSD, mas empresas com vários usuários, anexos, integrações fiscais e relatórios frequentes devem mirar 4 vCPUs, 8 GB de RAM e disco SSD ou NVMe com boa taxa de I/O. O ERPNext usa Frappe, Python, MariaDB, Redis, workers em background, filas e Nginx, então a VPS precisa sustentar processos simultâneos. Datacenter no Brasil reduz latência para equipes locais, enquanto backups testados, firewall, SSH com chave e snapshots antes de atualizações reduzem risco operacional.

Resumo rápido

• ERPNext em produção exige mais cuidado que um site institucional, porque combina aplicação, banco, filas, cache e arquivos anexados.
• Para uso inicial, considere 2 vCPUs, 4 GB de RAM e 60 GB de SSD como ponto de partida mais confortável que planos de 1 GB.
• Para empresas com 20 a 60 usuários, 4 vCPUs, 8 GB de RAM e 100 GB ou mais de disco costumam entregar margem melhor.
• Banco de dados e anexos tornam o backup crítico. Use cópias automáticas, retenção e teste de restauração.
• Datacenter no Brasil ajuda quando a equipe acessa o ERP o dia todo, especialmente em telas com muitas consultas.
• Segurança básica inclui firewall, SSH por chave, atualizações do sistema, TLS, fail2ban e usuários com permissões bem definidas.
• Antes de contratar, confirme storage, localidade, política de backup, snapshots, tráfego, suporte e forma de cobrança no site oficial.

O que muda ao hospedar ERPNext em VPS no Brasil

Hospedar ERPNext em VPS no Brasil é uma decisão diferente de contratar um SaaS pronto. A empresa ganha controle sobre ambiente, dados, versões, integrações e políticas internas, mas também assume responsabilidade por atualização, backup, segurança e disponibilidade. Isso combina bem com consultorias ERP, empresas com equipe técnica e negócios que precisam personalizar fluxos de compra, estoque, financeiro, manufatura ou CRM. Não combina tão bem com quem quer zero operação de infraestrutura.

ERPNext não é um site simples

O ERPNext roda sobre o framework Frappe e depende de vários serviços. Em uma instalação típica, você terá Nginx recebendo as requisições, processos Python servindo a aplicação, Redis para cache e filas, MariaDB como banco principal, workers para tarefas em background, agendador para rotinas periódicas e arquivos anexados em disco. Uma tela de relatório financeiro, por exemplo, pode acionar consultas pesadas no banco enquanto outro usuário importa notas, outro baixa anexos e uma integração externa envia pedidos.

Essa combinação muda o raciocínio de dimensionamento. Um WordPress simples pode sofrer mais com picos de visitantes anônimos, enquanto o ERPNext sofre muito com concorrência de usuários autenticados, relatórios, escritas no banco e jobs assíncronos. Se você está comparando alternativas de ERP self-hosted, também vale ler o conteúdo sobre VPS para Odoo e ERP self-hosted no Brasil, porque vários critérios de CPU, RAM, backup e latência se repetem.

VPS tradicional, Cloud Server e cloud instance

Na prática, o mercado usa VPS, Cloud Server e cloud instance de formas parecidas, mas existem diferenças. Uma VPS tradicional costuma ser uma fatia virtualizada de um servidor físico. Um Cloud Server ou cloud instance tende a oferecer provisionamento mais flexível, painel de upgrade, imagens, snapshots e recursos elásticos, dependendo do provedor. Para ERPNext, o mais relevante é entender se você consegue ampliar CPU, RAM e disco sem reinstalação traumática. Também é essencial saber se o provedor entrega armazenamento confiável, baixa latência para usuários brasileiros e ferramentas de recuperação quando algo sai errado.

Arquitetura recomendada para ERPNext self-hosted

A arquitetura mais comum para começar com ERPNext em uma VPS é o modelo tudo em um: aplicação, banco, Redis, Nginx e workers no mesmo servidor. Ele é simples, barato e mais fácil de administrar. Para uma empresa pequena, uma consultoria em fase de implantação ou um ambiente de homologação, esse desenho reduz complexidade. Você precisa monitorar menos peças e consegue aplicar backup de forma mais direta. O problema aparece quando banco, workers e aplicação começam a competir por CPU, RAM e I/O no mesmo disco.

Componentes principais do ambiente

Uma instalação real de ERPNext precisa considerar pelo menos seis blocos. O primeiro é o sistema operacional, normalmente Ubuntu LTS ou Debian estável, com atualizações de segurança ativas. O segundo é o stack Frappe, com Python, Node.js, Yarn e bench. O terceiro é o MariaDB, que guarda dados transacionais, cadastros, lançamentos, permissões e configurações. O quarto é o Redis, usado para cache, filas e comunicação interna. O quinto é o Nginx, responsável por TLS, proxy reverso e entrega de arquivos. O sexto é a camada de backup, que deve cobrir banco, sites, arquivos privados e arquivos públicos.

Em um servidor único de produção básica, uma configuração como 4 vCPUs, 8 GB de RAM, 100 GB de SSD e sistema em Ubuntu LTS dá margem para implantação com 20 a 40 usuários moderados. Para homologação, 2 vCPUs, 4 GB de RAM e 60 GB de SSD podem bastar. Para uma operação com anexos pesados, integrações contínuas e relatórios demorados, separar o banco em outro servidor pode fazer sentido.

Separar serviços ou começar em servidor único

Separar serviços aumenta controle, mas também aumenta custo e operação. Um arranjo com aplicação em uma VPS e banco em outra permite ajustar recursos de forma independente. O banco pode receber mais RAM e disco rápido, enquanto a aplicação ganha mais CPU para workers e requisições. Essa arquitetura também facilita manutenção, porque você consegue reiniciar a camada de aplicação sem tocar diretamente no banco. Em contrapartida, exige rede privada ou regras de firewall muito bem configuradas, além de backup coordenado.

Um caminho prudente é começar simples, mas não improvisado. Defina nomes claros para ambientes, como erp-prod, erp-hml e erp-backup. Use variáveis de configuração protegidas, sem expor senhas em scripts versionados. Antes de atualizar ERPNext, gere snapshot quando o provedor oferecer esse recurso e faça dump do banco. A meta não é montar uma arquitetura sofisticada no primeiro dia, e sim evitar uma instalação que funcione no teste e vire um risco quando a empresa começar a depender dela para faturar, comprar e fechar caixa.

CPU, RAM, disco e rede: como dimensionar sem chute

O dimensionamento do ERPNext deve partir de usuários simultâneos, volume de documentos, anexos, integrações e relatórios. Número total de usuários cadastrados ajuda pouco sozinho. Uma empresa com 80 usuários, mas apenas 12 simultâneos, pode exigir menos que uma operação com 25 usuários que importam pedidos, emitem relatórios de estoque e sincronizam e-commerce o dia inteiro. Por isso, a escolha da VPS para ERPNext no Brasil deve considerar perfil de uso real.

Configurações por volume de uso

Para laboratório, treinamento ou demonstração comercial, 2 vCPUs, 2 GB de RAM e 40 GB de SSD podem funcionar, desde que você aceite lentidão em builds, atualizações e relatórios. Para produção pequena, 2 vCPUs, 4 GB de RAM e 60 GB de SSD são um piso mais honesto. Esse perfil atende consultórios, pequenas distribuidoras, escritórios e empresas com poucos módulos ativos. Se houver muitos anexos, aumente disco desde o início, porque crescer armazenamento depois pode exigir janela de manutenção.

Para produção intermediária, mire 4 vCPUs, 8 GB de RAM e 100 a 160 GB de SSD ou NVMe. Essa faixa suporta melhor múltiplos workers, Redis, MariaDB com buffer maior e rotinas de backup sem derrubar a experiência do usuário. Para produção mais pesada, use 8 vCPUs, 16 GB de RAM e disco rápido, além de avaliar banco separado. Não prometa desempenho apenas por causa de NVMe, porque consultas ruins, relatórios mal filtrados e integrações mal desenhadas também travam ERP.

Quando crescer para mais recursos

Sinais de crescimento são fáceis de perceber quando há monitoramento. Se a memória fica acima de 80 por cento por várias horas, se o swap começa a ser usado com frequência, se o load average passa de forma constante o número de vCPUs, ou se o banco demora em consultas comuns, a VPS já está apertada. Ferramentas como htop, iotop, vmstat, journalctl e logs do MariaDB ajudam a separar problema de CPU, RAM, disco ou aplicação.

Também olhe para rede. Uma filial no Nordeste acessando um servidor nos Estados Unidos pode sentir telas mais lentas que a matriz em São Paulo usando um datacenter nacional. A diferença entre 20 ms e 160 ms não aparece apenas em download de arquivos. Ela pesa em várias requisições pequenas feitas pela interface do ERP. Se o time usa o sistema por oito horas por dia, latência baixa vira produtividade. Ainda assim, localização não substitui boa configuração. Servidor no Brasil com pouca RAM e disco saturado continuará ruim.

Perfil de uso	Configuração inicial sugerida	Quando usar	Ponto de atenção
Homologação e treinamento	2 vCPUs, 2 a 4 GB RAM, 40 GB SSD	Demos, testes, capacitação e validação de módulos	Não usar como produção sem backup e monitoramento
Produção pequena	2 vCPUs, 4 GB RAM, 60 a 80 GB SSD	Até cerca de 10 a 20 usuários moderados	Monitorar MariaDB, swap e crescimento de anexos
Produção intermediária	4 vCPUs, 8 GB RAM, 100 a 160 GB SSD ou NVMe	Empresa com módulos ativos, integrações e relatórios	Planejar snapshots, retenção e janela de atualização
Produção crítica	8 vCPUs, 16 GB RAM, 200 GB ou mais	Alto volume, muitas integrações ou operação diária intensa	Avaliar banco separado, réplica e plano de recuperação

Banco de dados, armazenamento e backups do ERPNext

O banco de dados é o coração do ERPNext. Cadastros, lançamentos, permissões, workflows, histórico e configurações ficam no MariaDB. Por isso, escolher VPS olhando apenas CPU pode levar a erro. Um servidor com CPU razoável, mas disco lento e pouca RAM para o banco, pode sofrer em relatórios de contas a receber, estoque por lote ou histórico de movimentações. Se o ERPNext será usado para operação diária, trate banco e backup como requisitos de primeira classe.

MariaDB e cuidados com I/O

Em instalações pequenas, MariaDB no mesmo servidor funciona bem. Ajustes como innodb_buffer_pool_size em torno de 40 a 60 por cento da RAM disponível para banco podem ajudar, desde que você deixe memória para aplicação, Redis e sistema. Em uma VPS com 8 GB, por exemplo, reservar 3 GB para o buffer do InnoDB pode ser um ponto inicial razoável, mas isso precisa ser medido. Se a máquina também roda workers pesados, subir demais o buffer pode causar swap e piorar tudo.

Disco SSD já é o mínimo esperado para produção. NVMe pode reduzir latência de I/O em cenários com muitas leituras e escritas, mas depende da implementação do provedor, do oversubscription, do tipo de plano e da carga vizinha. Não trate a sigla como garantia automática. Para aprofundar a escolha de banco em VPS, o guia sobre VPS para banco PostgreSQL ajuda mesmo quando o ERPNext usa MariaDB, porque os critérios de RAM, IOPS, backup, isolamento e monitoramento são parecidos.

Backup não é só arquivo compactado

Backup de ERPNext precisa cobrir banco, arquivos privados, arquivos públicos, configuração do site e, em alguns casos, custom apps. Um dump do banco sem anexos não restaura a empresa por completo. Um snapshot do disco sem retenção externa também não resolve desastre do provedor, exclusão acidental antiga ou ransomware. O ideal é combinar backups da aplicação com snapshot do servidor e cópia externa em storage separado.

Uma política simples pode ser: backup diário com retenção de 7 dias, backup semanal com retenção de 4 semanas e backup mensal com retenção de 6 a 12 meses. Para empresas com fechamento fiscal e financeiro, guarde cópias antes de atualizações grandes. O ponto que muita gente esquece é o teste. Uma vez por mês, restaure em ambiente de homologação e valide login, anexos, relatórios e integridade dos dados. Se você ainda não tem rotina clara, o artigo sobre VPS com backup automático mostra os critérios para avaliar recursos do provedor sem confundir snapshot com backup completo.

Segurança, acesso e rotina de operação

ERPNext concentra dados sensíveis: clientes, fornecedores, preços, documentos, fluxo financeiro, usuários internos e, em muitos casos, anexos fiscais ou contratuais. Uma VPS mal protegida coloca tudo isso em risco. Segurança não precisa ser um projeto enorme no início, mas precisa ser consistente desde o primeiro deploy. O básico bem feito já reduz bastante a superfície de ataque.

Hardening básico para produção

O primeiro passo é bloquear acesso desnecessário. Use SSH com chave, desabilite login direto do root, aplique senha forte para usuários administrativos e limite portas expostas. Em uma instalação comum, portas públicas devem ser 80 e 443 para web, além de 22 ou uma porta SSH controlada por firewall. MariaDB e Redis não devem ficar abertos para a internet. Se você separar banco e aplicação, permita conexão apenas pela rede privada ou pelo IP da aplicação.

Instale fail2ban para reduzir tentativas de força bruta, mantenha o sistema atualizado e configure TLS com renovação automática. Também vale criar usuários do ERPNext com papéis mínimos. Não transforme todo gerente em administrador do sistema. Em empresas maiores, revise permissões mensalmente, principalmente quando pessoas mudam de área ou saem da organização.

Um exemplo prático de firewall inicial com UFW seria permitir OpenSSH, HTTP e HTTPS, negar o restante e revisar regras após validar a aplicação. Outra prática simples é separar chaves por pessoa. Nada de uma única chave compartilhada entre consultor, desenvolvedor e administrador. Quando alguém sai do projeto, remover uma chave individual é rápido. Remover confiança de uma chave compartilhada é uma dor.

Monitoramento e manutenção

Operação saudável depende de rotina. Monitore CPU, RAM, disco, uso de swap, espaço livre, status de serviços, tempo de resposta HTTP e falhas de backup. Alertas por e-mail, Slack ou ferramenta de monitoramento evitam descobrir problema pelo usuário final. Um ERP com disco 100 por cento cheio pode corromper rotinas, travar uploads e impedir dumps. Esse é um erro comum e evitável.

Antes de atualizar ERPNext, leia notas da versão, teste em homologação e tenha plano de volta. Atualizações podem envolver migrações de banco, rebuild de assets e mudanças em custom apps. Uma janela de manutenção de 30 a 90 minutos costuma ser suficiente para ambientes pequenos, mas empresas com integrações devem avisar usuários e pausar jobs externos. Documente comandos executados, versão anterior, versão nova, horário e responsável. Parece burocrático, mas ajuda muito quando uma atualização falha às 22h e alguém precisa entender o que mudou.

Provedores, latência e pontos de verificação no Brasil

Ao escolher uma VPS para ERPNext no Brasil, provedores nacionais e globais entram na conversa por motivos diferentes. Datacenter nacional pode reduzir latência para usuários brasileiros e simplificar cobrança local, enquanto provedores globais podem oferecer ecossistema amplo, muitas regiões e recursos maduros de automação. A melhor escolha depende do perfil da empresa, da equipe técnica e da necessidade de suporte, não apenas de um nome conhecido.

Tabela comparativa de perfis

A tabela abaixo não é um ranking de preço. Recursos, localidades, cobrança, tráfego, storage e políticas de backup mudam com frequência e precisam ser confirmados nas páginas oficiais antes da contratação. A data de coleta das fontes usadas neste artigo está registrada no campo estruturado de fontes.

Provedor ou perfil	Pontos relevantes para ERPNext	O que confirmar antes de contratar	Melhor encaixe
LetsCloud	Opção brasileira com foco em Cloud Server, podendo ser avaliada quando latência nacional e cobrança local forem relevantes	Localidade disponível, tipo de storage por plano, snapshots, backup, tráfego, SLA e suporte	Empresas que querem avaliar infraestrutura no Brasil sem abrir mão de controle
DigitalOcean	Cloud global com documentação ampla, droplets, snapshots, volumes e imagens	Região mais adequada ao Brasil, custo final, backup, tráfego e latência real para usuários	Times técnicos que valorizam documentação e automação
Vultr	Cloud compute com várias localidades globais e opções de instâncias	Disponibilidade de região, tipo de disco, snapshots, backups e política de tráfego	Projetos que buscam flexibilidade de instâncias e testes rápidos
AWS Lightsail	Oferta simplificada dentro do ecossistema AWS	Região, limites do plano, snapshots, rede, custo de saída e integração com outros serviços AWS	Empresas que já usam AWS ou querem caminho de evolução dentro do ecossistema
Locaweb ou Hostinger	Provedores conhecidos no mercado brasileiro, com ofertas variando por produto	Se o plano é VPS adequada, acesso root, recursos dedicados, backup e limitações de uso	Empresas que preferem marcas populares e suporte comercial mais familiar

O que confirmar antes de contratar

Não publique nem decida com base em prints antigos de preço. Antes de fechar, confirme no site oficial: vCPU, RAM, disco, tipo de storage, tráfego mensal, política de cobrança, região, snapshots, backup, SLA, suporte e regras de upgrade. Se o provedor promete backup automático, entenda se é backup gerenciado, snapshot de disco, cópia incremental, retenção configurável ou apenas um recurso opcional pago.

Teste latência a partir dos locais reais de uso. Uma empresa com matriz em Curitiba e filial em Recife pode ter resultados diferentes de uma equipe toda em São Paulo. Se possível, suba um ambiente de teste por alguns dias, instale ERPNext com dados fictícios e simule telas críticas: abertura de relatório, cadastro de nota, upload de anexo, busca de cliente e login simultâneo. Esse teste prático costuma revelar mais que uma tabela de especificações.

Também pense na saída. Você consegue exportar backups completos? O provedor permite snapshot antes de manutenção? Há documentação para redimensionar disco? Existe bloqueio contratual relevante? ERP é sistema de longo prazo. Escolher VPS é também escolher uma rotina de operação para os próximos anos.

Recomendações por perfil

A recomendação certa muda bastante conforme maturidade técnica, criticidade do ERP e orçamento. O erro mais comum é usar a mesma configuração para demo, implantação e produção. Isso gera dois problemas: pagar demais em ambientes simples ou economizar demais no servidor que sustenta a operação da empresa. Separe perfis e defina regras claras para cada um.

Dev solo ou consultor ERPNext

Para dev solo, consultor ou pequena implantação em fase inicial, uma VPS com 2 vCPUs, 4 GB de RAM e 60 GB de SSD costuma ser um bom começo. Use esse ambiente para homologação, treinamento, parametrização e validação com poucos usuários. Configure backup diário, mesmo que os dados ainda não sejam finais, porque customizações e scripts também têm valor. Evite instalar vários clientes no mesmo servidor sem isolamento adequado. Se você atende mais de uma empresa, prefira instâncias separadas ou ao menos sites bem organizados, com backups identificados por cliente e data.

Time interno de TI

Para um time interno que vai operar ERPNext de verdade, a faixa de 4 vCPUs, 8 GB de RAM e 100 a 160 GB de SSD ou NVMe é mais equilibrada. Esse perfil permite rodar workers, banco, Redis e Nginx com folga inicial. Também dá espaço para logs, anexos e backups temporários antes de envio para storage externo. O time deve montar ambiente de homologação separado, criar checklist de atualização e manter documentação de acesso. Se a empresa depende do ERP para faturamento diário, não atualize direto em produção só porque o comando parece simples.

Produção empresarial

Em produção empresarial, pense em 8 vCPUs, 16 GB de RAM e 200 GB ou mais de disco rápido como ponto de partida para ambientes com muitos usuários, integrações e anexos. Avalie banco separado quando relatórios ou rotinas de escrita começarem a competir com a aplicação. Use monitoramento, alertas, snapshots antes de mudanças, backup externo e teste de restauração periódico. Para empresas com operação crítica, defina RPO e RTO em linguagem simples: quanto dado pode ser perdido e em quanto tempo o ERP precisa voltar. Sem esses dois números, qualquer plano de recuperação fica vago.

A decisão final não deve ser baseada em uma configuração fixa copiada de outro projeto. Pegue os números deste guia como ponto de partida, rode um piloto com dados próximos da realidade e monitore por pelo menos uma semana. Se CPU sobrar, mas disco ficar saturado, ajuste storage. Se RAM acabar, suba memória antes de culpar o ERPNext. Se usuários reclamarem de lentidão em outra região do país, teste latência e rota. VPS boa para ERPNext é a que sustenta a rotina da empresa com previsibilidade, backup restaurável e margem para crescimento.