Passos técnicos para abandonar o Firebase e migrar para uma hospedagem própria de 5 dólares por mês
TuBrief 편집팀
2026년 7월 14일
0
Computing/Software원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
커뮤니티의 다른 글
댓글 (0)
Log in to leave a comment
아직 작성된 글이 없습니다
원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
O Firebase é doce no início. Você pode implementar funcionalidades sem se preocupar com a infraestrutura. No entanto, assim que o serviço cresce um pouco, os valores na fatura começam a subir. Mudar para uma hospedagem própria pode parecer assustador no começo. E se os dados forem perdidos? E se o serviço parar cada vez que eu fizer um deploy?
Essas preocupações são legítimas. Mas existe uma maneira de fazer isso. Preparei um guia detalhado sobre como migrar os dados do Firestore com segurança para o PocketBase (um backend tudo-em-um baseado em SQLite) e como criar um ambiente de deploy com disponibilidade contínua usando GitHub Actions e Nginx.
Ao migrar os dados não estruturados do Firestore para o esquema do PocketBase, que é baseado em um modelo relacional, o primeiro obstáculo é o comprimento do identificador. O Firestore usa IDs de documento de 20 caracteres, mas o PocketBase impõe, por padrão, uma restrição de 15 caracteres alfanuméricos. Se você ignorar esse limite e tentar importar os dados, receberá o erro validation_length_invalid.
Para evitar esse problema, você precisa reduzir o tamanho mantendo a unicidade. A maneira mais segura é gerar um hash SHA256 do ID do Firestore e usar os primeiros 15 caracteres. Não precisa se preocupar com colisões; mesmo em grandes conjuntos de dados, a probabilidade de dois hashes de 15 caracteres serem idênticos é desprezível.
A estrutura do script de migração em Node.js para lidar com isso é a seguinte, utilizando os pacotes firebase-admin e axios para buscar os dados em lotes de 100 registros:
`javascript
// migration.js
const admin = require('firebase-admin');
const axios = require('axios');
const crypto = require('crypto');
admin.initializeApp({
credential: admin.credential.applicationDefault()
});
const db = admin.firestore();
const PB_URL = 'http://127.0.0.1:8090/api/collections/posts/records';
async function migrate() {
let lastDoc = null;
let hasMore = true;
while (hasMore) {
let query = db.collection('posts').orderBy('name').limit(100);
if (lastDoc) {
query = query.startAfter(lastDoc);
}
const snapshot = await query.get();
if (snapshot.empty) {
hasMore = false;
break;
}
for (const doc of snapshot.docs) {
const data = doc.data();
// Converte o ID de 20 caracteres do Firestore para 15 caracteres alfanuméricos
const newId = crypto.createHash('sha256').update(doc.id).digest('hex').substring(0, 15);
try {
await axios.post(PB_URL, {
id: newId,
firestore_id: doc.id, // Armazena o ID original para possível verificação
title: data.title,
content: data.content
});
} catch (err) {
console.error(`Falha na migração: ${doc.id}`, err.response?.data);
}
}
lastDoc = snapshot.docs[snapshot.docs.length - 1];
}
}
migrate();
`
Para realizar esse trabalho sem interrupções, você deve usar um período de transição. Primeiro, mova mais de 90% dos dados existentes em segundo plano com este script. Em seguida, implemente no código do cliente uma estratégia de escrita dupla (Dual-Write), gravando tanto no Firebase quanto no PocketBase simultaneamente. Após confirmar que os dados em ambos os lugares estão consistentes, altere os endpoints de leitura para o PocketBase e remova o código do Firebase. Do ponto de vista do usuário, o servidor não terá ficado fora do ar nem por um segundo.
O PocketBase é um backend leve executado como um binário único. No entanto, se você simplesmente executá-lo em um servidor Linux, não terá como recuperar o serviço caso o processo seja encerrado devido a uma falha inesperada de memória (OOM).
Você precisa configurar o systemd para garantir que o processo se reinicie sozinho caso caia. Crie o arquivo /etc/systemd/system/pocketbase.service e adicione o seguinte conteúdo:
`ini
[Unit]
Description=PocketBase Service
After=network.target
[Service]
Type=simple
User=pocketbase
Group=pocketbase
LimitNOFILE=65535
ExecStart=/opt/pocketbase/pocketbase serve --http="127.0.0.1:8090"
Restart=always
RestartSec=3
[Install]
WantedBy=multi-user.target
`
A configuração LimitNOFILE=65535 é importante aqui. Ao utilizar a funcionalidade de assinaturas em tempo real (WebSockets), ela evita que o serviço perca conexões quando há muitos usuários simultâneos, o que ocorreria devido ao limite padrão de descritores de arquivo do Linux.
Na frente, coloque o Nginx para lidar com certificados SSL e proxy. Adicione opções nas configurações em /etc/nginx/sites-available/pocketbase para evitar atrasos nas conexões de streaming em tempo real:
`nginx
upstream pocketbase {
server 127.0.0.1:8090;
}
server {
server_name api.yourdomain.com;
location / {
proxy_pass http://pocketbase;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# Suporte a WebSockets e streaming SSE em tempo real
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_buffering off;
}
}
`
Agora, basta usar o comando certbot --nginx para aplicar o certificado HTTPS e a infraestrutura básica estará pronta.
Por experiência, mesmo na VPS mais barata com 512 MB de RAM, se você ajustar levemente as configurações do SQLite, é possível lidar facilmente com mais de 1.000 requisições leves por segundo. Para maximizar o desempenho do SQLite ao rodar o PocketBase, o modo WAL (Write-Ahead Log) deve estar ativado. O PocketBase já o ativa por padrão, mas se você precisar manipular o SQLite diretamente, verifique as configurações PRAGMA journal_mode=WAL; e PRAGMA synchronous=NORMAL;. O gargalo de espera por gravação em disco desaparecerá quase por completo.
O erro mais comum cometido por desenvolvedores independentes é copiar manualmente o arquivo do banco de dados SQLite (data.db) de um servidor em execução para fazer backup. Esse método tem um alto risco de corromper os dados durante a cópia.
Usamos o Litestream. Ele é uma ferramenta que intercepta os frames do WAL do SQLite em tempo real e envia apenas as alterações para um armazenamento em nuvem. Recomendo o Cloudflare R2 como repositório de backup, pois a taxa de transferência de saída é gratuita, tornando o custo dos backups praticamente zero.
Crie o arquivo de configuração /etc/litestream.yml da seguinte forma:
`yaml
dbs:
`
Com essa configuração, mesmo que o arquivo original do banco de dados seja excluído, você pode restaurá-lo ao estado de menos de 1 segundo atrás com um único comando:
`bash
litestream restore -if-replica-exists /opt/pocketbase/pb_data/data.db
`
Se você acidentalmente excluir dados durante o desenvolvimento e quiser restaurar para um ponto específico no tempo, também é possível especificar o timestamp:
`bash
sudo systemctl stop pocketbase.service
litestream restore -timestamp "2026-07-14T15:00:00Z" -o /tmp/recovered.db /opt/pocketbase/pb_data/data.db
sqlite3 /tmp/recovered.db "PRAGMA integrity_check;"
mv /tmp/recovered.db /opt/pocketbase/pb_data/data.db
chown -R pocketbase:pocketbase /opt/pocketbase/pb_data/
sudo systemctl start pocketbase.service
`
O Cloudflare R2 oferece 10 GB de armazenamento gratuito por mês. Como ele também concede créditos para 1 milhão de requisições de escrita e 10 milhões de requisições de leitura, para um serviço individual, o custo de backup tende a zero.
Rodar um Docker facilita o deploy, mas em uma VPS pequena com 512 MB ou 1 GB de RAM, a memória consumida pelo próprio Docker daemon pode ser preciosa. Implementaremos um deploy sem interrupções (Blue-Green) alternando portas no systemd do Linux, sem usar Docker.
Aproveitamos a característica do SQLite que permite que vários processos leiam e escrevam no mesmo arquivo. Podemos criar um template de serviço systemd para rodar o binário do PocketBase nas portas 9011 (Blue) e 9012 (Green) separadamente.
Abaixo, um exemplo de workflow do GitHub Actions que envia o binário compilado para o servidor:
`yaml
name: Deploy
on:
push:
branches: [ main ]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Go
uses: actions/setup-go@v5
with:
go-version: '1.22'
- name: Build
run: |
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o pocketbase main.go
- name: Transfer Binary to VPS
uses: appleboy/scp-action@master
with:
host: ${{ secrets.VPS_HOST }}
username: ${{ secrets.VPS_USER }}
key: ${{ secrets.VPS_KEY }}
source: "pocketbase"
target: "/srv/pocketbase/next_release"
`
Quando o binário chega ao servidor, um script de deploy é executado. Ele verifica qual porta está ativa (9011 ou 9012) e inicia a nova versão na porta que estiver livre:
`bash
#!/bin/bash
CURRENT_PORT=$(curl -s http://127.0.0.1:8090/api/health | jq -r '.port' 2>/dev/null || echo "9011")
if [ "$CURRENT_PORT" = "9011" ]; then
TARGET_PORT="9012"
else
TARGET_PORT="9011"
fi
sudo systemctl start pocketbase@$TARGET_PORT.service
sleep 3
HEALTH_CHECK=TARGET_PORT/api/health | jq -r '.status')
if [ "HEALTH_CHECK" = "OK" ]; then
# Modificar a configuração upstream do Nginx para a nova porta e recarregar
echo "upstream pocketbase { server 127.0.0.1:TARGET_PORT; }" | sudo tee /etc/nginx/conf.d/upstream.conf
sudo systemctl reload nginx
# Encerrar o processo da versão anterior
sudo systemctl stop pocketbase@$CURRENT_PORT.service
echo "Deploy concluído. Porta TARGET_PORT.service
exit 1
fi
`
Com esse método, você consegue um deploy sem interrupções perfeito sem precisar de ferramentas caras de orquestração de containers. Mesmo que o usuário envie uma requisição durante o deploy, o Nginx segura a requisição por um breve instante (milissegundos) enquanto recarrega, encaminhando-a seguramente para a nova porta.
A hospedagem própria exige um esforço inicial de configuração, mas uma vez finalizada, torna-se uma base sólida para focar inteiramente no produto, sem se preocupar com custos de infraestrutura mensais.