Console Setup Guide

For: Platform engineers and administrators setting up an Axemere Gateway organization through the console.

This guide walks through provisioning your organization on the Axemere control plane, creating API keys, and connecting your first gateway, all through the Axemere console.

Table of Contents


Prerequisites

  • An Axemere account: navigate to console.axemere.ai to sign in
  • For managed gateway: nothing additional required
  • For self-hosted gateway: a host with Docker or the mvgc-gateway binary installed, and outbound TLS access to gcp.cp.axemere.ai:9090

Step 1 — Sign In to the Console

  1. Navigate to console.axemere.ai
  2. Sign in with Google or create an account with your work email

On first sign-in, a personal workspace is automatically created for your account. If you are setting up a gateway for a team or company, you will need to create an organization:

  1. Click the organization name in the left sidebar to open the organization switcher
  2. Select Create Organization
  3. Enter your organization name and confirm

A user can belong to more than one organization. Use the organization switcher in the sidebar to move between them. Each organization has its own org_id, policies, credentials, and execution records.


Step 2 — Your Organization

After signing in you land on the Dashboard. If this is your first time, you'll also see a Get Started item at the top of the left sidebar; it provides a checklist-style walkthrough of the same steps below and is a good companion to this guide.

Before going further, note your org_id:

  1. Click Settings in the left sidebar (or navigate to console.axemere.ai/settings)
  2. Under Organization, find the Org ID field
  3. Click the copy icon and save this value as ORG_ID; you will reference it in gateway configuration and requests

Sign In

Dashboard

Settings - Org ID

Copy ORG_ID
e.g. 01hx...

You can also rename your organization on this page. Org ID is permanent and cannot be changed.


Step 3 — Create an API Key

API keys authenticate requests to the managed gateway. Each key is scoped to your organization.

  1. Click Gateway Keys in the left sidebar
  2. Click Create Key
  3. Give the key a name (e.g. prod-backend, staging-ml-pipeline)
  4. Copy the key value. It is shown only once
  5. Store it securely (e.g. as AXEMERE_API_KEY in your environment or secrets manager)

Keys are prefixed mvgc_k_. If you lose a key, revoke it and create a new one; there is no way to retrieve a key after it is created.

Gateway Keys page

Create Key
give it a name

Copy key value
shown once only

Store as
AXEMERE_API_KEY


Step 4 — Choose Your Gateway Deployment

Axemere Gateway supports two deployment models. Choose the one that fits your infrastructure:

Managed GatewaySelf-Hosted Gateway
Hosted byAxemereYour infrastructure
SetupZero config, use the provided URLRun the Docker image or binary with a bootstrap token
Policy managementConsole + Axemere defaultsConsole + local admin API
Best forSaaS teams, quick start, low ops overheadEnterprise, data-residency requirements, private VPCs

Your Organization

Managed Gateway
dev.gcp.gw.axemere.ai
Axemere-hosted

Self-Hosted Gateway
your VPC / on-prem
Docker or binary

Axemere Control Plane
gcp.cp.axemere.ai

Policy - Credentials
Ledger - Metering

AI Providers
OpenAI - Anthropic
Gemini - Azure - Cohere


Step 5A — Managed Gateway (Axemere-Hosted)

The managed gateway is already running. You only need your API key from Step 4.

Gateway URL:

EnvironmentURLStatus
Developmenthttps://dev.gcp.gw.axemere.aiActive
Productionhttps://us.gw.axemere.aiComing soon

Verify the gateway is up:

curl -s https://dev.gcp.gw.axemere.ai/healthz | jq .
# → {"status":"ok","version":"..."}

Your API key is passed as a Bearer token on every request:

Authorization: Bearer ${AXEMERE_API_KEY}

No further setup is needed for the gateway itself. Continue to Step 6 to configure workloads and credentials.


Step 5B — Self-Hosted Gateway

Self-hosted gateways connect to the Axemere control plane using a bootstrap token. The bootstrap token is a single-use credential that registers your gateway node, pulls its initial policy bundle, and now also automatically issues an mTLS certificate from the control plane CA.

mTLS certificates are now issued automatically. On first startup with MVGC_BOOTSTRAP_TOKEN set, the gateway generates an ECDSA P-256 key pair and CSR, sends it to the CP, and receives a 90-day certificate. The certificate and CA bundle are stored in MVGC_KEY_DIR and loaded automatically on subsequent startups; no operator-provisioned cert files needed.

To renew before the 90-day expiry, generate a new bootstrap token and restart with it set. The gateway renews automatically when the cert is within 14 days of expiry.

If you need to use your own certificates, set MVGC_CP_CA_CERT, MVGC_NODE_CERT, and MVGC_NODE_CERT_KEY; these override the auto-provisioned cert for the current session.

5B.1 — Generate a Bootstrap Token

  1. Click Gateways in the left sidebar
  2. Click + Enroll Gateway in the top right
  3. In the dialog, enter a label for this gateway, then click Generate Token
  4. Copy the token value. It is shown only once

Bootstrap tokens are single-use. If your gateway fails to start before you use it, generate a new one.

5B.2 — Start the Gateway

Set the following environment variables, then start the gateway:

Environment variables:

export DATABASE_URL="postgres://user:pass@localhost:5432/mvgc_gateway?sslmode=disable"
export MVGC_GATEWAY_MODE="self-hosted"
export MVGC_CP_ADDR="gcp.cp.axemere.ai:9090"
export MVGC_BOOTSTRAP_TOKEN="<token from console>"
export MVGC_ORG_ID="<your ORG_ID from Step 3>"
export MVGC_NODE_ID="gw-node-prod-01"
export MVGC_ADMIN_TOKEN="<choose a strong secret>"
export MVGC_BUNDLE_ID="default"

Config file (mvgc.yaml) — recommended for bare-metal deployments:

gateway:
  mode:        "self-hosted"
  org_id:      "<your ORG_ID from Step 3>"
  node_id:     "gw-node-prod-01"
  admin_token: "<choose a strong secret>"
  bundle_id:   "default"

database:
  url: "postgres://user:pass@localhost:5432/mvgc_gateway?sslmode=disable"

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

See Config File reference for file location and full schema. Secrets you prefer not to store in a file (DATABASE_URL, MVGC_ADMIN_TOKEN) can remain as environment variables; they override file values.

Docker:

docker run -d --name mvgc-gateway \
  -p 7080:7080 \
  -e DATABASE_URL \
  -e MVGC_GATEWAY_MODE \
  -e MVGC_CP_ADDR \
  -e MVGC_BOOTSTRAP_TOKEN \
  -e MVGC_ORG_ID \
  -e MVGC_NODE_ID \
  -e MVGC_ADMIN_TOKEN \
  -e MVGC_BUNDLE_ID \
  axemere/mvgc-gateway:latest

Binary:

./mvgc-gateway

Verify the gateway connected to the control plane:

curl -s http://localhost:7080/healthz | jq '{status, cp_status}'
# → {"status":"ok","cp_status":"connected"}

cp_status must be "connected", not "offline" or "unconfigured". If it is offline, check that MVGC_CP_ADDR, MVGC_BOOTSTRAP_TOKEN, and MVGC_ORG_ID are set correctly.

ConsoleAxemere Control PlaneSelf-Hosted GatewayConsoleAxemere Control PlaneSelf-Hosted GatewayStart with MVGC_BOOTSTRAP_TOKENGateway ready, healthz cp_status:connectedCreateBootstrapToken(org_id, ttl)token (shown once)Register(node_id, bootstrap_token)org confirmed + policy bundleGetPolicyBundlebundle YAMLGetWorkloadsworkload definitionsListNodeCredentials(node_id)resolved credential set

Step 6 — Register Workloads

A workload identifies the application sending requests through the gateway. Workloads are used in policy rules and execution records.

Via the console (recommended):

  1. Click Workloads in the left sidebar under Configure
  2. Click Create Workload
  3. Enter a workload ID (e.g. wl-my-app), name, and optional description
  4. Click Save

Via the admin API (self-hosted, or scripted provisioning):

# For managed gateway — use the gateway URL + your admin token
# For self-hosted — use http://localhost:7080 + your MVGC_ADMIN_TOKEN
GATEWAY_URL="https://dev.gcp.gw.axemere.ai"   # or http://localhost:7080
ADMIN_TOKEN="${MVGC_ADMIN_TOKEN}"

curl -s -X PUT "${GATEWAY_URL}/v1/admin/workloads" \
  -H "MVGC-Admin-Token: ${ADMIN_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "workload_id": "wl-my-app",
    "name": "My Application",
    "org_id": "<YOUR_ORG_ID>",
    "description": "Production AI workload",
    "labels": {
      "team": "ml-platform",
      "env": "production"
    }
  }'

Step 7 — Register AI Provider Credentials

Credentials are the AI provider API keys the gateway injects into outbound requests. They are stored encrypted and never exposed after registration.

Via the console (recommended):

  1. Click Credentials in the left sidebar under Configure
  2. Click Add Credential
  3. Select the provider (OpenAI, Anthropic, Gemini, etc.), enter your API key, and assign a credential ID (e.g. cred-openai)
  4. Click Save; the key is encrypted immediately and cannot be retrieved after saving

Via the admin API (self-hosted, or scripted provisioning):

Register one credential per AI provider you intend to use:

# OpenAI
curl -s -X PUT "${GATEWAY_URL}/v1/admin/credentials" \
  -H "MVGC-Admin-Token: ${ADMIN_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "credential_id": "cred-openai",
    "provider": "openai",
    "mode": "alias",
    "api_key": "'${OPENAI_API_KEY}'"
  }'

# Anthropic
curl -s -X PUT "${GATEWAY_URL}/v1/admin/credentials" \
  -H "MVGC-Admin-Token: ${ADMIN_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "credential_id": "cred-anthropic",
    "provider": "anthropic",
    "mode": "alias",
    "api_key": "'${ANTHROPIC_API_KEY}'"
  }'

# Google Gemini
curl -s -X PUT "${GATEWAY_URL}/v1/admin/credentials" \
  -H "MVGC-Admin-Token: ${ADMIN_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "credential_id": "cred-gemini",
    "provider": "gemini",
    "mode": "alias",
    "api_key": "'${GEMINI_API_KEY}'"
  }'

Step 8 — Send Your First Request

With an API key, workload, and credential registered, you are ready to send a governed request.

Send a structured ActionRequest directly to the gateway:

# GATEWAY_URL=https://dev.gcp.gw.axemere.ai  (managed)
# GATEWAY_URL=http://localhost:7080           (self-hosted)
curl -s -X POST "${GATEWAY_URL}/v1/actions:execute" \
  -H "Authorization: Bearer ${AXEMERE_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "schema": "mvgc.action_request.v2",
    "request_id": "req-001",
    "workload_id": "wl-my-app",
    "org_id": "<YOUR_ORG_ID>",
    "connector_hint": "openai",
    "credential_hint": "cred-openai",
    "action": {
      "type": "ai.infer",
      "method": "POST",
      "target_host": "api.openai.com",
      "target_path": "/v1/chat/completions",
      "params": {
        "model": "gpt-4o-mini",
        "messages": [{"role": "user", "content": "Hello, world!"}]
      }
    },
    "attribution": {
      "project_id": "proj-hello-world"
    }
  }' | jq '{decision, record_id, result_status: .result.status_code}'

Expected:

{
  "decision": "allow",
  "record_id": "01hx...",
  "result_status": 200
}

Proxy / Drop-in Mode (Existing SDK Integrations)

Configure your existing AI SDK to use the gateway as a proxy. No changes to your prompt code; just update the base URL and API key:

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://dev.gcp.gw.axemere.ai/v1",
    api_key=os.environ["AXEMERE_API_KEY"],
)

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "Hello, world!"}],
)
print(response.choices[0].message.content)
import os
import anthropic

client = anthropic.Anthropic(
    base_url="https://dev.gcp.gw.axemere.ai",
    api_key=os.environ["AXEMERE_API_KEY"],
)

The gateway injects your registered AI provider credentials automatically; the AXEMERE_API_KEY in the SDK is your gateway API key, not your OpenAI/Anthropic key. Your provider keys never leave the gateway or control plane.


Step 9 — Verify in the Console Dashboard

Return to the console at console.axemere.ai. The Dashboard updates within a few seconds of your first successful request:

PanelWhat it shows
Gateway TrafficRequest volume over time, with blocked requests overlaid; toggle between total and per-node views
Blocked RequestsPolicy deny decisions this billing period; click to view denied records
Active NodesSelf-hosted gateway nodes with a heartbeat in the last 24 hours
Period SpendSubscription base price plus overage charges accrued so far this billing period
Overage RequestsRequests beyond your included quota, billed at your overage rate
Current Period UsageRequests, tokens in, and tokens out vs. your plan quota (shown when you have an active subscription)

If the dashboard shows no data after sending a request, check:

  1. The request returned decision: "allow" (not deny)
  2. The org_id in your request matches the org in the console
  3. The gateway's healthz shows status: "ok" and cp_status: "connected"

Request sent
decision: allow

Gateway
records + hashes

Control Plane
ledger + metering

Console Dashboard
metrics update


Next Steps

GoalResource
Write policy rules to allow/deny by workload, cost, or riskPolicies Configuration Guide
Add team members to your orgTeam & Billing page in the left sidebar
Set up a second gateway node for redundancySelf-Hosted IT Setup Guide
Explore request attribution and delegationDeveloper Integration Guide
Monitor gateway health and metricsNetwork Operations Guide
View all admin API endpointsAdmin API Reference