Stakpak: terminal AI for DevOps

Stakpak is trying to solve a very specific problem: the people who run modern software stacks spend huge chunks of their day inside a terminal, jumping between cloud commands, deployment scripts, log streams, and cluster dashboards. The pitch is that an artificial intelligence agent can sit in that terminal, understand the stack, and handle the repetitive parts without getting direct access to the secrets that unlock production systems. (stakpak.dev) That sounds small until you look at what “DevOps work” actually means in practice. A single engineer might need to write Terraform for infrastructure, inspect Kubernetes objects for a failed rollout, patch a continuous integration pipeline, and redeploy a service before customers notice anything is wrong. (devx.stakpak.dev) (github.com) Kubernetes, the orchestration system Stakpak talks about most, is itself a machine for keeping containers alive across many servers. You describe the desired state of an application in files, and Kubernetes keeps trying to make reality match that description by creating, restarting, or replacing containers as needed. (kubernetes.io) That model is powerful, but it produces a lot of operational grunt work. When a deployment fails, engineers often have to inspect events, compare configuration files, check secret mounts, trace network policies, and rerun commands until they find the one missing field or mis-scoped permission that broke the rollout. (kubernetes.io) Secrets are one of the hardest parts of that workflow. In Kubernetes, a Secret can hold a password, token, or key, but the official documentation warns that Secrets are stored unencrypted by default in the underlying data store unless teams add extra protections such as encryption at rest and least-privilege access controls. (kubernetes.io) That is where artificial intelligence agents make many infrastructure teams nervous. A coding assistant that can read files, run commands, and call external models is useful, but it also creates a new path by which credentials, internal topology, or production data could leak into prompts, logs, or model providers. (kubernetes.io) (github.com) Stakpak’s answer is to put the agent directly in the terminal and wrap it in security controls. The project describes itself as an open-source DevOps agent, licensed under Apache 2.0, that can generate infrastructure code, debug Kubernetes, configure continuous integration and continuous delivery pipelines, and automate deployments. (github.com) (lib.rs) The core claim is “secret substitution.” In the project’s own description, the large language model works with credentials “without ever seeing them,” which means the system tries to replace real secrets with placeholders when the model is reasoning, then inject the actual values only at execution time. (github.com) Stakpak pairs that with what it calls Warden guardrails. On the company’s pricing page, those guardrails are described as a network sandbox, and project documentation describes Warden as a policy enforcement layer that sits between the agent and production systems to block destructive operations before they run. (stakpak.dev) (deepwiki.com) The project is also leaning hard on auditability. Stakpak says the open-source tier includes local session audit logs stored in SQLite, and its broader product pitch emphasizes that the agent can run on your machines, with your own model keys, or with locally run models instead of forcing every action through a hosted black box. (stakpak.dev 1) (stakpak.dev 2) Under the hood, Stakpak has two related pieces. The newer “agent” product is the terminal-native assistant for live operations, while the older DevX tooling generates deployment artifacts for platforms such as Kubernetes, Terraform, Docker Compose, Argo CD, and GitHub Workflows from higher-level configuration. (github.com) (devx.stakpak.dev) That split matters because it shows where the company thinks the market is going. Infrastructure teams no longer just want code generation before deployment; they want an agent that can stay resident after deployment, monitor systems, react to health events, and only ask a human for help when it hits a boundary. The GitHub repository describes exactly that model as an agent that lives on your machines “24/7” and “only pings when it needs a human.” (github.com) The attraction is obvious. If an agent can turn a broken deployment into a short diagnosis, draft the fix, open the right files, and apply a safe rollout in minutes, it compresses work that now burns entire afternoons of senior engineering time. (github.com) (stakpak.dev) The risk is just as obvious, and it sits one layer higher than the usual “artificial intelligence makes mistakes” complaint. Once an agent is allowed to inspect infrastructure, choose actions, and execute commands, teams are no longer only trusting Kubernetes manifests or Terraform plans; they are trusting the hidden chain of prompts, tool calls, redaction rules, guardrails, and approval logic that sits between the human and production. (github.com) (deepwiki.com) That is why early adoption will probably hinge less on flashy demos than on proof. Infrastructure teams will want to know whether secret substitution really prevents exposure across all execution paths, whether guardrails fail closed instead of open, whether every action is reproducible in logs, and whether a human can verify what the agent actually did after a 3 a.m. incident. Those are not marketing questions; they are production questions. (github.com) (stakpak.dev) (kubernetes.io) If Stakpak can make that case, it fits a real shift in infrastructure work: the terminal stops being just a place where humans type commands and starts becoming a cockpit where humans supervise an agent. If it cannot, then the same teams that distrust putting secrets in plain text will distrust putting operational judgment inside a model-driven layer they cannot fully inspect. (stakpak.dev) (kubernetes.io)