Authentication
The real mechanism, for anyone self-hosting.
This documents what this codebase actually does — not an external API-key scheme, because none exists. Relevant to private-label operators who deploy their own instance.
Session cookie, not an API key
There is no external API-key scheme today. Every request is authenticated by a signed session cookie issued at sign-in — the same mechanism the portal and admin console use.
Password storage
Credentials are hashed with scrypt and stored as <saltHex>:<hashHex>. The local password path is the development/self-hosted credential flow; production is expected to federate to an external identity provider rather than store passwords directly.
Capability-based authorization
Every privileged action is named as an explicit capability (e.g. deployment:approve) and checked server-side against a default-deny grant table, keyed by role. Navigation never enforces this by itself — every page and mutation independently re-checks its own capability.
CSRF
Mutations require a double-submit CSRF token bound to the session, verified in the same call that checks the session and the capability — a Server Action cannot accidentally skip one of the three.