Automation & Ops devops-automationautopilotmcp-serverinfrastructure-codekubernetesci-cdsecret-redactiondocker

Stakpak

A DevOps agent that runs on your machines continuously and alerts people when needed.

FollowAgents review · FARS-2.1
Not recommended
57/ 100 5-point scale 2.9 / 5
1 2 3 4 5 6
Per-dimension scores and reasoning
1Trust17 / 29 · 2.9/5

Evidence shows: README emphasizes Secret Substitution (LLM does not directly access credentials), Warden Guardrails (network-level policies block destructive operations), mTLS, privacy mode, reversible file operations (automatic backups). Configuration supports allowed_tools, auto_approve, max_turns, indicating permission control and user confirmation mechanisms. Data flow: documentation explains config files and notification routes, but does not detail data flow. Sensitive data handling has dedicated mechanisms but lacks implementation details. Dependency security: Cargo.toml lists dependencies but no vulnerability scanning or audit evidence. External effects: guardrails and backup mechanisms exist but specific policies not described. Rollback: reversible file operations and backups mentioned, but no system-level rollback. Source attribution: publisher unverified, Apache-2.0 license present, but no contributor or maintainer info. Deductions: dependency security lacks evidence, source attribution unclear.

2Reliability8 / 14 · 2.9/5

Evidence shows: README and Cargo.toml consistent, version numbers unified, workspace structure clear. Dependency availability: multiple dependencies listed but no lock file or mirror info. Failure messages: preflight checks and doctor command mentioned, but no specific error handling examples. Deduction: failure messages evidence insufficient.

3Adaptability12 / 18 · 3.3/5

Evidence shows: README describes multiple use cases (DevOps, Kubernetes, CI/CD), supports multiple installation methods (Homebrew, binary, Docker), multiple model providers (Anthropic, OpenAI, Gemini, custom). Capability boundaries: allowed_tools and profile config exist, but not all tools listed. Trigger precision: cron schedules and notification routes exist, but trigger conditions not specified. Environment fit: supports Linux, macOS, Windows, Docker image, but resource requirements not stated. Deductions: capability boundaries and trigger precision details insufficient.

4Convention10 / 18 · 2.8/5

Evidence shows: README structure clear, with installation, usage, configuration, security sections. Install notes detailed, multiple methods. Naming: commands and config keys consistent. Examples and FAQ: multiple examples, but no FAQ. Known limitations: not explicitly listed. License: Apache-2.0, LICENSE file present. Versioning: CI and release process exist, but no CHANGELOG. Maintenance responsibility: not clearly stated. Deductions: missing known limitations, FAQ, CHANGELOG, and maintenance responsibility.

5Effectiveness7 / 13 · 2.7/5

Evidence shows: Output usability: TUI, MCP, ACP interfaces, but output format not detailed. Marginal value: emphasizes automated DevOps tasks, but no comparative data. Cost-benefit: free option (BYOK) exists, but no performance or resource consumption data. Deduction: cost-benefit lacks data.

6Verifiability3 / 8 · 1.9/5

Evidence shows: Claims in README (e.g., security features) lack implementation details or test evidence. Cross-source verification: CI and tests exist, but no independent verification. Fact-inference separation: some claims may be inferred, but not clearly distinguished. Deductions: claims lack traceability, cross-source verification insufficient.

Evidence confidence: Low Reviewed Aug 09, 2026 Reviewed revision 760cd2b5984d
Before you use it
  • Publisher identity unverified; treat source with caution.
  • Dependency security lacks vulnerability scanning or audit evidence; check dependency versions.
  • Security claims (e.g., Secret Substitution) lack implementation details; verify.
  • Missing known limitations and FAQ; potential hidden risks.
  • No CHANGELOG; version changes not transparent.
Review evidence [1][2][3][4][5]
See the full review method →

What does this agent do, and when should you use it?

Stakpak is an open-source DevOps CLI agent that can run on local or remote machines through a terminal TUI, a 24/7 Autopilot runtime, an MCP server, and ACP. It locally indexes and semantically searches Terraform, Kubernetes, Dockerfile, and GitHub Actions content, while running commands, modifying files, and tracking background work. Autopilot runs prompted jobs on schedules and can receive sessions or send notifications through Slack, Telegram, and Discord; behavior is configured in profiles, separately from notification routing. It supports a Stakpak API key as well as Anthropic, OpenAI, Gemini, and custom OpenAI-compatible endpoints. It fits teams that want deployment, troubleshooting, and infrastructure work to remain on their own machines and within their existing DevOps toolchain.

Run stakpak init to identify an application's stack, then start work through the TUI or a configured profile. The agent can execute system commands, stream progress for long-running work such as Docker builds and deployments, and manage background processes such as port forwards or servers; file modifications are described as being automatically backed up for recovery. stakpak up starts the background Autopilot, which runs prompted jobs from cron schedules in autopilot.toml and delivers results to the configured channel and target; inbound Slack, Telegram, or Discord messages can also start sessions. stakpak mcp start exposes local, remote, or combined tools, while stakpak mcp proxy loads upstream MCP servers from mcp.toml or mcp.json. stakpak acp provides an ACP endpoint for a configured Zed editor integration.

  1. A platform engineer maintaining Kubernetes and Terraform can run stakpak init and use the local index and semantic search to locate infrastructure configuration.
  2. An operations team that needs recurring deployment checks can add an Autopilot schedule with --cron and --profile monitoring, then notify Slack #ops.
  3. A developer maintaining an application on a small remote Linux host can run stakpak autopilot doctor and stakpak up after Docker is ready to keep the agent running in the background.
  4. A Zed user who wants a local development agent in the editor can configure stakpak acp as an agent server and start a Stakpak thread.
  5. A team with several existing MCP services can register stdio or HTTP servers with stakpak mcp add and multiplex them through stakpak mcp proxy.

What are this agent's strengths and limitations?

Pros
  • Autopilot separates cron scheduling, inbound channels, notification routes, and profile behavior, allowing distinct configurations for monitoring and deployment-watch workloads.
  • Its MCP support includes local, remote, and combined tool modes, plus stakpak mcp proxy for multiplexing stdio and HTTP upstream MCP servers.
  • The README documents dynamic secret substitution, mTLS by default, privacy mode, and recoverable file changes, addressing credential and change risks in DevOps workflows.
  • Documented provider paths include a Stakpak API key, Anthropic, OpenAI, Gemini, and custom OpenAI-compatible endpoints.
Limitations
  • Autopilot on a remote VM depends on Docker; the documentation recommends more than 2GB of RAM and recommends swap and linger for small Linux hosts.
  • Remote MCP tools and combined mode require an API key, while alternate models and custom endpoints require profile maintenance in config.toml.
  • Slack tools are described as experimental, so the documentation does not establish them as suitable for every production collaboration workflow.
  • Protection can be reduced with --disable-mcp-mtls or --disable-secret-redaction, but the documentation explicitly advises against doing so in production.

How do you install or deploy this agent?

Install the CLI with curl -sSL https://stakpak.dev/install.sh | sh. On Linux or macOS, Homebrew installation is brew tap stakpak/stakpak followed by brew install stakpak; the image is available with docker pull ghcr.io/stakpak/agent:latest. For first use, run stakpak and follow the interactive flow to create a Stakpak API key. For your own provider credentials, run stakpak auth login --provider anthropic --api-key $ANTHROPIC_API_KEY, replacing anthropic with openai or gemini as needed. Autopilot on a remote VM requires Docker accessible to the current user; the documentation recommends 2GB+ RAM and recommends swap on small Linux hosts.

How do you use this agent?

After authentication, run stakpak init, then run stakpak to open the TUI. Before starting the persistent runtime, run stakpak autopilot doctor, then stakpak up; use stakpak autopilot status and stakpak autopilot logs to inspect it, and stakpak down to stop it. For BYOK or a local compatible endpoint, define a profile in ~/.stakpak/config.toml and run, for example, stakpak --profile byok. To start local MCP tools without an API key, use stakpak mcp start --tool-mode local.

How does this agent compare with similar options?

Compared with a PaaS-style deployment approach, Stakpak is positioned as an agent that runs on the user's own machines while aiming to provide a continuous operations experience without that hosting lock-in. The documentation does not establish parity with specific PaaS hosting, scaling, or service features.

FAQ

Do I have to use a Stakpak API key?
No. The documented options include Anthropic, OpenAI, and Gemini API keys, plus a custom OpenAI-compatible endpoint in a profile. Local MCP tool mode is explicitly documented as requiring no API key.
How does Autopilot stay active and notify a team?
Start it with stakpak up; schedules use cron expressions and profiles, and notifications route through configured Slack, Telegram, or Discord channels and targets. A remote Linux host may need linger enabled so user services survive logout.
Will the model see my secrets?
The README states that dynamic secret substitution lets the model work with credentials without seeing their actual values, and it provides secret redaction. Do not use --disable-secret-redaction, which prints secrets in plaintext.
Can it work with existing MCP tools and Zed?
Yes. stakpak mcp proxy supports discovered or explicitly specified mcp.toml and mcp.json configurations for stdio and HTTP upstream MCP servers. Zed can be configured with stakpak acp as its agent-server command.

Compare agents like this one

The same FARS review applied across the shortlist this agent qualifies for.

Related agents