What problem does it solve? Moving a Jac server from local development to production involves configuring database backends, secrets, TLS, autoscaling, and external integrations, and mistakes like missing cpu_request or SQLite on multi-replica setups cause silent failures. ## Core Features & Use Cases - Production server configuration: Covers jac start flags, config profiles, disabling Swagger docs, and choosing SQLite, MongoDB, or Redis backends with clear precedence rules. - Kubernetes deployment: Documents jac start --scale with dry-run validation, HPA autoscaling, TLS via cert-manager, jac scale status, and the destructive jac scale destroy. - External integrations: Explains webhook walkers with API-key plus HMAC auth, WebSocket walkers with broadcast, S3 file storage with presigned URLs, Prometheus metrics, and Redis distributed locks. - Use Case: You have a Jac app running locally and need to ship it to a Kubernetes cluster with a custom domain, HTTPS, autoscaling, and a MongoDB backend while keeping secrets out of the repo. ## Quick Start Deploy my Jac app to Kubernetes with TLS and autoscaling by running jac start app.jac --scale --dry-run first to validate the config.