Axemere.ai

Cloud Deployment

For: Platform engineers deploying Axemere Gateway on AWS, GCP, or Azure.

IT Setup Overview | PostgreSQL Setup | Linux (Debian/Ubuntu) | Linux (RHEL/Fedora) | macOS | Docker/Podman | Kubernetes | Windows (WSL2) | Cloud

Step-by-step deployment guides are available for each cloud provider:

ProviderGuideComputeDatabase
GCPGCP QuickstartCompute Engine VMCloud SQL PostgreSQL 15
AWSAWS QuickstartEC2 InstanceRDS PostgreSQL 15
AzureAzure GuideAzure VMAzure Database for PostgreSQL

Table of Contents

PostgreSQL: Cloud Managed Databases

Create a PostgreSQL 15+ instance using your cloud console or OpenTofu module, then connect as the admin user and run:

CREATE USER mvgc_gateway WITH PASSWORD '<your-generated-password>';
CREATE DATABASE mvgc_gateway OWNER mvgc_gateway;

Use the host and port from your cloud provider's connection details. Enable SSL:

# Format: postgres://<user>[:<password>]@<host>[:<port>]/<database>?sslmode=<disable|require>
DATABASE_URL=postgres://mvgc_gateway:<your-generated-password>@<cloud-host>:5432/mvgc_gateway?sslmode=require

Note sslmode=require instead of disable -- cloud managed instances require TLS.

See PostgreSQL Setup for the full setup guide including other options.

TLS Termination

The gateway HTTP server does not terminate TLS natively. TLS should be handled by a reverse proxy or load balancer in front of the gateway.

Recommended options:

OptionExampleNotes
Kubernetes Ingressnginx-ingress or AWS ALBUse ingress.enabled: true in Helm values
Cloud load balancerGCP HTTPS LB, AWS ALBTerminate TLS at the LB; forward plain HTTP to pod port 7080
nginx / Caddy sidecarproxy_pass http://localhost:7080For bare-metal; configure nginx to listen on 443 and forward

Ensure that downstream clients trust the TLS certificate presented by your termination layer.

For the admin API, restricting access by network policy or mTLS at the reverse proxy layer is strongly recommended in production.

Running Multiple Replicas

The gateway is horizontally scalable. Multiple replicas can run behind a load balancer with the following considerations:

  • Shared database: All replicas must share the same DATABASE_URL -- Postgres is the shared coordination point.
  • Unique node IDs: Each replica must have a unique MVGC_NODE_ID to avoid key and registry collisions.
  • Hash queue: The offline hash queue is in-memory per replica. If a replica restarts mid-queue-drain, queued hashes are re-submitted from Postgres on the next drain cycle; no data is lost.
  • Record log file: Each replica should write MVGC_RECORD_LOG_FILE to a separate path or separate volume to avoid interleaved writes. Alternatively, disable this log (set to /dev/null) when using Postgres as the primary audit store.
  • No sticky sessions: Any replica can serve any request. No sticky sessions are required for the execute endpoint.
  • Kubernetes: Use replicaCount: 2 minimum and enable the PodDisruptionBudget (podDisruptionBudget.enabled: true -- on by default in the Helm chart).

Trusting the CA Certificate

For cloud and Kubernetes workloads using SSL MITM proxy mode, see Kubernetes -- Trusting the CA Certificate for the ConfigMap + SSL_CERT_FILE approach.

See Also