Deploy the runtime, understand what it is doing, and keep the user path recoverable when something fails. Kestrel runs locally through Local Core and remotely through a runner service; these guides cover the controls and evidence required to operate both forms.
Prepare and deploy
Start with local and remote runner connections, then configure environment and authentication, migrations, and review the production operating model. Keep runner and provider credentials on trusted servers, record each provider's exact deployment identity, and prove the request path before serving users.
Investigate and recover
Locate the affected request with Observability, structure the incident with Reliability, inspect persisted evidence with Replay, and use Troubleshooting when you need to begin from the visible symptom.
Authority and security
Use Environment and auth, Model authority, and Security to assign profiles, providers, tools, approvals, execution boundaries, and network egress to their owning services.
Control and quality
Use Operator control to act on work already in flight. Compare behavior before and after a change with Ruhroh evaluations and quality gates. Kestrel One model operators should also understand credential leases and model access decisions.
Mission Control owns project work and acceptance; Budgets and allocations own spend authority and ledger evidence.
Production delivery and rollback
Use Production delivery for Vercel's native web delivery and the separate local, target-by-target Fly, RunPod-worker, and Environment runtime commands.