Files
DriverVault/Docker-AIO
tajniak81andClaude Opus 5 9487de84b0 Docker AIO: a folder name without a space in it
The all-in-one folder is now Docker-AIO, so -f Docker-AIO/Dockerfile
resolves without quoting. Every path that pointed at the old name
follows it: the compose build stanza, the documented build commands,
and the links from the two READMEs.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-19 20:01:19 +02:00
..

DriverVault — Docker AIO (all-in-one image)

PocketBase + API Server + Web App in a single container, supervised by supervisord with nginx serving the SPA and proxying /api/ to the API Server on localhost. One image, one volume set, no compose network — the simplest way to stand DriverVault up on a single host.

Prefer the three-container stack in ../Docker when you want to scale, upgrade or restart the pieces independently.

:80   nginx ─► SPA, and /api/ ─► API Server on 127.0.0.1:8080 ─► PocketBase on :8070
File Use
Dockerfile the all-in-one image (build context must be the repo root)
docker-compose.yml builds from source — for development and local testing
docker-compose.prod.yml pulls the prebuilt image from the registry
.env.example / .env.prod.example copy to .env for the matching compose file

Run it

cd "Docker-AIO"
cp .env.example .env        # then edit — PB_ADMIN_* have no safe defaults
docker compose up -d --build

Production, from the registry:

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/_/.

Note the port mapping: inside the container the web app is on 80, published as WEB_PORT (8090 by default) to line up with the other deployment.

Building by hand

The build context must be the repo root so the Dockerfile can reach both API Server/ and Web App/:

docker build -f "Docker-AIO/Dockerfile" -t drivervault-aio .

Build args: VITE_API_BASE (leave empty so the bundle uses same-origin /api) and PB_VERSION (pin PocketBase, or leave empty to fetch the latest release at build time).

First boot

Identical to the multi-container stack, and idempotent:

  1. PocketBase upserts its superuser from PB_ADMIN_EMAIL / PB_ADMIN_PASSWORD.
  2. The API Server waits for PocketBase to report healthy, then creates any missing collections, reconciles existing ones, and creates the first app superadmin from DRIVERVAULT_SUPERADMIN_EMAIL / _PASSWORD. Set PB_BOOTSTRAP=false to skip once the database is established.

Volumes

Volume Holds
/pb/pb_data the PocketBase SQLite database and uploaded files
/data the API Server's plugins.json, and the .env the panel rewrites when a superadmin retargets the PocketBase connection

Both default to Docker-managed named volumes; set PB_DATA / API_DATA to absolute host paths in the prod file for bind mounts.

Charger control (OCPP)

Chargers in own/proxy mode dial in to /ocpp/{serial} on the API Server port (8080) — not through nginx — authenticating with a per-charger control token in an OCPP Basic-auth header. Because a plaintext ws:// would expose that token, OCPP_REQUIRE_TLS defaults to true.

This image serves plain HTTP, so charger control needs TLS terminated in front of it, with OCPP_PUBLIC_URL set to the public wss:// base. Only drop OCPP_REQUIRE_TLS on a trusted network.

Caveats

  • Everything runs as root in one container, and a crash of supervisord takes all three services down together. That is the trade for the simplicity.
  • Logs from all three processes are interleaved on the container's stdout/stderr (docker logs drivervault-aio).
  • PB_VERSION empty means the image pulls whatever PocketBase release is latest at build time, so two builds of the same source can differ. Pin it for reproducibility.