Skip to content

Prodpeek

One door into production that agents and developers go through, and it only opens for reading.

You want agents debugging production. You do not want them able to change it. Not because they are malicious — because they are eager, and an agent mid-troubleshooting will "just fix" something.

Prodpeek is one self-hosted process. Agents connect to /mcp with a personal key. Every call is checked against a per-service read-only allowlist, deny by default, enforced when the call is made rather than merely hidden from the tool list, and written to a hash-chained audit log. Credentials are injected by the gateway and never reach the agent.

Read-only is a claim. Prodpeek makes it a proof.

Start here

  • New to this?

    Fifteen minutes from nothing to an agent reading your production safely.

    → What Prodpeek is

  • Ready to install?

    One container, one volume, one environment variable.

    → Install

  • Need a credential?

    Step by step for each service, and what to switch off.

    → Connect a service

  • Already running?

    Point Claude Code at it and start asking questions.

    → With Claude Code

The Prodpeek console overview

What it protects you from

Three failures, in the order they actually happen.

The eager fix. An agent is debugging a failing deploy, finds the cause, and restarts the service to confirm. It was right about the cause. It also just restarted production at 14:00 on a Tuesday. With Prodpeek the restart is refused, the refusal has a reason, and the agent tells you what it found instead.

The credential that got away. An agent needs a Coolify token, so someone pastes one into a chat. It is now in a transcript, a log, a vector store and whatever the provider retains. Prodpeek's agents never hold a credential at all — the drop link exists so they cannot.

The read that was not safe. "Read-only" sounds safe until get_application_envs returns your database password. Some genuine reads are the risk. Prodpeek classifies those as read_leaks, denies them, and never sends their output to an LLM even when one is configured.

What it will not do

Three refusals, and they are what make the rest credible.

  • No write path. Not even "write with approval". An approval flow is a write path with a speed bump, and the speed bump is the first thing anyone disables.
  • No AI engine of its own. Bring your own key or use none. Everything works identically either way — the gate, the console, the CLI, the audit log, monitoring, the evidence pack. An AI key only ever adds.
  • No hosted SaaS of your data. It runs on your infrastructure. The only outbound connections are the ones you configured, and prodpeek egress prints them.

How it fits together

     your agent ─── MCP + client key ──▶  /mcp        ─┐
     a human    ─── browser ───────────▶  /admin      ─┤
     an agent   ─── admin key ─────────▶  /api/v1     ─┼─▶  decide()  ──▶  your systems
     CI, a CLI  ─── admin key ─────────▶  /mcp-admin  ─┘      │
                                                              └─▶ audit log (hash-chained)

Every path meets the same decide() before anything reaches one of your systems. There is no fourth path, and decide() is 200 lines of pure Python you can read in one sitting — that is deliberate.

Where things live
github.com/prodpeek/prodpeek The runtime. Source-available: read the code that decides.
github.com/prodpeek/profiles The read-only policies themselves. Apache-2.0.
github.com/prodpeek/docs This site.