The words of production, defined plainly.

An agent reads a request, decides which tools to call, inspects the results and repeats until the goal is met or it needs help. What makes an agent safe in production is not the model but the boundary around it: which tools it can reach, at which permission level, and who approves its changes.

An approval token ties a change to the exact plan a person reviewed. If the plan changes, the token no longer applies. In Kapten, act-level MCP tools require one, so an agent cannot apply a change nobody has seen.

Horizontal autoscaling adds or removes replicas of a service; cluster autoscaling adds or removes the nodes they run on. Both need sensible minimums, maximums and a signal that reflects real demand, otherwise they scale the wrong thing or scale the bill.

The new version (green) is deployed next to the current one (blue) and receives traffic only once it is healthy. Rolling back means switching traffic back. It costs double capacity for the duration of the switch and does not undo database changes.

In a BYOC model the vendor operates the software, but the infrastructure and data live in the customer’s own cloud account, region and bill. It is not self-hosting: the operational work stays with the vendor’s control plane, while ownership stays with you.

A canary release exposes a change to a fraction of users and watches error rates and latency before widening the rollout. It limits the blast radius of a bad release, provided the metrics you watch would actually show the problem.

Cold starts come from pulling images, booting runtimes, warming caches and opening connections. They matter for scale-to-zero environments and sudden traffic spikes. A readiness probe keeps traffic away from an instance until it is warm.

Databases limit concurrent connections, and every replica of every service opens its own. A pooler sits between the application and the database so scaling out the app does not exhaust the database. It is a common first production surprise for apps that worked fine on a laptop.

An image bundles code, dependencies and a start command so a service runs the same way everywhere. Tagging images by commit keeps them addressable, which is what makes a rollback a re-point rather than a rebuild.

A control plane holds desired state and drives infrastructure toward it: provisioning, releasing, scaling. In Kapten, the control plane coordinates work through a scoped role, while your workloads and data run in your account, in the data plane.

The data plane is the cluster, databases and network that serve your users. In a BYOC model it stays in your cloud account, so application traffic and stored data never pass through the vendor.

Regulation, contracts and customer policy often require data to stay in a given country or region. Choosing the cloud account and region for each environment is the practical lever. Residency is one input to a security review, not a substitute for it.

Drift appears when someone changes a resource by hand, or when a tool changes something outside its plan. Undetected drift makes the next plan wrong. Tagging every managed resource and comparing it to desired state is how drift is found.

Egress covers calls from your services to the internet or to other regions. It is frequently billed, and frequently overlooked in estimates. Routing it through a NAT gateway also makes it a security control point.

An environment has its own configuration, secrets, data and owner. Keeping environments separate is what lets you test a change without risking production. In Kapten, environments are the unit agents are scoped to.

If the SLO is 99.9% of requests succeeding over 30 days, the remaining 0.1% is the error budget. Teams spend it on releases and experiments; when it runs out, they slow down and invest in reliability.

First expand the schema so old and new code both work, deploy the new code, migrate data, then contract by removing what is no longer used. It keeps rollbacks possible, because an image rollback alone never undoes a schema change.

The four golden signals are a compact starting set for monitoring any user-facing service. If you only watch four things, watch these, per service and per environment.

A good health check reflects real readiness to serve, not just that the process is alive. Rollouts gated on health checks make “deployed” and “serving” the same claim.

Helm charts describe an application’s Kubernetes resources with values you can override per environment. They are a common way to install third-party software onto a cluster.

A role grants a set of permissions without long-lived credentials: a trusted party assumes it and receives short-lived ones. Kapten operates in your account through a role you create and can revoke at any time.

Idempotent operations make retries safe: re-running a deploy or a provisioning step converges on the same state instead of creating duplicates. Agents retry; their tools should be idempotent.

Infrastructure as code makes changes reviewable, repeatable and reversible. It also makes infrastructure a codebase that someone has to maintain, which is the work a platform takes on for you.

An ingress routes requests by host and path to the right service and usually terminates TLS. Every public endpoint is a decision worth reviewing: what is exposed, to whom, and why.

Kubernetes schedules containers, restarts failed ones, scales them and connects them. It is powerful and standard, and operating it well is a job in itself. Kapten runs your workloads on Kubernetes in your account so the foundation stays portable.

Least privilege limits what a compromised or mistaken actor can do. For agents it applies twice: to the cloud permissions behind the tools, and to which tools and environments the agent can reach at all.

If the liveness probe fails, Kubernetes restarts the container. It should detect deadlocks, not slow dependencies; a liveness probe that checks the database will restart healthy pods during a database blip.

MCP standardises how a client such as Claude Code or Cursor discovers and calls tools exposed by a server. One server works with any compliant client. Kapten exposes its platform through MCP so your assistant can observe, plan and act on your environments.

An MCP server describes the tools it offers, their inputs and their effects. Its design decides what an assistant can do: Kapten’s server groups tools by permission tier so read, plan and act are separate decisions.

A tool has a name, a description and a typed input schema. Good tools are narrow, idempotent and explicit about side effects, so an assistant can choose them correctly and a human can audit them later.

Instead of one agent doing everything, specialists handle architecture, security, cost or releases, often in parallel, and an orchestrator merges their results. It mirrors how an SRE team divides work, and keeps each agent’s permissions narrow.

A NAT gateway gives services in private subnets outbound access without exposing them to inbound traffic. It is billed per hour and per gigabyte, which makes it a regular line in cost reviews.

Logs, metrics and traces are the raw material; observability is whether they let you answer a new question about production. Starting from what changed (the latest deployment) is usually the shortest path.

On-call turns alerts into action: someone is reachable, knows the system and has the access to mitigate. Agents can shorten the investigation, but the decision to act in production stays with the person on call.

The orchestrator reads the request, decides which specialists to involve, runs them and merges their output into one plan for a human to approve. In Kapten’s crew this is Kapten.

A plan lists the resources, configuration and releases a change would create, modify or destroy, ideally with cost and risk. Reviewing a plan is how a human stays in charge of an agent that moves fast.

PITR combines snapshots with transaction logs, so you can recover to just before a bad migration or a mistaken delete. It only counts once you have tested a restore and timed it.

A postmortem records the timeline, impact, causes and follow-up actions. Its value is in the follow-ups that actually get done, not the document itself.

A preview environment deploys a branch or pull request in isolation, with test data and its own secrets. It needs an owner and an end date, or it quietly becomes a permanent cost.

A log line, issue or web page can contain text an agent mistakes for instructions. The defence is structural: narrow tools, read-only by default, and human approval for anything that changes state.

Until the readiness probe passes, the instance is kept out of the load balancer. It protects users from cold starts and from instances that lost a dependency.

Rightsizing lowers requests and instance sizes that are consistently underused, and raises those that are throttled. It is the most reliable cost lever for small teams, alongside removing idle environments.

With addressable images, a rollback re-points the service at an image that already exists instead of rebuilding. It does not undo data or schema changes, which is why migrations need their own plan.

A rolling update starts new instances, waits for them to become healthy, then stops old ones. Gating each step on health turns a bad release into a stopped rollout rather than an outage.

An RPO of fifteen minutes means backups or replication must allow recovery to within fifteen minutes of a failure. Agree it with the data owner before choosing a backup policy.

The RTO bounds how long a restore or failover may take. The only reliable way to know your real recovery time is to rehearse it.

A runbook turns tribal knowledge into steps anyone on call can follow. Runbooks are also good context for agents: they describe what normal looks like and which actions are acceptable.

Secrets belong in a secret store, scoped per environment, injected at runtime and rotatable. They do not belong in code, images, logs or an agent’s conversation history.

Each service has its own image, configuration, scaling and health. Mapping the services and how they connect is the first step in deploying any non-trivial application.

Cloud providers, platforms and customers each own part of the stack. Writing the split down (who patches, who backs up, who responds) is what prevents gaps. Kapten documents its side on the security page.

An SLI is a ratio such as successful requests over total requests, or requests faster than 300 ms. Good SLIs measure what users experience, not what servers report.

An SLO such as 99.9% availability over 30 days turns reliability into a decision. It defines an error budget and tells you when to slow down.

SREs own reliability, deployment, capacity and incident response, and automate the toil around them. Kapten’s agent crew packages that operational work for teams that do not yet have an SRE.

Staging catches what tests miss: configuration, migrations, integrations. It is only as useful as its similarity to production, and it must never hold production credentials.

Terraform declares cloud resources in configuration files and computes a plan before applying it. It is a strong foundation for teams with the time to maintain modules, state and upgrades.

TLS encrypts traffic and proves a server’s identity with a certificate. Certificates expire; automated issuance and renewal remove one of the most common self-inflicted outages.

Vibe coding gets a working prototype fast. The gap appears at deployment: environments, secrets, databases, health checks and rollbacks are not in the prompt. Kapten’s MCP gives the same assistant an SRE crew to close that gap.

A VPC holds subnets, routing and firewall rules for your resources. Keeping databases in private subnets and exposing only what must be public is the baseline network design.

With workload identity, a pod assumes a scoped cloud role through the platform, so no access keys live in environment variables. It removes a whole class of leaked-credential incidents.

It needs several things at once: readiness probes, graceful shutdown, enough capacity during the rollout and backward-compatible database changes. Miss one and the deploy is only zero-downtime most of the time.