Deployment
Configure your values file, install the Helm chart, and verify the running services.
Values File Templates
Create a values yaml file and update the values accordingly.
Remote HTTPS
Use this template if your deployment will sit behind a real domain with TLS enabled.
global:
# Apex domain for BoltMCP. The chart derives per-service hostnames as
# web.<domain>, auth.<domain>, server.<domain>, inspector.<domain>.
# Recommended: choose the `boltmcp` subdomain of your company's domain.
domain: "boltmcp.example.com"
# Advertise https:// URLs everywhere.
tls:
enabled: true
# Storage class for the bundled database's persistent volume. Leave unset
# to use the cluster default (GKE/AKS ship one). On EKS, set this to the
# class you created in Cluster Prep.
# storageClass: gp3
oidc:
adminUser:
# Email for the first admin user (must be a real email address).
email: "admin@example.com"Note that setting global.tls.enabled: true does not provision TLS itself.
Local HTTP
Use this template if you're deploying locally e.g. Docker Desktop Kubernetes.
global:
# Domain your HTTP ingress serves, e.g. an /etc/hosts entry pointing
# web.<domain>, auth.<domain>, server.<domain> and inspector.<domain>
# at your ingress controller.
domain: "boltmcp.local"
# Advertise http:// URLs everywhere.
tls:
enabled: false
oidc:
adminUser:
# Email for the first admin user (must be a real email address).
email: "admin@example.com"Pin a Chart Version
Set a version once and reference it in subsequent commands. Use the latest release version you've been provided:
export BOLTMCP_VERSION=0.3.8Install the Chart
Before installing BoltMCP, make sure you've completed Cluster Preparation
If it isn't already, set the shell variable HELM_REGISTRY_CONFIG to point to your BoltMCP key file. This is used implicitly to authorize Helm commands.
export HELM_REGISTRY_CONFIG="$PWD/keys/boltmcp-key.json"Deploy all services into the boltmcp namespace:
helm install boltmcp \
oci://europe-west2-docker.pkg.dev/boltmcp-platform/boltmcp-alpha/charts/boltmcp \
--version ${BOLTMCP_VERSION} \
-n boltmcp \
-f ./config/values-prod.yaml \
--timeout 15m--timeout 15m is required on EKS Auto Mode. On a brand-new EKS Auto
Mode cluster the general-purpose NodePool starts with zero nodes, and bringing
up the first node can take longer than Helm's default hook timeout. For GKE/AKS deployments the default --timeout 5m
is generally sufficient.
Verify the Deployment
Watch pods until all show Running / Completed:
kubectl get pods -n boltmcp -wExpected output:
NAME READY STATUS RESTARTS AGE
boltmcp-database-0 1/1 Running 0 2m52s
boltmcp-keycloak-xxxxxxxxxx-xxxxx 1/1 Running 0 2m52s
boltmcp-mcp-inspector-xxxxxxxxxx-xxxxx 1/1 Running 0 2m52s
boltmcp-mcp-server-xxxxxxxxxx-xxxxx 1/1 Running 0 2m52s
boltmcp-rest-api-xxxxxxxxxx-xxxxx 1/1 Running 0 2m52s
boltmcp-web-xxxxxxxxxx-xxxxx 1/1 Running 0 2m52s
boltmcp-migrate-core-xxxxx 0/1 Completed 0 2m14s
boltmcp-seed-xxxxx 0/1 Completed 0 2m14sIf a pod is not starting, check its logs and events:
kubectl logs -n boltmcp <pod-name>
kubectl describe pod -n boltmcp <pod-name>Retrying a failed install
If the install fails, the release is left in failed state and another plain helm install will error with "cannot re-use a name that is still in use". Check the failed job's pod logs to fix the underlying issue before deleting the job so a fresh one is created, then retry with helm upgrade --install:
kubectl delete job -n boltmcp <failed-job-name>
helm upgrade --install boltmcp \
oci://europe-west2-docker.pkg.dev/boltmcp-platform/boltmcp-alpha/charts/boltmcp \
--version ${BOLTMCP_VERSION} \
-n boltmcp \
-f ./config/values-prod.yaml \
--timeout 15m