Deploy on your infrastructure

The repository includes Dockerfile and compose.production.yml. The platform stack contains a gateway, API/dashboard, video and webhook workers, PostgreSQL, and SeaweedFS. The two public websites are independent static sites.

Try the stack on your machine

From the repository, with dependencies installed:

pnpm exec tsx scripts/setup-deployment.ts --name orilla
docker compose --env-file .local/deployments/orilla/compose.env \
  -f compose.production.yml up --build -d

Open http://127.0.0.1:18080. The generator saves initial credentials in .local/deployments/orilla/credentials.json. Read them locally and change the password after signing in.

An init service runs migrations and creates the first administrator. Repeating a deployment preserves existing accounts and credentials.

Prepare your own domains

pnpm exec tsx scripts/setup-deployment.ts --name orilla \
  --origin https://video.example.com \
  --s3-origin https://uploads.example.com \
  --email [email protected]

Replace the example domains. The platform origin serves the dashboard and API; the second exposes signed S3 uploads. Configure HTTPS and DNS before validating uploads.

Running the generator again with the same name preserves credentials. To change an existing installation’s origins, edit its variables while preserving data.

Coolify

1. Create an application from the repository with the Docker Compose build pack.
2. Select /compose.production.yml and use the repository root as the base.
3. Enter variables from the generated private file into the runtime configuration.
4. On gateway, configure the platform domain on internal port 8080 and the uploads domain on 8333.
5. Keep PUBLIC_URL and S3_PUBLIC_ENDPOINT set to the public HTTPS URLs, without internal ports.
6. Use API_TRUST_PROXY_HOPS=2 for the Coolify proxy → gateway → API chain and restrict trusted proxies to the corresponding networks.

The repository records an operational Coolify installation and bounded HTTPS validation. This does not validate a new installation’s domains, proxy, or providers. See implementation and verification status before attributing remote coverage to a feature.

Publish the landing page and documentation

Configure each site’s public variables from its .env.example, using your final domains. Build separately:

pnpm build:site
pnpm build:docs

Publish apps/site/dist and apps/docs/dist as two static sites. They do not need a running Node server. PUBLIC_* variables are embedded at build time: rebuild after changing them. Do not use these variables for secrets.

Persistence and maintenance

Preserve the project name and volumes when updating. PostgreSQL stores data; SeaweedFS stores media originals and outputs; the worker needs temporary processing space.

Your team manages capacity, restorable backups, updates, redundancy, and a CDN if needed. The initial stack uses one instance per service. It does not establish an availability or production capacity guarantee by itself.

Email and account keys

Password recovery and incident email require SMTP_HOST, SMTP_PORT, SMTP_FROM, optional paired credentials, and SMTP_TLS_MODE. Relay acceptance does not guarantee inbox delivery. Account and recovery explains the link lifecycle.

MFA requires MFA_ENCRYPTION_KEY; incident destinations require NOTIFICATION_ENCRYPTION_KEY. These are dedicated, stable keys containing 32 bytes encoded as hexadecimal. Configure them in the private environment and back them up with the data they encrypt. They are not rotated automatically at startup. Without the corresponding key, the feature reports unavailability; the rest of the platform does not configure external providers automatically. See notification channels.