Installing on your own server

A Linux host (Ubuntu 22.04 or newer in this guide) with a public IP. Ports 80 and 443 must be reachable from the internet: Let's Encrypt validates every certificate over them. Nothing else needs to be open inbound; the Connector, later, only connects outward.

apt update && apt -y upgrade
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw --force enable

Docker Engine with Compose v2, the docker compose subcommand rather than the old docker-compose binary.

curl -fsSL https://get.docker.com | sh
docker version
docker compose version

Pick the subdomain everything lives under, for example access.example.com, and create three A records at the server's public IP. The third is a wildcard: one record that covers every vendor app you will ever publish, so DNS is never touched again per app.

Wait for the records to resolve before continuing: dig +short manager.access.example.com and dig +short anything.access.example.com should both print the server IP; the second proves the wildcard.

Clone the repository on the server and move into the deploy directory. The fastest path is the setup script: it derives the cookie domain, the public URL and the passkey relying-party ID from the domain you give it, generates every secret once, pulls the published images and starts the stack. It is idempotent, so re-running it is safe.

git clone https://github.com/captivo-io/captivo-access.git
cd captivo-access/deploy
./setup.sh access.example.com

If you prefer to fill the file by hand, copy .env.prod.example to .env and generate each secret with openssl rand -hex 32. The variables that matter:

The four capability flags RECORDING_ENABLED, NATIVE_GATEWAY, VAULT_ENABLED and ISOLATED_ENABLED are on by default; leave them commented out, and set one to 0 only to switch that capability off. Most operational settings (retention, session limits, the allowlist, the webhook) are managed later from Infrastructure → Policy, where the value set in the console always wins over the environment.

If you used the setup script this already happened. Otherwise start the stack and watch Caddy obtain the first two certificates, for the manager and connect hostnames; that is why ports 80 and 443 had to be open.

docker compose -f docker-compose.prod.yml up -d
docker compose -f docker-compose.prod.yml ps
docker compose -f docker-compose.prod.yml logs -f caddy

You run no database migration by hand. The access-migrate service applies the schema on every up -d, is a no-op when nothing changed, and refuses any destructive change so it cannot silently drop data. If the Manager does not start, read docker compose -f docker-compose.prod.yml logs access-migrate first.

Scheduled jobs are automatic too: the access-cron container checks resource reachability every five minutes and runs audit retention, recording retention and the audit anchor once a day. No host crontab is needed.

Open https://manager.access.example.com/setup and register the first account with a passkey: Touch ID, Windows Hello or a security key. That account becomes the Admin. There is no default or seed account, and there are no passwords.

In the console, open Infrastructure → Custom domain. It shows the exact wildcard record for your domain and your server's IP, with a Verify DNS button. A green result means the wildcard is live and every app you publish will get HTTPS on its first visit. Red means the *.access record from step 3 is missing or has not propagated yet.

From here on the path is the same as on Cloud: install a Connector inside your network, define resources, invite people. If an app address later shows a certificate error or a 502, start with The app does not open.