Skip to content

Production

In production, Authara is typically deployed as part of a larger application stack.

Authara runs as a dedicated authentication service behind a reverse proxy or gateway and is usually mounted under:

/auth

Example routing:

/auth/* → Authara
/*      → Application

This allows authentication to live on the same origin as the application while remaining operationally separate.

Typical production topology

A common production deployment looks like this:

Client
  ↓
Load Balancer / Reverse Proxy / Authara Gateway
  ├── /auth/* → Authara Core
  └── /*      → Application

Authara Core connects to PostgreSQL internally.

Same-origin deployment

Authara is deployed on the same origin as the application.

Example:

https://example.com/auth/* → Authara
https://example.com/*      → Application

This simplifies:

  • cookie handling
  • CSRF protection
  • browser-based authentication flows
  • SSR and HTMX integrations

In this model, PUBLIC_URL should be set to the application origin without /auth.

Example:

PUBLIC_URL=https://example.com

HTTPS

Production deployments should always use HTTPS.

This is required for secure cookie handling and to protect authentication traffic in transit.

TLS is usually terminated by:

  • a load balancer
  • a reverse proxy
  • Authara Gateway (depending on configuration)
  • ingress infrastructure

Database

Authara requires PostgreSQL.

Production PostgreSQL should be treated as a durable infrastructure dependency.

Important considerations include:

  • backups
  • restore procedures
  • upgrade planning
  • monitoring
  • secure credential management

Authara does not manage PostgreSQL for you.

Migrations

Schema changes must be applied explicitly before starting a new Authara version that requires them.

Authara does not auto-migrate.

Production upgrade flow typically looks like this:

  1. deploy the new migrations image
  2. apply migrations
  3. deploy the new Authara Core version
  4. verify startup and health

See:

Configuration

Production configuration is provided through environment variables.

This usually includes:

  • PostgreSQL connection settings
  • PUBLIC_URL
  • JWT issuer and signing keys
  • session settings
  • OAuth provider configuration
  • rate limiting settings

Secrets should be stored in a secure secret management system rather than committed files.

Challenge-policy and rate-limit values may be changed by an operator only when the corresponding environment variable is absent. Supplying one explicitly locks that individual value to deployment configuration. Secrets and bootstrap settings are never runtime-editable. See Operator runtime settings.

See:

Scaling

Authara Core is designed to run as a separate service.

In multi-instance deployments, operators should consider:

  • shared PostgreSQL access
  • consistent environment configuration
  • load balancing behavior
  • schema compatibility during rollout

Some features, such as the default in-memory rate limiter, are instance-local.

Set AUTHARA_CACHE_PROVIDER=redis to share rate limits and access-token revocations across instances.

Runtime-setting writes take effect immediately on the accepting Core replica. Other replicas reconcile the PostgreSQL revision every two seconds. Plan for that bounded delay during concurrent rollouts and policy changes.

Operational model

Authara is designed to behave like infrastructure.

This means:

  • startup should be deterministic
  • schema changes should be explicit
  • runtime should not mutate shared state unexpectedly
  • failures should be visible and fail fast

Authara validates schema compatibility during startup and refuses to start if the database schema is incompatible with the running binary.

Summary

A production Authara deployment usually consists of:

  • Authara Core
  • PostgreSQL
  • a reverse proxy or gateway
  • your application

Authara is normally mounted under /auth on the same origin as the application, with explicit migrations and operator-controlled upgrades.