How to deploy Hyperledger Besu on Kubernetes with Helm
A platform team that must run permissioned Besu nodes in cloud Kubernetes and keep node keys in a cloud secret store should start with the documented route: the Quorum-Kubernetes Helm charts, with cluster.provider set to aws or azure and cloudNativeServices enabled. The charts currently support only AWS and Azure, so an organization running on another cloud, on-premises clusters or a mix will need a different deployment approach or a supported-provider decision before any build work starts. With cloudNativeServices enabled, node keys are handled through AWS Secrets Manager and IAM, or Azure Key Vault and Managed Identities, depending on the provider.
The integration covers the Helm deployment of validator and non-validator nodes, cloud-backed key storage, the reclaimPolicy setting for persistent volumes, spreading nodes across zones within a region, configuring bootnodes and static nodes so peering converges quickly, multi-cluster peering, and connecting an on-premises node into the cluster. It does not cover building or hardening the Kubernetes cluster itself, which is a separate piece of work with its own control plane, etcd and access decisions. It also does not decide the Besu permissioning model, the validator set or the genesis design, which must be settled first because the Helm values depend on them.
Before deploying, confirm three things with your cloud team and the chart maintainers. First, check that reclaimPolicy: Retain is acceptable for your storage cost and data lifecycle, because retained volumes keep chain data after a release is removed and must be cleaned up deliberately. Second, confirm that your Kubernetes version and node pools support the zone spread you plan, and that the cluster has enough nodes in each zone to host the pods the chart schedules. Third, plan the peering topology: for multi-cluster setups, the Besu docs recommend separate VPCs or VNets with non-overlapping CIDR blocks, peered together, and a cloud DNS service such as Route 53 or Azure DNS to keep peer lists current. An on-premises node may need extra configuration, so test its connectivity to the cluster before treating it as part of the network. Review the Besu production Kubernetes tutorial against the chart version you intend to use, since the exact values and steps can change between releases.
What you need before the first Helm install
A Besu network on Kubernetes depends on decisions made before any chart is installed: which cloud and cluster version you run, which Besu release you pin, and how secrets, networking and DNS are set up. Work through these six groups first, because most first-install failures trace back to one of them.
A supported Kubernetes cluster
The Besu production tutorial targets cloud clusters on AWS or Azure, and the Quorum-Kubernetes charts currently support only those two providers. Set cluster.provider to aws or azure to match your cluster. Check the minor version against the Kubernetes release table: the project maintains only the three most recent minors, with 1.37, 1.36 and 1.35 listed as of September 2026, so pick a version that still receives patches through your planned operating window.
A Besu release built for JDK 25
Besu 26.6.0 requires JDK 25 to build and run, so any custom build, plugin or tooling image must use that runtime. Besu ships roughly monthly under calendar versioning, so pin an exact image tag rather than a floating tag. Confirm the image tag that the chart version expects on the Besu releases page before you install, and record the tag in your change record.
Cloud accounts with secret and identity permissions
Cloud-native secret storage needs more than cluster access. On AWS, the chart uses Secrets Manager and IAM; on Azure, it uses Key Vault and Managed Identities. Ask your cloud team to grant the node identities permission to create, read and rotate only the secrets for their own node, and confirm who owns the key material after the first install. Write these grants down before the deployment, because the chart will not create them for you.
Non-overlapping CIDR blocks for multi-cluster use
If you plan to peer clusters or connect on-premises nodes, each cluster needs its own VPC or VNet with a CIDR block that does not overlap with any other network you will peer with. Decide the address plan for every site before the first install, because changing pod or node ranges later means rebuilding the peering. Include the on-premises ranges in the plan, not only the cloud ranges.
DNS for live peer lists
Bootnode and static node addresses change when nodes are rebuilt, so peer lists go stale quickly. The Besu docs suggest a cloud DNS service such as Route 53 on AWS or Azure DNS on Azure to keep these entries current. Confirm which DNS zone your team will own, who can edit records, and how a record is updated during a node replacement, and test name resolution across peered networks before you rely on it.
Helm and cluster tooling
Install the Helm client and the cluster command-line tools your team uses, and pull the chart from the Quorum-Kubernetes repository at a specific version. Confirm the chart version against the Besu release and the production tutorial, since charts and images must match. Store the chart values in version control so every install, upgrade and rollback can be reviewed and reproduced.
Deploying the Helm charts in sequence
This sequence takes a permissioned Besu network from an empty cloud Kubernetes cluster to a set of validators and RPC nodes that peer with each other and produce blocks. Each step ends with a check so the team knows the previous layer is sound before the next one is installed.
Confirm the cluster and cloud provider
The platform team confirms that the target cluster runs on AWS or Azure, since the Quorum-Kubernetes Helm charts currently support only those two providers for the cloud-native setup. Record the region, the Kubernetes version, the node pools and the network layout (VPC or VNet and CIDR ranges) in the deployment runbook. Done when the team can run kubectl against the cluster and list nodes in at least two availability zones within the chosen region.
Prepare cloud secret storage and identities
On AWS, create the Secrets Manager entries and IAM roles that the nodes will use for their keys. On Azure, create the Key Vault and the Managed Identities with access to it. Keep node keys out of Helm values files and out of the Git repository. Done when a test workload running under the intended identity can read the secret store path for one node and is denied access to the others.
Set provider and cloud-native values
In the Helm values for the Besu chart, set cluster.provider to aws or azure and set cloudNativeServices to true so the chart uses the cloud secret store and identity model prepared in the previous step. Review the rendered manifests with helm template before installing anything. Done when the rendered output references the expected secret paths and service accounts, and no node key appears as plain text in the output.
Set the volume reclaim policy to retain
Set reclaimPolicy to Retain on the storage class used for node data volumes. Retain keeps the underlying volume when a PersistentVolumeClaim is deleted, which protects chain data and key-related state from an accidental uninstall. Done when kubectl get storageclass shows the Retain policy on the class the Besu pods will use, and the team has written a procedure for reclaiming a retained volume.
Spread nodes across zones in the region
Configure scheduling so validator and RPC pods land on different availability zones within the same region. Use pod anti-affinity or topology spread constraints in the values file. Done when kubectl get pods -o wide shows each validator on a separate zone label, and no single zone failure would remove a quorum of validators.
Install bootnodes and the first static nodes
Install the bootnode set first, then the initial static nodes. Multiple bootnodes and static nodes shorten peering time, so deploy more than one of each. Record each node's enode address and confirm the peer list is written consistently for the network. Done when every bootnode and static node reports a running pod, its enode is published, and the logs show a connection attempt to at least one other static node.
Add the remaining validator and RPC nodes
Install the rest of the validator and RPC nodes with the same chart and values pattern, keeping the zone spread from the previous step. If an external on-premises node must join, confirm the networking path, firewall rules and address routing first, since the production tutorial notes that extra configuration may be needed. Done when all pods are ready and each node reports the expected number of peers in its admin or metrics output.
Confirm peering and block production
Check that every node lists its peers and that the validator set agrees on the chain head. Watch the block number on each validator over several block intervals and confirm it advances on all of them. If a validator stalls, check its peers and its consensus logs before changing any values. Done when the block height increases on every validator and the team has recorded the baseline peer counts for monitoring.
Keeping node keys out of plain Kubernetes Secrets
The node private key needs a deliberate storage choice before the first pod starts. Besu's documentation states that the local node private key file is not encrypted, and Kubernetes stores Secrets unencrypted in etcd by default. Put the key in a plain Kubernetes Secret and anyone with broad read access to the namespace, or to a backup of etcd, can recover the node identity. The Helm chart's cloudNativeServices: true setting moves key retrieval out of the cluster. On AWS, the node uses AWS Secrets Manager with access granted through IAM. On Azure, it uses Azure Key Vault with Managed Identities. Confirm in the chart version you deploy exactly which secret names, IAM roles or identities, and provider settings it creates, because the production tutorial is the reference for those details.
Moving retrieval to a cloud vault does not remove the cluster from the trust path. The cluster still schedules the pods, still holds whatever the chart mounts or caches, and still depends on the workload identity being scoped correctly. Review who can assume the IAM role or Managed Identity, who can read the vault, and whether audit logging on the vault is enabled and retained for your regulator's period. Restrict list and watch access on any remaining Secrets with least-privilege RBAC, and confirm that etcd encryption at rest is configured if any key material still lands there. A hardware-backed option applies when your policy requires keys that never leave a device. In that case, Besu's --security-module option with a plugin such as the Besu HSM plugin is the path to evaluate, and it needs its own design work, since the chart's cloud integration does not replace it.
The reclaimPolicy: Retain setting keeps persistent volumes after their claims are deleted, which protects chain data from accidental loss but leaves data and keys behind. Decide before go-live who is accountable for removing retained volumes, who approves deletion of the matching vault entries, and how that decision is recorded. A decommissioned validator whose key still exists in a vault and whose volume still sits in storage is a live risk, not a tidy leftover. Write this into the runbook alongside the backup procedure, and test a restore from a retained volume so the team knows the process works before it is needed.
AWS or Azure: what changes in the same Helm release
With cluster.provider set to aws and cloudNativeServices set to true, the chart uses AWS Secrets Manager for node key material and AWS IAM to grant the Besu pods access to it. The pods do not carry long-lived credentials. Instead, the IAM role is bound to the Kubernetes service account the workload runs under, so the permission is scoped to the nodes that need it.
- IAM roles before install: Create the role and trust relationship for the cluster's identity provider and confirm the service account name the chart will use matches the trust policy.
- Secrets Manager entries: Confirm the secret names and the region the chart expects, and that the node keys are created under those names rather than copied from a workstation.
- Least-privilege policy: Limit the role to reading the specific secrets for each validator or node, and deny listing across unrelated secrets.
- Zone and encryption settings: Check that the cluster spans the zones you planned and that the KMS key used for Secrets Manager is controlled by your organization.
- Reclaim behavior: Confirm that
reclaimPolicy: Retainis set so that volumes survive a deleted claim, and test that a restored pod reattaches to its data.
Before go-live, confirm with your AWS administrators that the role can read only its intended secrets and that CloudTrail records access to them. Confirm with the chart maintainers that the AWS path matches your Kubernetes version.
With cluster.provider set to azure and cloudNativeServices set to true, the chart uses Azure Key Vault for node key material and Managed Identities to authenticate the workload. As on AWS, the pods receive access through a workload identity rather than stored passwords, so access is granted and revoked in the identity layer.
- Managed Identity setup: Create the identity and federate it to the cluster's service account before install, then confirm the federation subject matches the namespace and account the chart deploys.
- Key Vault access policy: Grant the identity read access to the specific secrets for each node, using the access model your Key Vault is configured to use.
- Vault configuration: Confirm soft delete and purge protection are enabled on the vault, since an accidental deletion of a node key would stop the node.
- Network rules: If the vault uses a firewall or private endpoint, confirm the cluster's subnets can reach it before the first pod starts.
- Reclaim behavior: Confirm
reclaimPolicy: Retainis set and test a volume reattach after a claim is removed.
Before go-live, confirm with your Azure administrators that Key Vault audit logging is on and that the identity cannot modify or purge secrets. Confirm with the chart maintainers which Azure Kubernetes Service versions the chart has been exercised against.
The documented route in the Besu production tutorial covers only AWS and Azure, and the Helm chart currently supports only these two providers in its cluster.provider setting. Teams on another cloud, a private cluster or bare metal cannot rely on the cloud-native secret path described above and need a separate key design.
- Secret store choice: Decide which external store will hold node keys, such as a self-hosted vault or an HSM-backed service, and confirm the Besu node can read the key material at startup.
- Identity integration: Define how pods authenticate to that store without static credentials, and document who approves each identity.
- Chart changes: Confirm with the chart maintainers how key material is mounted and whether the release needs modification.
- Hardware key options: Review the Besu HSM plugin route with
--security-moduleif hardware-backed keys are required. - Operational ownership: Assign who rotates keys, restores volumes and runs the checks the AWS and Azure paths handle through their cloud platforms.
Before you start, ask the chart maintainers and the Besu community in writing which provider paths they support and how they test them.
Which cloud and Kubernetes objects hold each node's identity
This table maps each object that carries a Besu node's identity, from the node key to the DNS record used for peer discovery, and states who usually manages it. Read it as a checklist: for every row, confirm the exact object name, owner and reclaim behavior in your own cluster and cloud account before the first deployment.
| Component | Where it lives | Who manages it | What to confirm |
|---|---|---|---|
| Node key | Cloud secret object in AWS Secrets Manager or Azure Key Vault, read by the node pod | Platform team, with the chart creating the entry when cloud native services are enabled | Which vault or secret name the chart writes to, and who can read or rotate the value |
| Cloud secret object | AWS Secrets Manager or Azure Key Vault in the account or subscription that hosts the cluster | Cloud security or platform team under its key policy | Encryption key, access policy and whether the secret is shared across environments |
| Workload identity | IAM role on AWS or Managed Identity on Azure bound to the node workload | Cloud identity team, with permissions scoped to one node's secret | That the role grants read on the node's secret only, and that no human principal can read it by default |
| Kubernetes service account | Namespace-level service account linked to the workload identity | Platform team through the Helm chart values | The account name, its namespace, and that pods for other nodes cannot assume the same identity |
| Persistent volume and reclaim policy | Cluster volume holding Besu chain data, with the chart setting reclaimPolicy to Retain | Storage or platform team, with the chart creating the claim | Which storage class backs the volume, and the backup procedure for the data if the claim is deleted |
| Bootnode and static node peer lists | Enode URLs in the chart values or generated configuration for each node | Network operator group, usually agreed across all consortium members | Which nodes are bootnodes, which are static peers, and who approves changes to each list |
| DNS record for peer discovery | Cloud DNS service such as Route 53 or Azure DNS, resolving node hostnames | Platform team, with changes tracked as infrastructure code | The zone name, record TTL and the process for updating records when a node moves or is replaced |
Hardening secrets, RBAC and pod settings for Besu nodes
A Besu node's private key and its JSON-RPC credentials are the most sensitive material in the deployment, and the cluster around them decides who can read them. The cards below cover the controls that protect those values in etcd, the access paths operators use to reach the cluster, the pod settings that limit what a compromised container can do, and the cloud identities that fetch keys at start-up. Use the CIS benchmark as a review baseline for your own assessment, not as a claim of compliance.
Encryption at rest for etcd
Kubernetes stores Secrets unencrypted in etcd by default, so a Besu node key kept in a Kubernetes Secret is readable by anyone who can reach the etcd data or its snapshots. Configure encryption at rest for the API server before the network holds real keys, and confirm that etcd backups are encrypted and stored under the same access controls as the live data. Ask your managed Kubernetes provider how encryption keys are rotated and who holds them.
Least-privilege RBAC for Secrets
Role bindings that grant list or watch on Secrets let a user or service account read every Besu key in a namespace, even when they never call get on a specific name. Scope roles to named resources where the API allows it, keep the Besu namespace separate from platform namespaces, and review bindings after each change to the Helm release. Test the bindings with impersonation before go-live so the result is verified, not assumed.
Operator authentication to the cluster
Kubernetes does not store normal users as objects, so the team must choose how operators authenticate: X.509 client certificates, OpenID Connect or JWT bearer tokens, webhook token authentication, or an authenticating proxy. Short-lived tokens tied to your identity provider are easier to revoke than long-lived certificates when someone leaves the team. Document which path each role uses and test revocation before relying on it.
Pod Security Standards for Besu pods
Besu pods need only the access the client requires, so the namespace should enforce a Pod Security Standard at the restricted level where the chart allows it. Check that containers do not run as root, do not request privileged mode or host networking without a documented reason, and do not mount host paths for node data. Where a chart setting conflicts with the standard, record the exception and its owner in the deployment review.
Scoped cloud IAM and managed identity roles
With cloudNativeServices enabled, the chart relies on AWS IAM roles for Secrets Manager or Azure Managed Identities for Key Vault to fetch node keys at run time. Grant each node identity read access only to its own secret, not to a shared wildcard path, and confirm that cluster administrators cannot read secret values through the cloud console without an audit trail. Ask the team to show the policy that maps each node to its secret.
CIS Kubernetes Benchmark as a review baseline
The CIS Kubernetes Benchmark lists recommended configuration checks for the control plane, worker nodes and policies. Use it as a reference checklist for your own assessment of the cluster that runs Besu, recording which items pass, which are accepted risks, and who owns each decision. A benchmark result from a scanning tool is evidence for your review, not a score or certification for the network. Confirm the benchmark version that matches your Kubernetes release before you start.
Peering across zones, clusters and on-premises nodes
Spreading nodes across availability zones inside one region is the first peering decision, and the Besu production tutorial treats it as part of the deployment rather than an afterthought. The Quorum-Kubernetes Helm charts with cluster.provider set to aws or azure spread deployments across zones within a region. That keeps a single zone failure from taking out every validator, but it also means each node's peers sit in different failure domains. Before go-live, confirm in your own cluster that the scheduler places validators and RPC nodes on distinct zones, and that a node restarted in one zone can still reach its peers in the others. Also confirm the zone layout matches the quorum math in your validator plan, since losing two zones may still stop block production.
The tutorial also recommends running multiple bootnodes and static nodes, which speed up peering when a new node starts. A node that depends on one bootnode can stall if that bootnode is replaced or unreachable, so the practical check is to start a fresh pod with the bootnode set you intend to use and confirm it reaches the expected peer count. For multi-cluster setups, the Besu docs recommend separate VPCs or VNets with non-overlapping CIDR blocks, peered together, and a cloud DNS service such as Route 53 or Azure DNS to keep peer lists current. Plan the CIDR allocation before the first cluster is built, because overlapping ranges are hard to fix later. Decide who owns the DNS records that peer lists depend on, and test what happens when a node's address changes.
Connecting an on-premises node into the cluster may need configuration beyond the Helm defaults, according to the Besu tutorial. The network path, firewall rules for the P2P ports, and how the on-premises node resolves peer names all have to be set up and tested. Treat this as a separate acceptance test: confirm the on-premises node discovers and maintains peers in both directions, that it keeps syncing after a cluster node restarts, and that its traffic is restricted to the peers you approved. Confirm the exact ports, DNS behavior and any extra settings with the current Besu documentation for your release, since this area changes between versions.
Why nodes fail to peer or start on Kubernetes
This table maps the symptoms operators most often see when a Besu node on Kubernetes will not schedule, peer or start, to the likely cause, a first check and a fix. Work down the rows in order, because scheduling and identity problems often hide peering problems. The main takeaway is that a retained volume, a stale peer list and a cloud key policy each look like a network fault until the node identity and storage state are verified.
| Symptom | Likely cause | Check | Fix |
|---|---|---|---|
| Pods stay Pending across zones | Zone-spread rules cannot be met, or the node pool lacks capacity in one zone | Describe the pending pod and compare its scheduling events with node zone labels and available capacity | Add capacity in the missing zone or relax the spread constraint, then confirm each validator still lands on its own node |
| Node starts but finds no peers | Too few bootnodes or static nodes, or peers reachable only by old addresses | Confirm bootnode and static-node entries resolve and that the node can reach their P2P port | Add more bootnodes and static nodes, and open the P2P port between pods and external peers |
| Peer list stale after an IP or DNS change | Static peer entries hold addresses that changed when pods or load balancers were recreated | Compare the configured peer addresses with current service endpoints and DNS records | Point peer entries at stable DNS names, such as those from Route 53 or Azure DNS, and redeploy the peer list |
| Retained volume reused with the wrong genesis or node identity | reclaimPolicy Retain keeps old data, so a redeployed node reads a database from a different chain or key | Compare the genesis file and node public key with the values expected for this network before starting | Restore the correct genesis and key for this node, or provision a fresh volume and resync deliberately |
| Node cannot read its key from the cloud store | Workload identity lacks permission, the secret name or vault path is wrong, or a policy blocks access | Check the pod's service account binding, the IAM role or managed identity, and the Secrets Manager or Key Vault access policy | Grant read access to the named secret for that identity only, correct the name or path, and restart the pod |
| On-premises node cannot reach the cluster | Routing, firewall or overlapping address ranges block the P2P and discovery ports | Test TCP and UDP reachability on the P2P port from the on-premises host, and confirm CIDR ranges do not overlap | Open the required ports in both directions, add routes or VPN peering, and add the external node to the peer lists |
| Upgrade leaves a database older versions cannot open | Bonsai database auto-upgrades on first start, and the 26.10.0 release notes say older versions cannot open it | Confirm a backup of the data volume exists and was taken before the image change | Restore the pre-upgrade backup and run the older version; do not roll back an upgraded database without that backup |
| Wrong pod image or version mix on peers | Nodes run different Besu releases, or a rollout updated only some pods | List the running image tag on every validator and RPC pod and compare them | Align all nodes to the approved release in a controlled rollout and recheck peering afterward |
What buyers ask before running Besu on Kubernetes
What drives the cost of running Besu on Kubernetes, and what is one-time versus recurring?
Cost comes from design, build and handover work, plus the cloud and staff time needed to keep the network running afterward. One-time work includes the node layout, Helm values, cloud key vault wiring, zone spread, peering and the first runbooks. Recurring costs include cluster upgrades, Besu release upgrades, monitoring, backups and on-call time. Cost rises with the number of nodes, the number of clusters, the number of organizations peering in, and whether on-premises nodes must join. Ask any quote to separate the one-time build from a recurring support scope and to name who pays for cloud resources.
How long does a Besu Kubernetes deployment take, and what sets that duration?
Duration depends on scope rather than on a fixed number, so ask for a timeline that is tied to a written scope. The main variables are how many validator and RPC nodes you run, whether you deploy into one cluster or several, how many parties must agree on the peer list and genesis settings, and how quickly cloud accounts, DNS and key vault access are approved. Work on an external on-premises node or a second cloud adds coordination time. Timelines also slip when the internal team has not decided on key ownership before build starts.
What must our internal team provide before a partner can start?
The team needs to supply working access to the target cloud accounts (AWS or Azure) and Kubernetes clusters, plus the network plan. That plan should cover VPC or VNet layout, non-overlapping CIDR blocks for any multi-cluster peering, and DNS arrangements such as Route 53 or Azure DNS for peer lists. Key ownership must be decided in advance: who controls the node keys, who holds the cloud key vault roles, and who approves rotation. Also provide the consortium's agreed genesis and validator choices, and named contacts for each participating organization.
Can our engineering team deploy this alone, and where does a partner help?
A team with Kubernetes, Helm and cloud IAM experience can deploy a single-cluster network using the Quorum-Kubernetes charts and the Besu production tutorial. The harder parts are usually cross-organization decisions, multi-cluster peering, correct key vault and IAM policy, and proving that failover and recovery work. A partner can plan the architecture, build the deployment, document the runbooks and hand over with tested procedures. Confirm with your own engineers which parts they have done before, since the chart supports only AWS and Azure today.
Which Kubernetes versions and Besu releases should we plan around?
Plan around Kubernetes versions that are still maintained. As of September 2026 the supported minor releases were 1.37, 1.36 and 1.35, with end-of-life dates of October 28, 2027, June 28, 2027 and February 28, 2027 respectively. For Besu, the GitHub releases page lists 26.7.0 through 26.10.0 in the period you may be reviewing, and the 26.6.0 notes say Besu requires JDK 25. Also check the 26.4.0 note that Clique consensus was removed, and the 26.10.0 note that Bonsai databases auto-upgrade and need a backup before upgrading.
Where should node keys live, and what does the Helm chart store in the cloud?
With cloudNativeServices enabled, the chart uses AWS Secrets Manager and IAM on AWS, or Key Vault and Managed Identities on Azure, instead of leaving keys as plain Kubernetes Secrets. Kubernetes stores Secrets unencrypted in etcd by default, so encryption at rest and least-privilege RBAC are still required. The Besu node private key file is not encrypted, so teams with hardware requirements should evaluate the HSM plugin with the security module option. Confirm the exact key paths and IAM policies with your security team before go-live.
What should a written quote for this work include?
Ask for a quote that lists the scope in named deliverables: cluster target (AWS or Azure), number of validator and RPC nodes, number of clusters, bootnode and static node layout, zone spread, reclaim policy and key vault approach, on-premises node connections, and handover documents. The quote should state the assumptions the client must meet, the acceptance tests, and what happens if the scope changes. Separate one-time build fees from any recurring retainer for upgrades, monitoring and support. Ask which items are excluded, such as cloud spend, licensing of third-party tools, or audit preparation.
What operational risks should we review before the first production deployment?
The main risks are data loss from a reclaim policy that is not set to Retain, loss of peering after an IP or DNS change, and a failed Besu upgrade that leaves the database unopenable by the previous version. Review how zones are spread so a single zone outage does not stop consensus, and confirm that multiple bootnodes and static nodes are in place. Test backup and restore before the first upgrade. Also check how the team will rebuild a node from its key vault secret, since that path is rarely exercised until an incident.
How DeployOpen scopes and delivers a Besu Kubernetes deployment
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or closed networks. For a permissioned Besu network on Kubernetes, that means a written scope covering the Helm chart configuration, cloud key storage, zone layout, peering and handover before any build starts.
How we scope
- Confirm the cloud provider, cluster count, region and zone layout the network will run in before any design work starts.
- Record which validator, bootnode and RPC node roles each cluster hosts, and which on-premises nodes must join the network.
- Agree in writing which Helm chart values, secret stores, reclaim policies and peering components are in scope and out of scope.
How we build
- Deploy the chart configuration in a staging cluster, then verify node keys are read from the cloud secret service and never written to disk.
- Test pod spreading across zones, bootnode and static node peering, and recovery after a node or zone is removed.
- Validate multi-cluster connectivity with non-overlapping address ranges and confirm peer lists update through the chosen DNS service.
How we hand over
- Deliver the chart values, infrastructure definitions and runbooks as code in your repositories, with configuration documented for your team.
- Walk your platform and security staff through key rotation, reclaim policy behavior, backup of node data and the upgrade checklist.
- Provide evidence of tests run, including peering checks and failover results, so your own assessors can review the deployment.
How we support
- Ongoing support, Besu release upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Track the Besu calendar releases and the Kubernetes version support window, and plan upgrades with your change process.
- Ask for a quote based on the written scope, and confirm with DeployOpen which support hours and response terms apply.
