PocketBase: avalie na demo, mas rode o seu com senha, backup e rede fechada

A estagiária precisava avaliar o PocketBase para o cadastro de clientes da oficina. Abriu a demo pública, criou uma coleção e, para ver como ficava, importou uma planilha com nome, telefone e placa de 300 clientes reais. A avaliação foi ótima. O problema é que esses dados agora estão num ambiente que vocês não controlam, que outras pessoas acessam e que vocês não sabem quando é apagado.

A resposta curta: a demo serve para clicar na interface com dado inventado. Para qualquer coisa além disso, suba a sua própria instância, que é um único executável: rode-o como serviço com usuário próprio, escutando só em 127.0.0.1, atrás de um proxy com HTTPS, com um superusuário de senha forte, regras de API revisadas e backup testado. Isso leva menos de uma hora.

Por que a demo não é lugar de dado

Uma demo pública existe para mostrar a ferramenta a qualquer pessoa. Isso implica que outras pessoas acessam o mesmo ambiente, que o conteúdo pode ser limpo a qualquer momento e que você não tem contrato nenhum sobre onde os dados ficam ou quem os vê. Você não sabe nem se as suas coleções aparecem para o próximo visitante.

Para dado pessoal, isso pesa mais. Colocar telefone e placa de clientes num serviço de terceiros sem necessidade é exatamente o tipo de tratamento que a LGPD pede para evitar, e você não consegue apagar o que não controla. O post adequação à LGPD num sistema pequeno mostra o mínimo que vale ter.

A segunda armadilha é técnica: a URL da demo vai parar no código de integração durante o teste e fica lá. O app passa a depender de um ambiente que some sem aviso.

Como subir a sua instância, passo a passo

O exemplo é a Oficina Dois Irmãos, numa VPS Linux com nginx, no subdomínio api.oficina2irmaos.example.

1. Baixe o executável da página oficial de releases para a arquitetura da VPS e coloque em /opt/pocketbase.
2. Crie um usuário de sistema sem shell para rodar o serviço.
3. Crie o superusuário pela linha de comando, com senha gerada por gerenciador de senhas.
4. Configure o serviço systemd escutando em 127.0.0.1:8090.
5. Publique pelo nginx com HTTPS e deixe a porta 8090 fechada no firewall.
6. Revise as regras de API de cada coleção antes de ligar o app.
7. Configure e teste o backup, com cópia fora da VPS.

Usuário, superusuário e serviço

sudo useradd --system --home /opt/pocketbase --shell /usr/sbin/nologin pocketbase
sudo chown -R pocketbase:pocketbase /opt/pocketbase
cd /opt/pocketbase
sudo -u pocketbase ./pocketbase --help

O --help lista os comandos da versão que você baixou. Nas versões recentes, a conta administrativa se chama superusuário e é criada com o comando superuser; versões antigas usavam admin. Use o que a sua versão mostrar, e não deixe a criação da primeira conta para depois de publicar o painel.

# /etc/systemd/system/pocketbase.service
[Unit]
Description=PocketBase
After=network.target

[Service]
Type=simple
User=pocketbase
Group=pocketbase
WorkingDirectory=/opt/pocketbase
ExecStart=/opt/pocketbase/pocketbase serve --http=127.0.0.1:8090 --dir=/opt/pocketbase/pb_data
Restart=on-failure

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now pocketbase
sudo systemctl status pocketbase

Escutar em 127.0.0.1 é a decisão mais importante desse arquivo. O PocketBase só aceita conexões da própria máquina, e quem fala com o mundo é o nginx. Se alguém mudar para 0.0.0.0, o painel administrativo fica exposto em HTTP puro na porta 8090 para qualquer um que ache o IP.

Proxy com HTTPS

server {
    listen 443 ssl;
    server_name api.oficina2irmaos.example;

    ssl_certificate     /etc/letsencrypt/live/api.oficina2irmaos.example/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.oficina2irmaos.example/privkey.pem;

    client_max_body_size 20m;

    location / {
        proxy_pass http://127.0.0.1:8090;
        proxy_http_version 1.1;
        proxy_set_header Connection '';
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        proxy_read_timeout 360s;
    }
}

As linhas de buffering e timeout existem porque as assinaturas em tempo real do PocketBase usam conexões longas de eventos do servidor, que o proxy não pode segurar em buffer nem cortar cedo. Se o seu nginx atende vários sites, o post nomes de servidor no nginx evita que este bloco responda pelo domínio errado.

Regras de API: o ponto que mais vaza

Cada coleção tem regras separadas para listar, ver, criar, atualizar e apagar. Uma regra travada, sem valor definido, permite a operação só a superusuários. Uma regra definida como texto vazio libera para qualquer pessoa, inclusive sem login. A diferença na tela é sutil, e é aí que o cadastro de clientes vira lista pública.

Na oficina, a coleção clientes ficou assim: listar e ver com @request.auth.id != "", para que só funcionários logados vejam; atualizar e apagar com @request.auth.id != "" && @request.auth.perfil = "gerente", supondo um campo perfil na coleção de usuários. Depois de salvar, teste com curl sem token na rota de listagem da coleção e confirme que a resposta não traz registros.

Backup que você já restaurou

Tudo mora na pasta pb_data: os bancos SQLite e, com armazenamento local, a pasta storage com os arquivos enviados. O painel das versões recentes tem uma área de backups que gera um arquivo compactado e pode enviar para armazenamento compatível com S3. Se preferir fazer por fora, use a cópia consistente do SQLite em vez de copiar o arquivo com o serviço rodando:

DATA=$(date +%F)
sqlite3 /opt/pocketbase/pb_data/data.db ".backup '/var/backups/pocketbase/data-$DATA.db'"
tar -czf /var/backups/pocketbase/storage-$DATA.tar.gz -C /opt/pocketbase/pb_data storage

Mande os arquivos para fora da VPS e, uma vez por mês, restaure numa máquina de teste e abra o painel. A mesma lógica de backup que restaura de verdade vale aqui: backup que nunca foi restaurado é uma suposição.

Erros comuns

• Colocar dado real na demo pública. Os dados ficam num ambiente compartilhado que você não controla e não consegue apagar.
• Integrar o app com a URL da demo. O app quebra quando a demo é limpa, e ninguém lembra de onde vinha o endereço.
• Escutar em 0.0.0.0:8090. O painel administrativo fica exposto sem HTTPS para qualquer pessoa que encontre o IP.
• Deixar a regra de listagem como texto vazio. A coleção inteira fica legível sem login.
• Copiar o banco com o serviço rodando. O backup pode sair inconsistente e só se descobre na hora de restaurar.
• Esquecer a pasta storage. O banco volta e os anexos dos registros não.

Checklist

• A demo recebeu só dado inventado, e nenhuma integração aponta para ela.
• O PocketBase roda com usuário de sistema próprio, via systemd.
• O serviço escuta em 127.0.0.1 e a porta 8090 está fechada no firewall.
• O acesso externo é só por HTTPS, pelo proxy.
• O superusuário tem senha forte guardada em gerenciador de senhas.
• Toda coleção teve as cinco regras revisadas, e a listagem sem login foi testada.
• O backup inclui banco e storage, sai da VPS e foi restaurado ao menos uma vez.

Entre na demo e no seu painel agora: existe algum registro de pessoa real num lugar que você não consegue apagar sozinho?