# Voltro local env — compose baseline.
#
# The Voltro CLI auto-loads .env from each app dir + every ancestor
# at boot (see voltro/packages/cli/src/bin.ts). Shell exports always
# override .env values, so CI can set DB_URL via env without touching
# this file.

# ── Environment ────────────────────────────────────────────────────────
#
# DECLARE IT. Every `voltro db …` / `voltro migrate` invocation resolves an
# UNSET `NODE_ENV` to `production` — the same way `voltro serve` and `voltro
# start` do — so a bare `pnpm migrate` with no NODE_ENV refuses rather than
# applying an un-reviewed diff to what might be a production database. It also
# decides which `_voltro_*` bookkeeping tables the command declares, and a
# migration command that resolves it differently from the serving process
# declares a DIFFERENT schema.
#
# `voltro dev` declares `development` for itself and needs nothing from here;
# this line is what makes the explicit schema commands work locally.
NODE_ENV=development

# Postgres connection — points at the postgres service in
# docker-compose.yml (port 5433 to avoid clashing with a host pg on 5432).
# When you run inside the docker network (dev:docker / prod:up), the
# host is `postgres`. When you run native (pnpm dev with pnpm db:up),
# the host is `localhost` and port stays 5433.
DB_URL=postgres://app:app@localhost:5433/{{projectName}}

# Session signing secret — NO VALUE SHIPS HERE ON PURPOSE.
#
# `voltro dev` mints a unique one for this project into a gitignored
# .env.local on first boot, so local development needs nothing from you.
# A shipped placeholder would be a signing key published to everyone who
# downloads this template, making every session in your deployment forgeable.
#
# Your DEPLOYMENT needs its own — `voltro serve` refuses to start without it:
#     voltro secret generate session
VOLTRO_SESSION_SECRET=

# Used by docker-compose.prod.yml — the prod postgres uses a
# different password from dev (intentional: avoid `db:reset` blowing
# away the prod-shape dataset by accident).
POSTGRES_PASSWORD=change-me-in-prod

# ─── Optional backends — ALL OFF by default; uncomment to activate ───────────
# The cache and the durable KV each run on a zero-infra default (in-process
# memory / your SQL store). Point either at a RESP server (Redis / Valkey /
# KeyDB / Dragonfly / Upstash) ONLY when you want cross-instance sharing.
# Enablement is per concern — a bare REDIS_URL is NOT a master switch; each
# concern reads its own <NAME>_REDIS_URL first, then a shared REDIS_URL.

# @voltro/cache → Redis: a distributed query/result cache. Easiest path:
# `voltro add redis` uncomments these AND injects a `redis` service into
# docker-compose.yml; then `docker compose up -d redis` and reboot.
# CACHE_BACKEND=redis
# CACHE_REDIS_URL=redis://localhost:6379

# @voltro/kv → Redis: durable `ctx.kv`. Default backend is `database`
# (durable, shared across replicas, survives restarts) — leave it unless you
# specifically want KV on Redis. If you do, use a PERSISTENT redis (AOF/RDB),
# NOT the ephemeral cache service `voltro add redis` provisions: an
# eviction/restart is data loss for durable KV. See docs → Caching → Key-value
# backends.
# KV_BACKEND=redis
# KV_REDIS_URL=redis://localhost:6379

# One server for everything, instead of the per-concern URLs above:
# REDIS_URL=redis://localhost:6379