Deploy: SQLite#

Persistência de relatórios sem depender de nenhum banco externo. O estado é gravado em um arquivo .db montado como volume Docker — sobrevive a restarts, zero infra adicional.

Quando usar: times pequenos, servidor único, ambientes sem Postgres disponível.

Configuração#

Copie o env de exemplo e preencha o AUTH_SECRET:

cd examples/server
cp .env.sqlite.example .env.sqlite
# Edite .env.sqlite e defina AUTH_SECRET

Gere um segredo seguro:

openssl rand -hex 32

Subindo com Docker Compose#

docker compose -f docker-compose.sqlite.yml --env-file .env.sqlite up --build

O servidor sobe em http://localhost:8090 com persistência em um volume Docker (sqlite_data).

Sem Docker#

STORAGE_BACKEND=sqlite \
DATABASE_URL=/caminho/para/sulfite.db \
AUTH_SECRET=seu-segredo \
dart run bin/example_server.dart

O arquivo .db é criado automaticamente na primeira execução. O schema é aplicado via CREATE TABLE IF NOT EXISTS — reiniciar o servidor é seguro.

Variáveis relevantes#

STORAGE_BACKEND=sqlite          # ativa o backend SQLite
DATABASE_URL=/data/sulfite.db   # caminho do arquivo (default: sulfite.db)
AUTH_SECRET=...                  # obrigatório — segredo para assinar JWTs

Autenticação#

Com SQLite, a autenticação JWT está ativa. Para obter um token:

# Login com admin padrão (usuário criado no primeiro boot)
curl -X POST http://localhost:8090/api/v1/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username": "admin", "password": "admin"}'

Use o access_token retornado no header Authorization: Bearer <token> das chamadas subsequentes.

Limitações#

• Não suporta múltiplas réplicas (arquivo SQLite é local ao container).
• Tokens, jobs e shares ficam em memória (não sobrevivem a restart).
• Para tokens e shares persistentes em single-node, use PostgreSQL.

Próximo passo#

Quando precisar de produção confiável com todos os stores persistidos → PostgreSQL.