Self-hosted Cortex XSOAR alternative for air-gapped networks

Why air-gapped SOAR needs an alternative to Cortex XSOAR 6 on premises

If your disconnected network runs Cortex XSOAR 6 on premises, the 6.12 and 6.13 releases reach end of life on June 30, 2026, and Palo Alto Networks recommends 6.14 for on-premises and air-gapped sites. That puts a dated decision in front of you. Self-hosted Shuffle can meet an air-gapped requirement if its container images, apps and updates are carried across the boundary through a controlled transfer process. Confirm the current offline install steps in the Shuffle install guide and in your own test environment before you commit to a platform.

Cortex XSOAR 8 is offered as SaaS or on premises, and the on-premises version installs through a step-by-step terminal installer. A SaaS-only design is ruled out for a disconnected site, so the question is whether the on-premises build can be installed from media you control and whether its licensing and update process works without outbound access. Confirm both with Palo Alto Networks before planning. For Shuffle, list every component you must mirror: the frontend, the Go backend, the OpenSearch database, Orborus for job execution, and the app containers that workers start for each action. Each one becomes an item in your transfer inventory, and a missing item will stop workflows at runtime.

Treat every item crossing the boundary as a supply chain event. NERC CIP-013-2 requires utilities to address verification of software integrity and authenticity in their vendor procurement processes, and that same discipline fits any operator moving containers into an isolated network. Shuffle's backend is AGPL-3.0 and its workflows and apps are MIT, so the source you carry in is open to review. Build a repeatable path: obtain the artifacts, verify them, scan them, record what was loaded and by whom, then import them. Keep 6.14 running until the Shuffle workflows match the playbooks they replace.

What an air-gapped SOAR deployment must satisfy

A SOAR platform on a disconnected network has to run without outbound calls, install from media you have verified, and keep vendor access under control. The four requirements below connect the runtime, installation, supply chain and remote access decisions that a Shuffle deployment must answer before any playbook is moved across.

No outbound calls at runtime

Confirm that every component can run with no route to the internet: the Shuffle frontend, backend, OpenSearch and Orborus, plus each app container. Apps that call a vendor cloud API will fail or stall on a disconnected segment unless the target product is reachable inside the enclave. Test each playbook from a host with DNS and egress blocked, and record which integrations need an internal endpoint. Ask whether any feature phones home for licensing or updates, and block it at the boundary to see what breaks.

Offline installation of images and clusters

Every container image and Kubernetes control plane image has to be pulled on a connected staging system, scanned, and loaded into a private registry before installation. For Kubernetes, the kubeadm tooling can list and pull control plane images in advance and point the cluster at an internal registry. Shuffle's Helm charts and the OpenSearch images need the same treatment. Keep a manifest of image digests so the installed set can be checked against what was approved.

Verified transfer of apps and updates

Apps, container images and platform releases cross the boundary on removable media or a data diode, so each transfer needs a documented integrity check. Record who approved the item, the source, the hash and the version, and verify the signature or checksum on the inside. NERC CIP-013-2 is one example of a standard that expects supply chain processes to verify software integrity and authenticity for vendor software and patches, if your site is in scope. Apply the same discipline to Shuffle apps you build from OpenAPI specifications.

Encrypted, multi-factor vendor access

Vendor support sessions into a disconnected enclave are a common exposure point. For sites in scope of NERC CIP-005-7, remote access to high and medium impact BES Cyber Systems must pass through an Intermediate System with encryption and multi-factor authentication, and the site needs ways to detect and disable active vendor sessions. Outside that scope, the same pattern is still a sound baseline. Confirm which accounts can reach the Shuffle admin console, how SSO is wired, and who can revoke a session in minutes.

Keys and secrets stored offline

Shuffle encrypts saved app credentials and API keys in OpenSearch using the SHUFFLE_ENCRYPTION_MODIFIER secret. Losing or changing that value breaks every saved app authentication, and an air-gapped site cannot easily fetch a replacement from a vendor. Store the secret in a sealed, offline backup, document the rotation procedure, and rehearse a restore on a separate system. Confirm the backup covers OpenSearch snapshots together with the key.

Which open-source platforms fit an air-gapped SOAR role

Shuffle's install guide lists Docker and Kubernetes as installation paths. Docker Compose is the simplest way to place a Shuffle server inside a disconnected enclave, but the guide states that the default Compose setup is not a scalable build without changes and needs a minimum of 4 GB of RAM. The main planning task is image transfer: every container the stack needs, including OpenSearch and the app containers, must be pulled on a connected staging host, verified and moved across approved media before the network is cut off. Confirm the full image list with Shuffle before you build the transfer bundle.

Single server: One host can run the frontend, backend, OpenSearch and Orborus for a lab, a small team or one site. Size it above the stated minimum if workflows run often.
Docker Swarm: The distributed architecture spreads the stack across several servers. Plan shared storage and the number of Orborus nodes before you deploy.
Pinned image tags: Shuffle recommends the latest Docker tag for stable releases and the nightly tag for experiments. In a disconnected site, pin a tested tag and mirror that exact version.
Encryption secret: Store the SHUFFLE_ENCRYPTION_MODIFIER value in a separate, controlled vault. Losing or changing it breaks every saved app authentication.
Missing case management: Shuffle has no built-in case management or analyst war room, so incident records need a separate system inside the enclave.

Before you build the offline bundle, check the Compose or Swarm files against the install guide for the release you plan to run.

How Shuffle runs without internet access

Shuffle can run on an isolated network, but only if every component it needs is staged inside the boundary before cut-over. The server side has a frontend, a Go backend API listening on port 5001, and an OpenSearch document database that holds workflows, app credentials and execution records. The runtime side is Orborus, which polls the backend for jobs, starts a worker for each workflow execution, and that worker starts the app containers. Each of these pieces pulls images or packages at install time or at run time, so the offline plan should list them one by one: the Shuffle backend, frontend and Orborus images, the OpenSearch image, Memcached if you use it for a shared cache, and every app image your playbooks call. Confirm the exact image tags against the Shuffle install guide and the release notes for the version you choose, and mirror them into your private registry.

The hybrid model deserves a clear decision before you design the network. Shuffle documents a setup where a local Orborus connects to Shuffle Cloud and needs no inbound firewall ports, which suits a site that can reach out but not be reached. That design still depends on connectivity to a cloud backend, so it does not fit a fully disconnected site. For air-gapped work, the server and Orborus must both run locally, typically as a single server with Docker Compose or as a Kubernetes deployment with Helm charts. Plan the Compose route with care: the install guide states the default Docker Compose setup is not a scalable build without changes and needs a minimum of 4 GB of RAM. Treat 4 GB as the floor for a lab, then size OpenSearch, the workers and your app containers separately and confirm the numbers with Shuffle before production.

Deploying Shuffle on Docker or Kubernetes with no internet access

This sequence moves Shuffle and its dependencies into a disconnected network through an offline artifact bundle, a private image registry and a local Orborus runtime, so workflows and apps run without outbound connections.

Build the offline artifact bundle
On a connected staging network, the platform team pulls the Shuffle images, the OpenSearch image and any Memcached or NFS components the design needs, along with the Helm chart or Compose files for the chosen architecture. For Kubernetes, the team also runs kubeadm config images list and kubeadm config images pull to fetch the control plane images in advance. Every image is saved to an archive with its digest recorded, and the bundle is transferred across the boundary under your own change control. The step is done when each image in the manifest has a matching archive and checksum that the receiving team can verify.
Stand up a private image registry
Load the archives into an internal registry that only the isolated cluster or Docker hosts can reach. Confirm that the registry serves every tag the manifest lists, including the Shuffle tag you intend to run. Shuffle's docs recommend the latest Docker tag for stable releases and the nightly tag for experimental changes, so decide which channel your environment permits and pin that exact tag rather than relying on floating references. The step is done when a test pull from an isolated host succeeds for every image without reaching a public registry.
Initialize Kubernetes against the private registry
For a Kubernetes deployment, run kubeadm init with the --image-repository flag pointing at the internal registry so control plane components resolve locally. The cluster network add-on, storage class and Helm must also be sourced from the bundle. Record the registry path in the cluster build notes so later node joins use the same location. The step is done when the control plane reports ready and kubectl get pods in kube-system shows no image pull errors. Docker Compose sites skip this step and use the registry path in the Compose file instead.
Install Shuffle with Helm or Compose
Deploy the frontend, the Go backend API on port 5001 and the OpenSearch cluster from the local registry. Shuffle's install guide notes that the default Docker Compose setup is not scalable without changes and needs at least 4 GB of RAM, so size hosts accordingly. For high availability, the configuration docs recommend an OpenSearch cluster, NFS for shared files when running several backends and the backend and frontend scaled across servers. Confirm that the backend starts, the UI loads from inside the network and OpenSearch reports a healthy status. The step is done when a test user can sign in and the health checks pass without outbound traffic.
Configure Orborus for the local runtime
Orborus polls the backend for jobs and starts a worker for each workflow execution, and the worker starts app containers. Deploy at least two Orborus nodes so workflows keep running if one fails, and point them at the internal backend and registry. The Shuffle architecture docs describe a hybrid model with a local Orborus that needs no inbound firewall ports, but a fully isolated site runs the backend locally, so confirm that the Orborus image and every app image resolve from the internal registry. The step is done when a test workflow executes on each Orborus node and the worker containers pull only local images.
Load apps offline from specifications
Export the OpenAPI specification for each tool the playbooks need, then build the app in the App Creator or write it with the Python app SDK. Shuffle apps run as versioned Docker containers, so the security engineer builds each image, tags it with a version and pushes it to the internal registry. Keep the specification files and source code in your own version control so a rebuild does not depend on any external download. The step is done when each app appears in the Shuffle UI and a test action completes against a sandboxed copy of the target tool.
Protect the encryption modifier and credentials
Set SHUFFLE_ENCRYPTION_MODIFIER before the first saved credential is created. Shuffle encrypts app credentials and API keys in OpenSearch with AES-256 using this secret, and the configuration docs warn that losing or changing it breaks every saved app authentication. Store the value in your existing secrets manager, restrict read access to the platform team, and document the recovery procedure in your change records. Back up OpenSearch snapshots and the secret separately so neither alone can restore the environment. The step is done when a restore test on a second cluster recovers an app authentication, proving the secret and the data are both recoverable.
Record the bundle for future upgrades
Keep a signed manifest of every image digest, app version and Helm value used at go-live. Each upgrade repeats the staging build, the registry load and the verification steps, so the same evidence is produced each time. This record also supports supply chain expectations such as verifying the integrity of software carried across an isolated boundary, which NERC CIP-013-2 addresses for in-scope utilities. Confirm with your assessor which evidence they expect. The step is done when an upgrade rehearsal in a test enclave reproduces the same running versions from the manifest alone.

What do buyers ask before running Shuffle in an air-gapped network?

Can our team run Shuffle in an air-gapped network without outside help?

Yes, a team with container and Kubernetes skills can do it in-house, but the work is more than installing the software. Shuffle installs on Docker or Kubernetes, and its install guide states that the default Docker Compose setup is not scalable without changes and needs at least 4 GB of RAM. An offline install also means mirroring container images, loading the app containers and maintaining the OpenSearch database. Ask whether your staff have run multi-node container platforms in a disconnected environment and who will own the build after handover. A team that has done this before will find the in-house route realistic, while a team without that experience should weigh the cost of learning on a live response platform.

What makes the effort for a Shuffle air-gapped migration go up or down?

Effort rises with the number of playbooks to rebuild, the integrations that need new apps, and the high availability design you choose. The main drivers are:

Playbooks and workflows exported from XSOAR that must be re-created and tested in Shuffle
Integrations with no premade Shuffle app, which need an app built from an OpenAPI specification or written with the Shuffle app SDK
Kubernetes skills for Helm-based deployments
High availability: an OpenSearch cluster, optional Memcached for a shared cache, NFS for shared files across several backends, and more than one Orborus node

Each item adds design, build and test work. Ask the vendor or partner to list the count of each category before accepting any timing.

Which Shuffle tasks are one-time and which recur in an offline environment?

Building the environment, loading images, configuring SSO and rebuilding workflows are one-time tasks. Recurring work is what keeps an offline platform safe and current. Expect recurring effort in four areas:

Image refresh: new container images have to be pulled on a connected system, checked and carried across the boundary
App updates: each app is a versioned Docker container, so new versions need the same transfer and testing
OpenSearch maintenance: upgrades, backups and capacity checks on the database that holds cases and saved credentials
Key management: the SHUFFLE_ENCRYPTION_MODIFIER secret must be protected, since changing or losing it breaks every saved app authentication

The Shuffle docs recommend the latest Docker tag for stable releases and the nightly tag for experimental changes, so decide which channel your offline site will follow.

What should a DeployOpen quote for an air-gapped Shuffle build include?

A quote should follow a written scope that lists each deliverable and the environment it targets. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside the client's own network, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ask the quote to state:

The deployment architecture: single server, Docker Swarm, or Kubernetes with Helm
How container images, apps and OpenSearch data cross the air gap, and how each transfer is checked
The number of playbooks and integrations in scope, and which need app development
Backup, restore and encryption key handling
Handover documentation and training for your staff
Whether ongoing support, upgrades or continuous testing are a separate retainer

DeployOpen does not publish a price list, so the quote is the only route to a figure.

Does an air-gapped Shuffle deployment need a paid Shuffle edition?

Shuffle says all features are available in the open-source edition, and its paid tiers differ in feature limits, scaling and support. Its pricing article states that licensing is based on app runs, meaning actions that actually execute in a workflow, while users, apps and workflows are unlimited. Since v2.1.1, the limits between the open-source and enterprise editions are actively enforced. Confirm with Shuffle which limits apply to your planned run volume and scale, and whether an air-gapped site needs any license activity. Note that the hosted service at shuffler.io is not an option for a disconnected network, so the self-hosted edition is the route to check.

How long does an air-gapped Shuffle migration take?

The supplied facts give no duration for this migration, so timing has to come from the written scope. The main drivers are the number of playbooks to rebuild, the number of integrations that need new apps, the chosen architecture and how many environments (test and production) must be built. A single-server build with a few playbooks differs greatly from a Kubernetes HA design with many custom apps. Ask for a schedule that lists each phase, its entry and exit checks, and the points where your staff must sign off. Running the old XSOAR 6 and Shuffle side by side for each use case is a common way to keep response working during the cutover.

Which Shuffle HA components need the most planning for an isolated network?

The components that need the most planning are the OpenSearch cluster, shared files and the Orborus nodes. The Shuffle configuration docs recommend an OpenSearch cluster for high availability, optional Memcached for a shared cache, and NFS for shared files when several backends run. The docs also recommend scaling the backend and frontend across all servers and running more than one Orborus node, so workflows keep running if one node fails. Each of these adds storage, network and failover testing that must work without internet access. Plan the storage sizing, the NFS permissions and the failover tests before the build starts, and confirm the design with the Shuffle documentation for the version you deploy.

Does Shuffle's SSO work on-premises for an isolated site?

Yes, Shuffle's extensions documentation says SAML single sign-on was added in version 0.9.16 and OpenID Connect in 1.0.0, both available on-premises and in the cloud, with per-tenant SSO enforcement. The docs also note that SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect. For an air-gapped site, confirm that your identity provider is reachable inside the isolated network, that the certificates and metadata are loaded offline, and that the chosen protocol matches your identity platform's supported options. Test login, role mapping and enforcement before cutover.

Evidence assessors and regulators ask for

An assessor reviewing an isolated Shuffle deployment wants to see how software got inside the boundary, who approved it, and how access is controlled. The four items below are the records that answer those questions, and DeployOpen prepares them as part of the engagement. DeployOpen does not issue audit reports or certifications; independent auditors and certification bodies make those determinations.

Offline installation runbook

The runbook is the step-by-step record of how the platform was built without internet access: which Docker or Kubernetes images were pulled on the connected side, how they were moved across the boundary, and the exact commands used inside the enclosed network. Shuffle's install guide covers Docker and Kubernetes installation, and the Kubernetes offline steps (pulling control plane images in advance and pointing kubeadm at a private registry) belong in the same document. Ask the reviewer which format they expect, and keep the runbook under change control so it matches the running system.

Image and app inventory with hashes

Every container image and Shuffle app that crosses the boundary should appear in an inventory with its name, version tag, source, and a cryptographic hash recorded before transfer and checked after arrival. Apps built with the App Creator or the Python SDK run as versioned Docker containers, so each app version is a distinct artifact to record. This record supports the integrity and authenticity checks that NERC CIP-013-2 expects for software and patches carried across an isolated boundary. Confirm with your assessor whether they want hashes, signatures or both.

Approval trail for each transfer

Each transfer needs a named requester, a technical reviewer who checked the inventory, an approver with authority over the enclave, and dates for each step. The trail should show who was approved to bring in which artifact, and that rejected or deferred items were not loaded. Keep the approvals in the same system as the change tickets so an assessor can trace a running app back to its approval. Agree the approval roles and retention period with your compliance lead before the first transfer.

Access and SSO configuration

Access evidence shows who can sign in, which roles they hold, and how sign-in is enforced. Shuffle added SAML single sign-on in version 0.9.16 and OpenID Connect in 1.0.0, both available on-premises, with per-tenant SSO enforcement. SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect, so an on-premises build should document which protocol it uses and why. Record the identity provider configuration, the enforcement settings, and a list of local accounts that remain, and confirm the protocol choice with your identity team.

What changes for playbooks when you leave XSOAR 6

Start by exporting everything you have before you plan any rebuild. The Cortex XSOAR 8 documentation describes exporting all custom content from Settings, then Server Settings, then Custom content, then Export all custom content, and downloading individual playbooks from the content item menu. Run the same export against your XSOAR 6.14 instance, since the 8.x menu paths are documented for XSOAR 8 and you should confirm they match your installed version before relying on them. Store the export in your air-gapped enclave with checksums and a record of which instance it came from, because the exports become the inventory you rebuild from in Shuffle.

Treat the export as a starting point, not a working copy. Playbooks, integrations and scripts that depend on XSOAR's runtime, such as JavaScript integrations and logic tied to XSOAR's own engine, do not move into Shuffle automatically. Each playbook needs to be mapped step by step to a Shuffle workflow, and each integration needs a Shuffle app, either built from an OpenAPI specification in the App Creator or written with the Shuffle app SDK. Ask the team who owns each integration's credentials, because saved app credentials in Shuffle are encrypted with the SHUFFLE_ENCRYPTION_MODIFIER secret, and that secret must be backed up and kept unchanged after go-live.

Plan for case management as a separate decision. Shuffle automates response, but it does not provide XSOAR-style incident layouts, a war room or analyst case records, so any incident fields, SLAs and analyst notes held in XSOAR need a new home. Choose between pairing Shuffle with a case system you already run in the enclave or using a tool that ships its own cases, and confirm that choice before you retire XSOAR 6. Run both platforms side by side on one use case at a time so analysts can compare outcomes before the XSOAR instance is switched off.

Which other alternatives suit disconnected sites?

Is StackStorm a good fit for an air-gapped SOAR deployment?

StackStorm can fit disconnected sites when your work is mostly event-driven remediation rather than analyst case handling. It is Apache 2.0 licensed, and its 3.9.0 release, dated January 12, 2025, supports Python 3.8 to 3.11 and moved to pymongo 4.x. Its sensors, rules, workflows and packs run on your own hosts, so no cloud connection is needed for the core platform. Confirm that every pack you need can be mirrored into the enclosure, since packs usually pull code and dependencies from public sources. StackStorm does not include case management or an analyst war room, and it runs on MongoDB and RabbitMQ, which you must also install and patch offline.

Can n8n be used on an air-gapped network without a commercial license?

n8n can run without internet access, but its license limits where it fits. n8n is distributed under the Sustainable Use License, which permits internal business use and non-commercial or personal use, and it is source-available rather than OSI open source. Files marked .ee require a valid n8n Enterprise License. Have legal review the Sustainable Use License against how your organization plans to use it, and confirm that the features you need sit outside the .ee files. Because n8n is a general workflow tool rather than a security orchestration platform, you would also need to build your own case handling and security integrations.

Does Tracecat support an air-gapped Kubernetes deployment for XSOAR 6 users?

Tracecat documents an air-gapped Kubernetes deployment for teams running Cortex XSOAR 6 on premises, which makes it the option to check first if you need built-in case management. Tracecat is AGPL-3.0 licensed and ships its own cases, workflows, tables and AI agents. Features such as SSO and multi-tenancy sit in its paid Enterprise Edition, so confirm which ones your disconnected site needs. The details of the connectors, the durable execution on Temporal and the deployment steps are covered in the sibling Cortex XSOAR vs Tracecat comparison, which is the right next read before you plan a pilot.

Which option should a disconnected SOC pick if it needs case management?

If your analysts depend on incidents, layouts and a war room, pick a platform that includes case handling or plan to pair Shuffle with a separate case system. Shuffle is a strong automation layer, but it has no built-in incident layouts or war room. Tracecat includes cases in the same tool, which reduces the number of components to run offline. StackStorm and n8n do not provide analyst case management. Map your current incident types, fields and SLAs before choosing, because that mapping decides how much you must build yourself.

What does an offline SOAR deployment cost to run each year?

The recurring cost is mostly staff time and infrastructure, not licensing, for most of these open-source options. Each option needs servers or Kubernetes nodes, storage for its database, time to mirror container images and packages across the boundary, and people to patch and test them. Commercial SOAR licenses, by contrast, recur every term. Ask any implementation partner for a quote built from a written scope, covering installation, offline app or pack loading, backups, upgrades and support hours. Only the Shuffle licensing figures, such as its app-run metric, come from a published source, so confirm current terms with each vendor.

How do I load integrations into a disconnected SOAR without internet access?

Each platform needs its integration code, container images and dependencies mirrored into the enclosure through an approved transfer process. For Shuffle, apps run as versioned Docker containers, so you must mirror the app images and the containers they depend on before import. For StackStorm, mirror packs and their Python dependencies. Verify each artifact against its source, record hashes and keep an inventory, because this is the control that supply chain requirements such as NERC CIP-013-2 ask you to address for software and patches crossing an isolated boundary. Confirm that your chosen platform can import these artifacts without contacting external registries.

Can DeployOpen implement and harden one of these alternatives inside our isolated network?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. DeployOpen does not publish a price list, so a quote follows from the written scope. Its work prepares systems and evidence for compliance assessments but does not issue audit reports or certifications, which independent auditors and certification bodies provide.

Can our own team run an offline SOAR platform without outside help?

Your team can run an offline SOAR platform if it already operates container platforms and has an internal process for moving software across the boundary. Expect ongoing work in patching, backup and restore, integration updates and monitoring the automation runtime. Shuffle documents high availability needs, including an OpenSearch cluster and more than one Orborus node, and it encrypts stored credentials with a secret that must be backed up, since losing it breaks saved app authentications. Test a restore before go-live and assign named owners for each component, because those tasks are what usually decide whether a team can run the platform alone.

How DeployOpen plans an air-gapped Shuffle deployment

DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own air-gapped network, with security testing and compliance readiness alongside. The cards below follow the decisions that shape an isolated Shuffle deployment, from the offline image path to the paperwork an assessor will ask for.

Scoping the isolated boundary

DeployOpen starts by mapping which systems sit inside the isolated network, which feeds and tools Shuffle must reach, and which cannot be reached at all. Each integration is classified as internal-only, reachable through an approved transfer path, or retired. The output is a written scope with named deliverables and timelines agreed before any work starts. Ask the team to show how the scope handles apps that call external APIs, since those calls will fail without a plan.

Offline image and app supply chain

Shuffle runs its workflow apps as versioned Docker containers, so every image, app and dependency must be pulled on a connected system, verified and carried across the boundary. DeployOpen plans a repeatable transfer process with checksums, a private registry inside the network and a record of which versions were approved. This is the control point that NERC CIP-013-2 addresses for software integrity and vendor patches, and it is where most air-gapped Shuffle projects need the most care.

Platform build on Docker or Kubernetes

DeployOpen implements the chosen topology, either a single server with Docker Compose or Kubernetes with Helm charts, and sets the OpenSearch cluster, Orborus nodes and backend scaling needed for high availability. The default Docker Compose setup is not scalable without changes, so the build decision is made early. Confirm that the target cluster can pull its base images from the private registry before the first install.

Secrets, SSO and key custody

Shuffle encrypts saved app credentials with the SHUFFLE_ENCRYPTION_MODIFIER secret, and losing or changing that value breaks every saved app authentication. DeployOpen plans where this key is stored, how it is backed up under dual control, and how SAML or OpenID Connect sign-in is connected to your identity provider inside the network. Ask who holds the key and where the recovery copy lives before go-live.

Backup, restore and upgrade testing

Shuffle state lives in OpenSearch, and the offline path also requires keeping the approved image set, app versions and playbook exports under change control. DeployOpen defines backup schedules, restore tests and an upgrade procedure that starts from a carried-in image bundle. Ask for a restore test result on a separate system, not only a backup success log.

Testing, documentation and evidence

DeployOpen runs security testing against the deployed platform and its apps, then documents architecture, runbooks and the evidence an auditor will request. DeployOpen prepares controls and evidence for compliance assessments but does not issue audit reports or certifications; independent auditors and certification bodies do that work. Confirm which assessment framework applies to your environment before scoping the evidence set.