ANKER_MQTT_FRAME_LOG logs every inbound cloud frame with its bytes,
decoded or not — the ones this package drops are exactly the ones worth
naming, so they are logged before the drop.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Charger control needs TLS, and the stack speaks plain HTTP, so the README
said "terminate TLS in a reverse proxy" and left the operator to work out
which four settings have to agree. This adds the proxy: a Caddy overlay
that fronts the Web App BFF — which already carries /api/ and /ocpp/ — so
browsers and chargers arrive at the same name and the certificate is issued
on first boot.
The four settings are derived from DV_DOMAIN, since one value getting typed
right is better odds than four: OCPP_PUBLIC_URL, OCPP_REQUIRE_TLS back on,
CORS, and TRUST_FORWARDED_PROTO on the Web App. That last one is the
non-obvious one — without it the BFF overwrites Caddy's X-Forwarded-Proto
with its own plaintext hop and the API Server rejects the charger it just
told to connect over wss.
The README's OCPP section was stale besides: it still sent chargers to the
API Server port alone, from before the BFF carried that path.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The API Server tells a charger to dial the host it was itself asked on.
The panel asks through the Web App, so the address handed out is the Web
App's — which proxied /api/ and nothing else, and answered the WebSocket
handshake at /ocpp/ with index.html. A charger pointed at the endpoint the
screen showed could never connect to it, and the screen went on saying
"Not connected" without a hint as to why.
Both front doors now carry /ocpp/ through to the API Server: the BFF via
the same reverse proxy, which relays the 101 by hijacking, and the
all-in-one image's nginx via a location of its own, with timeouts long
enough for a session that is idle between heartbeats.
The proxied hop also has to say how the client arrived, since the API
Server reads X-Forwarded-Proto to decide a charger reached it over TLS.
That header is set from this server's own connection and overwrites
whatever came in: believing a client on that point would let a plaintext
charger claim wss and walk past OCPP_REQUIRE_TLS. TRUST_FORWARDED_PROTO
opts into the inbound value for the one deployment where it is true — TLS
ending at a proxy in front of the stack.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ee4ac44 removed the api_data volume, which left the panel's Settings ->
PocketBase and Settings -> Web App screens with nowhere to persist to: they
apply at runtime and the container environment wins again on restart. That
is only acceptable if the environment is actually reachable by an operator,
and for two of those keys it was not - WEBAPP_URL was hardcoded in all four
compose files, and POCKETBASE_URL in the two multi-container ones, so
there was no supported way to change them at all.
Both are now ${VAR:-default} with the previous hardcoded value as the
default, so nothing moves for an existing .env while the keys become
settable. CORS_ALLOW_ORIGINS and the admin credentials already were.
The env examples grow a section naming every setting the panel can also
change, saying plainly that the panel's version lasts only for the life of
the container, and giving the commented-out line to make it stick. It also
records the trap in WEBAPP_URL: it is a container-to-container call, so it
has to be reachable from the API Server rather than from a browser, which
is why the default is a service name and not localhost. POCKETBASE_URL is
described as repointable in the multi-container stack and left alone in the
AIO image, where it addresses that container's own PocketBase.
Also dropped two leftovers from when there were two volumes: the storage
sections still said "either".
Checked by parsing all five compose files and asserting each interpolation
default matches the value it replaced, so this cannot have moved a default
by accident. go build and go test ./... still pass (untouched here). Not
verified: no Docker CLI, so no `docker compose config` render and no build.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
01a8fec fixed the advice that led operators into this, but advice is not a
guard: a stack still running PB_BOOTSTRAP=false gets no app_settings
collection on upgrade, and the plugin panel sits at 503 while the retry
loop reads a collection that does not exist.
The fix is not to soften the reading. A missing collection stays "not
ready" rather than "no plugins configured", because the alternative lets
the first save write a fresh document over settings the server merely
failed to find - the failure this whole line of work exists to prevent.
Instead the server now fixes the cause: on a missing collection it creates
that collection and reads again.
Three pieces:
bootstrap.EnsureCollection creates one named collection from the desired
schema if absent, and nothing else. Deliberately narrower than Run - no
field reconcile elsewhere, no super-admin - so it is safe to call on a
deployment that turned the full bootstrap off. It creates the collection
the server cannot start without, not the schema the operator declined.
The store tells a missing collection apart from an outage. A 404 from a
list means the collection itself is gone: an existing but empty one answers
200 with no items. That is tagged errNoCollection, which wraps errNotReady
so every write is still refused, and IsMissingCollection narrows it. The
distinction matters because the remedies are opposites - creating
collections against a flaky database is exactly the wrong reflex, and a
test pins that an outage does not trigger it.
loadPlugins acts on the tag once, then re-reads. Failing to create is
reported as the original read error rather than the repair's, so the log
names the real problem.
Six tests: the tag and its negative in internal/plugins, and three in
internal/api against a fake PocketBase covering the collection being
created exactly once, an existing collection not being recreated, and an
outage creating nothing.
Docs from 01a8fec are corrected in the same pass - they said the panel
would answer 503 forever, which is no longer true. They now say what still
depends on the bootstrap (every other collection and field) and what does
not (app_settings alone).
go build, go vet and go test ./... pass; compose files still parse. Not
verified: no Docker CLI here, so the repair has not been exercised against
a real PocketBase, only the fake.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
The all-in-one image builds from the project root, and Docker only reads
.dockerignore from the context root — so the ones under "API Server" and
"Web App" never applied to it and every AIO build shipped the whole tree,
"Phone App/build" included. A root .dockerignore allow-lists the paths that
build actually copies.
The dev split stack passed neither PB_BOOTSTRAP nor the SUPERADMIN vars, so
it created the schema and then no user to log in with. It passes them now,
and .env.example says so.
WEBAPP_URL was never set anywhere, leaving the panel status page probing
localhost:8090 — itself — and always reporting the Web App as down. Each
compose file now points it at wherever the Web App really is, and the BFF
grew a real /healthz instead of letting the SPA fallback answer probes with
index.html and look healthy no matter what.
In the AIO, PocketBase and the API Server drop to an unprivileged user;
only nginx stays root to bind :80. The entrypoint takes ownership of the
two volumes first, so data written by the old root-only image stays
writable. All three images carry a HEALTHCHECK, every compose file declares
one too (so depends_on still gates against an older pulled image), and
web-app waits for the API Server to be serving rather than merely started.
Also: pinned alpine/golang/node and PocketBase 0.39.11, so a rebuild months
from now produces the same image; nginx forwards WebSocket upgrades instead
of stripping them, with the map in http.d where Alpine actually reads it;
and a .gitattributes keeps entrypoint.sh on LF, because a CRLF shebang from
a Windows clone fails at container start with "no such file or directory".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Audited every Dockerfile, compose file and .env.example against the code
they deploy. Four things had drifted:
Persistence. The API Server writes plugins.json and rewrites .env (the
panel's retarget-PocketBase flow) relative to its working directory,
which was a root-owned /app while the process runs as the app user - so
both writes failed, and no volume was declared to keep them anyway. The
binary moves to /usr/local/bin and the working directory becomes a /data
volume owned by app. The AIO image gets the same via directory=/data on
its supervisord program.
OCPP. Charger control was undeployable: OCPP_REQUIRE_TLS defaults to true
and appeared in no Docker file, so a charger dialling the plain-HTTP
/ocpp/{serial} was rejected with nothing explaining why. Both OCPP vars
are now threaded through the compose files and env examples, with the
reasoning (the per-charger control token rides in a Basic-auth header).
CORS. API Server/docker-compose.yml defaulted to localhost:5173, the Vite
dev port, where every other file uses 8090.
Env names. .env.example has called PB_URL/PB_ADMIN_*/PORT legacy for a
while, but the Docker layer still used them. Container-side names are now
POCKETBASE_*/API_ADDR; the .env keys operators set stay PB_ADMIN_* so
existing .env files keep working.
Left alone deliberately: alpine:latest stays unpinned (cannot verify
current tags or test the build from here), and the golang/node bases
already match go.mod and Vite 8's floor.
Validated as YAML only - there is no Docker CLI on this machine, so no
image was built and the /data ownership fix follows standard volume
semantics rather than an observed run.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Introduce registry-pull production stacks (docker-compose.prod.yml) for
both the multi-container Docker setup and the all-in-one Docker AIO image,
with everything an operator needs (superuser, super-admin, ports, volumes)
driven from .env.
The API Server now bootstraps PocketBase on startup: a new internal/bootstrap
package (Go port of setup-pocketbase.mjs) creates missing collections,
reconciles existing ones, and creates the DriverVault super-admin from
DRIVERVAULT_SUPERADMIN_* when absent. Idempotent and gated by PB_BOOTSTRAP.
The PocketBase superuser is still upserted by the PocketBase container, since
the REST API cannot bootstrap the first superuser.
Move PocketBase to port 8070 (internal + published) and the web app to 8090
across both stacks, with matching CORS defaults.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
READMEs: correct the auth model (PocketBase token relay, not JWT/sessions),
document the full feature set (technical checks, fuel, maintenance, documents,
reminders, attachments, integrations, OCPP charging control), the shipping
built-in connectors (toyota, anker-solix), and the current endpoint surface.
Docker: build against the current repo layout — Go 1.26, cmd/server entry
point, Web App source under web/. Add the missing Web App Dockerfile (Go BFF)
and .dockerignore, drop the obsolete AUTH_SECRET, modernise CORS var naming,
and standardise on drivervault-* naming.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
