Why teams deploy Apache Kafka in air-gapped networks
Teams run Apache Kafka in air-gapped networks when regulated data, operational technology or classified workloads must stay on a network with no internet path, and the streaming platform has to live inside that boundary. The short answer is that Kafka can run fully offline, because the broker, controller and client code is self-contained once it is inside your network. What changes is where every artifact comes from. Kafka is licensed under the Apache License 2.0 and the Apache Software Foundation project has no paid edition, so there is no license purchase to negotiate for an isolated deployment. The work moves to mirroring, building and operating the platform on your side of the boundary.
That work has three parts that depend on an internal source. The release archive of Kafka binaries must be copied from the Apache downloads page into an internal repository, and only the releases the project still supports should be carried across, starting with the current list on the Kafka downloads page. Container images for brokers and any operator must be pulled, checked and pushed to an internal registry. Kafka Connect connectors are not bundled with the platform, so each connector JAR and its dependencies must be collected, reviewed and baked into a Connect image before the network is closed. If any of these three sources is missing an entry, the cluster will fail at install or at the next patch, not at design time.
What to mirror into the isolated network for Kafka
Every Kafka deployment behind an isolated boundary depends on a small set of artifacts that must be fetched outside and carried in. Each one is a point where unverified software can enter, so each needs a recorded checksum and provenance before it is trusted inside.
Kafka release archives
Mirror the release archives for the supported releases listed on the downloads page: 4.3.1, 4.2.2 and 4.1.2. Keep the matching checksum and signature files next to each archive, and record which release the cluster runs. Older archives stay out of the mirror unless a documented need exists. Confirm the exact file names and verification steps against the downloads page before you copy anything across.
Container images
Images for brokers, controllers, Connect workers and any operators must be pulled, scanned and pushed to an internal registry under pinned tags. Pin by digest where your registry supports it, so a retagged image cannot change silently. Record the source registry, the digest and the signing data for each image. Confirm which official image tags the project publishes before you build your mirror list.
Java runtime and OS packages
Brokers, Connect and tools require Java 17 from Kafka 4.0 onward, so the JDK or JRE build is a boundary artifact in its own right. Mirror the operating system repositories or ISO images the hosts use, including the patches for the kernel, OpenSSL and the JVM. Keep package signing keys in your records so each package can be checked when it is installed.
Kafka Connect connector plugins
Connector plugins are third-party code that runs inside Connect workers with access to your data. Pull each connector archive, its licence file and its dependency list in advance, then build the Connect image from those local copies. Check each plugin's licence, since terms vary by connector. Ask the connector maintainers for their signing or checksum method before you accept a build.
Build tooling and dependencies
Any image build, Maven or Gradle step, and base image needed to compile connectors must be mirrored with its full dependency tree. A build that reaches a public repository at run time breaks the boundary without anyone noticing. Store the lock files, the dependency checksums and the build tool versions with the output. Test the offline build from a clean environment before relying on it.
Provenance and checksum records
Keep one register that lists each artifact, its source, its checksum, its signature check result, the person who approved the transfer and the date. NERC CIP-013-2 requires supply chain procurement processes to address verification of software integrity and authenticity for vendor software and patches, so this register is the evidence an assessor will ask for. Confirm with your compliance lead which framework applies to your environment.
Choosing how to bring Kafka artifacts across the boundary
In a fully disconnected network, the Kafka release archive, container images, connector plugins and their checksums move on approved media or through a one-way data diode. A staging host outside the boundary downloads the artifacts, records what it took and writes them to the transfer medium. The security team on the outside usually owns approval, and the team that runs the cluster owns the manifest.
- Transfer path: Stage archives, images and connector JARs on an outside host and write a manifest listing each file name, version and checksum.
- Approval: Named approvers sign the manifest before media leaves, and the record shows who approved which release.
- Re-verification inside: Recompute checksums on arrival, compare them with the manifest and the values the project publishes, then scan container images with your own tooling.
- Return path: A diode carries nothing back, so logs, vulnerability findings and requests for new artifacts need a separate, approved route.
- Media custody: Track who handles each device and scan it on entry before any file is copied.
Confirm with your security team whether a diode or removable media is the accepted path, and who must countersign each transfer.
In this model, the inside network reaches only an internal artifact proxy or mirror, and that proxy is the only system allowed to pull from approved upstream sources. The proxy sits in a controlled zone, so build hosts and cluster nodes never contact the internet directly. Approval happens at the gate between the upstream and the proxy, which makes that gate the main control point.
- Upstream allowlist: Pull only named release archives, images and connector versions, pinned to the versions your change process has approved.
- Approval queue: A reviewer approves each new version before it becomes visible to build hosts.
- Verification at ingest: Verify project-published checksums and signatures where they exist, and scan images before they are promoted.
- Immutable promotion: Keep promoted artifacts read-only and retain earlier versions so you can roll back a patch.
- Patch flow: Run patch releases through the same queue with a dated change record, so auditors can trace each update.
Even with a trusted proxy, confirm whether your policy requires a second check on the inside, who owns the proxy and how upstream access is logged.
Classified and high-assurance enclaves often accept only artifacts that have passed a formal review under an accredited transfer process. The technical copy is usually the easy part. Approval may involve several authorities, and the review can take longer than the installation itself. Your accreditation authority decides the transfer mechanism, so the process may differ from what a commercial air-gapped network uses.
- Accredited transfer: Use the mechanism your accreditation authority has approved, and confirm whether build tools and base images count as software to transfer.
- Separated approval: Expect separate approvers for the source, the content and the transfer, documented for each release.
- Independent verification: Re-hash artifacts and run malware and vulnerability scans on a separate inspection system before anything reaches the enclave.
- Integrity evidence: Keep provenance and checksum records. Energy sector operators may need this for supply chain controls such as NERC CIP-013-2, which asks for verification of vendor software and patch integrity.
- Expedited patches: Agree in advance on a faster path for urgent security patches, since a standard review may be too slow.
Confirm with your accreditation authority which artifacts need formal review and how long each approval step is expected to take in your environment.
How to build the air-gapped Kafka install in order
This sequence moves a Kafka 4.x KRaft cluster from an internet-connected staging area into an isolated network, with each step ending in a check that proves the artifacts and the cluster are what you expect. Work through it in order, because later steps depend on checksums, mirrored images and internal certificates set up earlier.
Inventory versions and the upgrade path
Record the Kafka release you will deploy, the Java runtime, the Connect connectors and the Kubernetes or VM platform each one depends on. Confirm the target release against the supported releases on the Kafka downloads page, and if you are coming from an older KRaft cluster, check the upgrade notes first, since 4.x requires Java 17 for brokers and Connect. Done means a signed-off bill of materials that lists every artifact, its version and its source URL, and an upgrade path that starts from a release your cluster can roll from. Confirm the rolling upgrade rules with the Kafka release plan before you commit to a version.
Mirror the release archive and images
On an internet-connected staging host, download the Kafka binary archive, its published checksum and signature files, and every container image your deployment references, including the Kafka image, the Java base image and any operator images. Store them in an internal artifact repository and registry that the isolated network can reach. Done means every file passes checksum and signature verification on the staging host, and the mirrored image digests match the digests you recorded in step one. Keep the verification output with the bill of materials so an auditor can trace each artifact back to its origin.
Set up internal package and registry endpoints
Point the broker, controller and build hosts at the internal artifact store and registry, and disable outbound package manager and container pulls at the network boundary. Configure the OS package sources, Maven or Gradle repositories used for connector builds, and the registry hostname that your Kubernetes or VM tooling will pull from. Done means a test host inside the isolated network can resolve and pull each artifact from the internal endpoints, and a test pull to an external hostname fails. Record the failure so you can show the boundary is enforced.
Build the Connect image with approved connectors
Build a Kafka Connect image from the mirrored base image, adding only the connector plugins your security and data owners have approved, along with their dependency jars resolved from the internal repository. Do this on the staging side or inside the isolated build network, and do not let the Connect worker download plugins at startup. Done means the image is pushed to the internal registry, each connector jar is listed with its checksum in the bill of materials, and a container started with no outbound route loads the plugins and reports them through the Connect REST plugin listing.
Provision internal CA certificates for listeners
Issue server and client certificates for each broker and controller listener from your internal certificate authority, including the advertised hostnames that clients will use. Distribute the trust chain to every host and to the Connect and tooling images, and set the truststores and keystores that the listener configuration expects. Done means a TLS handshake succeeds against each listener using only the internal CA, and a client that does not trust the internal CA is refused. Confirm the certificate lifetimes and renewal process with your security team, since the certificate authority and its renewal tooling must also run inside the boundary.
Format KRaft storage with a shared cluster ID
Generate one cluster ID with the kafka-storage tool, then format the metadata and log directories on every controller and broker with that same ID, using the initial controller settings that match your quorum layout. Keep the formatting commands and their output in your change record, because a mismatched ID or a reformatted directory is a common cause of a node failing to join. Done means each node reports successful formatting and its directory contains the expected metadata files.
Verify the quorum with no outbound calls
Start the controllers first, then the brokers, and confirm the quorum forms and every broker registers with the metadata quorum. Use the Kafka admin tools to describe the quorum and list brokers, then produce and consume a test message over the TLS listeners. Finally, capture the network flows from the cluster hosts during startup and a test workload, and confirm no connections leave the isolated network. Done means the quorum reports a leader and all expected voters, the test message round-trips, and the captured traffic shows only internal destinations. Keep the flow capture with the bill of materials as evidence for the offline claim.
Building Kafka Connect images with connectors in advance
Every connector plugin a Kafka Connect worker will load must be inside its image before the cluster is isolated, because a plugin cannot be fetched from a repository later. Connect workers load plugins from plugin paths at startup, so the build step is where you decide which connectors exist in the air-gapped estate. Treat the Connect image as a versioned artifact: build it on a connected staging network, record the exact connector versions and their checksums, and push the result through your mirror. Any connector you forget at this stage becomes a change request that needs another transfer across the boundary, so inventory the source and sink systems first.
Plan the build around three checks. First, confirm the Java runtime: since Kafka 4.0, brokers, Kafka Connect and tools require Java 17, so the base image and every connector must run on that level, and clients and Kafka Streams applications need at least Java 11. Second, resolve the dependency closure, meaning every transitive JAR a connector pulls in, not only the connector's own package, and check that the bundle does not conflict with the Kafka libraries already in the image. Third, review the license of each connector and its dependencies against your organization's policy, since many connectors are not licensed under the Apache License 2.0 that covers Kafka itself. Connector-specific build steps, configuration and failure modes belong in the Kafka Connect connector pages, so use those for the details of each plugin. The image is not finished when it first builds. Rebuild whenever a connector version changes, a security fix lands in a dependency, or the Kafka version moves, and rerun the same closure and license checks each time. Keep the previous image tagged so a rollback does not depend on the connected network. Document who approves a new plugin, because each addition enlarges what must be patched and reviewed across the isolated boundary.
Air-gapped build options and when each fits
This table compares the main ways to get images, plugins and certificates into a network with no internet access. Read each row as a choice you make once and then operate, and note that the operational cost column is where the ongoing work sits. The main takeaway is that mirroring and internal issuance usually cost more to run but remove repeated manual handling at each upgrade.
| Option | What it solves | Operational cost | When it fits |
|---|---|---|---|
| Mirrored private registry | Holds Kafka and Strimzi images and pulls them from inside the enclosure | Someone must sync, scan and retag each release and patch before it crosses the boundary | Kubernetes-based clusters with several environments pulling the same images |
| Preloaded image tarballs | Loads known image digests onto nodes without running a registry | Manual transfer per release and per node, with higher risk of version drift | Small, stable clusters with few upgrades and a single operator team |
| Internal artifact repository for Connect plugins | Serves connector JARs and dependencies to a Connect image build | Needs repository hosting, license review of each connector and checksum records | Teams that build custom Connect images regularly and need repeatable builds |
| Bundled plugin directories | Ships connector archives in a fixed directory baked into the image or host | Each connector update means a new image build and a new transfer | Few connectors that change rarely, such as one database source and one sink |
| Internal certificate authority with cert-manager | Issues broker, controller and client certificates automatically and renews them | Operating the CA, protecting its key, and maintaining issuers and rotation policy | Clusters with many listeners or frequent renewals and an owner for PKI |
| Manual certificate issuance | Produces certificates with the CA team outside the cluster and installs them as secrets | Repeated manual requests, tracking expiry dates and reinstalling at each rotation | Small deployments with a short list of certificates and a clear renewal calendar |
| Offline source of patch releases | Gives the team a verified copy of each supported Kafka patch release to review | Someone must monitor the downloads page and move signed archives across the boundary | Every air-gapped deployment, since patch releases arrive on their own schedule |
Internal certificate authorities for Kafka listeners
Kafka makes both SSL/TLS and SASL optional, so an isolated deployment has to decide listener by listener what is encrypted and how clients prove who they are. The cards below cover the decisions that tie those choices to an internal certificate authority that no public CA or online service can backstop.
Decide which listeners are secured
Kafka allows clusters to run unsecured or to mix secured and unsecured listeners, so nothing is protected by default. Map every listener to its traffic: client, inter-broker, controller and tool access. Write the choice down per listener before the first broker starts, because changing it later means a rolling restart of every node. Confirm that the controller listener and the broker listener are configured separately in your KRaft layout.
Build an internal CA trust chain
Brokers, controllers, clients, Kafka Connect workers and admin tools all need certificates that chain to a root your organization controls. Keep the root offline, issue intermediates for the Kafka estate, and distribute the root to every truststore that connects to the cluster. Check that each host name or subject alternative name matches the address clients and peers actually use, since a mismatch fails at handshake time.
Plan renewal without public CAs
Without a public CA or an automated external service, every certificate expiry is an operational event that someone must notice. Record the expiry date of every broker, controller and Connect certificate, and assign an owner for each renewal. Test the rotation procedure on a non-production cluster, including the rolling restart it requires. Confirm which keystore formats your Kafka version reads and how your internal PKI issues them.
Choose SCRAM for password-based clients
SCRAM-SHA-256 and SCRAM-SHA-512 are documented SASL mechanisms that store credentials in the cluster rather than in an external directory. They suit isolated sites where no Kerberos realm or identity provider is reachable. Credentials still need a rotation process and secure distribution to application teams. Confirm the mechanism version your clients support before you pick one.
Use Kerberos or OAUTHBEARER where they already exist
GSSAPI (Kerberos) and OAUTHBEARER are documented SASL options that fit sites already running a directory or token issuer inside the isolated network. Kerberos requires reachable key distribution services for every client, and OAUTHBEARER requires an issuer that the brokers can validate tokens against offline. Check that these services are available inside the boundary and that their own certificates are issued by the same internal CA.
Connect authorization to authentication
Authentication only tells Kafka who connected. In KRaft clusters the StandardAuthorizer stores ACLs in the metadata log, and resources without ACLs are limited to super users unless allow.everyone.if.no.acl.found is set to true. Define super users and the principal names your certificates or SASL identities produce before issuing credentials, so that access rules match the identities your internal CA actually signs.
Updating Kafka patch releases without internet access
Every bugfix release has to be mirrored, tested and rolled through the cluster by your own team. The Kafka downloads page lists 4.3.1, 4.2.2 and 4.1.2 as the supported releases, and the project makes bugfix releases as needed for those supported versions only, while aiming for three feature releases a year. Nothing arrives automatically on an isolated network, so the update process starts with someone watching the Apache Kafka downloads page and deciding which releases matter for your clusters. Mirror the broker archive, the matching Connect image and any container images through the same controlled import path you use for the original install, and check each artifact against the checksums and signatures published with it before it crosses the boundary. Keep a record of what was imported, when, and by whom, since that record is the evidence a supply chain review will ask for.
Plan each patch as a rolling upgrade in a staging copy of the air-gapped environment first. The Kafka time-based release plan states that rolling upgrades are supported from each release in the past year, which means the last three releases, to the latest version. Use that window to decide your minimum supported starting point: a cluster running a release outside that window will need one or more intermediate steps before it reaches the current line. Confirm the exact upgrade sequence for your version pair in the Kafka 4.3 upgrade notes before scheduling anything, and run your own client and Connect workloads against the staged cluster before touching production.
The same upgrade notes set a hard prerequisite for older clusters. They recommend that KRaft clusters older than 3.3.x first move to 3.9.x before going to 4.x, so a site still on an early 3.x line needs a two-stage plan with a second window and a second round of mirroring and testing. Clusters still running ZooKeeper must complete the migration to KRaft before any 4.x upgrade, because 4.0 removed ZooKeeper mode. Record these checkpoints in your change calendar now, and confirm the Java runtime on every node, since brokers and Connect require Java 17 from 4.0 onward and that runtime must also be mirrored and patched offline.
Security and access control in a disconnected cluster
In a disconnected network, the Kafka cluster is often the only place where access decisions are enforced and recorded. The cards below cover where authorization state lives, what happens when no rule exists, how external authorization fits in, and what local evidence your team must keep without help from a vendor cloud.
ACLs live in the metadata log
In KRaft clusters, the StandardAuthorizer stores ACLs in the cluster metadata log rather than in an external database. This means ACL state replicates with the controllers and moves with the cluster when you back it up or rebuild it. Before go-live, confirm that your authorizer class is set to the StandardAuthorizer and that your runbooks treat ACL changes as cluster metadata changes that must be reviewed like configuration.
**Missing ACLs deny by default**
Resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. Teams moving from a permissive test cluster often find producers and consumers failing after go-live for this reason. Confirm which accounts are listed as super users, keep that list short, and test that an unlisted client is denied before you onboard applications.
Keep the open-by-default setting off
Setting allow.everyone.if.no.acl.found to true lets any authenticated or unauthenticated principal reach resources that have no ACL. In an isolated network this can look harmless, but it removes the deny-by-default posture that auditors and security teams expect. Ask your security team to document any exception, the resources it covers and the date it will be removed, and verify the effective value on every broker during configuration review.
Authentication before authorization
Authorization only decides what an identity may do after Kafka has established who it is. Kafka supports SSL and SASL for client, broker and tool authentication, with GSSAPI (Kerberos), PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER as documented SASL mechanisms. Choose the mechanism that matches the identity source you can run inside the disconnected network, and confirm that unauthenticated listeners are not exposed to application subnets.
External authorization hooks
Kafka authorization is pluggable and can integrate with external authorization services. If your organization already manages access in a central policy engine inside the enclave, you may want Kafka decisions to follow it. Treat any custom authorizer as code you build, test, patch and keep available offline, and confirm with your Kafka version that the plugin interface you target is documented and supported.
Local audit evidence
Auditors and incident responders will ask who changed an ACL, when, and what traffic followed. Kafka's authorization model records the access state, but your team must decide how authorizer decisions, broker logs and configuration changes are collected, retained and protected inside the disconnected network. Ask your team to define the log destinations, the retention period and who can read them before the cluster carries regulated data.
Questions teams ask before an air-gapped Kafka build
Does running Apache Kafka in an air-gapped network require a paid edition?
No. Apache Kafka is an Apache Software Foundation project released under the Apache License 2.0, and the project itself offers no paid edition. The licensing question shifts to what surrounds Kafka: the operating system, the JVM, the container base images, connectors and any vendor distribution you choose. Check the license of each connector you plan to carry across the boundary, because some connectors and management tools are licensed differently from Kafka. Ask any partner or vendor to state in writing which components in the bundle carry commercial terms.
What drives the cost of an air-gapped Kafka build?
The main drivers are the number of artifacts to mirror and verify, the number of connectors and plugins, the number of environments, and the approval process that governs each transfer across the isolated boundary. Each Kafka release archive, container image, Java runtime, operating system package and connector jar adds a step to the mirror, the scan and the import. One-time work covers the mirror design, the internal certificate authority, the first build of Connect images and the runbook. Recurring work covers each patch cycle. Ask any quote to itemize these components so you can see which ones scale with your environment count.
How long does an air-gapped Kafka build take?
Duration depends on the size of the artifact set, the number of environments, how many connectors you need, and how long your internal review and transfer approvals take. Your own change and security approval cycle is often the longest single factor, so start that process early. A fixed-scope agreement sets the timeline in writing before work starts, based on the inventory you agree to. Ask for the timeline to be tied to named milestones such as mirror validation, first cluster bootstrap and first patch rehearsal.
What does the work need from our team?
Expect to provide access to the isolated network, a named owner for the transfer process, an internal certificate authority or its signing policy, and a decision on which Java and operating system versions are approved. You also need a registry or artifact repository inside the boundary, and someone who can approve the import of each release bundle. Kafka teams usually need someone who knows the Kafka configuration, and security staff who can review scan results. Confirm these roles early, since a missing approver is a common cause of delay.
Can our own team build an air-gapped Kafka environment without a partner?
Yes, many teams do, especially when they already run Kafka and have mature mirroring and approval processes. The work is manageable when the team has experience with Kafka KRaft bootstrapping, container image pipelines and internal PKI. The gaps that usually appear are the Connect image build, the verification of every imported package, and the patch rehearsal. A partner can take on any of these as a fixed-scope piece, or review your design, so you decide which parts to keep in-house.
How does patch cadence affect an air-gapped Kafka environment?
The Kafka project aims for three releases a year, one every four months, and issues bugfix releases as needed for supported releases only. The supported releases listed on the downloads page are 4.3.1, 4.2.2 and 4.1.2, with earlier versions archived. Because every patch must cross the boundary, plan a fixed monthly or quarterly transfer window and treat bugfix releases as a standing intake item. Confirm with your security team how quickly an urgent fix must be imported, and rehearse the rolling upgrade path in a non-production environment before you need it.
Which Java version do we need, and how do we keep it patched offline?
Since Kafka 4.0, brokers, Kafka Connect and tools require Java 17, and clients and Kafka Streams applications require at least Java 11, according to the Kafka upgrade notes. Choose one Java runtime for the brokers and Connect, mirror its patch releases alongside Kafka, and verify each one before import. Java updates carry their own security fixes, so they belong in the same intake process as Kafka bugfix releases. Ask your team to confirm the approved Java build, since it must also be present in every Connect and broker image you build inside the boundary.
How do we verify packages that cross the isolated boundary?
Verify the integrity and authenticity of every archive, image and connector before it enters the network, and record the checks as evidence. Compare published checksums and signatures against the source, scan the artifacts, and keep a signed manifest of what was imported. Supply chain requirements such as NERC CIP-013-2 ask for verification of software integrity and authenticity of vendor software and patches, and similar expectations appear in other frameworks. Confirm with your compliance lead which evidence format your auditors accept, since DeployOpen prepares these controls and evidence but does not issue audit reports or certifications.
Limits to confirm in your environment
Air-gapped Kafka depends on several things that no release note can settle for you. The cards below cover the items that most often change between a lab rehearsal and a production build, and each one needs a test on your own hardware, your own mirrors and your own network path.
Connector licensing and availability
Every Kafka Connect connector you bake into an image must be licensed for your use and must be fetchable from a source you have approved. Some connectors ship under licenses that restrict redistribution or commercial use, and some are only distributed through vendor portals that a restricted network cannot reach. Confirm the license text, the redistribution terms and the artifact source for each connector, then record the exact version and checksum that goes into your image build. A connector missing from the mirror at build time blocks the whole pipeline, so check this before the first rehearsal.
Mirror storage sizing
Mirrored release archives, container images, Connect plugin bundles and operating system packages all consume storage inside the isolated network, and they grow with every patch cycle you keep. Estimate how many Kafka versions you will retain for rollback, how many image tags you will keep, and how often you will refresh the mirror from the outside. Then test the transfer and verify the size on the inside network, because media capacity and transfer windows often decide the cadence more than the size of any single artifact.
KRaft and Java support on your OS
Confirm that the Kafka version you plan to run supports the Java version your target operating system ships or your approved package set provides. Since Kafka 4.0, brokers, Kafka Connect and tools require Java 17, while clients and Kafka Streams applications require at least Java 11. Check the upgrade notes for the exact Kafka release you select, and confirm that the Java runtime is available as an approved package inside the boundary, with its own patch stream. A supported Kafka release on an unsupported Java build is still a gap.
Offline monitoring stack
Metrics dashboards, alert managers, log shippers and any hosted notification service must run without reaching external endpoints. Check that each component installs from your mirror, that it does not phone home for licensing, telemetry or plugin downloads, and that its alert routes terminate on internal systems only. Kafka exposes JMX metrics that many teams scrape with an exporter, so verify the exporter, its dependencies and its dashboard templates all come from inside the boundary before you call monitoring ready.
Vendor documentation access
Operational runbooks often link to online documentation, release notes and issue trackers that your operators cannot open from the isolated network. Decide which upstream pages you will copy into an internal knowledge base, which version of each page you will keep, and who approves updates to that copy. Confirm that the copies are dated and tied to the Kafka version you run, because a runbook that describes an older configuration key can cause an outage during a patch window.
Patch release verification
Each supported Kafka release receives bugfix releases as needed, so your process must repeat the mirror, checksum and rehearsal steps on every patch cycle. Confirm that you can verify the signature or checksum of each archive and image against values published upstream, and that someone inside your organization owns the decision to accept a patch. Test a rolling upgrade in a staging cluster before production, since the release plan supports rolling upgrades from the last three releases to the latest version.
How DeployOpen scopes and delivers an air-gapped Kafka build
DeployOpen delivers an air-gapped Kafka build as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before any work starts. The scope usually fixes the Kafka release line, the broker and controller counts, the operator or packaging method, the Connect connectors to be pre-built, and the set of artifacts to mirror. Because Apache Kafka is released under the Apache License 2.0 with no paid edition from the project itself, the scope document should spell out which third-party images, connector archives and certificate chains are in the bundle, since those are the items that actually need licensing review. The mirroring and build plan then becomes the working document: it lists each release archive, container image and connector artifact, its source, its checksum or signature check, and the internal location it lands in.
The build itself runs inside your network. DeployOpen configures the KRaft clusters, the internal certificate authority trust, the listener and authorization settings, and the Connect image with its connectors, then hands over the configured clusters with runbooks and the verification records from the build. The update process for patch releases is set out in the same plan, so the client knows who pulls each bugfix release, how it is checked and how it moves across the boundary. Optional retainers can cover patch-release intake, upgrade preparation within the supported release window, and recurring testing of the isolated environment. The fees, response expectations and included activities for any retainer are fixed in its own written agreement, and the quote should separate one-time build work from these recurring services.
DeployOpen prepares systems, configurations, procedures and evidence that support compliance assessments, including records of how each artifact was verified and how access to the Kafka clusters is controlled. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so the client should confirm early with its assessor which evidence formats, sampling periods and control mappings they expect, and agree that list in the written scope.
