Why a self-hosted Tines alternative for air-gapped networks needs its own plan
For a security team on a fully disconnected network, the main open-source option to evaluate is Shuffle, self-hosted and staged offline. Tines cannot be assumed to fit that boundary: its hosted service needs outbound connectivity by definition, and the self-hosted route depends on the host reaching the internet, so the disconnected site needs its own plan rather than a simple redeployment. Shuffle's install guide covers Docker and Kubernetes, and its architecture docs describe a single server with Docker Compose, Docker Swarm and Kubernetes with Helm charts. None of those paths is offline-ready by default, so each has to be proven inside your own boundary.
The constraint changes how software reaches the platform. Every container image for the Shuffle backend, frontend, OpenSearch, Orborus and the app containers must be pulled on a connected staging network, verified, transferred across the boundary and loaded into a private registry. The Shuffle apps you rely on are versioned Docker containers, so each app image needs the same treatment, and apps built in the App Creator from OpenAPI specifications need their base images carried across too. The Kubernetes side has a documented precedent: kubeadm can pull control plane images in advance and point at a private registry, which shows the pattern even though Shuffle's own images still need confirming with its documentation.
Treat the gaps as items to verify, not assumptions. Confirm which Shuffle release and Docker tags you will stage, since the docs recommend the latest tag for stable releases and nightly for experimental changes, and an offline site should avoid moving targets. Ask whether the platform performs any call-home, license or update check that fails silently without internet access. Confirm how you will connect to internal tools only, and whether your chosen identity provider with OpenID Connect is reachable from the enclave. Finally, confirm that the Orborus runtime can execute workflows entirely inside the boundary, because the hybrid architecture that avoids inbound ports depends on reaching Shuffle Cloud.
What an air-gapped boundary requires from a SOAR platform
An air-gapped network removes the easy paths: no pulling images on demand, no vendor cloud, no unchecked updates. The cards below cover the decisions that follow from that boundary, from how app images get built and verified to how credentials and the encryption secret are kept safe.
No runtime internet access
Shuffle's Docker Compose and Kubernetes deployments normally pull images and components from public registries. On a disconnected host, every dependency must already exist inside the boundary before go-live. Confirm with the Shuffle docs exactly which containers and images the chosen architecture starts, and check that none of them phone home during normal operation. Test the install on a host with its outbound route removed before you commit to a design.
Locally built and loaded app images
Shuffle apps run as versioned Docker containers, and apps can be generated from OpenAPI specifications in the App Creator. In an air-gapped site, those app images must be built from internal sources and loaded into the local registry or Docker host. Decide who owns the build pipeline, where specifications are stored, and how an app version is retired. Ask the vendor or community which app images depend on external base images.
Verified software carried across the boundary
Every package, image and rule set brought across an isolated boundary is a supply chain decision. NERC CIP-013-2 expects procurement processes that verify software integrity and authenticity for vendor software and patches, which is an illustrative benchmark for energy operators and a useful model for other regulated sectors. Record a checksum for each artifact, keep the source media in a controlled store, and document who approved each transfer.
Reaching only internal tools
A SOAR platform in a disconnected network should call only the internal ticketing, identity, endpoint and log systems it is meant to automate. Map each app to a named internal endpoint, restrict egress from the Orborus runtime to those addresses, and confirm that no app is configured with a public API base URL. Shuffle's hybrid architecture needs no inbound firewall ports, but any internal-only design still needs its own network policy review.
Protecting saved credentials and the encryption secret
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. Losing or changing that secret breaks every saved app authentication, which is hard to recover from on a site with no internet fallback. Store the value in an offline, access-controlled vault, keep a tested copy under dual control, and include it in your backup and restore runbook.
Which open-source options fit an offline SOAR deployment
This table compares Shuffle, StackStorm and n8n on the offline constraint, licensing and main trade-offs for a disconnected SOAR host. Read the offline row as a question to put to each vendor for the exact version you plan to install, since none of the supplied sources confirms a complete air-gapped install path for these three.
| Criterion | Shuffle | StackStorm | n8n |
|---|---|---|---|
| Licensing | Backend under AGPLv3, workflows, documentation, apps and app specifications under MIT | Apache 2.0 | Sustainable Use License; files marked .ee need an n8n Enterprise License, so it is source-available rather than OSI open source |
| Latest version noted here | Shuffle v2.3.0, published September 28, 2026 on GitHub | 3.9.0, dated January 12, 2025, supports Python 3.8 to 3.11 | Confirm the current release and its license terms in the repository before deciding |
| Offline install path | Docker and Kubernetes installs; confirm how images and dependencies are loaded without internet access | Confirm offline package and container image sourcing for your chosen release | Confirm whether self-hosted installs can run disconnected under your license use case |
| Local app images | Apps run as versioned Docker containers, so each image must be built or mirrored into the local registry | Packs are installed from its catalog, so confirm how packs are staged offline | Community nodes are installed from npm, so confirm how packages are staged offline |
| Reaching internal tools only | Apps can call internal APIs, and Orborus can run locally with no inbound firewall ports in the hybrid design | Event-driven rules can target internal systems; confirm network reach from its runners | Can call internal HTTP endpoints; confirm any default external calls in your version |
| Database and runtime | OpenSearch document database and Orborus workers; plan for an OpenSearch cluster | MongoDB and RabbitMQ are the usual dependencies; confirm for your version | Node.js application with an optional external database; confirm the setup your version requires |
| Main trade-off | Purpose-built for SOAR with cases and app creator; you own the full stack and its patching | Strong for scripted auto-remediation; less of a no-code editor for analysts | Broad general automation; security-specific apps and licensing terms need review |
How Shuffle's components behave without internet access
Shuffle's server side is made of a frontend, a Go backend API listening on port 5001, and an OpenSearch document database that stores workflows, executions and saved app credentials. The runtime side is handled by Orborus, which polls the backend for jobs, starts a worker for each workflow execution, and that worker starts the app containers the workflow calls. Every one of these pieces is a container you deploy yourself, so an air-gapped site can run the whole chain on internal hosts. What matters for a disconnected network is not the layout but the moments when a component reaches for something outside the boundary: an image pull, a package download, a license check or a call to a vendor endpoint. Map those moments before you schedule the install.
The hybrid architecture described in Shuffle's architecture docs, where a local Orborus connects to Shuffle Cloud and needs no inbound firewall ports, is a cloud link by design. It depends on outbound connectivity to the hosted service, so it does not apply to a fully disconnected site. For an isolated deployment, the relevant choices are a single server with Docker Compose, Docker Swarm, or Kubernetes with Helm charts, all run entirely on internal infrastructure. Pick one of these before you plan image transfer, because each has its own set of images to stage.
Confirm, in writing with Shuffle and by testing in a staging enclave, which pulls happen at install time and which happen at run time. At install, you need every container image for the backend, frontend, OpenSearch and Orborus, plus any base images they reference. At run time, check whether Orborus or the worker fetches app images that are not already present, and whether any app or integration calls a public endpoint, such as a vendor API that a workflow expects to reach. Also confirm how the app creator behaves when you import an OpenAPI specification with no network access. Any pull that surprises you in staging is a gap to close before cutover, not after.
How to build and load Shuffle images inside an air-gapped network
This sequence moves Shuffle release artifacts across the boundary, places them in an internal registry, builds app images from OpenAPI specifications, and leaves a server that runs workflows with egress limited to internal tools. Each step ends with a check you can confirm before the next one starts.
Choose and pin the Shuffle release outside the boundary
On a connected staging host, the platform team selects the Shuffle release and Docker tag to deploy. The Shuffle docs recommend the latest Docker tag for stable releases and the nightly tag for experimental changes, so most teams should pin a specific stable version rather than track nightly. Record the tag, the image digests and the matching Docker Compose or Helm files in a change ticket. Done means the tag is written down and every image it needs is listed, including the OpenSearch image, the frontend, the backend, Orborus and the app images you intend to use.
Scan and verify artifacts before transfer
The security team pulls the pinned images on the staging host, checks their digests against the values recorded in step one, and runs a vulnerability and malware scan on each image. Verifying software integrity and authenticity before a package crosses an isolated boundary is the control NERC CIP-013-2 describes for vendor software, so keep the scan reports with the transfer record. Done means every image has a passing scan result, a matching digest and a signed transfer manifest approved by someone outside the build team.
Transfer images into the internal registry
Operators export the verified images to an approved transfer medium, carry them across the boundary under the site's media-handling procedure, and push them into an internal registry. Kubernetes clusters built without internet access follow the same pattern: kubeadm can list and pull control plane images in advance, and its --image-repository flag points kubeadm init at a private registry, as an illustrative model for how Shuffle images should reach the cluster. Done means each image pulls from the internal registry on a node with no outbound route to the internet.
Configure Compose or Kubernetes against the internal registry
Platform engineers edit the deployment files so every image reference points to the internal registry and the pinned tags, then confirm the host meets the Shuffle install guide's minimum of 4 GB of RAM before first start. Single-server Docker Compose is the simplest path, but the install guide notes its default setup is not scalable without changes, so plan the Swarm or Kubernetes layout early if high availability is required. Done means the stack starts from local images only and the logs show no attempt to pull from a public registry.
Build app images locally from OpenAPI specifications
Integration engineers use the App Creator to generate Shuffle apps from the OpenAPI specifications of internal tools, then build the resulting app containers on a build host inside the boundary and push them to the internal registry. Apps are versioned Docker containers, so each build should carry a version tag that the workflows reference. Python apps written with the Shuffle app SDK follow the same path. Done means each internal app image runs on the Shuffle host, and a test action returns a response from the internal tool it targets.
Restrict egress to internal tools only
Network engineers create firewall rules that allow the Shuffle backend, frontend and Orborus workers to reach only the internal endpoints the workflows need, such as the SIEM, ticketing system and identity provider. Orborus runs workflow executions and starts app containers, so review both the server and runtime segments. Hybrid architectures that depend on Shuffle Cloud do not fit a fully disconnected site, so confirm the chosen architecture needs no external callbacks. Done means a connection test from each Shuffle container to a public address fails, and the same test to each approved internal tool succeeds.
Set the encryption secret and back up before go-live
The administrator sets SHUFFLE_ENCRYPTION_MODIFIER in the environment file and stores it in the site's secrets vault before the first workflow saves an app credential. Shuffle encrypts saved credentials and API keys in OpenSearch with AES-256 using this value, and losing or changing it breaks every saved app authentication. Schedule backups of the OpenSearch data, the files directory and the encryption secret, stored separately, and test one restore on a second host. Done means a restore reproduces a working saved credential and a workflow run.
Which supporting tools need offline installers too
If you run Shuffle on Kubernetes with Helm charts, the cluster itself must be buildable without internet access before Shuffle goes on top. The upstream kubeadm workflow handles this in two steps: you list the control plane images the cluster needs, pull them on a machine that can reach a source, and then point the initialization at a private registry inside the enclave. The rest of the cluster, including the network plugin, DNS and any ingress controller, needs the same treatment, so plan the image inventory as a whole rather than as one list.
- Control plane images: Run
kubeadm config images liston a connected staging host, thenkubeadm config images pull, and push the results to your internal registry. - Registry flag: Use the
--image-repositoryoption onkubeadm initso the control plane pulls from your registry, not a public one. - Add-on images: The network plugin, metrics components and ingress images are outside kubeadm's list and must be mirrored separately.
- Chart dependencies: Helm charts reference images and sub-charts, so render the chart offline and collect every image it names.
- Node packages: Container runtime and OS packages for each node also need an offline repository.
Confirm with your platform team which registry, mirror and update process they will use, and whether your cluster build already has an approved offline procedure.
Shuffle uses OpenSearch as its document database, and Elasticsearch also works according to the install guide. Because it stores workflows, execution records and encrypted app credentials, OpenSearch is the component most likely to hold sensitive data inside the enclave. Its images and plugins must come from your internal registry or mirror, and its configuration must be treated as part of the security baseline rather than an afterthought.
- Image source: Mirror the OpenSearch image and any plugin packages your build uses into the internal registry, pinned to tags you have tested.
- Cluster sizing: Shuffle's high availability guidance recommends an OpenSearch cluster, so plan for more than one node if you need failover.
- Storage and backup: Persistent volumes, snapshot locations and restore procedures must work with no external object store.
- Credential key: The
SHUFFLE_ENCRYPTION_MODIFIERsecret protects saved app credentials in OpenSearch, so back it up with the database, because losing or changing it breaks saved authentications. - Upgrades: Each OpenSearch version bump requires a new offline image set and a tested upgrade path.
Ask the vendor or your architect which OpenSearch version and plugin set your Shuffle release supports before building the offline bundle.
The value of Shuffle in a disconnected site comes from the internal systems its workflows call: a SIEM, a ticketing system, an endpoint platform or a vulnerability scanner. Each of these becomes a Shuffle app or an OpenAPI-based integration, and each app runs as a versioned Docker container. Those containers must be built or loaded inside the enclave, and the APIs they reach must be reachable only on internal routes. Shuffle's own offline behavior does not change what the target tool needs to run without internet access.
- App containers: Build each app image locally from its specification or Python source, then load it into the internal registry.
- Internal endpoints only: Restrict each app's network path to named internal hosts, and confirm the Orborus runtime can reach them without outbound internet.
- Vendor offline rights: Many tools gate air-gapped deployment behind paid editions, so confirm the license permits offline use before you depend on it.
- Published offline guidance: GitLab, Security Onion and Wazuh each publish offline or air-gapped installation guidance, which you can use when those tools are part of the workflow.
- Update channel: Decide how new app versions and vendor patches are reviewed and carried across the boundary.
For each target tool in your workflows, confirm offline rights and the update method in writing with the vendor before scheduling the build.
Evidence to keep for an air-gapped SOAR deployment
A reviewer assessing an isolated Shuffle deployment will ask how every image and package got inside the boundary, how it is configured and whether it can be recovered. The cards below list the records DeployOpen prepares as readiness evidence, so your own auditor or assessor can test them. They are inputs to an assessment, not an audit result.
Image and package inventory
A numbered list of every container image, Helm chart, app package and Python dependency carried across the boundary, with its source, version tag and SHA-256 hash recorded at the point of download. Each app image should also map to the Shuffle app it supports. Check that the inventory matches what the internal registry actually holds, since drift between the two is the most common gap found at review.
Transfer log
A record of each media import: who approved it, what was on the media, the scan results and the hash verification performed on the far side. Keep the log append-only and tie each entry to an item in the inventory. Ask your security team how a rejected package is recorded, because that case is often missing from transfer logs.
Internal registry configuration
The settings for the private registry that serves Shuffle images to the orchestrator, including access control, image signing or digest pinning and retention rules. Shuffle runs app containers through Orborus, so the registry must answer every image reference a workflow can trigger. Document which tags are allowed and who can push to the registry.
Shuffle version and tag in use
The exact Shuffle release and Docker tag deployed in each environment, recorded alongside the nightly or stable choice and the date it was imported. Shuffle recommends the latest Docker tag for stable releases and the nightly tag only for experimental changes, so an air-gapped site should state which it runs and why. Keep this record in step with the inventory.
Access and SSO configuration
Exports of the authentication settings, including SAML or OpenID Connect configuration, per-tenant SSO enforcement and role assignments. Confirm that the identity provider used inside the network is reachable from the Shuffle backend and that local accounts are limited to break-glass use. Reviewers usually ask who can change these settings and how changes are logged.
Backup and restore tests
Records of backups of the OpenSearch database and the encryption secret, plus dated restore tests into a separate environment. The SHUFFLE_ENCRYPTION_MODIFIER value must be stored in a separate, protected location, because losing or changing it breaks every saved app authentication. A backup that has never been restored is not evidence of recovery, so log each test and its result.
Questions buyers ask about offline Shuffle deployments
Does Shuffle run fully offline on an air-gapped network?
Shuffle can run on a host with no internet route, but only after everything it needs has been moved across the boundary first. The platform is installable through Docker or Kubernetes, and its architecture separates the backend, the OpenSearch document store and Orborus, which starts a worker and app containers for each workflow execution. Those app containers must already exist in a local registry, and any app that calls an external service will fail unless that service is reachable from inside the enclave. Confirm the image list and the internal endpoints with your team before assuming the install will work offline.
What drives the effort and cost of an offline Shuffle deployment?
The main cost components are staging, scanning, app building, high availability and testing. Staging means building an image inventory, pulling it on a connected side and carrying it across a controlled transfer path. Scanning covers checking every package and image for integrity and vulnerabilities before it enters the boundary. App building means creating integrations from OpenAPI specifications or writing Python apps with the Shuffle SDK, then packaging them as local containers. High availability adds OpenSearch cluster nodes, shared files and more than one Orborus node. Ask for each component to be priced separately in a written quote, and note which parts recur, such as the update cycle that repeats each release.
How long does an air-gapped Shuffle deployment take?
No duration has been established for this work, so the honest answer depends on your written scope. The schedule depends on how many apps you need, how many environments you run, how strict your transfer and scanning process is, and how many workflows must be rebuilt and tested. Ask for a timeline tied to named deliverables, with a clear list of what your team must provide and when. Be wary of any timeline quoted before the inventory of apps, workflows and internal endpoints is complete.
What does the work need from our team?
Your team needs to provide people who know the enclave, the transfer process and the internal tools Shuffle must reach. That includes a network owner who can confirm which internal endpoints are reachable, a security reviewer who approves the package and image intake, and a person who owns the workflows and their credentials. The SHUFFLE_ENCRYPTION_MODIFIER secret must be stored and backed up securely, because changing or losing it breaks every saved app authentication. Plan time for these owners to review each workflow during testing, since they know which actions are safe to run in production.
Can our own engineers deploy and run offline Shuffle without an outside partner?
A capable platform team can do this internally, provided it has the skills for air-gapped container registries, image scanning, OpenSearch administration and building apps from OpenAPI specifications. The harder part is ongoing maintenance: each Shuffle release needs a new image set, a new scan and a new transfer, and the team must keep running the platform after the first install. Ask yourself whether the team can absorb those recurring tasks alongside its current workload. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, including air-gapped networks, under a fixed-scope written agreement, and ongoing upgrades and testing are available as retainers.
Does Tines have a comparable offline option?
Confirm this directly with Tines before you assume it. Tines' pricing FAQ says flexible hosting options are available on request, and its paid editions include flexible deployment options, but the pricing page does not state that an air-gapped path exists for every edition. Ask Tines in writing whether it offers a self-hosted deployment that runs without internet access on the host, what it requires for updates and licensing, and who supports the environment. Compare the answer with the Shuffle effort described above so the decision rests on a documented capability.
What should we ask for in a written scope?
Ask for a scope that lists the Shuffle architecture to be deployed, the full image and app inventory, the internal tools each workflow reaches, the transfer and scanning method, the high availability design, and the testing and handover steps. The quote should separate one-time work, such as the initial build and workflow rebuild, from recurring work, such as upgrades and retainer support. Request a list of the client responsibilities and the assumptions behind each estimate, so you can see which costs rise if the app count or environment count grows.
How DeployOpen deploys Shuffle under an air-gapped constraint
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For a Tines replacement on a disconnected site, we start by fixing what the Shuffle host can reach, then build every image, app and dependency inside that boundary before anything is loaded.
How we scope
- Inventory which internal tools, log sources and ticketing systems the workflows must reach, and nothing beyond them
- Confirm the offline image transfer path, the approved media and who signs off each package crossing the boundary
- Agree in writing which Shuffle architecture fits the site, and whether a local Orborus is needed for execution
How we build
- Build and stage Shuffle images and app containers in an internal registry, then verify them before loading
- Generate app definitions from OpenAPI specifications for each internal tool, reviewed and version-pinned in the change record
- Set and back up the SHUFFLE_ENCRYPTION_MODIFIER secret, since losing it breaks every saved app authentication
How we hand over
- Deliver runbooks for offline upgrades, image transfer, backup and restore of the OpenSearch data
- Document network flows showing that only the internal tools listed in scope are reachable from the platform
- Provide evidence packs that support your compliance readiness work, though independent auditors issue any attestation
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous security testing are available as a retainer
- Security testing of the Shuffle deployment and its app integrations can be scoped as a separate written engagement
