Authentication modes

Every public access entry on an application carries an authentication mode. The check happens at the serving device’s Caddy layer, before any request reaches your workload. The four modes:

none — public

policies: { auth: { mode: none } }

Anyone who knows the URL can reach the service. No credential check. Use for marketing sites, public APIs, anything genuinely meant to be open.

If you don’t want the URL itself to be discoverable, pair none with a generated (random-suffix) hostname. The hostname acts as a weak shared secret — fine for low-stakes sharing, not fine as a real access control.

org — Edgible organization members only

policies: { auth: { mode: org } }

A request reaches the workload only if the requester has a valid Edgible session for a member of your organization. Visiting in a browser triggers a sign-in flow; if the user is a member of the right org, the request goes through and the user stays logged in for the session.

Use for internal tools — dashboards, admin UIs, on-call runbooks. It removes the need to run a VPN: your team logs into Edgible (which they already do) and the existing session also serves as the authn for these tools.

The check is membership only — a per-app role model isn’t part of org mode. If you need finer-grained authorization, do it inside your application after the request lands.

api-key — bearer token

policies: { auth: { mode: api-key } }

The request must include a bearer token issued for this application. Caddy verifies the token against a list the agent receives from the control plane.

Issue a token with the CLI:

edgible application api-keys create \
  --app-id <app-id> \
  --name "ci-deploy-key" \
  --expires 2026-12-31

Send it on every request:

curl https://api.example.com/v1/things \
  -H "Authorization: Bearer <key>"

Tokens can be listed (api-keys list), deleted (api-keys delete), and given an expiry. Rotation is your responsibility — the platform doesn’t auto-rotate API keys.

Use for programmatic access from scripts, CI pipelines, partner integrations, or any other machine consumer.

short-code — rotating short-lived tokens

policies: { auth: { mode: short-code } }

Like api-key, but the token is shorter, the lifetime is shorter, and it can be capped to a maximum number of uses. Designed for sharing brief access — “send this link to the contractor for the next two hours.”

edgible application short-codes create \
  --app-id <app-id> \
  --name "contractor-access" \
  --expires "2026-04-30T18:00:00Z" \
  --max-uses 50

The created code is included in the URL or in a query parameter, depending on how the consumer wants to use it. Toggle a code on or off without deleting it (short-codes toggle).

Use when you want to share access without provisioning an account, and you want the access to disappear on its own.

Combining modes

A single access entry has one mode. If you need different policies for different audiences, give the workload multiple access entries — one per audience — each with its own hostname and policy. See Access, hostnames, and TLS for the multi-access example.

What none of these modes are

Edgible’s auth modes authenticate the caller — they don’t authorize the call beyond membership. None of them inspect the request body, none of them read JWT claims for your application, none of them apply per-route ACLs. Authorization beyond “the caller has a credential” lives inside your workload — Caddy hands the request through, and you decide what the user is allowed to do.

If you need WAF-style request inspection, IP allow-lists, or rate limiting, those are platform features tracked on the roadmap but not in the box today.