# Voltro local env — compose-mariadb baseline.
#
# The Voltro CLI auto-loads .env from each app dir + every ancestor at
# boot. 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

# MariaDB connection — points at the mariadb service in docker-compose.yml
# (port 3307 to avoid clashing with a host MySQL on 3306). Inside the
# docker network (dev:docker) the host is `mariadb`; native (pnpm dev with
# pnpm db:up) it's `localhost` on 3307.
DB_DIALECT=mariadb
DB_URL=mysql://app:app@localhost:3307/{{projectNameSnake}}
# Cross-replica real-time via the binlog reader (the compose DB runs with
# binlog_format=ROW + binlog_row_image=FULL + a replication grant). CDC=0
# falls back to single-process inline emit.
CDC=1

# File storage — MinIO locally (S3-compatible). The createbuckets one-shot
# provisions the bucket; the public /_voltro/storage/:id route serves blobs.
STORAGE_PROVIDER=minio
S3_ENDPOINT=http://localhost:9000
S3_BUCKET={{projectNameSnake}}
S3_ACCESS_KEY_ID=minioadmin
S3_SECRET_ACCESS_KEY=minioadmin
S3_FORCE_PATH_STYLE=1

# 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 DB uses a different root
# password from dev (avoids `db:reset` blowing away a prod-shape dataset).
MARIADB_ROOT_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