Documentation index · Security policy
Container Pilot requires write access to /var/run/docker.sock to recreate containers. Docker socket access is effectively privileged host access. Compromising an administrator account or the application can therefore compromise the Docker host.
- Never expose the Web UI directly to the public Internet.
- Prefer a VPN or trusted management network.
- Use an HTTPS reverse proxy or native HTTPS. Set
CP_SECURE_COOKIE=truebehind a proxy; native HTTPS enables it automatically. - Restrict port
3080with host and network firewalls. - Keep Container Pilot and the Docker host updated.
- Passwords are stored as salted scrypt hashes.
- Sessions use HTTP-only, SameSite cookies.
- State-changing API requests require a matching CSRF token and same-origin request.
- Login attempts are rate limited.
- Viewer accounts cannot execute administrative actions.
The initial password is read through a Docker secret. Never commit the secrets/ directory, /data/state.json, registry credentials, debug dumps, or unredacted production logs.
Registry passwords and webhook tokens are accepted only through configured secret files and are not returned by the API. Webhook URLs are administrator-controlled outbound destinations. HTTPS is enforced unless the explicit development override is enabled. This does not prevent an administrator from selecting an internal HTTPS endpoint; administrator access is already equivalent to privileged Docker-host access.
Native TLS certificate and private-key paths are configured through environment variables, while their contents remain mounted files. Container Pilot requires certificate and key together, supports encrypted keys through a separate passphrase file, and enforces TLS 1.2 or newer. Never store private keys in the repository or application state.
Rollback restores a container image and container configuration. It does not restore database schemas, volumes, bind-mounted files, or external services. Use application-aware backups for stateful workloads.