# Bare baseline

Native Node + pnpm. No containers, no orchestration. You bring your
own Postgres.

## What this baseline gives you

- `.env.example` — the env vars Voltro reads on boot, with sane
  defaults for a local install.
- `deploy/voltro.service.example` — a sample systemd unit you can
  copy to `/etc/systemd/system/voltro.service` on a VPS and adjust.
- `deploy/README.md` — short notes on rolling-your-own deploy.

That's it. No `Dockerfile`, no `docker-compose.yml`, no
`charts/`. By design.

## What you have to do

### Local dev

1. Install Postgres locally (`brew install postgresql@17`,
   `apt install postgresql-17`, or run a one-off
   `docker run postgres:17-alpine -p 5432:5432 ...`).
2. Create the database: `createdb voltro_local`
3. Copy env: `cp .env.example .env` and edit `DB_URL`.
4. `pnpm install && pnpm dev`

### Production deploy

You're on your own. Common approaches:

- **systemd on a VPS** — see `deploy/voltro.service.example` for a
  starting unit. `pnpm voltro build .` per app, copy `dist/` over,
  enable + start the unit.
- **PM2 / Forever / Nodemon** — wraps the same `node dist/...`
  command with auto-restart.
- **Cloud Run / Fly.io / Render** — these will want a `Dockerfile`
  anyway. If you're going that route, switch to the **compose**
  baseline: `voltro baseline set compose`.

## Switching baselines

Run `voltro baseline set compose` to add Docker / `voltro baseline
set helm` to add a Helm chart. The switch writes the new baseline's
files and backs up your current `.env.example` + any conflicting
files to `.voltro-baseline-backup/<timestamp>/`. Your application
code is never touched.