Runzos

Baserow, NocoDB ou EspoCRM: qual base/CRM open-source rodar em VPS?

Por Maicon Ramos · · 11 min de leitura

Ilustração de uma base no-code, uma interface sobre banco SQL e um CRM conectados a VPS, banco persistente e backup.
Navegue por tópicos
  1. A resposta curta: escolha a categoria antes da VPS
  2. Não são três CRMs: o que cada ferramenta resolve
  3. O que a VPS realmente assume por baixo da interface
  4. CPU, RAM e disco: por que não existe plano mágico
  5. O custo invisível: atualização, backup e restore
  6. Quando SaaS ganha da VPS
  7. Qual VPS faz sentido depois da escolha?
  8. FAQ
  9. Conclusão: hospede uma operação, não a promessa de software grátis

Escolha Baserow para modelar uma base nova, NocoDB quando o SQL já é o centro dos dados e EspoCRM para vendas e atendimento estruturados. A VPS só entra depois dessa decisão. Ela vale quando existe alguém responsável por persistência, atualizações, acessos, backup e restore. Sem essa operação, SaaS ou hospedagem gerenciada pode ser a opção mais coerente.

A resposta curta: escolha a categoria antes da VPS

Baserow, NocoDB e EspoCRM não resolvem exatamente o mesmo problema. Baserow ajuda a criar uma base operacional nova. NocoDB oferece uma camada visual para dados SQL. EspoCRM organiza o processo comercial, com leads, contas, contatos, oportunidades e atividades.

Essa é a regra mais útil deste comparativo: categoria antes de container. Antes de abrir uma VPS ou subir Docker Compose, defina qual trabalho precisa melhorar. Uma interface bonita não transforma uma base genérica em CRM completo. Também não faz sentido instalar um CRM especializado se o gargalo é organizar dados internos.

A VPS entra depois da decisão de produto. Ela faz sentido quando você aceita cuidar de persistência, acesso, HTTPS, atualização, backup e teste de restore. Caso contrário, uma oferta SaaS ou hospedada pode ter menor custo total, mesmo com mensalidade.

Escolha

Use quando

O que a documentação confirma

Evite quando

Baserow

Você quer modelar uma base, interfaces e automações no-code

O Compose exige SECRET_KEY, senha do banco e senha do Redis

Seu problema principal já é um funil comercial pronto

NocoDB

Você já tem SQL e quer visualizar ou controlar esses dados

A instalação Docker inclui app, worker, PostgreSQL, Redis e volumes

Você quer um CRM pronto sem desenhar o processo

EspoCRM

Leads, oportunidades, atividades e atendimento orientam o trabalho

O projeto suporta PHP, servidor web e bancos relacionais documentados

Você precisa de uma plataforma no-code geral

Não são três CRMs: o que cada ferramenta resolve

Baserow: para construir uma base operacional

Baserow é a escolha quando a operação ainda precisa ser modelada. Isso pode incluir cadastro interno, acompanhamento de projetos, uma base de fornecedores ou um fluxo comercial simples criado pela própria equipe. O ponto não é chamar tudo de CRM. É ter liberdade para montar uma base e interfaces ao redor dela.

A instalação Docker Compose do Baserow pede SECRET_KEY, DATABASE_PASSWORD e REDIS_PASSWORD. Isso mostra que a decisão não se resume à tela de planilha. Há segredos e serviços persistentes sob a interface.

O guia de deploy do Baserow cita 1 vCPU e 2 GB de RAM como mínimo para um container específico. Ele também trata PostgreSQL e Redis como recursos separados naquele desenho. Essa referência não é um plano universal para uma VPS com aplicação, banco, cache, uploads, logs e cópia externa.

Baserow pode apoiar um processo comercial quando alguém modela campos e fluxos. Porém, a pesquisa não confirma equivalência automática com um CRM de vendas completo. Para Rafael, ele é mais adequado quando a necessidade começa por uma base nova, não por um funil pronto.

NocoDB: para dar uma camada visual ao SQL

NocoDB faz mais sentido quando o dado SQL já existe ou quando a equipe quer manter um modelo de dados relacional como centro da operação. A proposta é usar uma interface visual sobre esses dados, em vez de reconstruir tudo como uma coleção de planilhas desconectadas.

A stack Docker oficial do NocoDB documenta NocoDB, worker, PostgreSQL e Redis. O worker atende imports, exports e automações. PostgreSQL guarda metadados e dados. Redis atua como cache e fila.

A mesma documentação descreve os volumes nomeados postgres_data, redis_data e nocodb_data. Eles sobrevivem a restart e a docker compose down. Persistência, porém, não é sinônimo de backup externo. Se o disco, a máquina ou a configuração falharem, você precisa de uma cópia independente e de um restore testado.

NocoDB não vira CRM completo apenas porque aceita tabelas e relações. Ele pode apoiar um processo comercial bem desenhado. Mas, se a equipe quer leads, oportunidades e rotina de vendas sem montar isso do zero, EspoCRM começa mais perto do problema.

EspoCRM: para operar relacionamento comercial

EspoCRM é a escolha quando a empresa precisa que o processo comercial tenha estrutura própria. A pesquisa confirma recursos de leads, contas, contatos, oportunidades, atividades, e-mail e suporte. Essa categoria reduz a necessidade de improvisar entidades e estágios que já pertencem ao trabalho de vendas e atendimento.

Nos requisitos de servidor do EspoCRM, o projeto lista Apache, Nginx ou IIS; PHP de 8.3 a 8.5; MySQL 8+, MariaDB 10.3+ ou PostgreSQL 15. Há também instalação oficial com Docker, MariaDB e caminhos para Docker Compose, Traefik e Caddy.

Isso não elimina a responsabilidade operacional. Um CRM especializado evita construir o funil manualmente. Ainda assim, alguém precisa atualizar a aplicação, cuidar do banco, restringir acessos e recuperar o ambiente quando necessário.

O que a VPS realmente assume por baixo da interface

Quando o software é auto-hospedado, o servidor passa a sustentar mais do que uma página web. A aplicação depende de dados, credenciais, processos de fundo e caminho de recuperação. Docker Compose facilita empacotar serviços. Ele não substitui TLS, política de acesso, backup ou monitoramento.

Camada

Baserow

NocoDB

EspoCRM

O que verificar

Aplicação

Interface e serviços do Compose

App principal

Aplicação CRM em PHP ou Docker

Versão usada e rota de atualização

Banco

PostgreSQL no desenho documentado

PostgreSQL na stack Docker

MySQL, MariaDB ou PostgreSQL suportados

Dados persistentes e credenciais

Cache ou worker

Redis no desenho observado

Redis e worker documentados

Cron conforme caminho de instalação

Processos de fundo e consumo de recursos

Arquivos

Dados e configuração precisam sobreviver

Volumes nomeados documentados

Anexos, logs e configuração exigem planejamento

Disco, permissões e cópia externa

Entrada segura

Não vem pronta pela escolha do container

Não vem pronta pela escolha do container

Webserver ou proxy faz parte do ambiente

Domínio, HTTPS e contas administrativas

Recuperação

Backup e restore são responsabilidades externas

Volume não substitui cópia externa

Banco e arquivos precisam de recuperação planejada

Restore testado, não apenas snapshot

Uma stack concreta de NocoDB ilustra a diferença: aplicação, worker, PostgreSQL, Redis e volumes persistentes ficam no mesmo ambiente Docker. É uma composição viável para começar. Ela também concentra disputa por CPU, RAM, disco e atenção operacional na mesma VPS.

No Baserow, os segredos obrigatórios e a presença de PostgreSQL e Redis mostram cenário parecido. No EspoCRM, PHP, banco, servidor web ou Docker compõem o ambiente. As peças mudam, mas a pergunta permanece: quem responde quando uma atualização falha ou os dados precisam voltar?

CPU, RAM e disco: por que não existe plano mágico

É tentador procurar uma resposta como “qual VPS o Baserow precisa?”. A documentação não sustenta uma tabela honesta de usuários por plano. O guia de deploy do Baserow cita 1 vCPU e 2 GB para um container. Não é a dimensão total de uma máquina que também executa banco, Redis, uploads e backup.

No EspoCRM, memory_limit = 256M é uma recomendação para o PHP. Não é RAM total da VPS. O sistema ainda precisa acomodar sistema operacional, banco, webserver, cron, anexos e logs. No NocoDB, a pesquisa não encontrou uma tabela oficial de recursos por quantidade de usuários.

Por isso, a compra deve seguir a pilha real, não o nome da ferramenta. Comece com a arquitetura declarada, estime o espaço para dados e arquivos, e deixe margem para os serviços que convivem no host. Depois acompanhe consumo e revise a capacidade com dados do seu ambiente.

A documentação do EspoCRM recomenda considerar VPS ou servidor dedicado para produção e alerta que hospedagem compartilhada pode impor limitações. Isso não informa desempenho, SLA, localização ou capacidade de um provedor específico. É apenas um sinal de que uma aplicação comercial não deve depender de recursos indefinidos.

O custo invisível: atualização, backup e restore

O software pode estar disponível para auto-hospedagem. A operação não é gratuita por definição. O custo aparece em VPS, domínio, HTTPS, disco, cópia externa, atualização, investigação de falhas e tempo de quem assume a manutenção.

O NocoDB documenta atualização com pull e recriação da composição. A recomendação responsável não é usar latest como política. Antes de atualizar, confira a mudança, faça backup e teste em ambiente apropriado quando o sistema guardar dados comerciais.

No EspoCRM, a instalação Docker documenta um caminho com MariaDB. No Baserow, a instalação exige segredos. Esses fatos não garantem segurança, disponibilidade ou recuperação. Eles deixam claro que há estado persistente para proteger.

Snapshot no mesmo provedor também não deve ser tratado como única cópia. A pergunta útil não é “tenho backup?”. É “consigo restaurar banco, arquivos e configuração de modo verificável?”. Sem esse teste, o backup é uma hipótese.

Evite prometer LGPD, residência de dados ou segurança absoluta só porque o serviço roda em uma VPS. Essas conclusões dependem de configuração, fornecedores, acesso, processo interno e avaliação específica. O mesmo vale para SMTP, WhatsApp, entregabilidade e integrações: não assuma que estão resolvidos sem documentação e teste do cenário concreto.

Quando SaaS ganha da VPS

SaaS não é derrota técnica. Ele pode ser a escolha racional quando a equipe precisa de um CRM funcionando, mas não tem alguém para manter banco, Docker, atualizações e recuperação. A mensalidade pode comprar previsibilidade operacional que uma economia aparente não entrega.

Situação

Escolha mais coerente

Risco se ignorar

Você modela uma base nova e aceita operar a pilha

Baserow em VPS

Comprar infraestrutura sem rotina de manutenção

Seus dados SQL já existem e precisam de interface

NocoDB em VPS

Duplicar dados ou criar fluxo visual sem responsável

O processo é vendas, oportunidades e atendimento

EspoCRM em VPS

Construir um CRM manual onde um CRM especializado seria mais direto

Ninguém é dono de backup, update e restore

SaaS ou oferta hospedada

Transformar uma economia em indisponibilidade operacional

A equipe precisa de suporte operacional previsível

SaaS ou serviço gerenciado

Assumir uma pilha que não consegue recuperar

A decisão não deve ser pelo produto “mais completo”. Baserow serve para criar a base. NocoDB serve para expor e controlar dados SQL. EspoCRM serve para estruturar relacionamento comercial. A auto-hospedagem só ganha quando esse controle é útil e tem dono.

Qual VPS faz sentido depois da escolha?

Se você já definiu a categoria e aceitou manter banco, atualização e restore, vale comparar uma VPS para hospedar a base ou CRM. A oferta de VPS da Turbo Cloud no Runzos é o CTA principal para essa etapa.

Também há alternativas de infraestrutura no Runzos: VPS Hostinger e VPS Servla. Compare a oferta atual antes de contratar. Este artigo não afirma preço, cupom, hardware, suporte, localização, SLA ou backup de nenhum plano.

FAQ

Baserow e NocoDB são CRM?

Não por padrão. Baserow é uma plataforma para construir base e interfaces. NocoDB é uma camada visual sobre dados SQL. Ambos podem apoiar fluxos comerciais modelados pela equipe, mas a pesquisa não confirma que substituam automaticamente um CRM especializado.

Qual a diferença entre Baserow e NocoDB?

Baserow é mais indicado para criar uma base operacional nova e apps no-code. NocoDB se encaixa quando o banco SQL já é parte da operação e precisa de uma interface visual, worker, automações e controle de dados.

EspoCRM pode usar PostgreSQL?

Sim. A configuração de servidor do EspoCRM lista PostgreSQL 15 entre os bancos suportados. Ela também lista MySQL 8+ e MariaDB 10.3+.

Qual VPS o Baserow precisa?

Não há uma recomendação universal confirmada para VPS completa. O Baserow cita 1 vCPU e 2 GB de RAM para um container em um guia específico. Banco, Redis, arquivos e cópia externa precisam entrar no cálculo da pilha real.

NocoDB precisa de PostgreSQL e Redis?

O instalador Docker documentado gera uma stack com NocoDB, worker, PostgreSQL e Redis. PostgreSQL guarda metadados e dados. Redis atende cache e fila nesse desenho.

EspoCRM precisa de Docker?

Não necessariamente. A documentação lista requisitos de webserver, PHP e bancos suportados. Ela também oferece um caminho oficial de instalação com Docker e MariaDB.

Posso rodar app, banco e backup na mesma VPS?

Você pode concentrar componentes no mesmo host, mas isso não torna a cópia independente. Volumes persistentes não substituem backup externo. Restore precisa ser testado antes de ser considerado um plano de recuperação.

Quando SaaS é melhor que CRM ou base auto-hospedada?

Quando ninguém consegue assumir atualização, acesso, banco, backup e restore. Nesse cenário, a mensalidade pode custar menos do que a manutenção invisível de uma operação que guarda leads e dados comerciais.

Conclusão: hospede uma operação, não a promessa de software grátis

A melhor escolha começa antes da VPS. Use Baserow para construir uma base nova. Escolha NocoDB para trabalhar sobre SQL. Prefira EspoCRM quando o processo comercial precisa de estrutura própria.

Depois, aplique a regra de categoria antes de container. Uma VPS vale o esforço quando controle e economia não escondem uma operação sem responsável. Se você aceita esse compromisso, compare uma VPS para a sua stack no Runzos. Se não aceita, SaaS continua sendo uma decisão técnica sensata.

BaserowNocoDBEspoCRMVPSCRM open-sourceself-hosted

Compartilhe:

Leia também