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
- Step 1 — Sign In to the Console
- Step 2 — Your Organization
- Step 3 — Create an API Key
- Step 4 — Choose Your Gateway Deployment
- Step 5A — Managed Gateway (Axemere-Hosted)
- Step 5B — Self-Hosted Gateway
- Step 6 — Register Workloads
- Step 7 — Register AI Provider Credentials
- Step 8 — Send Your First Request
- Step 9 — Verify in the Console Dashboard
- Next Steps
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-gatewaybinary installed, and outbound TLS access togcp.cp.axemere.ai:9090
Step 1 — Sign In to the Console
- Navigate to console.axemere.ai
- 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:
- Click the organization name in the left sidebar to open the organization switcher
- Select Create Organization
- 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:
- Click Settings in the left sidebar (or navigate to console.axemere.ai/settings)
- Under Organization, find the Org ID field
- Click the copy icon and save this value as
ORG_ID; you will reference it in gateway configuration and requests
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.
- Click Gateway Keys in the left sidebar
- Click Create Key
- Give the key a name (e.g.
prod-backend,staging-ml-pipeline) - Copy the key value. It is shown only once
- Store it securely (e.g. as
AXEMERE_API_KEYin 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.
Step 4 — Choose Your Gateway Deployment
Axemere Gateway supports two deployment models. Choose the one that fits your infrastructure:
| Managed Gateway | Self-Hosted Gateway | |
|---|---|---|
| Hosted by | Axemere | Your infrastructure |
| Setup | Zero config, use the provided URL | Run the Docker image or binary with a bootstrap token |
| Policy management | Console + Axemere defaults | Console + local admin API |
| Best for | SaaS teams, quick start, low ops overhead | Enterprise, data-residency requirements, private VPCs |
Step 5A — Managed Gateway (Axemere-Hosted)
The managed gateway is already running. You only need your API key from Step 4.
Gateway URL:
| Environment | URL | Status |
|---|---|---|
| Development | https://dev.gcp.gw.axemere.ai | Active |
| Production | https://us.gw.axemere.ai | Coming 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_TOKENset, 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 inMVGC_KEY_DIRand 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, andMVGC_NODE_CERT_KEY; these override the auto-provisioned cert for the current session.
5B.1 — Generate a Bootstrap Token
- Click Gateways in the left sidebar
- Click + Enroll Gateway in the top right
- In the dialog, enter a label for this gateway, then click Generate Token
- 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.
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):
- Click Workloads in the left sidebar under Configure
- Click Create Workload
- Enter a workload ID (e.g.
wl-my-app), name, and optional description - 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):
- Click Credentials in the left sidebar under Configure
- Click Add Credential
- Select the provider (OpenAI, Anthropic, Gemini, etc.), enter your API key, and assign a credential ID (e.g.
cred-openai) - 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.
Explicit Mode (Recommended for New Integrations)
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_KEYin 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:
| Panel | What it shows |
|---|---|
| Gateway Traffic | Request volume over time, with blocked requests overlaid; toggle between total and per-node views |
| Blocked Requests | Policy deny decisions this billing period; click to view denied records |
| Active Nodes | Self-hosted gateway nodes with a heartbeat in the last 24 hours |
| Period Spend | Subscription base price plus overage charges accrued so far this billing period |
| Overage Requests | Requests beyond your included quota, billed at your overage rate |
| Current Period Usage | Requests, 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:
- The request returned
decision: "allow"(notdeny) - The
org_idin your request matches the org in the console - The gateway's
healthzshowsstatus: "ok"andcp_status: "connected"
Next Steps
| Goal | Resource |
|---|---|
| Write policy rules to allow/deny by workload, cost, or risk | Policies Configuration Guide |
| Add team members to your org | Team & Billing page in the left sidebar |
| Set up a second gateway node for redundancy | Self-Hosted IT Setup Guide |
| Explore request attribution and delegation | Developer Integration Guide |
| Monitor gateway health and metrics | Network Operations Guide |
| View all admin API endpoints | Admin API Reference |