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.