Docs / Self-host

// RUN IT IN YOUR VPC

Self-host & the data-plane split

The gateway core is open and self-hostable. Run it in your own network and prompts, responses, and provider keys never leave your boundary. Only the leaf hash and metering numbers cross to the control plane — and even those are optional. You still emit the identical chained, anchored, independently-verifiable receipts.

What crosses the boundary

The system has two planes. The data plane is the gateway proxy that sees your traffic; the control plane is the dashboards, registry, and aggregate stats. The split is deliberately narrow:

Stays in your VPCOptionally crossesNever crosses
Prompt & response bodies Leaf hash (receipt_hash) Prompt content
Provider API keys Metering (tokens, cost, latency) Response content
Redaction & guardrail rules Merkle roots for anchoring Provider secrets
Hash-only egress. In posture: hashed_only the receipt's inputs_hash and outputs_hash are the only content-derived values, and they are one-way SHA-256 of already-redacted bodies. There is no path from an egressed receipt back to a prompt.

Install the core

The open gateway core, the SDK, and the receipt format are free to run with no receipt cap. Paid plans are for the managed control plane, never for the proof.

shell
# run the open gateway core in your own infra npm i @agentics/gateway-core # or with the container docker run -p 8080:8080 \ -e AGENTICS_POSTURE=hashed_only \ -e AGENTICS_ANCHOR=self \ ghcr.io/agentics/gateway-core:latest # every dispatch still emits a chained, anchored, verifiable receipt. npx @agentics/verify <receipt-hash>

Who anchors

Anchoring writes a batch's Merkle root to a public ledger. You choose where that happens:

The proof is identical either way. A self-hosted receipt and a managed receipt have the same schema, the same canonicalization, and the same Merkle fold. The six-line recipe verifies both, byte for byte — your auditor can't tell which produced it, and doesn't need to.

Data residency

Because the data plane is yours, residency is a deployment choice, not a contract clause. Run a gateway per region and route to it with the conditional routing DSL on $meta.region — each region's content stays in-region while every region's receipts fold into one verifiable ledger.