env.example

# env.example
#
# Copy this to .env and fill in the values.
# Docker Compose reads this file for all services.
#
# Auth and API keys live in app/.env.local (gitignored). Docker Compose
# loads both .env and app/.env.local for the production app service.

# --- Database (used by both Docker Compose and the app) ---
# connection_limit: max pool size (default = num_cpus * 2 + 1, often too low on NAS)
# pool_timeout: seconds to wait for a free connection before erroring (default 10)
# NOTE the database name. `npm run setup` seeds DEMO DATA, so it only runs
# against a database whose name says that is what it is for -- one carrying
# seed/demo/scratch/sandbox/sample/ci as a whole word (prisma/seed/demo/guard.ts).
# Every other name is assumed to hold real work and is refused. A production
# deployment names its database something else and does not run the demo seed.
DATABASE_URL=postgresql://dbuser_fbc:your-password-here@db:5432/holt_demo?connection_limit=20&pool_timeout=10
POSTGRES_USER=dbuser_fbc
POSTGRES_PASSWORD=your-password-here
POSTGRES_DB=holt_demo

# --- app/.env.local ---
# Copy app/.env.local.example to app/.env.local. Two of its values are
# REQUIRED or the app will not boot / you cannot log in:
#   APP_ENCRYPTION_KEY   -- validateEnv refuses to start without it
#   AUTH_LOCAL_ENABLED   -- without it the password provider is not registered,
#                           so the seeded staff logins do not work
# Google OAuth is optional; local password login covers a fresh clone.

# --- Automated Gmail Import ---
# Service account key file (mounted via docker-compose volume)
# GMAIL_SERVICE_ACCOUNT_PATH=/app/config/service-account.json
# GMAIL_IMPERSONATE_EMAIL=you@example.com
# AUTO_IMPORT_API_KEY=<random-64-char-hex-string>

# --- Source-system conventions (POS/ERP you import FROM) ---
# YOUR naming inside the source system, not vendor constants. The vendor's own
# conventions stay in code; these are the parts only your deployment knows.
#
# Report-filename prefixes. Comma-separate them -- a deployment normally uses
# more than one (a full name on some exports, an initialism on others), and
# naming only one silently unroutes every report filed under the other.
# Unset, the router matches BARE report names only (`Customers.csv`), so an org
# that does not prefix its exports needs no configuration. It will NOT guess
# that `Deleted_Customers.csv` is your customer master.
# ORDORITE_REPORT_PREFIX=Acme_Home,AH
#
# Store codes embedded in order numbers. The vendor's A/M suffix marks a return
# (ABxxA1234) vs an order (ABxxM1234); the codes themselves are yours.
# ORDORITE_STORE_CODES=AB,CD,EF
#
# Order-number prefixes that mean "return" on their own, if you use such a
# series (e.g. RS1234 for returns booked to your S store). Empty by default and
# deliberately so: guessing this wrong books ordinary orders as returns and
# subtracts them from revenue.
# ORDORITE_RETURN_PREFIXES=RS
#
# Your staff email domain, or a short stem of it. Salespeople sometimes type
# their OWN address into a customer record; the import refuses to merge
# customers on any email in this domain. A stem ("acme") also covers typos.
# COMPANY_EMAIL_DOMAIN=acme

# --- Backups (scripts/backup-db.sh, installed by scripts/install-cron.sh) ---
# BACKUP_REMOTE is the difference between a backup and a second copy of a
# single point of failure. When set, a failed off-host copy FAILS the backup;
# when unset, every run warns. rsync target or an rclone remote.
# BACKUP_REMOTE=user@nas:/volume1/holt-backups
# BACKUP_REMOTE_CMD=rsync        # rsync (default) | rclone
# BACKUP_DIR=./backups
# RETENTION_DAYS=14