What running Hyperledger Fabric chaincode as an external service changes
If you are a network operator who must run chaincode outside the peers, for example as Kubernetes workloads, the supported method is the external builder and launcher installed on each peer, paired with an external chaincode package. That package carries only the chaincode server endpoint information and TLS artifacts, not source code, so the peer no longer compiles the chaincode itself. This page covers the runtime that hosts the chaincode and the operations around it.
The most visible change is that per-peer source builds are no longer required. In the traditional model, every peer that endorsed for a chaincode built and launched it from source, which meant each organization's peers had to agree on build inputs and rebuild whenever the chaincode changed. With an external service, the chaincode runs as its own process with its own lifecycle, and each peer connects to that endpoint. The Fabric docs describe this as chaincode managed independently of the peer, which is why it suits cloud deployments such as Kubernetes.
The chaincode runtime is also managed separately from the peer lifecycle. You can restart, scale, patch or redeploy a chaincode server without restarting the peer, and you can upgrade peer binaries without rebuilding chaincode. Each organization decides where its chaincode server runs, which means the operations team must own its health, certificates, resource limits and logs. Confirm with your own platform team who is on call for a chaincode pod failing at 2 a.m., because the peer will report errors that look like peer faults.
Two decisions shape the work from the start. First, TLS between the peer and the chaincode server is optional according to the Fabric docs but highly recommended outside simple test environments, so plan certificate issuance and rotation before the first production package. Second, the external builder and launcher is installed into the peer's configuration, which means every peer in your organization needs it, and its version must match the Fabric line you run. Ask your Fabric operator to confirm which builder configuration applies to your peer version before you change anything on a live channel.
This page does not cover the application logic inside the chaincode, such as transaction design, endorsement policies, data models or business rules. Those belong to the chaincode development scope and are not addressed here. Read the external service sections for the runtime steps, and treat any changes to chaincode behavior as a separate project with its own testing and approval.
What you need in place before configuring external chaincode
Five prerequisites shape how external chaincode runs. Each one sets a version, trust or connectivity boundary that the peer configuration depends on, so settle them before you package any endpoint information. Confirm current support dates with the upstream release pages before you commit to a line.
Fabric version line
Pick the Fabric line before you write any chaincode service configuration. The v2.5 release is the long-term support line for production users, and the 3.x line receives patch releases in parallel, with v3.1.5 and v2.5.16 both published June 18, 2026. Check the Fabric docs for which features apply to each line, because 3.0 removed the v1.x legacy chaincode lifecycle and requires channels on the v2.x lifecycle first. Confirm the current patch level before you pin images.
Kubernetes version in support
Run chaincode workloads on a Kubernetes minor version the project still supports. As of September 2026, the supported minors were 1.35, 1.36 and 1.37, with end of life dates of February 28, 2027, June 28, 2027 and October 28, 2027 respectively. Plan your upgrade path around the version skew policy, which requires the API server to move one minor version at a time and allows kubelets up to three minors behind. Confirm current dates on the Kubernetes releases page before committing.
Certificate authority for chaincode TLS
Decide which certificate authority issues the TLS certificates that chaincode servers present to peers. Fabric CA issues enrollment certificates, handles renewal and revocation, and generates certificate revocation lists, but you still need to confirm it can issue server certificates with the subject alternative names your endpoints use. Check that you can rotate chaincode server certificates without rebuilding images and that revocation reaches every peer. The Fabric docs treat TLS as optional but highly recommended outside simple test environments.
Network paths from every peer
Every peer that endorses for a chaincode must reach each chaincode endpoint you declare, so map those paths before packaging. Each peer opens its own connection, which means a firewall rule, security group or network policy that allows one peer and blocks another will fail only for that peer. Test from each peer's network segment, including peers in other member organizations and clusters, and record the endpoint addresses each connection file will contain. Ask each peer operator to confirm that the DNS names resolve from their side.
Container image pipeline for chaincode
Build chaincode server images through a pipeline you control, because external chaincode is a service you package and version, and peers no longer build it. Pin base images and dependencies, scan the output, and tag each image with the chaincode package version. If you plan to hold peer or orderer MSP keys in an HSM, budget for custom images from the start, since the prebuilt Fabric Docker images are not built with PKCS#11 support. Confirm registry access from each cluster and how image updates reach production.
How the external builder and launcher replaces per-peer chaincode builds
The external builder and launcher is the Fabric peer extension point that makes an external chaincode service practical. Operators install programs on the peer that the peer calls to build, launch and discover chaincode. In the external case, the peer's external builder does not compile source code. It reads a small package, learns where the chaincode server is, and records the connection details the peer needs. The chaincode itself runs as a separate process that the peer does not manage, and that process can be a Kubernetes workload with its own lifecycle, scaling and restart rules.
The sequence starts when an organization installs a chaincode package whose type is external. The package contains connection information for the chaincode server, typically an endpoint address and the TLS artifacts the peer uses to authenticate to it, and no chaincode source or compiled binary. During installation the peer hands the package to the external builder. The builder's detect step decides whether it handles the package, the build step produces the connection metadata the peer stores, and the release or launch step confirms the peer can reach the service. The exact script names, the metadata file layout and the field names are defined by the Fabric docs for each release, so confirm them against the chaincode-as-a-service page for the version you run before you write any builder script.
The main benefit for cloud deployments is that the chaincode server is decoupled from every peer. Under the older model, each peer that endorsed for a chaincode needed the same package installed and built locally, which meant the code moved to every peer and each peer performed its own build. With an external service, one chaincode server can serve the peers that point to it, and the source stays with the team that owns it. Each organization still installs a package on its own peers, but that package holds only the endpoint and TLS material. This also means chaincode can be rolled out as a container image on a platform the organization already runs, rather than as a build step inside each peer's environment.
Configuring Hyperledger Fabric chaincode as an external service, step by step
This sequence moves chaincode out of the peer and into a runtime that operators manage separately, such as a Kubernetes workload. It ends with an approved and committed chaincode definition that peers invoke through an authenticated TLS connection.
Confirm Fabric and Kubernetes versions first
The platform team and the network operators agree on the Fabric release line before any change, because the external chaincode path depends on the peer binaries and the lifecycle in use. Confirm whether the network runs the 2.5 LTS line or the 3.x line, and confirm that every channel already uses the v2.x lifecycle, since v3.0 removed the v1.x lifecycle. Record the Kubernetes minor version your distribution runs and check it against the supported releases list, so the chaincode workload targets APIs the cluster serves. Done when these versions are written into the change record for every peer organization.
Install the external builder on each peer
Each organization's peer operator adds the external builder and launcher to the peer configuration, pointing the peer at a directory that contains the detect, build, release and run scripts. Restart peers in a rolling order so channel availability holds. Configure every peer the same way, because a peer without the builder cannot process an external package. Confirm the exact configuration keys and script layout against the Fabric documentation for your release. Done when a peer log shows the external builder registered at startup and the peer returns to normal operation on its channels.
Build the external chaincode package
The chaincode developer produces a package that holds connection information in place of compiled source. The connection file lists the chaincode server address, the dial timeout and the TLS settings, including the client key pair and root certificate if mutual TLS is required. A metadata file marks the package as external and gives it a label. Archive the metadata and the connection data into a single tar.gz file, and keep that one file as the package every peer installs. Done when a test peer installs the package and reports a package identifier that matches the one computed from your build.
Deploy the chaincode server on Kubernetes
The chaincode server runs as a Kubernetes Deployment with its own Service. Load the TLS certificate and key from a Secret or an external store through the Secrets Store CSI Driver, and restrict who can read them. Kubernetes stores Secrets unencrypted in etcd by default, so confirm that encryption at rest is configured before the certificate is loaded. Apply pod security settings that match your organization's standard, and set the listening port to the one named in the connection file. Done when the pod is Running and its logs show the server listening on the expected port with TLS enabled.
Expose the endpoint and verify TLS
Make the Service reachable from every peer that will run the chaincode. Peers inside the same cluster may use a cluster-internal address, while peers in other organizations' networks usually need an ingress or load balancer that you control. Confirm that network policy allows the connection and that the server certificate chains to the root certificate in the package. Done when a TLS handshake from each peer's network succeeds, which you can test with a client tool such as openssl s_client against the endpoint, and the server accepts the connection.
Install and approve the package through lifecycle
Each organization runs the lifecycle install command on its own peers with the external package. It then queries the installed package ID and approves the chaincode definition for its organization using that ID. Every organization must use the same chaincode name, version and sequence number. Run the commit readiness check before committing, so each organization's approval is visible to the others. Done when the readiness check reports that each organization has approved the same definition.
Commit the definition and test a transaction
After the approvals required by the channel's lifecycle policy are in place, one organization submits the commit command for the chaincode definition on the channel. Peers that host the chaincode then invoke the external server for transactions. Run a query and an invoke on a test channel, and compare the results with the expected values in your test plan. Done when peers log the commit, the committed-definition query returns the new definition on each channel, and the test transaction returns the expected result from every endorsing peer.
Mapping Fabric chaincode artifacts to Kubernetes objects
This table maps each artifact an external chaincode service depends on to the Kubernetes object that usually holds it, and shows whether the value is set by one organization or agreed across the channel. Read the scope column first: per-organization values are set by each member, while the chaincode definition is approved channel-wide. Confirm field names and file layouts against the Fabric documentation for your release line before writing manifests.
| Fabric artifact | Kubernetes counterpart | Scope and what to confirm |
|---|---|---|
| Chaincode endpoint in the package | Service name and port reachable from the peer | Per organization. Each org's package names the endpoint its peers call. Confirm the address field for your version. |
| Chaincode server TLS certificate and key | Secret or CSI-mounted volume in the chaincode namespace | Per chaincode server. Keep the key file-based and confirm the server reads it from the mounted path. |
| Peer trust roots | ConfigMap or Secret mounted into the chaincode server | Per organization for the roots it trusts. Confirm which CA certificates the server validates peer connections against. |
| Chaincode definition (name, version, sequence, endorsement policy) | No dedicated object. Stored in channel configuration through the lifecycle | Shared across the channel and approved by member organizations. Confirm the approval steps in your release docs. |
| Chaincode server image | Deployment pinned by image digest | Per organization. Record the digest alongside the definition version so code and approved definition stay matched. |
| Peer access to the endpoint | NetworkPolicy allowing traffic from peer namespaces or addresses | Per organization. Confirm your cluster network plugin enforces NetworkPolicy before relying on it. |
| Package identity for traceability | Deployment label or annotation holding the package ID | Per organization. This is an operating convention, so agree the label format with your change process. |
How to verify an external chaincode service before a channel depends on it
Before any production channel depends on an externally run chaincode service, run a fixed test sequence on a non-production channel and keep the evidence. The sequence should start with the package itself. Confirm that the peer accepts the external chaincode package, which contains only the chaincode server endpoint information and TLS artifacts rather than source code, and that the external builder and launcher on the peer completes its build step without errors. A failure here usually points to a malformed connection document, a wrong label, or a builder configuration problem on the peer, so fix it before moving on to runtime tests.
Next, confirm the TLS handshake with each chaincode endpoint separately. Each peer that will use the package should complete a mutual TLS connection to the chaincode server, and the server certificate must chain to the root the peer trusts and match the name in the connection document. Test this from the peer's network position, not from a laptop, because routing and network policy often differ. Then invoke every chaincode function with known inputs and compare outputs against expected values written down in advance. Check both successful results and rejected inputs, since a function that returns the right value for valid data can still mishandle malformed arguments.
Next, test resilience. Restart the chaincode pod and confirm that transactions succeed again without re-installing the package or restarting the peer. Then force rescheduling to another node, for example by cordoning the current node in the test cluster, and repeat a transaction. These tests prove that the service identity and endpoint survive the normal life of a Kubernetes workload. Also rotate the TLS certificate used by the chaincode server in the test environment, following the process your team plans to use in production. The goal is to confirm that the peer picks up the new certificate on the agreed procedure and that no channel is left unable to reach the service during the change. Ask your team to document the exact steps and the expected downtime, if any, before the test begins.
Then test the failure path. Stop the chaincode server or block its endpoint, submit a transaction that calls it, and record exactly how the peer and client report the error. Confirm that the endpoint failure does not corrupt the ledger and that transactions resume once the server returns. The peer's operations service exposes health checks and log level management on its own endpoints, secured with mutual TLS client certificates. Use the health endpoint to confirm peer status during each test, and temporarily raise the log level with the logspec endpoint when a failure needs more detail, then restore the original level. Only clients holding authorized certificates can call these endpoints, so plan that access in advance.
For change control, keep a dated record for each test: the package identifier and version, the peer and chaincode server versions, the commands run, the inputs and expected outputs, the observed results, relevant log excerpts, health endpoint responses, and the certificate serial numbers used. Store these records with the change ticket so an auditor or approver can trace what was verified and when. Ask your implementation partner or internal team to confirm in writing which evidence they will produce for each test before the work starts, and agree which failures block promotion to production.
Securing Hyperledger Fabric external chaincode on Kubernetes
Running chaincode as an external service moves a sensitive workload into Kubernetes, so the security of that workload depends on the cluster as much as on Fabric. The cards below cover the transport, key storage, cluster secret handling and workload isolation decisions that a team should settle before the first chaincode server goes live.
TLS between peers and chaincode
The Fabric docs describe TLS between peers and chaincode servers as optional but highly recommended outside simple test environments. Plan certificate issuance, rotation and revocation before go-live, including who issues the certificates, how often they renew, and how a compromised chaincode server identity is revoked. Confirm the expiry and renewal process with your own certificate authority owners, because a lapsed chaincode certificate stops transactions on every peer that calls it.
Encryption at rest for secrets
Kubernetes stores Secrets unencrypted in etcd by default, and chaincode connection material and TLS private keys are typically held that way. Configure encryption at rest for the API server, and confirm that the etcd backups inherit the same protection, since a snapshot of unencrypted secrets is an exposure in its own right. Ask your platform team to show the encryption configuration and to test a restore of an encrypted backup.
Least-privilege access to secrets
Restrict list and watch access to Secrets in chaincode namespaces with narrowly scoped RBAC roles, because a principal that can list Secrets can read every credential in the namespace. Where secrets must live outside the cluster, the Secrets Store CSI Driver can mount them from an external store into the pod at runtime. Review who holds cluster-admin and namespace admin rights, since those roles bypass most per-resource controls.
Pod Security Standards for chaincode namespaces
Apply Pod Security Standards to the namespaces that run chaincode servers, selecting the enforcement level that your chaincode images can meet. Chaincode containers rarely need privileged access, host networking or host paths, so the restricted profile is the usual target, with exceptions documented per workload. Verify the labels on each namespace during change review, because a namespace without enforcement labels accepts any pod specification.
CIS Kubernetes Benchmark review
Use the CIS Kubernetes Benchmark as a reference when reviewing the control plane, worker nodes and network policies that host chaincode. Map each relevant recommendation to an owner and record whether it is met, accepted with a reason, or outstanding. Treat the benchmark as a checklist for an assessment you run yourself, since it does not certify the cluster, and ask your security team which benchmark version and profile they want to report against.
HSM keys and custom images
Fabric can keep peer and orderer MSP keys in a hardware security module through PKCS#11, but TLS keys must remain file-based. The prebuilt Fabric Docker images are not built with PKCS#11 support, so a team that needs HSM-backed MSP keys will likely build custom images. Confirm the HSM vendor's client library, the image build pipeline and the key ceremony owners before choosing this path, and plan how the custom images will be patched alongside Fabric releases.
Keeping chaincode runtimes aligned through Fabric and Kubernetes upgrades
Upgrading an external chaincode runtime is not a separate event from upgrading Fabric, so plan both as one change with a defined order. The first gate is lifecycle. Fabric v3.0 removed the v1.x legacy chaincode lifecycle, so every channel must already run on the v2.x lifecycle before any binary moves. Confirm this per channel with the channel administrators, because a channel still on legacy definitions will block the upgrade path. Migrating Kafka ordering to Raft is a separate prerequisite on the same list, and it belongs in the pre-upgrade checklist rather than in the chaincode runbook. The Fabric upgrade guide sequences the work in four steps: back up the ledger and MSPs, upgrade orderer binaries in a rolling fashion, upgrade peer binaries in a rolling fashion, then update application channel capability levels. Capability updates change network behavior, so they should be the last step, taken only after every orderer and peer runs the new binaries. Treat the backup step as a restore test, not a file copy, and record which peer and orderer versions each channel was running at each stage so that a rollback decision is based on evidence. Chaincode servers are a second moving part. Because an external chaincode package holds only the endpoint and TLS artifacts, the chaincode server image is versioned separately from the peer. Decide in advance whether chaincode servers move before, during or after the peer binaries, and document that order for each organization. The key risk is a chaincode server built against an API or serialization assumption that a peer on the other side of the upgrade does not yet share. Run the chaincode server in a staging network at the same peer version you are about to deploy, and confirm that endorsement succeeds before promoting the server image. Kubernetes adds its own skew rules. The version skew policy requires kube-apiserver to move one minor version at a time, ahead of kube-controller-manager, kube-scheduler and kubelets, and allows kubelets to be up to three minor versions older than the apiserver. Pick a supported minor release that your distribution certifies, check its end-of-life date on the Kubernetes releases page, and schedule the cluster upgrade so that chaincode pods do not fall outside the window. Before each cluster step, take an etcd snapshot as part of the control plane backup plan. Finally, the Fabric Gateway client API is compatible with both v2.5 and v3.0, so client applications can follow a separate track. Confirm which v2.5 patch line your organization is running, and do not let application teams wait on the network upgrade or the reverse. Assign one owner to each track, so the chaincode server, peer binary, cluster and client changes are scheduled against a single agreed calendar.
Common failures when running chaincode as an external service
This table lists the failures most often seen when chaincode runs as a separate service that peers call over the network, with the cause of each and the check that confirms it. Read each row as a triage starting point, and confirm the exact behavior of your Fabric and Kubernetes versions against the official documentation before changing production settings. The main takeaway is that most failures trace back to endpoint naming, certificate identity, or secret and certificate lifecycle, which are all checkable before go-live.
| Failure | Likely cause | Fix and confirming check |
|---|---|---|
| Peer cannot reach the chaincode endpoint | The Service name, DNS record, or network policy does not allow traffic from the peer namespace to the chaincode pod port | Resolve the endpoint from the peer pod with a DNS lookup and open a TCP connection to the port. Then review the Service selector and any NetworkPolicy ingress rules for the peer's namespace and labels. |
| TLS handshake fails between peer and chaincode server | The certificate subject alternative name does not match the address in the connection.json endpoint, or the peer does not trust the issuing CA | Inspect the server certificate's SANs and compare them with the endpoint value in the package. Confirm the CA bundle in the package matches the CA that signed the server certificate. |
| Chaincode server loses in-memory state after restart | The chaincode code assumes state persists between invocations inside the process, which a pod restart or rescheduling breaks | Keep all ledger data in the world state through the shim APIs and treat process memory as cache only. Test by restarting the chaincode pod mid-workload and confirming transactions still validate. |
| Package points at an endpoint that changed during a Kubernetes upgrade | The Service IP, DNS name, or ingress address changed after cluster rebuild or upgrade, while the installed package still holds the old address | Use a stable DNS name for the chaincode Service. Compare the address in the installed package with the current Service after each cluster change and reinstall the package with the updated endpoint if needed. |
| Certificates expire without rotation | Chaincode server or TLS client certificates were issued with a fixed lifetime and no renewal process was defined or tested | Record each certificate's expiry date in your inventory and set alerts well before expiry. Rehearse rotation in a non-production network, including the package update and the peer restart it requires. |
| Secrets readable by too many service accounts | Chaincode TLS keys or credentials are stored in Kubernetes Secrets that broad RBAC roles or default service accounts can list or read | Restrict get, list and watch on those Secrets to the chaincode workload's service account only. Review RBAC bindings and confirm encryption at rest is configured for etcd, as the Kubernetes Secrets guidance describes. |
| Chaincode image lacks a dependency used by the external builder | The external builder or launcher scripts call a tool or library that the container image does not include, so the build or launch step fails | Run the builder and launcher scripts manually inside the image with a sample package. Confirm every binary and library they invoke is present, and pin the image version used in the builder configuration. |
Questions buyers ask before running external chaincode
Can our own team run external chaincode without a partner?
Yes, if your team already runs Fabric and Kubernetes and has the upgrade and TLS skills the Fabric docs describe. In that case, most of the work is configuration, testing and a runbook your staff can repeat. Confirm these skills before deciding:
- Operating peers and orderers through rolling binary upgrades
- Issuing and renewing TLS certificates through your certificate authority
- Managing Kubernetes workloads, secrets and network policy
- Reading peer and chaincode server logs during an incident
A partner's review is worth it when the first production rollout spans several organizations, when TLS or PKI ownership is unclear, when an HSM is in scope, or when nobody on the team has operated a chaincode server before. Many teams use a separate design review before go-live, scoped apart from the full build.
What drives the cost of running Fabric chaincode as an external service?
The main cost driver is the scope you agree in writing. A quote usually changes with the number of organizations and peers that connect to each chaincode server, the number of chaincode packages to move, how mature your TLS and PKI practices are, how ready your Kubernetes platform is, whether an HSM must hold MSP keys, and how much testing you require before production. Design and build work is usually one-time, while support, upgrades and retained testing recur. Ask for a written scope that lists each organization, peer, package and environment, and marks each item as one-time or recurring. DeployOpen does not publish a price list, so compare quotes against the same written scope.
How long does it take to move chaincode to an external service?
Duration depends on the agreed scope and the state of your clusters, so no timeline can be given responsibly without them. Clusters that already run Kubernetes with working certificate issuance, secrets handling and monitoring usually move faster than clusters that need platform work first. Coordination across member organizations is often the slowest part, because each one must name owners, approve changes and run its own tests. Ask for a written timeline with milestones tied to the scope. Also check which dependencies sit outside the engagement, such as CA changes, cluster upgrades or change board approvals, and plan a test channel run before any production channel changes.
Do we still need to install chaincode on every peer?
No. The Fabric docs say an external chaincode package contains only the chaincode server endpoint information and TLS artifacts, so installing the chaincode on each peer is no longer required. The external builder and launcher on each peer read that package and connect the peer to a chaincode server that runs independently in your cluster. This removes per-peer builds and lets operators upgrade the chaincode runtime without rebuilding on every peer. Each organization still controls its own peer and must trust the endpoint it is configured to reach. Plan endpoint naming, package distribution and version tracking before the first install.
What must our organization provide before an external chaincode project starts?
Your organization must provide four inputs: a named owner for each member organization, access to the Kubernetes clusters where peers and chaincode servers run, access to the certificate authority that issues enrollment and TLS certificates, and a test channel where chaincode changes run before production. Named owners approve scope decisions and sign off on endpoint and certificate changes. Cluster access should cover the namespaces, network policies and secrets used by the chaincode workloads, granted under your least-privilege model. CA access lets the team confirm issuance, renewal and revocation paths. The test channel should mirror production policies closely enough that results carry over. Write these inputs into the scope so they are scheduled early.
Is TLS required between peers and external chaincode servers?
The Fabric docs say TLS is optional but highly recommended outside simple test environments. For a production network that handles production business data, treat TLS as a baseline and confirm the requirement against your security policy and any compliance obligations. Plan certificate issuance, distribution to both the peer and the chaincode server, renewal before expiry, and revocation. Clarify which CA issues these certificates, how private keys are stored, and who responds when a certificate expires. Document the TLS settings in your runbook so an operator can verify them during each upgrade. Ask your reviewer which controls in your framework the TLS design supports, and confirm that mapping with them directly.
Does an HSM change how external chaincode is deployed?
It can. The Fabric docs state that peer and orderer MSP keys can be kept in an HSM through the PKCS#11 standard, but TLS keys must remain file-based. The prebuilt Fabric Docker images are not built with PKCS#11 support, so an HSM setup needs custom images that your team or the engagement must build, test and patch. Confirm which keys go to the HSM, which stay on disk, how the chaincode server reaches its keys, and how backups of HSM-held keys are handled. Test the HSM path in the test channel before any production node depends on it, including a peer restart and a certificate renewal.
How DeployOpen scopes, delivers and supports external chaincode services
DeployOpen plans, implements, documents and supports Hyperledger Fabric chaincode run as an external service inside your own infrastructure. Each engagement starts from a written scope that sets out which chaincode runtimes, peers and organizations are covered, and the work is built, tested and handed over against that scope. Ongoing support is available as a retainer.
How we scope
- Inventory every chaincode package, peer and member organization that will move to external runtimes.
- Agree in writing which runtime platform, endpoint naming and TLS model the network will use.
- Confirm which Fabric lines are in use, including any channels still on the legacy lifecycle.
How we build
- Configure the external builder and launcher on each peer and verify it discovers the chaincode endpoints.
- Build endpoint and TLS packages in place of source packages, so each peer no longer compiles chaincode.
- Test TLS between peers and chaincode servers, including certificate rotation, before any channel go-live.
How we hand over
- Deliver runbooks for packaging, approving and committing chaincode definitions across member organizations.
- Document the chaincode runtime configuration, secret locations and certificate renewal steps for your operators.
- Walk your platform and security teams through failure cases, such as a chaincode server restart during endorsement.
How we support
- Offer ongoing support, patching and upgrade work as a retainer once the handover is complete.
- Plan chaincode runtime changes alongside Fabric binary upgrades and channel capability updates.
- Run security testing of chaincode endpoints and their TLS configuration when your change process requires it.
