Server-only secrets

Configure the installation ID and API key through the deployment platform's encrypted server secret system. Do not bake the key into a container image or expose it as a build-time frontend variable.

Public base URL

ACCESS402_PUBLIC_BASE_URL must be the canonical URL clients use, not an internal container address. A production value might be https://api.example.com, even when the application listens internally on http://0.0.0.0:8000.

Multiple instances

Multiple workers or containers may share the same installation credentials when they serve the same deployment, origin, and code-owned policy catalog. Configuration caches are per process, while authoritative policies, idempotency, usage reservation, and settlements remain centralized in Access402.

One installation may authorize local, staging, and production origins when they represent the same application and code-owned route catalog. The installation keeps one scoped credential while each deployment selects Sandbox or Live through its server-side ACCESS402_MODE.

Use separate installations when environments need separate credentials, projects, ownership boundaries, or independently changing route catalogs. A different hostname alone does not require another installation.

Deploy code and policy changes together. Each process synchronizes at startup and refreshes signed configuration independently.

Proxies and CORS

Preserve the original HTTPS host and path through reverse proxies. Normalize duplicated slashes consistently and do not let a CDN cache paid responses publicly. Set an exact CORS origin for credentialed browser clients and allow OPTIONS preflight to reach the adapter.