HashiCorp Ships Two Helm Charts That Kill Boundary Deployment Drudgery

Until today, running Boundary on Kubernetes meant rolling your own deployment scripts, config maps, and lifecycle management from scratch. HashiCorp just cut that work with two official Helm charts: one for the Boundary controller and one for the Boundary worker. Together they give self-managed and HCP Boundary customers a standardized, repeatable path that matches how teams already operate Kubernetes workloads.

Two Charts, One Consistent Deployment Model The controller chart handles the control plane - authentication, authorization, session brokering. It renders Boundary's HCL config through a templated ConfigMap and consumes secrets from Kubernetes via Boundary's env:// interpolation. On first install, a pre-install Helm hook runs database schema initialization automatically. For upgrades, database migrations are gated behind an explicit opt-in flag (--set controller.database.migrate.enabled=true), so you don't accidentally mutate the schema. SHA256 checksum annotations on the Deployment trigger restarts when values change, preventing configuration drift. Readiness probes against the /health endpoint gate rolling updates, ensuring new pods are healthy before old ones terminate. The worker chart deploys data-plane workers that register with the controller and proxy traffic. It supports all three registration models: controller-led (pre-provisioned activation token), worker-led (token in pod logs for manual registration), and KMS-led (shared key). Identity and auth material persist on a PVC, so a restart or reschedule doesn't require re-registration. If session recording is enabled, a second PVC stores recorded data durably. Upgrades preserve persistent state and a configurable termination grace period lets active sessions drain before the pod stops.

What This Changes for Self-Managed and HCP Boundary Users Self-managed Boundary customers get a production-ready path for the full stack without assembling deployments, services, and database init scripts by hand. The controller chart ships with pod anti-affinity rules and pod disruption budgets for multi-replica resilience across availability zones. HCP Boundary customers - whose controllers and ingress workers run on HashiCorp Cloud Platform - can use the worker chart alone to deploy self-managed workers in their own private networks, extending the data plane into environments HCP can't reach directly. Installation is standard Helm 3 - both charts are published as OCI artifacts. A quickstart snippet shows helm install boundary-controller oci://... with a values file and pre-existing secrets for PostgreSQL connection, KMS keys, and TLS certificates. The worker chart requires an HCL config file passed via --set-file worker.config=/path/to/worker.hcl. Both support standard helm upgrade and rollback, with the controller chart requiring explicit opt-in for database migrations.

The Bottom Line for Operators These charts remove the largest friction point for Boundary on Kubernetes: the bespoke orchestration glue that every team had to build and maintain. They bring Boundary's Day 2 operations - rolling updates, config drift prevention, safe schema migrations, and persistent worker identities - in line with how seasoned Kubernetes teams expect to manage stateful workloads. Head to the (https://github.com/hashicorp/boundary-helm/tree/main/charts/boundary-controller) and (https://github.com/hashicorp/boundary-helm/tree/main/charts/boundary-worker) repositories on GitHub to review the source and full deployment guide.

Source: Deploy Boundary on Kubernetes with official Helm charts
Domain: hashicorp.com