Deployment models

Choose the deployment model around where the gateway must run and which networks its upstream targets occupy.

Responsibility by model

Concern	Managed	Self-hosted
Runtime location	Provider-controlled boundary.	Customer-controlled infrastructure.
Upstream access	Explicitly approved public HTTPS targets.	Approved public or private routes.
Runtime operation	Managed fleet and configuration delivery.	Customer deployment and dependency operation.
Policy and tools	Approved configuration and caller policy.	The same governed access boundary.

A private target requires a self-hosted route. Do not choose managed deployment on the assumption that a public endpoint will automatically bridge into a private network.

Prepare a self-hosted install

The core dependencies are PostgreSQL and Valkey. Prepare the configured identity provider or supported local identity, secret backend, and customer-controlled OpenTelemetry destination. Use the release’s Helm chart and its values schema.

Credential-bearing configuration uses references. Keep secret values outside chart values and rendered manifests intended for review.

Before installing, render and validate the intended chart configuration in the release checkout:

helm lint deploy/helm/enterprise-mcp-gateway
helm template amelfi deploy/helm/enterprise-mcp-gateway

Rendering validates configuration shape. It does not prove that a cluster can reach the database, identity provider, secret backend, or upstream targets. Use your deployment-specific values for installation and then perform deployment checks.

Validate the release

Use signed images and verify the signature identity and digest for the actual artifact. Retain SBOM evidence. A fixture or synthetic manifest is not proof that a released image was signed.

Follow the installation runbook for the detailed configuration contract.