Deployment requirements

Workforce Intelligence runs as a set of Docker containers on a single Linux box that you control. This article lists what must be in place before you start either install path (AWS CloudFormation or on-premises).

The box#

You need a Linux machine, virtual or physical, that:

• Runs Docker with the Docker Compose plugin. install.sh installs Docker for you when it is missing, and the CloudFormation template installs Docker and the Compose plugin during first boot.
• Has sudo access for the account you install with, and openssl available (used to generate secrets).
• Can reach the internet to pull container images from ghcr.io and, if you use a domain, to complete certificate issuance.
• Has enough room for Postgres, the application, the web server, the Dokku container, and the per-company Coworker workbench containers that run on the same Docker daemon. The CloudFormation template defaults to a t3.large (2 vCPU, 8 GiB) with a 40 GiB root volume as a starting point.

Ports#

Port	Used for	Notes
80	Web app over HTTP	Also used for the certificate challenge when you configure a domain.
443	Web app over HTTPS	Used when you set WI_DOMAIN.
22 (default)	Dokku SSH, where Builders push code for deployed Apps	Change it with WI_DOKKU_SSH_PORT.

Open these to wherever your users and Builders connect from. You can change the published HTTP and HTTPS ports with WI_HTTP_PORT and WI_HTTPS_PORT (see Configuration reference).

The Dokku container publishes its SSH port on the host, and the default is port 22. If the box's own SSH server already listens on 22, set WI_DOKKU_SSH_PORT to a free port before you start the stack, and open that port to your Builders.

The CloudFormation template opens ports 80 and 443 (to HttpCidr and HttpsCidr) and port 22 only when you set SshCidr. If your Dokku SSH port is something else, add an inbound rule for it to the stack's security group yourself.

A GitHub token for the image registry#

The application images are private packages on the GitHub Container Registry (ghcr.io): wi-server and wi-web, published under the image owner radialventures by default.

You need:

1. A GitHub account with read access to the wi-server and wi-web packages. Confirm this on the organization's packages page before you start. Membership in a GitHub organization does not by itself grant read access to every private package.
2. A classic personal access token for that account with the read:packages scope and nothing else. Fine-grained personal access tokens do not work with GHCR. This is a limitation of the GitHub registry, not of Workforce Intelligence.

You provide the username and token once, to install.sh, as GHCR_USER and GHCR_TOKEN. Docker stores the login on the host, and later pulls and in-app updates reuse it. See Registry credentials for updates for what to do when the token expires.

An address for the app#

Decide how people will reach the box before you install:

• A domain name that resolves to the box. With it, Caddy obtains and renews a real certificate and serves HTTPS. See Domains and HTTPS.
• A hostname or IP address with plain HTTP. The app is served, but in production the session cookie is marked secure, so browsers do not keep a sign-in made over plain HTTP. Use a domain with HTTPS for anything people will sign in to.

The address you choose becomes WI_ALLOWED_ORIGIN, for example https://wi.example.com.

Where the box must be reachable from#

If you use a domain with automatic HTTPS, ports 80 and 443 must be reachable from the public internet so the certificate authority can verify the domain. A box behind NAT, such as one in a private subnet routed through a NAT gateway, cannot complete that verification.