One replica, no transparent resumption
Run exactly one server replica. Runtime sockets, grants, transfers, forwarding streams and live-view routing are process-local. Recreate upgrades interrupt connections. Horizontal scaling, zero-downtime failover and restart-transparent streams are not available. An interrupted action may already have happened. Check the website’s resulting state before deciding what to do next; do not automatically replay actions with unknown outcomes. Use/healthz for health checks and /readyz for readiness, including database connectivity. A healthy response alone does not verify pairing or browser operations.
Reverse proxy and resource limits
- Use HTTPS/WSS, preserve the canonical Host and enforce exact origins for authenticated endpoints. These request checks are separate from unrestricted browser document targets: no control-plane hostname is protected by a page URL denylist. Keep administrative sign-ins in a separate non-automated profile unless intentionally delegating that authority.
- Allow authenticated runtime and media WebSocket upgrades, capability streaming and the forwarding relay when used.
- Disable proxy buffering and caching on streaming routes. Set explicit request-size, request-time and idle limits compatible with your configured application quotas.
- Never log Authorization headers, cookies, device proofs, capability URLs, secret capture/export bodies or private page content.
- Keep PostgreSQL private. Align container memory, disk and open-stream limits with application quotas.
Backups
Back up PostgreSQL state and the encryption/authentication keys needed to use that state. Store backups and keys under protected access, and test restoration in an isolated environment before you need it. Dedicated browser profiles live on the machine running the native CLI and can contain signed-in sessions. A server database backup does not include them. Treat any profile backup as sensitive; stop the browser before copying its profile, and do not substitute a personal daily-driver profile. Secret vaults are ephemeral. Do not include them in ordinary backups or crash reports. Back up server data and browser profiles separately.Upgrades and recovery
- Record your current CLI, server image and chart versions and preserve the deployment configuration and secret references.
- Back up persistent state and confirm you can restore it. Review the target version’s requirements before changing the deployment.
- Schedule downtime and stop active browser work. Keep the server at one replica during the upgrade; use the chart’s Recreate deployment strategy.
- Follow the Helm guide for the upgrade and schema setup. Do not clear the database as an upgrade step.
- Check readiness, then verify device approval, MCP connection and a harmless browser operation through your public HTTPS endpoint. If used, also test upload/download, forwarding and secret export with synthetic data rather than real credentials.