Como instalar o PocketBase numa VPS com HTTPS e dados persistentes

Fala aí, beleza? Pra colocar o PocketBase na VPS com HTTPS, tu envia um único executável pro servidor (ele não precisa de dependências externas) e roda o comando serve passando o seu domínio

O próprio PocketBase emite o certificado Let’s Encrypt e passa a atender nas portas 80 e 443, sem tu configurar certificado na mão 🙂

Um serviço systemd mantém o processo no ar e reinicia sozinho, e a pasta pb_data guarda os dados da aplicação, incluindo os uploads enviados pelos usuários, então é ela que precisa ser persistida e entrar no backup

O cenário aqui é uma instância nova, com acesso root e domínio próprio

Só fica o alerta: o projeto mudou de casa e ainda está antes da v1.0.0, então pra sistema crítico o risco precisa ser pesado com calma

Avisos atuais do projeto PocketBase antes de ir para produção

O aviso mais importante é que o PocketBase mudou de casa, e isso muda de onde tu baixa o executável

O repositório pocketbase/pocketbase no GitHub foi arquivado e ficou só leitura em 26/10/2026 (anúncio na issue do repositório)

A v0.40.6, publicada em 23/10/2026, foi a última versão lançada ali, e as notas dessa versão já avisavam que ela provavelmente seria a última no GitHub

O desenvolvimento passou pra ganigeorgiev.com/pocketbase, e o mantenedor informou que não vai ter espelho mantido no GitHub

Quem acompanhava releases ou atualizações de segurança precisa se inscrever de novo nesse novo endereço

O comando ./pocketbase update passou a buscar novas versões em ganigeorgiev.com

E tem mais: o projeto continua em desenvolvimento ativo e não garante compatibilidade total com versões anteriores antes da v1.0.0

Na prática, isso pede três cuidados:

• fixar a versão que tu está usando
• ler as notas da versão ANTES de atualizar
• avaliar o risco com calma se o sistema for crítico

Os passos de produção abaixo seguem o guia oficial Going to production

O que você precisa antes de instalar o PocketBase na VPS

Tu precisa de quatro coisas: VPS com root, domínio, executável oficial e um servidor SMTP

• VPS com acesso root: o exemplo oficial roda o processo como root pra conseguir usar as portas 80 e 443, que são privilegiadas. Usuário sem root normalmente precisa de permissões especiais pra isso
• Um domínio seu: é o valor que tu passa pro serve, e é pra ele que o Let’s Encrypt emite o certificado
• O executável do PocketBase: obtido na fonte oficial atual, em ganigeorgiev.com
• Um servidor SMTP: a documentação recomenda usar um pros e-mails da aplicação

Pra esse projeto, a recomendação principal da Hora de Codar é a VPS da Hostinger (este artigo contém links de afiliado da Hostinger)

O motivo é técnico, ligado a cada etapa do tutorial:

• Acesso root: é o que permite usar as portas 80 e 443 e criar o serviço systemd do jeito que a documentação mostra
• SSD NVMe e processadores AMD EPYC: é nesse disco e nesse processador que o PocketBase grava e lê os arquivos da pasta pb_data, incluindo os uploads dos usuários
• Backups semanais automáticos: restauram o servidor inteiro pelo painel e complementam o backup do pb_data, sem substituir ele

Que diferença tem um do outro?

O backup semanal automático volta o servidor todo pra um ponto no tempo, já o backup do pb_data é o teu dado da aplicação, que tu consegue guardar fora do servidor e restaurar onde quiser

Passo a passo: PocketBase com HTTPS automático e systemd

O caminho é: executável em /root/pb, primeira execução com o domínio, serviço systemd, criptografia das configurações e ajustes no painel

Bora ver na prática?

Passo 1: enviar o executável para o servidor

Envie o executável do PocketBase pra pasta /root/pb, a mesma usada no exemplo oficial

Como ele é portátil, publicar é basicamente isso: o arquivo no servidor, sem instalar dependência nenhuma

Resultado esperado: o executável em /root/pb/pocketbase

Erro comum deste passo: pegar o binário no repositório arquivado do GitHub e ficar parado na v0.40.6, sem as correções que agora saem só em ganigeorgiev.com

Passo 2: primeira execução com HTTPS automático

Rode o serve passando o seu domínio no lugar de yourdomain.com:

/root/pb/pocketbase serve yourdomain.com

Resultado esperado: o PocketBase emite sozinho o certificado Let’s Encrypt pra esse domínio e passa a servir HTTPS

Erro comum deste passo: rodar com um usuário sem permissão pras portas 80 e 443

Como elas são portas privilegiadas, sem root (ou sem as permissões especiais) o HTTPS automático não sobe

Passo 3: criar o serviço systemd

Rodar no terminal na mão funciona, mas fechou a sessão SSH, já era…

O systemd resolve isso: inicia o PocketBase com o servidor e reinicia o processo se ele cair

Crie o arquivo /lib/systemd/system/pocketbase.service copiando o modelo completo do guia oficial

As diretivas do serviço nesse exemplo são estas:

Type             = simple
User             = root
Group            = root
LimitNOFILE      = 4096
Restart          = always
RestartSec       = 5s
StandardOutput   = append:/root/pb/std.log
StandardError    = append:/root/pb/std.log
WorkingDirectory = /root/pb
ExecStart        = /root/pb/pocketbase serve yourdomain.com

Tome cuidado! Copie o arquivo inteiro do guia, com os cabeçalhos de seção, e troque só o yourdomain.com pelo teu domínio

E o que é esse LimitNOFILE?

No Unix, conexões de rede também usam descritores de arquivo, e o limite padrão costuma ficar perto de 1024

A documentação marca esse ajuste como opcional, útil quando há muitas conexões realtime (diferente do SMTP e do rate limiter, que ela classifica como "altamente recomendados"). O LimitNOFILE = 4096 faz esse ajuste dentro do serviço (fora do systemd, a alternativa citada é ulimit -n 4096)

Agora ative e inicie o serviço:

systemctl enable pocketbase.service
systemctl start pocketbase

Resultado esperado: o PocketBase rodando como serviço, com saída e erros indo pro /root/pb/std.log

Erro comum deste passo: rodar só o start e esquecer o enable

Aí funciona hoje, mas o serviço não volta sozinho depois de um reboot da VPS

Passo 4: criptografar as configurações

Esse passo é opcional e protege as configurações da aplicação caso alguém tenha acesso ao arquivo do banco, por exemplo num backup guardado fora do servidor

Crie uma variável de ambiente com uma string aleatória de 32 caracteres e inicie o PocketBase com a flag --encryptionEnv apontando pro nome dela:

pocketbase serve --encryptionEnv=PB_ENCRYPTION_KEY

Como tu já tem o serviço systemd, o comando que ele executa precisa receber essa flag e enxergar a variável

Tome cuidado! Essa chave precisa ficar guardada em lugar seguro e separado do backup, senão a proteção perde o sentido

Passo 5: configurar SMTP e rate limiter no painel

Na interface de administração, configure o servidor SMTP em Settings > Mail settings, como a documentação recomenda

Aproveite e ative o limitador de requisições (rate limiter) embutido nas configurações, também classificado como altamente recomendado

Os valores dependem do teu SMTP e do tráfego da tua aplicação, então não tem número mágico aqui

Passo 6: checar se está tudo no ar

Pra validar, confira duas coisas:

• o log em /root/pb/std.log, procurando erros na subida do serviço ou na emissão do certificado
• o acesso ao seu domínio pelo navegador com https://

Se o log está limpo e o domínio abre com HTTPS, a base está pronta 😀

Como garantir dados persistentes e montar o plano de backup do pb_data

Tudo que importa mora no pb_data, incluindo os arquivos enviados pelos usuários

Perdeu essa pasta, perdeu a aplicação, então o backup precisa girar em torno dela

Opção A: backup embutido do PocketBase

O painel tem backups embutidos em Settings > Backups, guardados localmente (padrão) ou num armazenamento compatível com S3, de preferência num bucket separado

O limite: durante esse backup embutido o desempenho pode cair um pouco e algumas consultas podem demorar mais

E quando o pb_data fica grande (o exemplo citado na documentação é 5 GB ou mais), a recomendação é partir pra outra estratégia, como um script combinando sqlite3 .backup e rsync

Opção B: cópia manual do pb_data

Tu também pode copiar o pb_data manualmente

Pra garantir segurança transacional, o PocketBase precisa estar parado durante a cópia, e com o serviço que tu já criou fica assim:

systemctl stop pocketbase
# copie a pasta pb_data para o destino do seu backup
systemctl start pocketbase

Erro comum: copiar o pb_data com o processo rodando

A cópia até termina, mas sem a garantia transacional que a documentação pede

Plano em camadas

Um plano que faz sentido pra maioria dos casos combina:

• backup do pb_data guardado fora do servidor (o S3 do backup embutido serve pra isso)
• os backups semanais automáticos da VPS da Hostinger, que restauram o servidor inteiro pelo painel
• a chave do --encryptionEnv guardada separada dos dois, se tu optar por usar essa criptografia opcional

Como verificar: depois do primeiro backup, confira se o arquivo apareceu no local configurado em Settings > Backups: localmente ou no bucket S3 definido lá

E faça o teste de restauração antes de precisar dele de verdade, backup que nunca foi restaurado é só esperança haha

Quando usar proxy reverso ou Docker em vez do HTTPS embutido

O HTTPS embutido resolve o caso simples: uma aplicação, um domínio, um servidor

Fora disso, vale olhar pra proxy reverso ou Docker, conforme o cenário

Proxy reverso (NGINX, Apache ou Caddy)

Faz sentido quando tu quer hospedar várias aplicações no mesmo servidor ou ter controles de rede mais finos

Nesse modelo, o proxy reverso fica na frente recebendo o tráfego externo, e o exemplo oficial de NGINX encaminha as requisições pra http://127.0.0.1:8090, então cabe a ti configurar o PocketBase pra responder nesse endereço local. Pode ser preciso configurar os "User IP proxy headers" no PocketBase para que ele veja o IP real dos visitantes

No NGINX, por exemplo, o encaminhamento usa:

proxy_pass http://127.0.0.1:8090;

Repara que esse exemplo oficial mostra só o encaminhamento pra porta 8090, sem detalhar certificado nessa configuração. Se tu optar por esse modelo em vez do HTTPS automático que o PocketBase emite quando roda direto com o domínio, o TLS normalmente precisa ser configurado seguindo a documentação do próprio proxy escolhido (NGINX, Apache ou Caddy)

Docker

Com Docker, os dados só persistem se tu montar um volume no diretório pb_data do container

No exemplo oficial, esse diretório é /pb/pb_data e o comando do container é /pb/pocketbase serve --http=0.0.0.0:8080

Erro comum: subir o container sem volume

Funciona lindo até o dia que tu recria o container e o banco e os uploads somem junto 😛

Quer ver como é subir um serviço numa VPS na prática? Nesse vídeo é o n8n que vai pro servidor:

E se o teu caso é rodar automações com orçamento curto, tem um guia de como instalar n8n numa VPS barata pra pequenos projetos

Próximo passo depois de colocar o PocketBase no ar

Com o HTTPS respondendo, a primeira tarefa é agendar o backup hoje mesmo: embutido com S3 se o pb_data é pequeno, cópia com o serviço parado se ele já passou do tamanho em que o ZIP atrapalha

Depois, se tu usou a criptografia opcional, guarde a chave fora do servidor e anote a versão que está rodando

Antes de qualquer atualização, confira versões e correções em ganigeorgiev.com e leia as notas, já que não há garantia de compatibilidade antes da v1.0.0

Ainda não criou a instância? Dá pra conferir a VPS para este projeto e seguir o passo a passo desde o início

E se o sistema for crítico, a decisão de rodar um projeto pré-1.0 em produção é do teu time, pesando o risco com calma

Até o próximo post! =)

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.