3. Configure & install Helm

Owner: Cloud Ops

This step is shared by AWS, Google Cloud, and Azure. The provider guide from Step 2 produced the cloud foundation and provided the provider-values template; save that overlay in ~/arbium-install before continuing. This page adds the portable application configuration and installs the same chart everywhere.

Values layering

Every installation uses three layers, in this order:

1. The chart’s built-in values.yaml defaults.
2. One cloud preset: values-aws.yaml, values-gcp.yaml, or values-azure.yaml.
3. Two customer-owned, untracked overlays:
   • <environment>.<provider>.values.local.yaml from Step 2 for cloud wiring.
   • <environment>.values.local.yaml from this page for application, Entra, and optional fleet-console configuration.

Later files win. Keep cloud-specific values in the provider overlay and shared application values in the final overlay.

What the chart installs

• Edge functions and the in-cluster embedder.
• Flyway migrations as an edge-functions init container.
• Scheduler CronJobs.
• ConfigMaps, Services, service accounts, and optional network policies.
• External Secrets resources that read the selected cloud secret store.
• The shared Ingress routes.
• Optional SCIM provisioning and the Admin fleet console.
• Optional HPA, PDB, telemetry, and CaptureLake components.

Terraform continues to own cloud infrastructure. Helm owns application resources inside Kubernetes.

Authenticate and pull the release

Use the GHCR credential supplied by Arbium:

echo '<github-package-token>' | helm registry login ghcr.io \
  --username <github-username-or-bot-account> \
  --password-stdin

mkdir -p ~/arbium-install
cd ~/arbium-install
helm pull oci://ghcr.io/try-caret/charts/chaindb \
  --version <release-version> \
  --untar

The chart’s appVersion selects the matching runtime image tags. Do not override image repositories or tags unless the customer mirrors images into ECR, Artifact Registry, or ACR.

Create the shared application values

Save this as ~/arbium-install/<environment>.values.local.yaml beside the provider overlay. Substitute the customer’s HTTPS host and Entra values. Keep this file out of source control.

global:
  namespace: arbium
  environment: <environment>
  publicBaseUrl: https://arbium.<customer-domain>

config:
  edgeFnsUrl: https://arbium.<customer-domain>
  edgeFnsAnonKey: self-host-local
  verifyJwt: "false"
  auth:
    method: oidc
    label: Customer SSO
    publicBaseUrl: https://arbium.<customer-domain>
    provisioningMode: signon
    oidcIssuerUrl: https://login.microsoftonline.com/<entra-tenant-id>/v2.0
    oidcAudience: <arbium-agent-client-id>
    oidcAllowedAlgs: RS256
    oidcClientId: <arbium-agent-client-id>
    oidcScopes: openid,email,profile,offline_access
    oauthRedirectUrl: caretcapture://auth-callback

embedder:
  enabled: true
  mode: http
  replicaCount: 1

scheduler:
  enabled: true

migrations:
  runOnStartup: true

admin:
  enabled: false

scim:
  enabled: false

telemetry:
  sentry:
    enabled: false

The OIDC issuer must use the customer’s Entra tenant and the v2 endpoint. The audience and client ID are the bare Arbium Agent application GUID, not api://<client-id> and not an object ID. IT sets requestedAccessTokenVersion = 2 during app registration.

The publishable edgeFnsAnonKey is not an administrative secret. The scheduler, enrollment, JWT, license, registry, SCIM, and Admin OIDC values remain in the cloud secret store configured by the provider overlay.

Optional: require SCIM-provisioned users

Use this when the customer wants an explicit Entra group allowlist for agent access. The provider overlay must map scim-bearer to the SCIM token in the cloud secret store.

config:
  auth:
    provisioningMode: scim

scim:
  enabled: true
  existingSecret: scim-bearer
  scimUserGroupIds: <users-group-object-id>[,<another-group-object-id>]
  scimAdminGroupIds: ""

Give IT the Tenant URL https://arbium.<customer-domain>/scim/v2 and the SCIM bearer token through the approved secure channel. Entra provisioning must map SCIM externalId from the Entra objectId for both users and groups.

Optional: enable the fleet console

The Admin UI shares the same hostname and is served under /admin. It requires the Arbium Admin app registration, SCIM provisioning, and at least one admin group. The provider overlay must map the admin-ui-oidc and scim-bearer Secrets from the selected cloud secret store.

config:
  auth:
    provisioningMode: scim

scim:
  enabled: true
  existingSecret: scim-bearer
  scimUserGroupIds: <users-group-object-id>
  scimAdminGroupIds: <admins-group-object-id>[,<another-admins-group-object-id>]

admin:
  enabled: true
  existingSecret: admin-ui-oidc
  entra:
    tenantId: <entra-tenant-id>
    adminGroupId: ""
  authz:
    mode: scim

The Arbium Admin application’s Web redirect URI must be exactly:

https://arbium.<customer-domain>/admin/api/auth/callback

The chart generates and persists the Admin UI session secret through External Secrets. Do not put the Admin client secret or a session secret in the values file.

Choose CPU or GPU embedding

CPU mode works on every supported cloud and is the baseline for small installs:

embedder:
  enabled: true
  gpu:
    enabled: false
  resources:
    requests:
      cpu: "1"
      memory: 2Gi
    limits:
      cpu: "2"
      memory: 4Gi

For AWS or Google Cloud, enable GPU mode only after the provider guide’s GPU node pool is ready. The cloud preset supplies the provider-specific selectors and tolerations:

embedder:
  enabled: true
  gpu:
    enabled: true

The Azure baseline is CPU-only. Add and validate an AKS GPU pool before enabling GPU mode there.

Render and review

Set <provider> to aws, gcp, or azure and use the same three files for lint, render, install, and future upgrades:

helm lint ./chaindb \
  -f ./chaindb/values-<provider>.yaml \
  -f <environment>.<provider>.values.local.yaml \
  -f <environment>.values.local.yaml

helm template arbium ./chaindb \
  --namespace arbium \
  -f ./chaindb/values-<provider>.yaml \
  -f <environment>.<provider>.values.local.yaml \
  -f <environment>.values.local.yaml \
  > /tmp/arbium-rendered.yaml

Review the rendered resources before applying them. In particular, confirm:

• Every image is versioned for the intended release.
• The External Secrets provider matches the selected cloud.
• The database connection method matches the provider guide.
• ingress.host, global.publicBaseUrl, and the Entra Admin redirect host agree.
• OIDC uses the v2 issuer, bare client GUID, and RS256.
• Workloads reference the ghcr-pull image pull Secret.
• The rendered OIDC_ISSUER_URL, OIDC_AUDIENCE, and OIDC_CLIENT_ID values are non-empty.
• Optional SCIM and Admin resources are either fully configured or disabled.

Install

helm upgrade --install arbium ./chaindb \
  --namespace arbium \
  --create-namespace \
  --timeout 15m \
  -f ./chaindb/values-<provider>.yaml \
  -f <environment>.<provider>.values.local.yaml \
  -f <environment>.values.local.yaml

The chart creates the arbium namespace. External Secrets then materializes the runtime and GHCR pull Secrets. Pods can briefly report ImagePullBackOff while the pull Secret is being created; Kubernetes retries automatically.

Watch the rollout:

kubectl get externalsecret -n arbium
kubectl get pods -n arbium -w
kubectl rollout status deployment/chaindb-edge-fns -n arbium --timeout=15m

Finish provider ingress and TLS

AWS

Read the ALB hostname and point the customer DNS record at it:

kubectl get ingress chaindb -n arbium \
  -o jsonpath='{.status.loadBalancer.ingress[0].hostname}{"\n"}'

Use a Route 53 alias or a CNAME supported by the customer’s DNS provider. The ACM validation record from Step 2 remains separate from this application record.

Google Cloud

DNS should already point to the reserved static address. Wait for the Google managed certificate:

kubectl get managedcertificate chaindb-tls -n arbium -w

After it becomes Active and HTTPS works, change kubernetes.io/ingress.allow-http to "false" in the GCP provider values and run the Helm command again.

Azure

Apply the prepared Certificate after the namespace exists:

kubectl apply -n arbium -f manifests/tls-certificate.yaml
kubectl get certificate chaindb-tls -n arbium -w

The certificate should become Ready=True after DNS resolves and Let’s Encrypt completes HTTP-01 validation.

Confirm authentication configuration

kubectl -n arbium get configmap chaindb-config \
  -o jsonpath='{.data.OIDC_ISSUER_URL}{"\n"}{.data.OIDC_AUDIENCE}{"\n"}{.data.OIDC_ALLOWED_ALGS}{"\n"}'

Expected: the customer’s v2 issuer URL, the Arbium Agent client GUID, and RS256. Correct the common values and run helm upgrade if they differ.

Migrations

Migrations run through the version-matched chaindb-migrations init container. Flyway applies pending migrations before each edge-functions pod starts and skips versions already recorded in schema history. No separate migration Job is required.

If an approved external pipeline owns migrations, set:

migrations:
  runOnStartup: false

Upgrading the chart

Authenticate to GHCR, pull the new chart into a new directory, review the release notes and values changes, then repeat the render and install commands with the same provider and customer overlays. Always pin the new chart version; do not upgrade by tracking latest.

Uninstall

Uninstall the application before destroying the provider foundation:

helm uninstall arbium -n arbium
kubectl delete namespace arbium

Continue to 4. Verify deployment.