Stakpak Agent: A DevOps Autopilot That Keeps the LLM Away From Your Secrets
Ship your code, on autopilot. An open source agent that lives on your machines 24/7 and keeps your apps running. 🦀
At a glance
- What is it?
- Stakpak is an Apache-2.0 Rust agent that runs scheduled DevOps prompts on your own machines, with secret substitution and network-level guardrails. The design is worth understanding before you point it at production.
- Who is it for?
- Adopt Stakpak if you already run Docker on a host you control and want scheduled, prompt-driven checks that notify a Slack or Telegram channel, with the LLM never holding raw credentials. Do not adopt it if you need a stable API, cannot grant Docker access to the agent user, or expect unattended remediation of production incidents.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 72 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Stakpak fills: scheduled DevOps prompts without handing over the keys
Most LLM agent tooling assumes you will paste a credential into a prompt or export it into the agent's environment. Stakpak's README frames the problem directly: one mistake from an agent with production access and "your production is toast." The project's answer is a Rust binary that runs on your own machines, executes prompts on a cron-like schedule, and reports back through chat transports. The target user is an infrastructure or platform engineer who already administers Linux hosts and wants routine checks (health probes, deploy watching) handled by a prompt rather than a bespoke script. It is not a hosted control plane. The agent lives where your apps live, and the README's pitch is "all the upside of a PaaS, none of the lock-in." That framing sets the scope: single-host or small-fleet autonomy, not multi-tenant orchestration.
Autopilot, schedules and channels: the runtime model
The autonomous piece is called Autopilot. The README gives lifecycle commands: stakpak autopilot up, status, logs, down, and doctor. There are aliases, stakpak up and stakpak down, for the first and last. Underneath, two configuration files split responsibilities. ~/.stakpak/config.toml holds profile behavior: model, allowed_tools, auto_approve, system_prompt, max_turns, and provider credentials. ~/.stakpak/autopilot.toml holds runtime wiring: schedules, channels, notification routes, and service settings. A schedule is a cron expression plus a prompt plus a profile reference. A channel is a transport (slack, telegram, discord) plus a target (a Slack channel name or ID). The README is explicit that these are separate concerns: schedule --profile monitoring controls how the run behaves, while notification --target "#ops" only controls where the message goes. Schedules inherit the default notification route unless you pass --notify-target or --notify-channel. That separation is the most interesting design decision in the project, because it means a monitoring profile can be reused across schedules that report to different destinations without duplicating model or tool settings.
Secret substitution and Warden guardrails: what the safety claims actually describe
Two mechanisms carry the security argument. Secret substitution is described as letting the LLM "read/write/compare secrets without seeing actual values." The README does not publish the substitution implementation, so the exact interception point (process environment, file read, API call) is not verifiable from the supplied material. Treat the claim as a stated design goal rather than a demonstrated property. Warden guardrails are described as network-level policies that block destructive operations before they run. Again, the policy language and rule format are not shown in the README; the linked documentation at stakpak.gitbook.io/docs is where that would live. What is documented is a set of adjacent features: mutual TLS for MCP connections, a privacy mode that redacts IP addresses and AWS account IDs, and secure password generation. Together these suggest the threat model is credential exfiltration and accidental destructive commands, not a fully sandboxed execution environment. If your review process requires reading the enforcement code before trusting it, the README alone will not satisfy that.
Getting it running: install, init, doctor, up
Installation is a shell script: curl -sSL https://stakpak.dev/install.sh | sh. Then stakpak init to let the agent inspect your apps and tech stack, and stakpak autopilot up to start the background runtime. The README lists prerequisites for a remote VM: Docker installed and accessible to the current user, 2GB or more RAM recommended for autopilot plus sandbox runs, swap strongly recommended on small Linux hosts, and linger may be required for Linux user services to survive logout. The command stakpak autopilot doctor is positioned as a deployment-readiness check before first boot, and stakpak up runs preflight checks. A minimal Slack setup looks like this: stakpak autopilot channel add slack --bot-token "$SLACK_BOT_TOKEN" --app-token "$SLACK_APP_TOKEN" --profile ops --target "#ops", followed by a schedule such as stakpak autopilot schedule add health --cron '*/5 * * * *' --prompt 'Check health' --profile monitoring. The equivalent autopilot.toml uses a [notifications] block with channel and target keys, and [[schedules]] entries with name, cron, prompt, profile, and optionally notify_target. The README notes that channel IDs are more reliable than names for private channels, DMs, and scripts.
Where the design strains: single-host assumptions and a fast release cadence
The prerequisites are the limitation. Docker access for the current user is effectively root-equivalent on that host, so the trust boundary is the machine, not the agent. If you cannot grant Docker to the agent's user, Autopilot's sandbox runs are not available to you. The 2GB RAM recommendation and the swap guidance imply small VMs will struggle, and the linger requirement means a naive systemd setup will silently stop after logout. There is also a release-cadence signal: v0.3.86, v0.3.87, and v0.3.88 all shipped within about a week in June 2026, and the version is still 0.x. Rapid 0.x iteration is normal for this category, but it means configuration keys and subcommands can move. The README already shows both lifecycle aliases and canonical subcommands for the same actions, which is convenient now and a maintenance surface later. Anyone pinning to a specific tag should expect to re-read cli/README.md on upgrade.
How it differs from a general-purpose coding agent
A general agent such as a terminal-based coding assistant is invoked interactively, works inside one repository, and stops when the session ends. Stakpak inverts that: the default mode is a long-running service driven by cron expressions, with output routed to chat rather than stdout. The practical difference shows up in configuration. A coding agent's config is mostly model selection and permissions. Stakpak's config splits behavior (profiles in config.toml) from delivery (channels and notification routes in autopilot.toml), and adds schedules as first-class objects. It also ships domain features a coding agent would not need: infrastructure code indexing for Terraform, Kubernetes, Dockerfile and GitHub Actions; a documentation research agent; asynchronous task management for background commands like port forwarding; and subagents behind an --enable-subagents flag. If your work is editing application code in a repo, a coding agent is the better fit. If your work is repeatedly asking the same operational question on a timer, Stakpak's model is closer to what you want.
Licence, maintenance and what to verify before adopting
The project is Apache-2.0, which permits commercial use and modification and includes an express patent grant. That is a permissive licence with no copyleft obligation on your own code; the usual requirements around attribution and notice retention still apply. This is not legal advice, and if you redistribute the binary or embed it in a product, have counsel review the NOTICE and attribution requirements. Maintenance cost is the real question. The README points to cli/README.md and the GitBook docs for full setup, which means the repository README is a summary and the operational detail lives elsewhere. Before committing, verify three things on your own host: that stakpak autopilot doctor passes cleanly, that a schedule with a deliberately failing prompt produces the notification you expect on the target you configured, and that the Warden policy format in the docs covers the destructive operations you actually care about. The last one matters most, because the guardrail claim is the load-bearing part of the pitch and the README does not show the rules.
Editorial conclusion
Adopt Stakpak if you already run Docker on a host you control and want scheduled, prompt-driven checks that notify a Slack or Telegram channel, with the LLM never holding raw credentials. Do not adopt it if you need a stable API, cannot grant Docker access to the agent user, or expect unattended remediation of production incidents. Before first boot, run stakpak autopilot doctor and confirm your host meets the 2GB RAM and swap guidance, then add a single schedule with a narrow prompt and watch its notifications for a week.
Community notes