Why Apache NiFi in air-gapped networks needs planning before install
A NiFi install on an isolated network has to be planned as a closed system, because no package, NAR or certificate can be fetched when a team needs it. NiFi itself is an Apache Software Foundation project released under the Apache License 2.0, and the project does not sell a paid edition. That means there is no license purchase to negotiate for an offline deployment. The cost is engineering and governance effort: deciding what enters the network, verifying it, storing it internally and proving that the system behaves the same without outside access. Teams usually need this setup when they run in regulated environments, operational technology (OT) adjacent networks or sovereign environments where data and software must stay inside a controlled boundary.
NiFi needs the network at three points. At install, you need a Java runtime (Java 21 is the minimum) and the NiFi binaries. At startup, the process must reach its configured keystore, truststore, authentication provider and, in a cluster, its coordination service. At runtime, the flow itself may call external endpoints, and any optional Python-based processors need their own packages. Each of these must be satisfied from inside the network, so the team should inventory them before the first install. Confirm the Python versions your chosen processors support (the administration guide lists Python 3.10, 3.11 and 3.12 for the Python-based processors, which it describes as beta), and confirm which NARs your flows require.
Plan the transfer process early, because the same controls will be tested later. Each binary, NAR and Python package carried across the boundary should have its checksum or signature verified against the source before it is staged, and the verification record should be kept. This maps to the supply chain expectations in NERC CIP-013-2 for teams in the electric sector, and to the same discipline elsewhere. Also confirm with your own security and compliance leads how certificates and time sources will be issued and synchronized on the isolated segment, since NiFi's TLS and cluster behavior depend on both. Decide these questions before install, because changing them after a cluster is running is much more expensive.
Offline deployment options and when each fits
This table compares four ways to get NiFi and its extensions onto a network with no internet access. Read each row for the situation it suits, what it adds to your change process and what you must confirm before choosing it. The main takeaway is that the more custom code you carry across the boundary, the more verification and change control you own. Note that NiFi 2.12.0 is the current release on the downloads page, and the 1.x line is out of support.
| Option | When it fits | What it adds to change control | What to confirm first |
|---|---|---|---|
| Convenience binary with verified offline transfer | Standard processors only, and the team can accept the bundles in the official binary | Checksum and signature verification of the release archive on import, plus a record of who approved each transfer | That the release you need is 2.12.0 or a later 2.x patch, and that every required processor ships in the standard binary |
| Custom distribution built with the NARs you need | Optional or third-party bundles are missing from the binary and you can build and sign them internally | A build pipeline on your side, a repeatable Maven build per release and a reviewed bill of materials for every bundle | Build tooling and JDK versions that work offline, and who owns rebuilds when a new 2.x release ships |
| Autoloaded custom NARs | Extra bundles must be added without rebuilding the distribution, and restarts must be limited | Each NAR becomes a separately approved artifact with its own version, dependency review and rollback plan | The autoload directory's polling behavior, how version conflicts are resolved and whether startup blocks on a missing NAR |
| NAR providers pointed at an internal store | Many bundles or teams need a central, controlled source that nodes pull from | The internal store becomes a supply chain control point, so access, integrity checks and mirroring procedures must be documented | Which provider types your version supports, how nodes authenticate to the store and how the store is synced from approved media |
| Python processor dependencies | Flows use Python-based processors, which the administration guide describes as a beta feature | Wheels or packages are staged on internal media, pinned and scanned before entry | Supported Python versions (3.10, 3.11 or 3.12) and whether your packages build from local wheels only |
| Staying on 1.x for offline use | Usually a poor fit, because the 1.28 line is the last minor release of version 1 and its support ended December 8, 2024 | Ongoing exposure to unpatched Jetty, Spring and AngularJS components inside an isolated network | Whether a migration plan to 2.x, including the step through 1.27.0 and the flow.json.gz change, can be scheduled |
How to stage NiFi for an isolated network
This sequence moves a verified NiFi release, its Java runtime, any optional Python and custom NARs, and its certificates and time source across the boundary, then proves the node starts and runs without outbound connections. Each step ends with a check that the transferred artifacts or running system match what was approved.
Mirror and verify release artifacts on the transfer side
On the connected side, the platform team downloads the NiFi binary, its checksum and signature files from the official Apache download page, and verifies them against the published values and the project's signing keys before anything is copied. Record the version, file names and hashes in a transfer manifest that your change process can approve. The step is done when the hashes computed on the transfer host match the published values and the manifest is signed off by the person accountable for supply chain controls. This check supports the software integrity and authenticity expectations in NERC CIP-013-2 where that standard applies to you.
Stage Java 21 and the Python runtime
Mirror a Java 21 runtime from your approved vendor or internal repository, since NiFi's administration guide lists Java 21 as the minimum. If you plan to use the optional Python processors, also stage Python 3.10, 3.11 or 3.12, noting the guide describes that feature as beta. Install both on the isolated hosts from the transferred packages and confirm the versions with the
java -versionandpython3 --versioncommands. The step is done when every node reports a supported Java major version and a supported Python minor version, and the manifest records each package hash.Bundle the NARs your flows require
Build or select the NAR set your flows need before transfer, because the convenience binary may not contain every processor or service you use. Confirm each component against the NiFi component documentation for your version, and decide whether to extend the distribution with a custom assembly or to load custom NARs through the autoload directory after installation. Hash each NAR and add it to the manifest. The step is done when every flow in scope can be mapped to a NAR in the bundle and no flow depends on a component that would be downloaded at runtime.
Configure security before first start
Without a security configuration, NiFi binds to 127.0.0.1, so the UI is reachable only from the host itself. Decide the bind address, TLS material and authentication provider (single-user, LDAP, OpenID Connect, SAML 2.0 or X.509 client certificates) in your change record before first start, and set the values in the NiFi properties files. Do not expose the UI on a non-loopback address unless that choice is documented and approved. The step is done when the configuration review confirms the intended listener address, the authentication provider is set, and the Kerberos provider is not in use because the guide marks it deprecated.
Install certificates and the internal trust chain
Issue or import the server certificates from your internal certificate authority, along with the trust chain that clients and cluster peers need, and place the keystores and truststores in the locations your configuration references. Confirm that the certificate subject names match the host names your users and nodes use, and that the validity dates cover the planned go-live window. Include revocation information your environment expects, since isolated networks often cannot reach public revocation endpoints. The step is done when a local TLS handshake to the NiFi port succeeds and the certificate chain validates against the internal root.
Set the internal time source
Point every NiFi host and any Java or Python clock dependency at an internal time source, such as a controlled NTP server or a hardware reference that your network team operates. Accurate time matters for certificate validation, cluster coordination, provenance timestamps and log correlation. Confirm the source is reachable without internet access and record its configuration in the build manifest. The step is done when each host reports synchronized time against the internal source and the offset is within the tolerance your security team has set.
Test startup with no outbound connections
Block outbound traffic from the NiFi hosts at the firewall or host policy, leaving only the internal services the platform needs, then start NiFi and watch the bootstrap and application logs. Confirm that the UI loads over the intended interface, that the authentication provider accepts a test login, and that no processor attempts an external lookup during startup. Capture connection logs or firewall denials to show what was attempted. The step is done when NiFi reaches a running state with zero unexpected outbound attempts and the test evidence is stored with the release record.
Python processor dependencies and custom NARs offline
The optional Python-based processors run under a Python interpreter that NiFi starts alongside the JVM. The NiFi administration guide lists Python 3.10, 3.11 or 3.12 for these processors and describes the feature as beta, so test its dependency handling on your own build before relying on it. Each Python processor can bring package requirements, and on a connected network those packages are fetched during setup. On an isolated network nothing may be fetched at runtime, so every package and its transitive dependencies must be collected in advance.
- Fix the interpreter first. Choose one supported minor version and build the environment on the same operating system image as the production nodes.
- Collect the full dependency tree. Download packages for the exact target platform, including transitive dependencies, not only the names listed in processor documentation.
- Pin every version. Use exact version specifiers and keep a lock file in the offline bundle so the set can be rebuilt later.
- Record file hashes. Store a hash for each package so the isolated side can confirm that every file matches the list approved on the connected side.
- Verify each node. After installation, check that each node's interpreter imports every required package, because a single node with a different set will behave differently.
Confirm that the interpreter version, lock file and hash list all come from the same approved build before anything is staged.
NiFi extensions ship as NAR files. Custom processors, controller services and optional bundles that are not in the convenience binary must either be built into a custom distribution or added at runtime. A NAR that extends another bundle needs its parent NAR at a matching version, and any third-party Java libraries it uses belong in the offline set as well. Decide per NAR which delivery path it takes, because the paths carry different restart and change control effects.
- Inventory every NAR by source. Record each bundle's name, version, build source and the owner who approved it.
- Resolve parent bundles. Confirm whether each NAR extends another bundle, and bring that parent at the matching version.
- Match the runtime and release. Build against Java 21, the minimum runtime listed in the administration guide, and confirm each NAR targets the same NiFi release as the nodes.
- Choose the delivery path. A custom distribution fixes contents at build time, while the autoload directory lets you add NARs without a restart, which changes what the change board needs to review.
- Use an internal artifact store. Point the build and any NAR provider at an internal repository that holds only approved artifacts, so no node contacts a public source.
Check each NAR's parent bundle, Java version and target NiFi release against the approved inventory before it reaches a node.
Everything that crosses an isolated boundary needs evidence of where it came from and that it has not changed. NERC CIP-013-2, the supply chain risk management standard for the electric sector, asks registered entities to address verification of software integrity and authenticity in their procurement processes, including for patches. Organizations outside that sector often adopt the same discipline for any package carried across a boundary. Verification is the step that turns a downloaded folder into an approved bundle.
- Check signatures and checksums. Verify each NAR and Python package against the publisher's published checksum or signature before it is copied.
- Keep a provenance record. Log the download source, date, person and tool for each artifact so an auditor can trace it.
- Scan the bundle. Run malware and vulnerability scans on the connected side and keep the scan reports with the bundle.
- Reject anything unexplained. Remove packages that appear in the tree but not in the approved inventory, and do not add them to the bundle.
- Sign the final bundle. Apply your own signature or checksum to the complete transfer set, so the isolated side verifies one object rather than many.
Confirm who is accountable for approving each bundle and where the provenance records are stored before the first transfer.
Once the bundle is inside the isolated network, every NAR and Python package must be placed where NiFi and its interpreter can load it without contacting an external source. Any tool that resolves packages by name needs to point at a local source, either an internal mirror or a directory on the bundle media. Placement is also where configuration mistakes appear, such as a Python path that differs between nodes or a NAR copied to one node and missed on another.
- Point package tooling at local sources. Configure the package installer on each build host to use the internal mirror or the bundle directory only, and disable public index lookups.
- Match ownership and permissions. Give the NiFi service account read access to the extension directories and keep write access limited to the deployment process.
- Keep placement identical across nodes. Use the same paths, file names and versions on every node, and compare checksums across the cluster after the copy.
- Block outbound resolution in testing. Confirm the NiFi processes can start with outbound network access closed, so a missing file fails visibly during the test rather than in production.
- Document each path. Record where each NAR and package sits and which configuration key or directory points to it, so the next upgrade does not depend on memory.
Check that each node starts, loads every expected extension and reports no missing Python module before the change is closed.
The first attempt to resolve dependencies on the isolated network almost always reveals a gap, such as a missing transitive package, a platform-specific wheel or a parent NAR that was never collected. Those gaps are cheaper to close on a test cluster than during a production change window. A rehearsal also shows how long the steps take and which people need to be involved, which is information you should gather from your own runs rather than from estimates.
- Build a test cluster with the same base image. Match the operating system, Java runtime and Python minor version to production, and keep the test network isolated.
- Install from the bundle alone. Run the full installation using only the approved bundle and internal sources, and record every failure.
- Repeat from a clean state. Rebuild the environment from scratch at least once, so hidden leftovers from earlier attempts do not mask a gap.
- Test extension behavior. Start each custom processor and each Python processor, run a short sample flow, and confirm the expected output.
- Feed results back. Update the inventory, lock file and hash list with each fix, and approve only the final version for production.
Ask the team to show a clean rebuild from the final bundle, with egress blocked, before the production transfer is scheduled.
Security controls that matter on an isolated network
An isolated NiFi deployment keeps its security posture only if every artifact, identity, certificate and clock value entering the boundary is handled deliberately. The cards below cover the controls that tend to be decided late and then fail audit or operations reviews.
Verify every artifact at the boundary
Every NiFi binary, NAR, Python dependency and container image carried across the boundary should be checked for integrity and authenticity against the publisher's signatures and checksums before it is staged. Record who verified each item, when, and against which source. This is the control NERC CIP-013-2 describes for vendor software and patches in OT-relevant environments, and it is the step most often skipped when transfers are done by media. Confirm the verification method with your own security team and the project's published release artifacts.
Choose authentication before the first node starts
NiFi offers single-user, LDAP, OpenID Connect, SAML 2.0 and X.509 client certificate authentication, and the Kerberos provider is deprecated. On an isolated network, confirm that your chosen identity source is reachable inside the boundary, since OpenID Connect or SAML metadata endpoints hosted outside it will break logins. Single-user mode is suited to small, controlled setups, and it should not become the production default by accident.
Run an internal certificate authority
TLS for the NiFi UI, cluster node traffic and client certificates needs a certificate chain that the isolated network trusts without public roots. Decide who issues node and user certificates, how long they last, how revocation is handled, and how renewals are scheduled so a rotation does not disconnect a cluster. Keystores and truststores must be updated on every node, so plan the rotation as a change with a rollback path. Ask your PKI team which intermediate CA will sign NiFi certificates and whether it publishes revocation data inside the network.
Synchronize time from an internal source
Clustered NiFi nodes, certificate validation, provenance timestamps and audit logs all depend on consistent clocks. Without internet access, nodes cannot rely on public time servers, so point them at an internal NTP or PTP source that is itself disciplined from an approved reference. Clock drift can cause certificate validation failures and misordered provenance events that undermine investigations. Confirm the time source with your infrastructure team and monitor offset on every node.
Route patches through the same verified path
Security fixes for NiFi, its Java runtime, the operating system and optional Python packages must enter the isolated network through the same verification and approval workflow as the original install. Maintain a staging mirror of the artifacts you have verified, and record each patch against the version it changes. Treat the patch intake as a recurring change process, not a one-time event, and confirm with the project which releases are still supported before you plan an upgrade.
Limit the default network exposure
When no security configuration is provided, NiFi binds to 127.0.0.1, so the UI is reachable only through the loopback interface. Moving it to a network interface should be a deliberate, reviewed change tied to TLS and authentication, not a convenience edit. Document which ports open between nodes, to the identity provider, to the certificate authority and to the internal artifact store, and block everything else at the boundary.
How certificates and time sources affect NiFi on isolated networks
On a network without internet access, NiFi cannot rely on public certificate authorities or public time servers, so the internal certificate authority, the trust store contents, the renewal process and the clock sources all have to be designed before the first node starts. NiFi's secured mode depends on TLS for the web UI, node-to-node traffic and client authentication, and each of those depends on certificates that chain to a CA your nodes already trust. If the CA root or intermediate certificates are missing from the trust store used by NiFi, nodes and browsers fail in ways that look like login or cluster problems rather than certificate problems.
Certificate expiry is the failure mode to test first. Issue a short-lived test certificate in a lab, let it expire, and confirm which symptoms appear in the UI, in the cluster view and in the bootstrap and application logs. Then rehearse the renewal: replace the keystore and truststore on one node, restart it, and confirm it rejoins the cluster before touching the next node. Check the keystore and truststore settings in nifi.properties and the TLS guidance in the NiFi administration guide for your exact version, since property names and supported key formats are version-specific and should be confirmed before you write the renewal runbook.
Clock drift is the second failure mode to plan for. Without public NTP reachability, every node needs a time source your organization operates, such as an internal NTP service or a hypervisor-provided clock that you have verified, and you should confirm the offset between nodes under load. Drift between nodes can break TLS validation, which compares certificate validity windows against the local clock, and it can disturb cluster coordination, which the administration guide describes through ZooKeeper or Kubernetes state and leader election. Test this deliberately by skewing one node's clock in a non-production cluster and recording which behaviors change.
Limits to confirm in your environment
An isolated network removes the easy paths for updates, packages and services that NiFi takes for granted. The items below are the assumptions most often wrong at the start of an offline build, and each one should be verified against your own environment before the bill of materials is final.
Optional bundles in the binary
Confirm that every processor bundle your flows need ships in the convenience binary. Anything outside it requires a custom distribution built with the nifi-assembly module, which means Maven dependencies must be resolvable from your internal mirror. Missing bundles are often discovered only when a flow fails to import, so list every component by name against the NiFi component documentation before you request media approval.
Python processor beta status
The NiFi administration guide describes Python-based processors as a beta feature. Before you commit a flow to them, confirm that your Python 3.10, 3.11 or 3.12 interpreter and every pip dependency can be staged offline, and that your change board accepts a beta component in production. Plan a wheel repository and a tested dependency lock, because a processor that cannot import a library will fail at runtime.
Cluster coordination inside the enclave
Check where cluster state and leader election live. ZooKeeper, embedded or external, and Kubernetes ConfigMaps or Leases must all resolve and run inside the isolated network. A coordination service that reaches an outside address for updates or discovery will break node elections after an upgrade. Test node failover with the external network path fully disconnected, not only with the NiFi nodes themselves isolated.
Java 21 from an internal mirror
NiFi requires Java 21 as its minimum runtime. Confirm that your internal package mirror carries a Java 21 build with its security updates, and that the JDK is verified against the vendor checksum before it enters the enclave. Also check that the TLS trust store and the JVM cacerts file are managed the same way on every node, since drift between nodes shows up as intermittent handshake failures.
Registry dependence before NiFi 3.0
If your flow version control depends on NiFi Registry, plan for its deprecation. The NiFi downloads page notes that Registry is planned for removal in NiFi 3.0. Decide whether your offline Git service can host a supported Flow Registry Client, and confirm that the GitHub or GitLab client you choose can reach your internal Git host without external calls, so that version history does not depend on a component scheduled to leave the product.
Questions teams ask before running NiFi offline
What drives the effort and cost of running Apache NiFi offline?
The main drivers are the number of NARs you need beyond the convenience binary, the number of nodes in the cluster, how much verification each artifact needs before it crosses the boundary, and how formal your change control is. A single-node lab with a short list of bundles is a very different job from a clustered production system with custom processors, Python dependencies and an internal artifact store. Each added NAR adds build, test and verification work, and each added node adds configuration and validation work. Ask any provider for a written scope that lists every bundle, every node, the verification steps and the change approval path, so the quote reflects those items rather than a generic offline install.
Which parts of an offline NiFi project are one-time and which recur?
The initial build is one-time work: designing the custom distribution, staging the artifacts, configuring NAR providers, setting up certificates and time sources, and proving the system works without internet access. Recurring work begins with every upgrade, because each new NiFi release, NAR version and Python dependency must be downloaded on a connected network, checked for integrity and authenticity, carried across the boundary and tested again. Operational tasks such as rotating certificates, patching the base operating system and reviewing configuration drift also recur. Ask for the upgrade transfer and verification steps to be priced or scoped as a repeatable procedure, not as part of the first build.
How long does an offline NiFi deployment take?
Duration depends on the environment, the number of bundles, the number of nodes and how quickly your security and change-management teams review each transfer. Network isolation rules, approval queues and the availability of a staging network often matter more than the NiFi configuration itself. No general timeline is stated here, so treat any figure you hear with caution. Ask for a written scope that breaks the work into phases, names the dependencies you must clear, such as access to a staging network or certificate authority, and states the assumptions behind each phase. Timelines are confirmed in that written scope before work starts.
What must our team provide for an offline NiFi project?
Plan to provide the following before the build starts:
- Network access to a staging environment that mirrors the isolated network closely enough to test transfers and startup
- An internal certificate authority that can issue server and client certificates for NiFi nodes and users
- An identity provider, such as LDAP, OpenID Connect or SAML 2.0, for user login
- Internal time sources (NTP or equivalent) that every node and dependent system can reach
- An internal artifact store for Maven artifacts, Python packages and NiFi binaries, along with the approval process for moving files across the boundary
Confirm the exact list, owners and access levels in the written scope, since they vary with your architecture.
Can an internal team run an offline NiFi deployment without a partner?
Yes, an internal team can do this if it has engineers who know NiFi administration, Java runtime management, certificate handling, artifact supply chain controls and the isolated network's rules. The harder parts are usually building a custom distribution that stays maintainable across upgrades, verifying every package that crosses the boundary, and keeping the process repeatable for each release. Assess your team against those skills and against the upgrade cadence you expect. A partner can cover some or all of that work under a fixed scope, and ongoing support is available as a retainer if you prefer a lighter internal load.
Does DeployOpen issue certifications for offline NiFi environments?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. For a regulated environment, such as one subject to NERC CIP requirements, ask your auditor which evidence they expect for software integrity checks, remote access controls and change management, then agree on how the implementation will produce that evidence. The NERC standards referenced for this topic are a good starting point for that conversation.
Keeping NiFi current when the network stays closed
An air-gapped NiFi still needs upgrades, and the planning starts with the version line you run today. The NiFi project has ended maintenance for the 1.x series: NiFi 1.28 is the last minor release, and the downloads page lists December 8, 2024 as the end-of-support date for 1.28.1. The project explains that 1.x depends on Jetty 9.4, Spring Framework 5.3 and AngularJS 1.8, which cannot be upgraded within that line. If your isolated deployment is still on 1.x, the migration is the first project to schedule, not an optional refresh. The NiFi migration guidance requires moving to NiFi 1.27.0 before 2.0.0, so a 1.x estate that is far behind the current release needs that intermediate step built into its transfer plan.
Each NiFi release crosses the boundary as a new verified bundle, so the offline transfer process from earlier in this topic runs again for every version you adopt. Confirm the checksums and signatures against the values published with each release, then retest every custom and optional NAR against the new version before it reaches production. Expect the 2.x changes to affect configuration as well as code. The migration guidance changes the flow file from flow.xml.gz to flow.json.gz, and 2.0 replaced the variable registry expression language scope with an ENVIRONMENT scope. Any internal runbook that refers to those names needs updating. Plan the work with the Apache NiFi migration guidance open, and use the separate pages on Apache NiFi upgrades, custom distributions and configuration across environments to scope each step.
Operational risks of isolated NiFi and how to test for them
An isolated NiFi deployment fails in quiet ways: a processor is missing, a mirror drifts from the verified set, a certificate or clock goes wrong, or no one can rebuild the node without the internet. Each risk below pairs with a test or drill that exposes it before a production change or an expiry date makes it an outage.
Missing NAR found in production
A flow that validates in a test environment can reference a processor bundle that was never copied into the offline distribution. The gap appears only when a production change imports the flow or a node restarts. Test by importing every versioned process group into a clean node built from the offline set, then confirming each processor reports as valid with no missing bundles. Repeat this check whenever a flow adds a component.
Drift between mirror and verified set
Offline mirrors of NARs, Python packages and container images can quietly diverge from the set that was checked for integrity and authenticity. Two nodes or two sites may then run different builds of the same bundle. Test by comparing checksums of every artifact on each node and mirror against the approved manifest, and treat any mismatch as a failed release rather than a warning.
Certificate expiry goes unnoticed
Internal certificate authorities on isolated networks rarely send renewal reminders, and NiFi's TLS, cluster and client certificates each carry their own end dates. A certificate that expires on a quiet weekend can take a cluster offline. Build an inventory of every certificate with its expiry date and alert well before the earliest one. Rehearse a renewal on a test cluster, including trust store updates on every node.
Clock drift on isolated time sources
Without internet access, nodes often depend on an internal NTP server that may itself drift or fail silently. Clock skew breaks TLS validation, cluster heartbeats and provenance timestamps that auditors later read. Test by measuring offset on each node against the internal source, then deliberately stop the source during a drill and confirm that the alert fires and the cluster behaves as expected.
Rebuilding with no external source
Recovery from a corrupted node or a lost disk must not depend on a download from the internet. Confirm that the offline bundle contains the NiFi binary, every required NAR, the Java runtime and the Python dependencies. Test by rebuilding a single node from the bundle alone on an empty host, joining it to the cluster and checking that the flow loads from the repository copy. Record the time the rebuild takes so the recovery plan reflects real effort.
Python dependencies missing at runtime
Optional Python-based processors need Python 3.10, 3.11 or 3.12 along with their own packages, and these packages often pull further dependencies from a public index. A processor can start cleanly and then fail on its first run when a transitive package is absent. Test by running each Python processor in the isolated environment with representative input and checking that the packages resolve from internal sources only.
What a scoped air-gapped NiFi engagement covers
A scoped air-gapped NiFi engagement starts with a written scope that fixes what will be delivered before any work begins. The first deliverable is an inventory of every NAR the flows need, including the bundles that are absent from the convenience binary, and every Python dependency that the optional Python processors will load. Each item should be traced to a flow, a processor type and a version, and each should be marked as either bundled or to be supplied from an internal store. Ask the provider to confirm which NiFi release line the inventory targets, because the NAR set and the Python runtime requirements differ between 1.x and 2.x. Python processors are described as a beta feature in the administration guide, so the scope should say whether they are in or out.
The second part of the scope covers artifact verification and deployment. Every binary, NAR, Python wheel and container image carried across the boundary should have a recorded checksum and a signature check that the team can repeat, with the results kept as evidence. NERC CIP-013-2 is one example of a control that asks utilities to verify software integrity and authenticity for vendor software and patches, and similar expectations appear in other regulated sectors. The engagement should name who performs the transfer, who approves it, and where the manifests are stored. Deployment then runs inside the client's own data center or cloud accounts, using the client's certificate authority, time source and internal artifact stores. Confirm in writing which of these the provider will configure and which remain with your team.
Documentation and handover close the engagement, and they are where ongoing support is defined. Expect a runbook covering the offline update procedure, the artifact manifest, the NAR provider settings, certificate renewal steps and the steps to test a new bundle before it reaches production. Ask for a handover session in which your operators rebuild a distribution or deploy a NAR without the provider present. Ongoing support, upgrades and testing are available as a retainer, and that retainer is separate from the fixed-scope build. Ask for the retainer terms to be written out in the same document as the scope, so that you know who patches the offline repository, who reviews new NiFi releases and how quickly an isolated environment can receive a fix. Fees and durations should come from the written quote, not from assumptions about the work.
How DeployOpen scopes, delivers and supports offline NiFi
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including air-gapped networks. For Apache NiFi, that means agreeing in writing which flows, NARs, Python dependencies, certificates and time sources the offline installation must carry before any build work starts.
How we scope
- Inventory the flows, processors and NARs the offline NiFi must run, and separate them from optional bundles.
- Record the NiFi 2.x target version, Java 21 runtime and any Python processor requirements in the written scope.
- Agree how packages cross the isolation boundary, including who verifies checksums and signatures and who approves each transfer.
How we build
- Build a custom distribution with only the approved NARs and point NAR providers at your internal artifact store.
- Stage Python processor dependencies and internal certificate authorities, and test the install with no outbound network access.
- Confirm time synchronization and TLS trust chains on the isolated network, then test flows end to end before go-live.
How we hand over
- Deliver the build procedure, the package manifest and the verification steps as documentation your team can repeat.
- Walk your operators through the bundle update process for each new NiFi release and each approved NAR change.
- Hand over configuration records for nifi.properties, bootstrap.conf and the NAR provider settings, with the responsible owner named.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Retainer work can cover re-running the offline bundle process for new 2.x releases and reviewing new NARs before import.
- Ask us to confirm the support boundary, response arrangements and upgrade stops in the written agreement before work begins.
