Penpot self-hosted no Brasil: VPS sem gargalo

Resposta direta

Para rodar Penpot self-hosted no Brasil com boa experiência para designers e times de produto, escolha uma VPS ou Cloud Server com pelo menos 2 vCPUs, 4 GB de RAM, 60 GB de SSD, Docker, PostgreSQL persistente, HTTPS válido e backup testado. Para produção com vários usuários simultâneos, o ponto de partida mais seguro costuma ser 4 vCPUs, 8 GB de RAM e 100 GB de SSD ou NVMe, além de monitoramento de CPU, memória, disco e conexões em tempo real. A localização do datacenter pesa bastante: servidores no Brasil reduzem latência para colaboração, abertura de arquivos e sincronização de alterações. Se o provedor não tiver região brasileira, Miami pode ser aceitável, mas precisa ser testada com usuários reais antes de virar padrão.

Resumo rápido

• Penpot self-hosted combina aplicação web, backend, PostgreSQL, Redis, assets persistentes e comunicação em tempo real.
• Para laboratório, 2 vCPUs, 4 GB de RAM e 60 GB de SSD já permitem validar fluxos reais com Docker.
• Para produção, 4 vCPUs, 8 GB de RAM e 100 GB de disco reduzem risco de swap, lentidão e falhas em uploads.
• PostgreSQL não deve ficar sem backup, snapshot e rotina de restauração testada.
• HTTPS é obrigatório para login, sessão, cookies seguros e uso confiável no navegador.
• Datacenter no Brasil melhora a latência percebida por designers, PMs e desenvolvedores trabalhando juntos.
• WebSocket e proxy reverso precisam de timeouts corretos para colaboração em tempo real.
• Preços, regiões, storage e recursos de provedores devem ser verificados nas páginas oficiais antes da contratação.

O que muda ao hospedar Penpot por conta própria

Hospedar Penpot por conta própria é diferente de instalar um site institucional em uma VPS simples. O Penpot é uma ferramenta de design colaborativo, com interface pesada no navegador, autenticação, arquivos de projeto, comentários, bibliotecas compartilhadas e sincronização entre pessoas. Na prática, ele se comporta mais como uma aplicação SaaS interna do que como um blog. Isso muda o jeito de escolher servidor, configurar Docker, proteger dados e planejar crescimento.

Penpot não é só mais uma aplicação web

Em uma instalação típica, o Penpot roda com múltiplos serviços. Você terá containers para frontend, backend, exportação, banco PostgreSQL e, em muitas composições, Redis ou serviços auxiliares. O PostgreSQL guarda boa parte dos dados estruturados, como usuários, equipes, projetos e metadados. Os arquivos e assets precisam de armazenamento persistente. Se você derruba os volumes por engano em uma atualização de Docker Compose, pode perder mais do que uma configuração. Pode perder trabalho de design.

Esse é o motivo para tratar o ambiente como produção desde cedo. Mesmo em um time de cinco pessoas, uma instância Penpot pode virar repositório central de telas, componentes, protótipos e decisões de produto. Um servidor mal dimensionado afeta diretamente a rotina: telas demoram a abrir, exports falham, uploads travam e sessões colaborativas ficam instáveis. Se a equipe já usa Docker para outros serviços, vale cruzar este artigo com o guia de VPS para Docker, porque os mesmos cuidados com volumes, logs, rede interna e restart policy aparecem aqui.

Quando self-hosted faz sentido

O modelo self-hosted faz sentido quando a empresa quer controle sobre dados, integrações internas, requisitos de compliance ou previsibilidade operacional. Agências que atendem clientes sensíveis, startups que preferem manter artefatos de produto em infraestrutura própria e equipes públicas ou educacionais podem se beneficiar bastante. Também existe o fator cultura: alguns times querem uma alternativa open source ao Figma sem depender totalmente de um serviço externo.

Mas esse controle cobra uma conta operacional. Alguém precisa atualizar imagens, acompanhar releases, revisar logs, renovar certificados, testar backup e monitorar disco. Se ninguém no time sabe administrar Linux, Docker e banco de dados, a economia aparente pode sair cara. O melhor cenário é ter um responsável técnico claro, mesmo que seja meio período, e documentar comandos básicos: como subir o stack, como restaurar backup, como checar uso de disco e como reiniciar serviços sem apagar volumes.

Requisitos de VPS para Penpot self-hosted no Brasil

O dimensionamento de VPS para Penpot self-hosted no Brasil deve começar pelo perfil de uso, não pelo menor plano disponível. Uma instalação vazia consome pouco, mas o consumo cresce com usuários simultâneos, tamanho dos arquivos, número de equipes, uploads, exports e rotinas de backup. O erro comum é escolher 1 vCPU e 1 GB de RAM porque o ambiente subiu no primeiro teste. Ele sobe, mas não necessariamente aguenta uma semana real de trabalho.

CPU, RAM e disco para começar sem sufoco

Para validação técnica, 2 vCPUs e 4 GB de RAM formam um ponto de partida honesto. Essa configuração permite rodar Docker, Penpot, PostgreSQL e serviços auxiliares sem depender o tempo todo de swap. Em produção pequena, com 5 a 15 usuários ativos e alguns projetos, 4 vCPUs e 8 GB de RAM dão mais margem para picos de uso, builds de assets, exports e consultas do banco. Se o time trabalha com muitos arquivos pesados, bibliotecas compartilhadas e histórico longo, pense em 100 GB de disco desde o início.

O disco precisa ser tratado com cuidado. SSD já é aceitável para muitos cenários, mas NVMe pode ajudar quando há mais I/O, muitos assets e banco sob carga. Ainda assim, disco rápido não compensa banco mal mantido, logs infinitos ou backup inexistente. Reserve espaço para o sistema, imagens Docker, volumes, dumps do PostgreSQL e snapshots. Uma VPS com 60 GB pode parecer grande no primeiro dia, mas logs, imagens antigas e backups locais enchem rápido. Em produção, configure rotação de logs e não deixe dumps acumularem sem política de retenção.

Rede e latência para colaboração em tempo real

A localização do datacenter pesa mais no Penpot do que em uma aplicação administrativa comum. Designers interagem com canvas, componentes, comentários e atualizações frequentes. Uma latência de 10 a 30 ms no Brasil costuma ser percebida de forma muito diferente de 140 a 180 ms para regiões distantes, especialmente quando várias pessoas editam ou revisam o mesmo projeto. Não significa que um servidor fora do Brasil seja inviável, mas significa que a experiência precisa ser medida.

Provedores com presença no Brasil ou opções próximas, como Miami, podem entrar na análise, mas região, disponibilidade de plano, tipo de disco, bandwidth e preço mudam com frequência. LetsCloud pode ser avaliada quando a prioridade é infraestrutura próxima do público brasileiro, mas recursos como NVMe, snapshots, backup automático e localidades precisam ser confirmados por plano antes de qualquer decisão. DigitalOcean, Vultr, AWS Lightsail, Linode ou Akamai, Hetzner e outros provedores também podem atender dependendo da região escolhida, do orçamento e da maturidade operacional do time. Dados comerciais de concorrentes foram considerados como voláteis e exigem revisão humana antes de publicação comparativa de preço.

Docker, PostgreSQL e armazenamento persistente

Penpot self-hosted normalmente é implantado via Docker Compose, o que simplifica o primeiro deploy, mas não elimina responsabilidade operacional. O Compose ajuda a organizar containers, redes, variáveis e volumes. O problema aparece quando o time trata container como se fosse dado persistente. Container pode ser recriado. Volume de banco e volume de assets não podem desaparecer. Essa separação mental evita boa parte dos acidentes.

Separar aplicação, banco e arquivos

Uma configuração saudável mantém os dados do PostgreSQL em volume nomeado ou diretório persistente, com backup externo. O mesmo vale para assets, uploads e arquivos gerados. Em um exemplo simples, você pode ter volumes como penpot_postgres_data, penpot_assets e penpot_redis_data, além de uma pasta /opt/penpot para o Compose e arquivos de ambiente. O arquivo .env deve ficar fora do repositório público e nunca deve conter chaves expostas em documentação interna aberta.

Para PostgreSQL, pense além de subir o container. Defina usuário, senha forte, banco dedicado, locale adequado e uma rotina de dump. Um exemplo prático de backup diário é executar pg_dump dentro do container, salvar em diretório temporário, compactar e enviar para um storage externo. Não basta ter dump local no mesmo disco da VPS. Se o disco falhar, você perde servidor e backup ao mesmo tempo. Para aprofundar essa parte, o guia de VPS para banco PostgreSQL ajuda a dimensionar memória, disco, conexões e rotina de manutenção para bancos em produção.

Cuidados com volumes e upgrades

Antes de atualizar o Penpot, faça snapshot da VPS quando disponível, dump do PostgreSQL e cópia dos volumes críticos. Depois, leia as notas da versão. Parece burocrático, mas evita transformar uma atualização simples em indisponibilidade de horas. Em ambientes pequenos, uma janela de manutenção de 30 minutos fora do horário comercial já resolve. Em ambientes maiores, teste primeiro em uma cópia com dados anonimizados ou em uma instância staging.

Também vale controlar o crescimento dos logs. Docker pode ocupar dezenas de gigabytes se o driver de logs ficar sem limite. Uma configuração comum é limitar logs JSON por container com tamanho máximo e quantidade de arquivos, por exemplo 10 MB por arquivo e 3 rotações. Use docker system df para medir imagens, volumes e cache, mas tenha cuidado com comandos de limpeza agressivos. Nunca rode limpeza de volumes sem saber exatamente o que está removendo. No Penpot, um docker volume prune executado no servidor errado pode apagar dados persistentes.

HTTPS, domínio, firewall e operação segura

Penpot deve rodar com HTTPS em qualquer ambiente usado por pessoas reais. Sem TLS, você abre margem para problemas de sessão, cookies inseguros, bloqueios no navegador e exposição de credenciais em redes não confiáveis. O básico é apontar um domínio, configurar proxy reverso com Nginx, Caddy ou Traefik e emitir certificado via Let’s Encrypt. Em times pequenos, Caddy costuma ser prático porque automatiza certificados. Em ambientes com mais serviços, Traefik pode fazer sentido pela integração com Docker.

TLS obrigatório para uso real

Um exemplo comum é expor o Penpot em design.suaempresa.com.br, com proxy na porta 443 encaminhando tráfego para o container interno. O proxy precisa preservar cabeçalhos como Host, X-Forwarded-Proto e X-Forwarded-For, além de suportar conexões longas quando houver recursos em tempo real. Se o Penpot gerar URLs internas com HTTP em vez de HTTPS, revise variáveis de ambiente ligadas ao domínio público e ao esquema de URL. Esse tipo de erro aparece em login, callback, imagens quebradas ou redirecionamentos estranhos.

Certificados também precisam de monitoramento. Let’s Encrypt renova automaticamente, mas só se as portas, DNS e permissões estiverem corretos. Uma regra simples é criar alerta para expiração em menos de 15 dias. Outra prática útil é manter um endpoint de health check, mesmo que básico, para detectar indisponibilidade antes dos designers abrirem chamado no meio de uma reunião com cliente.

Hardening básico do servidor

A VPS não deve ficar exposta como veio do provedor. Crie usuário sem root para operação diária, use chave SSH, desative login por senha quando possível e mantenha firewall liberando apenas portas necessárias: 22 para SSH restrito por IP quando viável, 80 para emissão e renovação de certificados, 443 para acesso web. O PostgreSQL não precisa ficar público na internet se roda em Docker no mesmo host. Redis também não deve ser exposto externamente.

Backups merecem teste, não só configuração. Uma rotina aceitável inclui dump diário do PostgreSQL, retenção de 7 a 14 dias, cópia externa e restauração validada pelo menos uma vez por mês. Para equipes com clientes, registre o tempo de restauração esperado. Se a instância cair às 10h, o time precisa saber se volta em 15 minutos, 1 hora ou meio dia. Essa clareza muda a escolha do provedor, do plano e da arquitetura.

Tabela comparativa de perfis e recursos

A tabela abaixo não compara preços, porque valores, promoções, bandwidth e regiões mudam com frequência e exigem revisão humana antes da publicação. A ideia é traduzir perfis de uso em recursos mínimos recomendados para Penpot self-hosted. Use como ponto de partida técnico, depois valide com métricas reais de CPU, memória, disco e latência durante uma semana de uso.

Como ler a tabela sem cair no subdimensionamento

O menor perfil serve para laboratório e prova de conceito, não para centralizar o trabalho de uma equipe inteira. Se o Penpot será usado diariamente por designers, PMs, desenvolvedores e stakeholders, trate como aplicação crítica. O gargalo mais comum em planos pequenos é memória, principalmente quando PostgreSQL, backend, frontend, proxy e rotinas de backup disputam o mesmo host. Quando a memória acaba, o sistema começa a usar swap, e a experiência degrada rápido.

Perfil de uso	Usuários simultâneos	Configuração recomendada	Disco e backup	Observações práticas
Laboratório ou dev solo	1 a 3	2 vCPUs, 4 GB RAM	60 GB SSD, dump manual e snapshot antes de upgrades	Bom para testar Docker Compose, domínio, login e importação de arquivos pequenos
Time pequeno de produto	5 a 15	4 vCPUs, 8 GB RAM	100 GB SSD ou NVMe, backup diário externo	Indicado para uso diário, bibliotecas compartilhadas e reuniões de revisão
Agência ou produto em produção	15 a 40	4 a 8 vCPUs, 16 GB RAM	160 GB ou mais, backup diário, retenção e restauração testada	Melhor separar staging, monitoramento e política clara de manutenção
Ambiente com compliance interno	variável	8 vCPUs, 16 GB RAM ou mais	Storage com criptografia, retenção definida e cópia externa	Exige controle de acesso, logs, processo de atualização e documentação operacional

Se a equipe crescer, não aumente plano no escuro. Primeiro veja métricas. CPU alta por poucos segundos durante export pode ser normal. Memória sempre acima de 85 por cento, swap ativa e disco chegando a 80 por cento pedem ação rápida. No PostgreSQL, observe conexões, tamanho do banco, tempo de queries e crescimento dos dumps. No Docker, acompanhe docker stats, uso de volumes e logs. Em Cloud Server, upgrade vertical costuma ser mais simples, mas confirme se exige reboot e se o disco pode ser expandido sem migração complexa.

Colaboração em tempo real e gargalos comuns

A colaboração em tempo real é uma das partes que mais muda a percepção de qualidade. O usuário não pensa em CPU, proxy ou WebSocket. Ele percebe atraso no cursor, comentário que demora a aparecer, projeto que fica carregando ou queda durante uma revisão. Por isso, a escolha da VPS para Penpot self-hosted no Brasil precisa considerar rede e conexões longas, não apenas armazenamento e banco.

WebSocket, proxy reverso e timeouts

Aplicações colaborativas costumam depender de conexões persistentes ou padrões parecidos com WebSocket, long polling e eventos assíncronos. O proxy reverso precisa respeitar isso. Em Nginx, por exemplo, configurações de proxy_read_timeout, proxy_send_timeout, cabeçalhos de upgrade e buffers podem afetar sessões longas. Se o proxy encerra conexões rápido demais, usuários veem instabilidade mesmo com CPU sobrando. O artigo sobre VPS para WebSocket e aplicações em tempo real aprofunda esse ponto, especialmente para quem também hospeda chats, dashboards e ferramentas colaborativas.

Também existe o papel da latência. Um time todo em São Paulo acessando um servidor na Europa terá experiência diferente de acessar uma região brasileira ou próxima. Para validar, rode testes simples com ping, mtr e carregamento real no navegador. Não fique só no benchmark sintético. Abra um arquivo grande, convide duas ou três pessoas, editem simultaneamente, façam comentários e exportem assets. Esse teste revela gargalos que números isolados não mostram.

Onde monitorar antes de aumentar plano

Quando o Penpot fica lento, a primeira reação costuma ser trocar para um plano maior. Às vezes resolve, mas nem sempre. Antes disso, verifique quatro pontos: memória, disco, banco e proxy. Se a RAM está no limite, aumentar para 8 GB ou 16 GB pode ser o caminho. Se o disco está cheio por logs, um plano maior só adia o problema. Se o PostgreSQL está sem manutenção, o gargalo pode estar em consultas, conexões ou I/O. Se o proxy está com timeout baixo, não adianta comprar mais CPU.

Um painel simples com Netdata, Prometheus com Grafana ou métricas do provedor já ajuda. Configure alertas para CPU sustentada acima de 80 por cento, memória acima de 85 por cento, disco acima de 75 por cento e falhas HTTP 5xx. Em produção, registre incidentes. Uma planilha com data, sintoma, métrica e correção já cria histórico suficiente para decidir se é hora de escalar, separar banco em outro servidor ou ajustar configuração.

Recomendações por perfil

A melhor VPS para Penpot self-hosted no Brasil depende de quem usa, da criticidade dos arquivos e da capacidade do time de operar infraestrutura. Um designer solo testando alternativa ao Figma não precisa da mesma arquitetura de uma agência com 30 pessoas e clientes ativos. A recomendação abaixo separa perfis para evitar dois erros comuns: gastar demais antes de validar o uso ou economizar demais em uma ferramenta que vira central para o produto.

Dev solo ou laboratório

Para um dev solo, designer técnico ou laboratório interno, comece com 2 vCPUs, 4 GB de RAM e 60 GB de SSD. Use Docker Compose, domínio próprio, HTTPS e backup manual antes de cada atualização. Esse perfil serve para testar login, criação de equipes, importação de arquivos, bibliotecas e export. Não coloque projetos críticos de cliente aqui. Se o objetivo é aprender, documente os comandos básicos em um README privado: subir stack, parar stack, ver logs, fazer dump do PostgreSQL e restaurar em uma VPS nova.

Time pequeno de produto

Para um time de 5 a 15 pessoas, escolha 4 vCPUs, 8 GB de RAM e 100 GB de SSD ou NVMe quando disponível no plano. Aqui o Penpot já entra no fluxo diário, então backup externo e monitoramento deixam de ser opcionais. Configure proxy reverso com HTTPS, alerte expiração de certificado e acompanhe memória, disco e erros 5xx. Se a equipe está no Brasil, priorize datacenter nacional ou região próxima validada por teste real. LetsCloud pode entrar na lista quando baixa latência local for prioridade, mas confirme storage, backup, snapshots e localidades no site oficial antes da contratação.

Produção com clientes e múltiplos projetos

Para agência, software house ou produto com muitos stakeholders, use 4 a 8 vCPUs, 16 GB de RAM e 160 GB ou mais de disco, com retenção de backup, restauração testada e janela de manutenção definida. Considere separar staging da produção para testar upgrades do Penpot antes de aplicar no ambiente principal. Se o volume de dados crescer ou o PostgreSQL virar gargalo, avalie banco separado, storage externo para assets e política de arquivamento de projetos antigos. O objetivo não é montar uma arquitetura complexa no primeiro dia, mas impedir que uma ferramenta de design vire ponto único de falha sem plano de recuperação.