tajniak81andClaude Opus 5
01a8fecf40
Every deployment file advised setting PB_BOOTSTRAP=false "once the database
is established". That was harmless while the schema was static. It stopped
being harmless in 9bd5c52, which moved the plugin settings into a new
app_settings collection: a stack upgraded with the bootstrap off never gets
that collection, and a missing collection is deliberately read as "the
database is not ready" rather than "no plugins configured" - so the plugin
panel answers 503 indefinitely and the background retry spins forever.
Fixing the advice rather than the reading: treating a missing collection as
empty would let the first save write a fresh document over settings the
server had simply failed to find, which is the failure this whole line of
work exists to prevent.
So all four compose files, all four .env examples, both stack READMEs and
the AIO Dockerfile now say to leave the bootstrap on, including across
upgrades, and name the symptom an operator would otherwise have to guess
at. Turning it off is still supported, but framed as something to do only
for a database known to match the running release.
Compose files still parse as YAML; go build, go vet and go test ./... pass
(untouched by this commit - it is comments and docs only). Note that this
is guidance, not a guard: an operator who sets PB_BOOTSTRAP=false anyway
still ends up in the same place, and the server would have to re-run the
bootstrap when it finds the collection missing to make that impossible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
110 lines
5.1 KiB
Markdown
110 lines
5.1 KiB
Markdown
# DriverVault — Docker (multi-container stack)
|
|
|
|
Three containers — **PocketBase**, **API Server**, **Web App** — on one compose
|
|
network. This is the deployment to use unless you specifically want everything
|
|
in a single image; for that see [`../Docker-AIO`](../Docker-AIO).
|
|
|
|
```
|
|
Browser ─► Web App BFF (:8090) ──/api/*──► API Server (:8080) ─► PocketBase (:8070)
|
|
```
|
|
|
|
Only the Web App port is meant to be public. The API Server and the PocketBase
|
|
admin UI are published for convenience and, in the prod file, bound to
|
|
`127.0.0.1` by default.
|
|
|
|
| File | Use |
|
|
|---|---|
|
|
| `docker-compose.yml` | **builds from source** in this repo — for development and local testing |
|
|
| `docker-compose.prod.yml` | **pulls prebuilt images** from the registry — for deployment |
|
|
| `.env.example` / `.env.prod.example` | copy to `.env` for the matching compose file |
|
|
| `pocketbase/` | the PocketBase image (official release binary on alpine) |
|
|
|
|
## Run it
|
|
|
|
```bash
|
|
cd Docker
|
|
cp .env.example .env # then edit — PB_ADMIN_* have no safe defaults
|
|
docker compose up -d --build
|
|
```
|
|
|
|
Production, from the registry:
|
|
|
|
```bash
|
|
cp .env.prod.example .env # then edit
|
|
docker compose -f docker-compose.prod.yml pull
|
|
docker compose -f docker-compose.prod.yml up -d
|
|
```
|
|
|
|
Then: web app on `http://host:8090/`, the API Server's superadmin panel on
|
|
`http://host:8080/`, PocketBase admin on `http://host:8070/_/`.
|
|
|
|
## First boot
|
|
|
|
Both steps are idempotent, so restarts and upgrades are safe:
|
|
|
|
1. **PocketBase** upserts its superuser from `PB_ADMIN_EMAIL` / `PB_ADMIN_PASSWORD`.
|
|
This is the only way to create the first superuser — the REST API cannot
|
|
bootstrap it. The API Server then authenticates with the same credentials.
|
|
2. **The API Server** creates any missing collections and reconciles existing
|
|
ones, then creates the first app `superadmin` from
|
|
`DRIVERVAULT_SUPERADMIN_EMAIL` / `_PASSWORD` if no such user exists.
|
|
|
|
> Leave `PB_BOOTSTRAP` at `true`, including across upgrades. A release can add a
|
|
> collection the server needs — `app_settings`, which holds the plugin settings,
|
|
> is one — and a stack that skipped the bootstrap never gets it. The plugin panel
|
|
> then answers `503` indefinitely, because a missing collection is read as "the
|
|
> database is not ready yet", never as "no plugins configured". Turn it off only
|
|
> for a database you know already matches the release you are running.
|
|
|
|
No manual `setup-pocketbase.mjs` step is needed here — the server runs the same
|
|
schema reconcile itself.
|
|
|
|
## Volumes
|
|
|
|
| Volume | Holds |
|
|
|---|---|
|
|
| `pb_data` | the PocketBase SQLite database and uploaded files |
|
|
| `api_data` | the `.env` the API Server panel rewrites when a superadmin retargets the PocketBase connection (plugin settings live in `pb_data`, with everything else) |
|
|
|
|
Both default to Docker-managed named volumes. In the prod file, set `PB_DATA` /
|
|
`API_DATA` to absolute host paths for bind mounts instead.
|
|
|
|
> The API Server serves as the unprivileged `app` user, so `/data` has to be
|
|
> writable by it. Its entrypoint arranges that itself: it starts as root, takes
|
|
> ownership of `/data` if `app` does not already hold it, then drops privileges.
|
|
> So a **bind mount** to a root-owned host path needs no manual `chown`, and
|
|
> neither does a **named volume** left over from an image that ran as root. The
|
|
> one case it cannot fix is a container forced to another user (`user:` in
|
|
> compose, `docker run --user`), where the entrypoint has no privileges to
|
|
> `chown` with — prepare the host directory yourself there. PocketBase runs as
|
|
> root, so `PB_DATA` is unaffected either way.
|
|
|
|
Plugin enable-state and global config used to live in a `plugins.json` on this
|
|
volume, which made them the one piece of configuration a lost volume could erase
|
|
without anyone noticing. They are now in PocketBase, backed up with `pb_data`
|
|
like everything else. An existing `plugins.json` is imported automatically on the
|
|
first boot after the upgrade and renamed to `plugins.json.migrated`; keep the
|
|
volume mounted for that boot.
|
|
|
|
## Charger control (OCPP)
|
|
|
|
Chargers in own/proxy mode dial in to `/ocpp/{serial}` **on the API Server
|
|
port**, authenticating with a per-charger control token in an OCPP Basic-auth
|
|
header. A plaintext `ws://` would put that token on the wire in the clear, so
|
|
`OCPP_REQUIRE_TLS` defaults to `true` and non-TLS connections are rejected.
|
|
|
|
This stack serves plain HTTP, so to actually use charger control you need to
|
|
terminate TLS in a reverse proxy in front of it and set `OCPP_PUBLIC_URL` to the
|
|
public `wss://` base (behind a proxy, deriving it from request headers is
|
|
unreliable). `OCPP_REQUIRE_TLS=false` is for trusted networks only. You will
|
|
also need `API_BIND` set so the proxy can reach the port.
|
|
|
|
## Notes
|
|
|
|
- `docker-compose.yml` builds the API Server and Web App from `../API Server`
|
|
and `../Web App`, so run it from this directory with the repo checked out.
|
|
- The Web App's Vue bundle is built with an empty `VITE_API_BASE`, so the
|
|
browser uses same-origin `/api` and the BFF proxies it — no CORS in play.
|
|
- `CORS_ALLOW_ORIGINS` therefore only matters if a browser calls the API Server
|
|
directly. Native mobile apps are not subject to CORS at all.
|