Deploying | PropelAuth BYO Documentation

Deploying

PropelAuth BYO ships as a single Docker container that runs alongside your existing infrastructure. It’s built in Rust for minimal resource usage and maximum compatibility with any container platform.

The Basics

BYO requires just two things:

A Postgres database (managed or self-hosted)
The propelauth/propelauth-byo Docker image

That’s it. Deploy it to ECS, Kubernetes, Cloud Run, Fly.io, or any platform that runs containers.

Configuration

Configuration files define how each BYO feature behaves. You can find templates in the config template repo:

git clone git@github.com:PropelAuth/byo-config-template.git

Mount these configs into your container at /configs (or specify a custom path with DIRECTORY_CONFIG_PATH). Many teams use git-sync or similar tools to version control their configs and maintain an audit trail. BYO automatically picks up changes without restarts.

Environment Variables

Core configuration:

LICENSE_KEY=pa_...                    # Your BYO license

DATABASE_URL=postgres://...           # Your Postgres connection

DIRECTORY_CONFIG_PATH=/configs        # Config files location (default: ./configs)

PORT=2884                             # API port (default: 2884)

DASHBOARD_PORT=2884                   # Dashboard port (defaults to PORT)

INITIAL_OWNER_USERNAME=admin          # First dashboard user

The DASHBOARD_PORT variable lets you separate dashboard access from API traffic - useful for network-level access control.

Database Connection

Use either a single DATABASE_URL or individual components:

# Option 1: Connection string

DATABASE_URL=postgres://user:pass@host:5432/dbname

# Option 2: Individual settings

PG_HOST=localhost

PG_PORT=5432

PG_USER=postgres

PG_PASSWORD=postgres

PG_DATABASE=postgres

PG_SSL_MODE=prefer  # disable, allow, prefer, require, verify-ca, verify-full

Advanced Database Tuning

For high-traffic deployments, you can tune the connection pool:

PG_POOL_MAX_CONNECTIONS=32           # Max pool size

PG_POOL_MIN_CONNECTIONS=2            # Min pool size

PG_POOL_ACQUIRE_TIMEOUT_SECS=5       # Connection acquisition timeout

PG_POOL_IDLE_TIMEOUT_SECS=600        # Idle connection timeout

PG_POOL_MAX_LIFETIME_SECS=1800       # Max connection lifetime

Resource Requirements

BYO is surprisingly lightweight. Most features like SSO, SCIM, impersonation, and passkeys have minimal resource requirements - even free tier databases work fine.

Session management is the only feature that benefits from additional resources at scale. We’ve handled hundreds of requests per second with just 3 small ECS nodes (1 CPU, 2GB memory) and a ~$20/month AWS RDS instance. If you want to set up autoscaling, the main metric to scale off of is # of requests per second.

If you need help sizing your environment, just reach out and we’ll be happy to help.

Production Considerations

Database: BYO creates tables prefixed with pa_ to avoid conflicts with existing schemas
Updates: Pull the latest image and redeploy - BYO handles migrations automatically
High Availability: Run multiple BYO instances behind a load balancer for redundancy

That’s all there is to it. BYO adapts to your infrastructure, not the other way around.