# 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](https://github.com/PropelAuth/byo-config-template):

```bash
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:

```bash
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:

```bash
# 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:

```bash
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.