Stakpak Agent: a 24/7 DevOps agent that keeps your apps running

The problem Stakpak Agent targets: unattended DevOps without handing over the keys

Most agent tooling assumes a human is watching the transcript. Stakpak assumes the opposite. The README describes it as an agent that "lives on your machines 24/7, keeps your apps running, and only pings when it needs a human," and the pitch is explicitly about the trust boundary: "You can't trust most AI agents with your DevOps. One mistake, and your production is toast." The intended user is a small platform or DevOps team that wants the convenience of a managed PaaS scheduler but keeps the execution environment on hardware it controls. The workspace layout supports that reading. Cargo.toml lists members for cli, tui, libs/agent-core, libs/server, libs/gateway, and four separate MCP crates (client, config, server, proxy), which is the shape of a system that runs locally and talks outward through a proxy rather than a thin client for a hosted backend. The homepage is stakpak.dev and the docs live at stakpak.gitbook.io/docs. Nothing in the README describes a hosted execution tier, so treat the machine you install on as the machine that does the work.

How the agent runs: schedules, profiles, notification routing, and secret substitution

Configuration is split across two files. The README states that ~/.stakpak/config.toml holds profile behavior (model, allowed_tools, auto_approve, system_prompt, max_turns, provider credentials) and ~/.stakpak/autopilot.toml holds runtime wiring (schedules, channels, notification routes, service/server settings). A schedule references a profile by name, and the profile decides how the agent behaves for that run. The README is explicit that these are separate concerns: "schedule --profile monitoring: behavior for runs started by that schedule" while "notification --target \"#ops\": where schedule notifications are sent; it does not choose the model or tools." That separation is the design decision worth noticing. A health check and a deploy watcher can share one behavior profile and still report to different destinations, which is what the deploy-watch example does with --notify-target. On the safety side, the README lists Secret Substitution (the LLM works with credentials without seeing them), Warden Guardrails (network-level policies that block destructive operations before they run), and mTLS for MCP traffic. The mechanism is not spelled out in detail beyond those descriptions, so the honest summary is that substitution and policy enforcement happen outside the model's context, and the README does not document how the substitution map is stored or rotated.

Installing Stakpak Agent and starting a first scheduled check

The README gives a one-line install script, then two commands: init to understand your apps and tech stack, and autopilot up to start the background agent. Run them in that order on the host that will keep running. The README also documents up and down as lifecycle aliases for the autopilot subcommands.

curl -sSL https://stakpak.dev/install.sh | sh # install Stakpak
stakpak init # understand your apps and tech stack
stakpak autopilot up # start the autonomous agent, running 24/7 in the background

After the agent is up, the README lists the canonical subcommands for checking on it. status reports the current state, logs prints output, and down stops the runtime. The README shows the same lifecycle as a single alias pair, stakpak up and stakpak down.

stakpak autopilot status
stakpak autopilot logs
stakpak autopilot down

To add work, the README's example registers a health schedule with a cron expression, a prompt, and a profile name. The profile must already exist in ~/.stakpak/config.toml; the schedule only references it by name.

stakpak autopilot schedule add health --cron '*/5 * * * *' --prompt 'Check health' --profile monitoring

The README gives the equivalent block for ~/.stakpak/autopilot.toml, which is what the CLI writes when you add a schedule or channel. Notification routing uses two words throughout: channel is the transport, target is the destination inside it.

[notifications]
channel = "slack"
target = "#ops"

[[schedules]]
name = "health"
cron = "*/5 * * * *"
prompt = "Check health"
profile = "monitoring"

Autopilot prerequisites and the doctor check

The README is unusually direct about host requirements, and they are the first thing to check because autopilot fails at boot rather than degrading. Docker must be installed and accessible to the current user. 2GB+ RAM is recommended for reliable autopilot plus sandbox runs. Swap is strongly recommended on small Linux hosts, and Linux user services may require linger to survive logout. The README states that stakpak up now runs preflight checks before startup, and that stakpak autopilot doctor can be used as a deployment-readiness check before first boot. The documented sequence is doctor first, then up.

stakpak autopilot doctor
stakpak up

Treat doctor as a gate: if it does not pass, the failure is in the host, not in the prompt you wrote. The Dockerfile shows the same posture from the packaging side. It uses aqua for lazy-loading CLI tools, which the file says reduces image size from roughly 2GB to roughly 600MB, with tools downloaded on first use and cacheable through a volume at /home/agent/.local/share/aquaproj-aqua. That means the first kubectl or terraform invocation inside a fresh container is slow, and an air-gapped host will not be able to fetch those tools at all.

Where Stakpak Agent is the wrong tool

Stakpak is a runtime you operate, not a service you subscribe to. If you do not have a machine that stays up, or you cannot install Docker on it, the autopilot path does not apply. The README's own prerequisite list rules out a laptop that sleeps, a locked-down CI runner without Docker access, and a host with under 2GB of RAM if you want sandbox runs. The second limitation is scope. The README frames the work as DevOps: generating infrastructure code, debugging Kubernetes, configuring CI/CD, and automating deployments. It is not presented as a coding assistant for application logic, and the profile fields (allowed_tools, max_turns) are about constraining an operational agent, not about pair programming. The third is the guardrail model itself. Warden is described as network-level policy that blocks destructive operations before they run. That is a useful layer, but it is a policy layer: if you write a schedule prompt that asks for something destructive and your policy does not cover that operation, the README does not describe a second line of defense. There is also no documented rollback mechanism for changes the agent makes. The README does not mention one, so plan on your own version control and backups rather than assuming the agent can undo its work.

How Stakpak differs from a general-purpose coding agent

The closest comparison is a general coding agent such as Claude Code or Codex, which the surrounding search traffic shows people reach for when they want an agent in a terminal. The difference is the operating model rather than the model itself. A coding agent is session-oriented: you open it, describe a task, watch it, and close it. Stakpak's autopilot is daemon-oriented: stakpak up starts a background runtime, schedules fire on cron expressions, and output is routed to Slack, Telegram, or Discord instead of to your terminal. That changes what the agent is good at. A session agent can afford to ask clarifying questions; a scheduled run at */5 * * * * cannot, which is why the profile carries auto_approve and allowed_tools as fixed policy decided in advance. The second difference is credential handling. Stakpak's secret substitution is designed so the model operates on credentials without reading their values, a concern that session agents generally leave to the operator's shell environment. If your problem is "help me write this Terraform module today," a session agent is the simpler fit. If your problem is "tell me at 3am when the deploy drifts," Stakpak is built for that shape of work.

Maintenance, release cadence, and licence

The last push to the default branch was on 2026-07-06, and the most recent release listed is v0.3.88 on 2026-06-10, preceded by v0.3.87 the same day and v0.3.86 on 2026-06-04. The workspace version in Cargo.toml matches at 0.3.88, so the crates and the CLI move together. That is a fast patch cadence on a 0.x version, which cuts both ways: fixes land quickly, and a 0.x minor bump can still change behavior. Treat upgrades as something to test rather than apply blindly, and check the release notes for the CLI and the MCP crates separately, since the workspace publishes stakpak-mcp-client, stakpak-mcp-server, and stakpak-mcp-proxy as their own versioned crates. The project is licensed Apache-2.0, and the repository includes a THIRD-PARTY-NOTICES.md file, which indicates bundled dependencies are tracked there. Apache-2.0 permits commercial use and modification and includes a patent grant, but it also carries notice and attribution obligations, and the Dockerfile pulls in a large set of third-party tools through aqua that carry their own licences. If you redistribute a Stakpak-based image, review those notices rather than relying on the top-level licence alone. None of this is legal advice; it is a pointer to the files that exist.

Editorial conclusion

Adopt Stakpak if you already run Docker on a Linux box, want cron-style health and deploy checks with Slack or Telegram notifications, and refuse to hand raw credentials to a model. Do not adopt it as a hosted control plane or a general chat assistant; the README positions it as a self-managed runtime on your machines. Verify three things before trusting it with production: that stakpak autopilot doctor passes on the target host, that the schedule prompts you write are narrow enough to be safe when they run unattended, and that your Slack target resolves, since private channels and DMs are more reliable addressed by channel ID than by name.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. stakpak/agent on GitHub