Control Plane Connectivity

For: Platform operators running a self-hosted gateway connected to the Axemere Control Plane (Core Platform or higher).

Operations Overview | Approval Workflows | Quarantine | Risk Scoring | CP Connectivity | Telemetry

When a gateway is connected to the Axemere Control Plane (CP), it receives signed policy bundles, submits execution record hashes for the Merkle audit ledger, and keeps credentials and workloads in sync, all over gRPC with mutual TLS. This guide covers the connection lifecycle, offline fallback behavior, and how to diagnose connectivity issues.

Free Gateway (no CP): If you are running the gateway without a CP connection (no MVGC_CP_ADDR), this guide does not apply: your gateway operates entirely from local policy files.

Managed Gateway (Growth Pack / Dedicated): If you are using the Axemere-hosted gateway fleet, CP connectivity is handled automatically. You do not configure it directly.

Table of Contents

• Connection Modes
• Self-Hosted Gateway: Check-In Mode
• Offline Fallback Behavior
• Enrollment and mTLS
• Policy Bundle Durable Cache
• Record Hash Submission
• Healthz Status Fields
• Environment Variables
• Troubleshooting
• See Also

Connection Modes

When MVGC_CP_ADDR is not set, the gateway runs as a Free Gateway with local policy files and no distributed features: no ledger, no remote bundles, no console-managed API keys or credentials. All CP-connected modes require MVGC_CP_ADDR.

Running your own CP is not a standard offering. Companies running self-hosted gateways connect to Axemere's CP, either through the console (Core Platform) or via the managed fleet. Private CP deployments are available through a separate enterprise arrangement.

Self-Hosted Gateway: Check-In Mode

The check-in is an idle keepalive: it fires after the gateway has been inactive for MVGC_CHECKIN_IDLE_THRESHOLD (default: 60s). While the gateway is actively processing requests, the CP connection is kept current through request activity itself; the idle check-in is the fallback that fires when traffic goes quiet.

This means your gateway always appears online in the console as long as it is processing requests or has been idle long enough to check in.

The gateway only fetches updated data when the version number has changed, minimizing bandwidth.

Configure the idle threshold:

export MVGC_CHECKIN_IDLE_THRESHOLD=60s   # default

Offline Fallback Behavior

When the control plane is unreachable, the gateway continues serving requests using its cached state:

Hash submission queue: Record hashes are written to the pending_hash_submissions Postgres table when the CP is offline. The queue is durable: it survives gateway restarts. Entries are drained automatically when the CP reconnects. Monitor mvgc_pending_hash_submissions to track backlog depth during extended outages.

Enforcement posture: Depending on your org's configuration, the gateway may begin blocking AI requests after a grace period if the CP remains unreachable for an extended time. This posture (permissive vs. strict) is set by Axemere for your org. Contact support if you need to adjust it.

Enrollment and mTLS

Self-hosted gateways authenticate to the CP using mTLS. The private key is generated on the gateway and never transmitted. For full details on enrollment, certificate lifecycle, and revocation, see the mTLS Guide.

Quick reference:

Via environment variables:

# First startup — enrolls with the CP and stores cert in MVGC_KEY_DIR
export MVGC_BOOTSTRAP_TOKEN="<token from console>"
export MVGC_CP_ADDR="gcp.cp.axemere.ai:9090"
export MVGC_ORG_ID="<your org_id>"
export MVGC_KEY_DIR="/var/lib/mvgc/keys"
./mvgc-gateway

Or in mvgc.yaml (see Config File):

control_plane:
  addr:            "gcp.cp.axemere.ai:9090"
  bootstrap_token: "<token from console>"

gateway:
  org_id: "<your org_id>"

security:
  key_dir: "/var/lib/mvgc/keys"

Subsequent startups use the stored cert automatically. Certs are auto-renewed 14 days before expiry (90-day validity).

Policy Bundle Durable Cache

The last successfully fetched policy bundle is cached in the gateway_bundles Postgres table. This cache survives restarts:

• If the CP is unreachable at startup, the gateway loads the cached bundle and operates normally.
• The cache is updated after every successful GetPolicyBundle fetch.
• To force a cache refresh: POST /v1/admin/policy/cache (deletes the cached bundle and triggers a fresh fetch on next check-in or stream reconnect).

# Force policy cache refresh
curl -s -X DELETE http://localhost:7080/v1/admin/policy/cache \
  -H "MVGC-Admin-Token: $MVGC_ADMIN_TOKEN"

Record Hash Submission

The gateway submits a SHA-256 hash of each execution record to the CP ledger via SubmitRecordHash. This is how records become part of the Merkle audit trail.

Monitor the queue depth via the mvgc_pending_hash_submissions gauge. Alert if it stays elevated: it indicates the CP has been offline for an extended period.

Healthz Status Fields

GET /healthz (no auth required) exposes CP connectivity status:

curl -s http://localhost:7080/healthz | jq '{cp_status, bundle_id, last_hash_submit_at}'

{
  "cp_status": "connected",
  "bundle_id": "01955f3e-0000-7abc-8def-000000000001",
  "last_hash_submit_at": "2026-03-12T14:30:00Z"
}

Use last_hash_submit_at to detect a stalled hash submission pipeline. If this timestamp stops advancing while requests are being processed, investigate CP connectivity and queue depth.

Environment Variables

Troubleshooting

See Also

• mTLS Guide — enrollment, certificate lifecycle, revocation
• Bundle Signing — how bundles are signed and verified
• Managed Gateway Guide — full managed mode configuration
• Merkle Proof Verification — what happens to submitted record hashes
• Telemetry — mvgc_pending_hash_submissions metric
• Glossary — check_in