Skip to content

Login

Scryer login can use password authentication, MFA, recovery codes, and passkeys. Passkeys depend on browser WebAuthn rules, so in production Scryer, the browser-facing URL, and the reverse proxy all have to agree about the public HTTPS origin.

Passkey setup for a production deploy behind reverse-proxy HTTPS has three required pieces. This guide assumes Caddy as the reverse proxy.

Scryer must know the WebAuthn relying party. For a subdomain install, set:

SCRYER_WEBAUTHN_RP_ID=scryer.example.com
SCRYER_WEBAUTHN_RP_ORIGIN=https://scryer.example.com
SCRYER_WEBAUTHN_RP_NAME=Scryer

The relying-party ID is the domain WebAuthn binds credentials to. The relying-party origin is the exact browser origin: scheme, host, and optional port.

Passkeys only turn on when WebAuthn is configured and form login is effectively enabled — if auth is disabled, passkeys stay disabled.

The proxy must expose Scryer over real HTTPS and pass normal proxy headers:

scryer.example.com {
reverse_proxy scryer:8080
}

Caddy’s default reverse_proxy behavior is usually enough: it preserves Host and sets X-Forwarded-Proto: https. Scryer checks forwarded proto for secure-request behavior.

If Caddy terminates TLS, Scryer itself can stay plain HTTP internally.

If you host under a path prefix, include that too:

SCRYER_BASE_PATH=/scryer
SCRYER_WEBAUTHN_RP_ID=scryer.example.com
SCRYER_WEBAUTHN_RP_ORIGIN=https://scryer.example.com

The RP origin is the scheme + host + optional port only. It should not include /scryer.

  • SCRYER_WEBAUTHN_RP_ID is a domain, not a full URL.
  • SCRYER_WEBAUTHN_RP_ORIGIN must be the exact browser origin: https://host[:port].
  • Do not use http:// in production. WebAuthn requires a secure context, except localhost.
  • If Caddy terminates TLS, Scryer itself can stay plain HTTP internally.
  • If using a non-default external HTTPS port, include it in origin, e.g. https://scryer.example.com:8443.
  • If either RP ID or RP origin is missing, Scryer disables passkeys and logs a warning.

For a typical Docker-style deployment behind Caddy, set:

SCRYER_BIND=0.0.0.0:8080
SCRYER_AUTH_ENABLED=true
SCRYER_WEBAUTHN_RP_ID=scryer.example.com
SCRYER_WEBAUTHN_RP_ORIGIN=https://scryer.example.com
SCRYER_WEBAUTHN_RP_NAME=Scryer

After the restart, log in with a password first, then add or register a passkey from the account/security UI.

When form login is disabled, Scryer normally protects public clients from being treated as trusted admin users. This matters when your UI is reachable from outside the host or local network.

SCRYER_ALLOW_UNAUTHENTICATED_PUBLIC_ACCESS is the explicit override for that behavior. When set to true, unauthenticated public clients can act as admin while auth is disabled. Use it only for deliberately isolated deployments.

SCRYER_UNAUTHENTICATED_PUBLIC_ACCESS_ALLOWLIST narrows that override to specific clients:

SCRYER_ALLOW_UNAUTHENTICATED_PUBLIC_ACCESS=true
SCRYER_UNAUTHENTICATED_PUBLIC_ACCESS_ALLOWLIST=192.0.2.10,2001:db8::/64,admin-vpn.example.com

The allowlist accepts comma-separated IPs, CIDRs, or DNS hostnames. If your instance is reachable from external IPs, keep auth enabled unless you have a very deliberate network boundary around Scryer.

If form login is enabled but no local full-admin user has a usable password, use the one-boot recovery flow instead of disabling auth long-term.

See Recover Locked Out Scryer for the SCRYER_RECOVERY_ADMIN_PASSWORD procedure. That guide also covers the important safety step: block external access before starting the recovery boot.