Deploying Raucle: cloud, on-premise, and everywhere between

EPIC28 Ltd · 1 September 2026

In every architecture review, the deployment question arrives in the first hour: where does this thing sit? It is the right question. A security control's position determines what it can see, what it can stop, and what its records are worth. A gate that sits to the side of the execution path is a gate in name only.

Raucle supports three deployment shapes. They are not three products — they are the same gate, placed at three different depths of your architecture. This post walks through each, what it looks like in cloud and on-premise environments, and the hardening baseline we ship for production.

Shape one: embedded in the agent

The lightest deployment is a library inside the agent's own process. You install the SDK, register the middleware, and the gate runs on every tool call inside the agent runtime:

pip install 'raucle[agent-framework]'

agent.middleware.add(RaucleFunctionMiddleware(
    gate=gate, sink=receipt_sink))

Adapters exist for the Microsoft Agent Framework, LangChain, AutoGen, CrewAI and OpenClaw, plus the MCP client path. The agent inherits the gate: no extra network hops, no new infrastructure, receipts written wherever you point the sink. This is how teams start — often in a single afternoon — and it is the right shape for development, pilots and low-risk workloads.

Its honest limitation: the gate lives inside the same trust boundary as the agent. If the host is compromised, the gate is compromised with it. For regulated production, that pushes most organisations to the second shape.

Shape two: the gateway

For production, Raucle runs as a gateway: a small network service that sits between the agent runtime and the tools. Agents make MCP calls to the gateway; the gateway checks each call against policy, executes allowed calls, denies the rest, and writes its receipts to storage you control.

The gateway ships as a container. In its simplest production form it is a Docker Compose stack: the gateway on an internal network, Caddy in front for TLS with automatic certificates, policies mounted read-only, receipts on a persistent volume. It runs identically on a cloud VM, in Kubernetes, or on a bare-metal box in your own comms room — the container does not care where the metal lives.

In cloud environments, the same pattern takes the native form. On Azure, the repository ships a bicep-based sidecar deployment behind API Management: the agent platform calls the APIM endpoint, APIM enforces its own policies, and the Raucle gateway runs as the MCP sidecar in front of the tools. On AWS, the gateway deploys behind your load balancer of choice with receipts landing in your account's storage. In both cases the security posture is identical to on-premise: the gate sits on the execution path, and the evidence stays in infrastructure you control.

Shape three: credential custody

The strongest deployment is what we call credential custody: the gateway does not just check calls, it holds the tool credentials. The agent never sees the API keys. For each allowed call, the gateway brokers a scoped, short-lived credential, performs the action, and records it.

This closes the last gap in the other two shapes. If your gate sits on the path but the agent still holds the tool's key, a path that bypasses the gate can still reach the tool. Under custody there is no credential to bypass with: acting without a receipt is not merely forbidden, it is impossible, because the agent cannot authenticate to anything. If you deploy one shape in a bank, a hospital or a factory, deploy this one.

Where Raucle sits determines what it can prove. A receipt proves what happened where the gate was — and nowhere else.

The production hardening baseline

Whatever the shape, the gateway ships with a production security guide, and the baseline is the kind of thing an audit team expects to see:

• TLS everywhere. The gateway itself runs plain HTTP behind Caddy with automatic Let's Encrypt certificates, HSTS and security headers; bring your own certificates on-premise.
• Network isolation. The gateway is never exposed directly: only the proxy answers on 80/443, and the gateway stays on an internal Docker network.
• Secrets done properly. No keys in images or environment variables: Docker secrets or an external manager — Vault, AWS Secrets Manager — feed the admin and signing keys at runtime.
• Least-privilege runtime. The container runs as a non-root user, policies are mounted read-only, and there is no default admin key — it must be injected.
• Rate limiting and WAF. Built-in rate limits on the gate endpoints, and an OWASP Core Rule Set WAF option in front of the admin panel.
• SIEM streaming. Every gate decision forwards in real time to Splunk, Elasticsearch or Azure Sentinel, with buffering and retry if the SIEM is down.

Choosing a shape

The decision usually maps to risk, not to cloud versus on-premise. Embedded suits development and pilots. The gateway suits most production deployments, cloud or on-premise, and is where the majority of integrations land. Credential custody suits the workloads where a wrong action is a reportable event: payments, production changes, customer data.

The cloud question is mostly orthogonal — the gateway runs wherever containers run, the SDK runs wherever Python runs, and neither needs to phone home. What matters is where the gate sits relative to the execution path, and who holds the credentials.

The deployment guides live in the repository alongside the code, including the Docker Compose stack, the Azure bicep templates and the SIEM integration walkthroughs. If you want a second opinion on where the gate belongs in your architecture, that is a conversation we enjoy: [email protected].