Skip to main content
By default plamotrack listens on 127.0.0.1 and answers only to names it knows, so a fresh install is reachable from the machine that runs it and nowhere else. Four settings in .env decide who can reach an instance and by what name — WEB_BIND, ALLOWED_HOSTS, PUBLIC_BASE_URL and TRUSTED_PROXIES, each explained in the configuration reference. The four ways people run it map onto them like this. “Tested” means the deployment checks in the plamotrack repository ran against that configuration before the release these pages describe. The results are in that release’s notes on GitHub.

Plain HTTP or TLS

Plain HTTP carries the session cookie and any token in clear text. The first and third ways have a plain-HTTP hop on your network — between your devices and the instance, or between the tunnel connector and the instance. The second and fourth terminate TLS in front of the stack, so the only plain-HTTP hop is on the host itself. What plamotrack does in every case: the owner login, the access tokens, the allowed-hosts check, the rate limits and the audit log. What it never does: open a port you didn’t ask for.

Unsupported

These are not documented ways to run it, and the docs say so rather than leaving it to be discovered:
  • WEB_BIND=0.0.0.0 on a public interface without TLS in front.
  • Publishing the API container’s port 8000 directly. The bundled web container (nginx) is part of the security model — route separation, default-deny on unlisted paths and the per-client rate limits — and the API assumes it is there.
  • A proxy in front of the stack that is not named in TRUSTED_PROXIES. Forwarded headers are then ignored: the rate limits key on the proxy’s address and the audit log records it. A degradation, not a bypass.
  • Changing PUBLIC_BASE_URL on an instance with connected AI clients without reconnecting them. It is part of the instance’s identity, and every OAuth link is invalid once it changes.