Why Shuffle security hardening starts with what the platform holds
Hardening a self-hosted Shuffle means protecting the encryption secret that guards saved app credentials, controlling how webhooks reach the platform, limiting host-level access from the runtime, securing the OpenSearch store, and scoping each integration key to the access its workflows need. The reason to start here is what Shuffle holds. A SOAR platform stores API keys and app credentials for the SIEM, EDR, ticketing and identity tools it drives, and in many setups it can act on those systems: close a ticket, isolate a host, disable an account. A single compromise can therefore reach every connected tool at once, which makes the platform a more valuable target than any one of the tools behind it.
The saved credentials sit in OpenSearch, where Shuffle encrypts app credentials and API keys with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. Anyone who can read the database and the secret can recover those credentials, so the two must be protected together. The Shuffle configuration docs warn that losing or changing the secret breaks all saved app authentications, which makes it an operational dependency as well as a security control. Before go-live, decide where the secret is stored, who can read it, how it is backed up separately from the database, and how a change would be carried out. Confirm in the configuration docs how the value is set for your deployment model.
The runtime is harder to secure than a default install suggests. Orborus polls the backend for jobs, starts a worker for each workflow execution, and the worker starts app containers. The component that executes workflows therefore needs privileged access to the container runtime on its host, which makes it a privileged component with a wider blast radius than the stateless API. Treat the runtime host as part of the security boundary. Decide who administers it, what else runs on it, which internal networks it can reach, and whether the container runtime access can be narrowed in your environment. Each app container inherits whatever network reach you give it, so review that reach as part of the design.
Each integration adds a credential that needs its own scope. A SIEM query key, an EDR action key and a ticketing key should be separate credentials, and none should be a broad administrator token. Build an inventory that lists each app, each connection, the permissions it uses, the workflows that call it and the owner who approves changes. Then compare the rights granted to each key with the actions its workflows actually execute, and remove what is unused. This inventory is usually the largest effort in the hardening work, because it has to be built from the playbooks that already exist. Start it before you change any credentials so the change list is complete.
The edition and deployment model do not change the hardening work. Shuffle is licensed under AGPL-3.0, and according to its open source article, all features are available in the open-source edition. Paid tiers differ in feature limits, scaling and support. Hardening is therefore the team's own responsibility, whichever model you choose: a single server with Docker Compose, Docker Swarm, Kubernetes, or a hybrid with a local Orborus. The controls in this section apply to each of them. Confirm with Shuffle which limits apply to your edition before you design around them, and record the decision so the next upgrade does not reopen it.
Which Shuffle components carry security risk
The components below form one path, from the browser through the backend and runtime to the containers that call your security tools. Each card names what the component holds or can reach and what to check. Exact access patterns differ by deployment model, so confirm them against the architecture docs for the version you run.
Frontend web interface
The web interface where analysts build workflows, manage apps and configure users. It is the entry point most people reach from a browser, so it carries session and authentication exposure. Check that it is served only over TLS, that it sits behind your reverse proxy or access controls, and that administrative functions are limited to named roles. Confirm that the frontend and backend images are on matching versions.
Go backend API on port 5001
The Go backend API listens on port 5001 and handles workflow storage, execution requests, app configuration and API key use. It has the widest reach on the server side because it talks to OpenSearch, serves the frontend and receives requests from Orborus. Restrict which networks can reach port 5001, keep it off the public internet unless a webhook requires exposure, and confirm the access pattern for your deployment model in the architecture docs.
OpenSearch document database
OpenSearch stores workflows, execution records, and saved app credentials and API keys. Those credentials are encrypted with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, but the key sits in the same deployment as the data it protects. Require authentication and TLS on OpenSearch, limit network access to the backend and Orborus, and store the encryption secret separately from data backups. Losing or changing the secret breaks all saved app authentications.
Orborus runtime poller
Orborus polls the backend for queued jobs and starts a worker for each workflow execution. It links the control plane to the runtime, so it inherits trust in the backend and in the host it runs on. Decide where it runs, whether on the same host, a separate server or a private network, and confirm which inbound and outbound connections it needs. Plan for more than one Orborus node so workflows keep running if one fails.
Workers and app containers
Each workflow execution gets a worker, and the worker starts app containers for the actions it runs. Those containers run integration code and hold the credentials needed to call your SIEM, EDR and directory services, so they reach sensitive internal systems. Review which app images are pulled, pin versions, and confirm which networks the containers can reach from the runtime host. Treat app images as code that needs the same review as your own.
Docker socket access
The runtime needs the Docker API to start containers, and this access is often granted by mounting the Docker socket into the runtime environment. Whoever controls the socket can start privileged containers on the host, which makes it a path to full control of that machine. Confirm in the architecture docs for your version which components mount the socket and in which deployment model. Limit it to the runtime host and keep other workloads off that host.
Which hardening choices fit your environment and what each costs to run
This table compares the main hardening decisions for a self-hosted Shuffle deployment, the options for each, when each fits and what it costs to run. Read each row against your network layout, certificate process and team capacity before choosing. The main takeaway is that exposure, container control and secret handling create most of the ongoing upkeep, so settle them before go-live.
| Decision | Options and when each fits | Operational cost to run |
|---|---|---|
| Where TLS terminates | Reverse proxy or load balancer: fits when an existing edge already manages certificates. Platform-terminated TLS: fits when Shuffle is the only entry point. | Proxy adds a component to patch and a renewal point. Platform TLS puts certificate files and renewals inside the deployment. |
| Webhook exposure | Internet-facing: external senders call directly. Restricted source range: senders have fixed addresses. Hybrid with local Orborus: internal workflows with no inbound ports. | Internet exposure needs edge rate limiting and logging. Allow lists need upkeep when sender addresses change. Hybrid splits troubleshooting between cloud and local components. |
| Container control for the runtime | Direct Docker socket mount: simplest path, fits when the host is dedicated to Shuffle. Restricted option: fits strict policies; confirm availability for your version. | Socket access gives host-level container control, so isolation and monitoring carry the risk. Restricted setups need confirmed configuration and added testing. |
| OpenSearch security | Network isolation only: fits a private segment reachable only from Shuffle servers. Authentication and TLS: fits multi-host or audited environments. | Isolation depends on firewall rules that must track node changes. Security features add certificates, roles and per-node settings to maintain. |
| Integration keys | One key per app: fits separate rotation and audit trails. Shared key: fits small setups with one owner and few apps. | Per-app keys mean more rotation and tracking, but limit the impact of a leak. Shared keys cut upkeep but force changes everywhere at once. |
| Encryption secret for app credentials | SHUFFLE_ENCRYPTION_MODIFIER held in a managed secrets store: fits every deployment. | Losing or changing it breaks all saved app authentications. Backup and change procedures must exist before go-live. |
How to sequence Shuffle security hardening so nothing is exposed during the work
This sequence orders the hardening work so each change is verified before the next one exposes or depends on it. It starts by mapping what can be reached, protects the encryption secret before any credential is saved, then closes network paths and reduces privileged access before per-integration keys are issued.
Inventory exposed ports and the backend
Before changing anything, list every address and port where the frontend, the Go backend on port 5001, OpenSearch and each webhook endpoint can be reached, from inside and outside your network. The platform engineer running the work records which hosts answer, which firewall rules allow them and which integrations depend on each path. Done means you have a written exposure map that a second person has reviewed, and an external scan shows no unexpected listener on port 5001. Keep this map as the baseline for every later check.
Confirm the encryption secret is stored and recoverable
Before any app credential or API key is saved, confirm that the SHUFFLE_ENCRYPTION_MODIFIER value is loaded from a secrets store, with no plain environment file holding it, and that the value is recorded in your recovery process. The Shuffle configuration docs warn that losing or changing this secret breaks all saved app authentications, so the check is a restore test. Retrieve the value from the store, confirm it matches the recorded copy and confirm named people know how rotation would be handled. Done means a test credential still authenticates after the backend restarts.
Place TLS in front of frontend and webhooks
Terminate TLS at a reverse proxy or load balancer in front of the frontend and every webhook endpoint, and pass through only the paths each service needs. Confirm the certificate chain is valid for the hostnames that users and external senders actually use, and disable plain HTTP listeners on those paths. The check is a connection test from outside your network: the frontend and a test webhook should answer only over HTTPS, and a plain HTTP request to a webhook should fail or redirect without reaching the backend. Done means the backend on port 5001 is not reachable through the public path.
Restrict network paths to backend and OpenSearch
Limit inbound access to the backend on port 5001 and to OpenSearch so that only the frontend, the Orborus runtime nodes and the administrative hosts that need them can connect. Apply the rules at the host firewall, security group or network policy layer. Confirm that Orborus can still reach the backend in your chosen architecture, including any hybrid setup where the runtime sits in a private network. Done means a connection attempt to the backend or OpenSearch from an unapproved network fails, while a test workflow from an approved runtime completes.
Review Docker socket access in the runtime
Identify every component that mounts or reaches the Docker socket, since access to it gives control over the host's containers. Check the Shuffle version you run and its documentation for how the runtime uses the socket, then reduce access where that version allows, such as isolating worker and app container hosts on dedicated machines. Record any access you cannot remove in the version you run as an accepted risk with a named owner. Done means the list of socket consumers is documented and a test workflow still runs after each change.
Secure OpenSearch access and authentication
Enable authentication and transport protection for OpenSearch according to the OpenSearch security documentation for your version, and give Shuffle its own service identity with only the index permissions it uses. Keep OpenSearch on the restricted network path from the previous step. Confirm that snapshots and backups are encrypted and access controlled, since they hold the same stored credentials. The check is a direct query to OpenSearch without credentials, which should be refused, followed by a workflow that reads and writes Shuffle data successfully.
Create per-integration API keys with minimal permissions
Create a separate API key or service account for each integration, granting only the actions that its workflows call, and record the owner and purpose of each one. Save each key only after the earlier steps are complete, so no credential is stored while the encryption secret, TLS or network controls are still unverified. Done means each key is saved in Shuffle, its scope matches the documented need, and any unused or duplicate key has been revoked and removed.
Retest integration workflows after restarts
Re-run every workflow that calls an integration using the new per-integration keys, and confirm each one authenticates. Restart the backend and the Orborus nodes, then run the workflows again to confirm that saved credentials still decrypt and executions still start. Include one deliberate failure, using a wrong key, to confirm the error is raised and logged. Done means each integration has a clean run record, the failed-authentication test is documented and the scope of each key is signed off by its owner.
Shuffle security hardening controls by component
Shuffle holds saved app credentials, API keys and webhook entry points, so hardening spans several components. The controls below are grouped by area, and each one names who owns it. Where a setting depends on the Shuffle version you run, confirm it in the vendor documentation before you change production.
Encryption secret handling
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. Generate the value once, store it in your secrets manager, and restrict read access to the people and hosts that deploy Shuffle. Back it up with the same care as the OpenSearch data it protects, because losing or changing it breaks every saved app authentication. Your team owns storage and backup. Confirm with the vendor documentation how the value must be handled during upgrades.
Webhook exposure and TLS
Webhook triggers are the part of Shuffle most likely to face the internet, so terminate TLS in front of them at a reverse proxy. Never expose the backend API on port 5001 directly to untrusted networks. Restrict which source addresses can reach webhook endpoints and apply rate limits at the proxy. Your team owns proxy configuration and firewall rules. Confirm with the vendor documentation which endpoints must be reachable for your deployment architecture.
Docker socket and runtime hosts
Orborus polls the backend for jobs, starts a worker for each workflow execution, and the worker starts app containers, so the hosts running them carry significant privilege. Limit which hosts run Orborus and workers, and separate runtime hosts from the management plane where your architecture allows. Avoid running app containers with extra privileges, and treat access to the Docker socket as root-equivalent. Your team owns host placement. Confirm with the vendor documentation which privileges Orborus requires in your version.
OpenSearch network isolation
OpenSearch is the document database behind Shuffle, so anyone who reaches it can read or alter workflow data. Keep it on a private network that only the backend and the nodes that need it can reach, and enable authentication and TLS between nodes and clients. Control who can access snapshot repositories, because snapshots carry the same data as the live index. Your team owns network segmentation and snapshot access. Confirm with the vendor documentation which OpenSearch security settings your Shuffle version expects.
Least-privilege API keys
Create one API key per integration so a leaked key exposes a single connection and can be revoked without affecting others. Grant each key only the permissions its integration needs, and assign a named owner who answers for it. Set a rotation schedule and remove keys when the app they serve is retired. Your team owns the key inventory and rotation policy. Confirm with the vendor documentation how keys are scoped and revoked in your version.
How SHUFFLE_ENCRYPTION_MODIFIER protects saved app credentials
The SHUFFLE_ENCRYPTION_MODIFIER secret is the key that protects every app credential and API key your team saves in Shuffle. According to the Shuffle configuration docs, Shuffle encrypts saved app authentications in OpenSearch with AES-256, using this secret as the keying material. The practical effect is that a copy of the OpenSearch dataset, whether from a snapshot, a disk image or an over-broad database export, does not by itself expose the Slack tokens, SIEM passwords or API keys that your workflows depend on. An attacker or an insider with read access to the index still needs the secret, which lives in a different place and should be controlled separately.
This separation only works if the secret is actually separate. Keep SHUFFLE_ENCRYPTION_MODIFIER out of the same backup archive as the OpenSearch data, out of the Compose or Helm files committed to source control, and out of shared chat or ticket attachments. Put it in the secret store your platform team already uses, such as a vault, a Kubernetes secret managed through your normal change process, or the environment configuration of the host with restricted file permissions. Confirm with your own security team who can read it, who can change it, and whether those reads are logged. Also confirm that the Shuffle containers receive it at runtime from that store rather than from a copy on a developer laptop.
The operational consequence is the one most teams underestimate. The docs warn that losing or changing the secret breaks all saved app authentications. Shuffle does not hold a second copy that can rescue you, so a lost secret means re-entering every credential for every app, and workflows that depend on those apps stop until that is done. Changing the value is no simpler: encrypted records written under the old secret must be re-encrypted or re-saved under the new one. Treat rotation as a migration project with a plan, a rollback point, a test environment and a window agreed with the people who own the workflows. Do not treat it as an edit to an environment variable. Ask the Shuffle maintainers or your implementation partner to confirm the supported rotation procedure for your specific version, and do not rely on a procedure you found in a forum post.
For disaster recovery, record the secret in a form that survives the loss of your primary secret store, such as a sealed copy held by two named custodians or a split-knowledge arrangement, and store it apart from the backups it unlocks. Record the version of Shuffle it belongs to and the date it was set. Then prove the recovery path. Restore the OpenSearch snapshot into a non-production environment with the recorded secret, open a saved app connection, and run one workflow that uses it. If decryption fails, you have learned that before an incident rather than during one. Repeat this test after every upgrade and after any change to the secret store.
When you engage an implementation partner, ask for written documentation covering: where the secret is stored in each environment and who can access it; the backup and recovery procedure for the secret, tested against a restored OpenSearch snapshot; the supported rotation steps for the Shuffle version you run, with the team confirming them; the restore test results and the list of saved apps verified after restore; and a runbook for what to do if decryption fails. Ask who signs off on each item and how the documentation will be kept current after upgrades.
How the hardening work differs by deployment model
On one host, the frontend, backend API, OpenSearch and runtime share the same machine, so every exposure point and the container control path sit in one place. Hardening is mostly about host boundaries and what the network can reach.
- Exposure points: the frontend and the backend API on port 5001 are the reachable surfaces. Decide which ones users, webhooks and integrations need, and publish only those.
- Container control: the component that starts worker and app containers drives the host's Docker engine. Treat that access as close to host administration, and confirm in the configuration docs which Compose services mount the Docker socket in your version.
- OpenSearch placement: OpenSearch shares the host's disk, memory and network. Bind its port to an internal interface and keep it out of any published port mapping.
- Shifting steps: host firewall rules, restricted SSH access, and reviewing volume mounts carry most of the work on this model.
Before go-live, check the Compose file for every published port and every volume mount, and record the result as evidence for your review.
Swarm spreads backends, frontends, OpenSearch and workers across several nodes, so exposure and container control move to the cluster level. Manager nodes hold cluster control, and any node that runs a container-control component needs the same care as a single server.
- Exposure points: cluster traffic between nodes and the published service ports are both exposed. Limit cluster management traffic to the node subnets and publish only the services that need users or webhooks.
- Container control: Docker API access on manager nodes is the highest-value target. Limit which nodes run services that touch the engine, and restrict who can join nodes with tokens.
- OpenSearch placement: use placement constraints to pin OpenSearch to dedicated nodes with persistent storage. A single OpenSearch node is a single point of failure, so cluster design should follow the high availability guidance.
- Shifting steps: node labels and placement constraints replace per-host layout, secrets move to Swarm secrets or an external vault, and overlay network encryption should be confirmed for your version.
Review the placement constraints and join token handling with your platform team, because a mistake in either affects every service in the stack.
In this model the control plane runs in Shuffle Cloud while Orborus runs inside your network. Orborus polls the backend for jobs, so it initiates the connections itself and the design needs no inbound firewall ports. Exposure shifts from inbound services to outbound destinations and to the credentials that reach your internal systems.
- Exposure points: no inbound ports are opened for Orborus. Review the outbound destinations it may reach, including the Shuffle Cloud endpoints and your internal SIEM, EDR and directory services.
- Container control: the local Orborus starts worker and app containers on your hosts, so the Docker engine and container control sit inside your perimeter. Harden those hosts as you would any build or automation host.
- OpenSearch placement: confirm with Shuffle where the document database runs for the cloud tier and where saved app credentials are encrypted, because that decides who controls the encryption secret.
- Shifting steps: runtime host hardening, egress filtering, and the number of Orborus nodes for redundancy move to your team. Decide whether internal credentials stay local or live in the cloud.
Confirm the egress allowlist and the location of the encryption secret with Shuffle before the runtime goes live.
Kubernetes adds ingress controllers, service accounts, role-based access control and network policies. Container control is exercised through the API server and the kubelet instead of a Docker socket on each host, but Orborus in Kubernetes mode still needs permission to create workloads for workers and apps.
- Exposure points: expose the frontend and webhook routes only through an ingress controller with TLS, and avoid node-level port exposure for services that do not need it.
- Container control: scope the Role that Orborus uses to the namespace it needs. Avoid cluster-wide administrator rights, and confirm the exact permissions the chart grants before you install it.
- OpenSearch placement: run OpenSearch as a stateful workload with persistent volumes. Confirm the chart values for OpenSearch security settings and how they are supplied.
- Shifting steps: network policies, pod security settings, secrets from Kubernetes Secrets or an external secret manager, and pinned image tags replace host-level controls.
Run the chart's rendered manifests through a review of service accounts and network policies before you apply them to a shared cluster.
When the network cannot pull images or check for updates freely, image sourcing, updates and secret handling need explicit planning. Every platform image and every app image a workflow uses must be available inside the network, and each one must be checked before it is relied on.
- Image sourcing: mirror the Shuffle platform images and the app images your workflows call into an internal registry. Keep a list of tags and digests so you know exactly what is running.
- Updates: upgrades arrive by manual transfer. Test each release in a staging environment first, and confirm the supported offline procedures with Shuffle for your version.
- Secret handling: provision the encryption secret and saved credentials without depending on an internet-hosted vault. Losing or changing the encryption secret breaks all saved app authentications.
- Outbound behavior: list every external call your version makes and confirm which ones can be disabled or routed internally.
- Tags: the docs recommend the latest tag for stable releases and the nightly tag for experimental changes. In restricted networks, pin tags so that a mirror always matches what was tested.
Ask Shuffle to confirm the offline install and upgrade steps for your exact version before scope and timeline are agreed.
How to test Shuffle security hardening and confirm it fails safely
Test Shuffle hardening by trying to reach it from outside and by breaking its dependencies on purpose, then record what happens. Start with exposure. From a host outside the Shuffle network, scan the backend API port (5001), the OpenSearch HTTP and transport ports, and any internal management endpoints you can reach, such as cluster administration APIs or admin pages. Only the frontend path and the intended webhook route should answer. For webhooks, send the same test request through the approved reverse proxy and directly to the backend, then confirm that only the proxied path is accepted. Use the same scanner, source host and settings on every run so results can be compared across changes.
Next, confirm that workflows fail closed. Revoke an API key in the target system and run a workflow that uses it. The action should stop with an authentication error, without continuing on partial data or a cached result. Then test the encryption secret. Start a copy of the stack with SHUFFLE_ENCRYPTION_MODIFIER removed, then with a wrong value, against a copy of the data. Saved authentications should fail to decrypt and the workflow should stop. Block a webhook source at the firewall, send a test event, and confirm that no workflow run starts. For each failure, check the logs. They should show the failing step, the workflow and the app involved, and the time. Search backend logs, worker output and Orborus output for the secret value, API key values and any decrypted credential. None of them should appear.
Recovery tests show whether your backups and secret records are usable. Restore an OpenSearch backup and your configuration into a clean environment, setting SHUFFLE_ENCRYPTION_MODIFIER to the value recorded when the original system was running. Then run one read-only action for each saved app and confirm it authenticates. If an action fails with a decryption error, the most likely cause is the secret, not the backup, so check the recorded value before anything else. Also confirm that Orborus connects to the restored backend and that a test workflow executes. Note how long the restore took and which steps were manual. Those observations feed your recovery plan, and you should confirm them against your own environment rather than assume them.
Run all of these tests first in a non-production environment that matches production in topology, Shuffle version and image tags. Shuffle's documentation recommends the latest Docker tag for stable releases and the nightly tag for experimental changes, so record the exact tags you deploy, because the tag alone does not identify the version. For every test, record the date, the tester, the tool and command, the expected result, the actual result and the evidence. Evidence can include scan output, screenshots and log excerpts with secrets redacted. Keep these records for internal review and for auditors. DeployOpen prepares evidence but does not issue audit reports. If the expected behavior for a case is unclear, confirm it with the Shuffle maintainers before you accept the result, and repeat the full set after every upgrade.
What drives the effort and cost of Shuffle security hardening
This table lists the factors that change how much work a Shuffle hardening project takes and how each one can be reduced. Read each row as a question to answer about your own environment before requesting a quote. The main takeaway is that the number of integrations, runtime locations and webhook sources usually matters more than the hardening steps themselves.
| Driver | Why it changes the work | How to keep it down |
|---|---|---|
| Integrations and API keys to scope | Each integration needs its own least-privilege API key, scope review, and entry in the credential inventory. Saved credentials are encrypted in OpenSearch with the SHUFFLE_ENCRYPTION_MODIFIER secret, so each one must be validated after any secret change. | Consolidate tools behind fewer integration accounts where the vendor allows it, and retire unused app authentications before the review starts. |
| Runtime locations and private networks | Each Orborus runtime location needs its own network path, outbound rules and host hardening. Locations inside private networks need more firewall and connectivity review than cloud-hosted ones. | Use a single runtime zone where the security model permits it, and group internal tools that share one network segment. |
| Webhook endpoints and their sources | Every webhook is an inbound path that needs TLS, authentication of the sender, and exposure review. The number of distinct source systems drives how many trust relationships must be documented and tested. | Route several sources through one hardened ingress point with shared authentication, and remove webhooks that no active workflow uses. |
| TLS and identity already standard in your organization | If certificate management and SSO patterns already exist, Shuffle can reuse them. If not, certificates, identity provider configuration, and per-tenant enforcement must be designed from scratch. | Confirm internal certificate authority and identity provider standards before scoping, and reuse existing SAML or OpenID Connect configuration. |
| OpenSearch topology | A single OpenSearch node leaves encryption, authentication, network binding and backup to be configured and tested. A clustered setup adds node-to-node security, snapshot repositories and access separation. | Decide the topology early, and confirm with your platform team whether an existing managed or shared OpenSearch service fits the requirement. |
| Documentation for an assessment | If an internal or external assessor will test controls, each hardening decision needs a written control description, configuration evidence and a test record. This can add more work than the configuration itself. | Ask for control mapping to your existing framework up front, and reuse the evidence templates your assessment team already accepts. |
| Workflows per integration and retesting | Each workflow that calls an integration must be retested after key rotation, app version changes or permission changes. Many workflows on a shared integration multiply the regression effort. | Group workflows by integration, prioritize the highest-risk paths for retesting, and keep a test case per integration so checks can be rerun quickly. |
What to monitor, back up, upgrade and document after hardening
Hardening a self-hosted Shuffle is not finished when the first build passes its checks. The controls you set at the start only stay effective if someone watches them, and the operational work that keeps them in place should be assigned to named owners before go-live. Start with four signals that show whether the protections are still doing their job: authentication failures against the Shuffle frontend and backend, webhook requests rejected at the source check, containers started on the runtime hosts that were not expected from a workflow execution, and changes in how API keys are used by apps and integrations. Route these to a log store your security team already reviews, and agree on which events page someone and which are reviewed weekly. Backups need a deliberate design because two pieces of state are only useful together. The OpenSearch document store holds workflows, app configuration and saved credentials, but those credentials are encrypted with the SHUFFLE_ENCRYPTION_MODIFIER secret. A backup of OpenSearch without that secret cannot restore working app authentications, and a copy of the secret without the data restores nothing useful. The Shuffle configuration docs warn that losing or changing the secret breaks all saved app authentications. Back up both under the same change record, store the secret in a separate custody system from the data snapshots, restrict read access to a small named group, and test a restore into an isolated environment before you rely on it. Confirm the exact snapshot tooling and retention settings with your OpenSearch deployment, because they depend on how your cluster is built. Every upgrade should trigger a repeat of the exposure and failure tests from the original hardening work. Upgrades can change which ports are listening, which images the frontend, backend, worker and Orborus components pull, and which configuration keys are read at startup. Treat an upgrade as a change to the attack surface until the tests show otherwise. Compare the listening ports and the webhook rejection behavior against the baseline you recorded, check that the Docker socket is still mounted only where you intended, and confirm that the TLS settings on the public entry point still hold. Also check that the apps you rely on still run on the upgraded version. Upgrade mechanics and the support responsibilities that follow them are covered on the Shuffle upgrades and support page. API keys need a review schedule, not only a creation process. Each key used by an integration should map to one app, one purpose and one owner, and the review should confirm that the permissions still match what that integration does today. When a SIEM connector, ticketing integration or custom app is retired, its keys should be revoked in Shuffle and removed from the saved app configuration, not left behind because nobody remembered them. Ask each owner to confirm the keys they expect to exist, and compare that list with what is stored. Keys that no owner can explain should be treated as a finding and rotated or removed. Finally, keep a hardening record that a new engineer or an auditor could read without asking the original team. It should list each decision with its reason, such as where TLS terminates, which network paths reach the webhooks, which hosts may run the Docker socket, and who holds the encryption secret. Record the owner for each control, where the secret and backup keys are kept, and the test evidence from each run, including the date, the version tested and the result. Preparing this evidence supports compliance readiness work, but it is your organization and its assessor that decide whether the controls meet a given requirement.
What buyers and engineers ask before hardening a self-hosted Shuffle
How much effort does hardening a self-hosted Shuffle take?
Effort depends on how many components you run and how exposed they are, so it varies between sites. The effort-driver table elsewhere on this page lists the main factors, and this answer explains how to use it. Start by confirming your deployment architecture, since a single Docker Compose server, a Docker Swarm cluster, a hybrid setup with a local Orborus and a Kubernetes deployment each change the work. Then count the items in scope: TLS and webhook exposure, Docker socket access, OpenSearch security, the encryption secret and the number of API keys tied to integrations. Testing failure cases adds time in every cycle, so ask any partner how many test rounds the written scope includes and what each one covers.
Can an internal team harden Shuffle without an outside partner?
Yes, if the team already has container, network and OpenSearch administration skills and time to test failure cases. Shuffle runs a frontend, a Go backend API, an OpenSearch document database and Orborus, which starts a worker for each workflow execution, and the worker starts app containers. Hardening touches every one of these, so the engineer making changes needs to understand how traffic moves between them. The hardest part is often proving the change works: confirming that webhooks still arrive, that workers still reach the backend on port 5001 and that workflows still run after a node restart. If one of those skills or the test time is missing, a fixed-scope engagement can cover the gap.
What does hardening Shuffle require from our organization?
The work needs five things from your organization. First, environment access: administrative access to the hosts, container platform, network devices or cloud accounts where Shuffle runs, inside your own infrastructure. Second, a secrets store where the encryption secret and integration credentials can be kept under access control. Third, a named owner for API keys who can approve scopes and rotation. Fourth, a test window in which workflows can be paused or run against non-production systems. Fifth, documentation of the network design, including firewall rules, DNS, certificate handling and which runtime locations reach internal SIEM, EDR and directory services. Missing items usually cause delays, so confirm each one before the written scope is signed.
Does hardening Shuffle change which features the open-source edition includes?
Shuffle's documentation states that all features are available in the open-source edition, while paid tiers differ in feature limits, scaling and support. Since v2.1.1, the limits between editions are actively enforced, so the version you run matters. Hardening is mainly a configuration and network exercise, but it can change how you reach a limit, such as scaling or runtime count. Confirm the current limits for your version with Shuffle before you design the runtime layout, and record them in the scope. Licensing on the paid tiers is based on app runs, so include your expected workflow volume in that check.
What happens if the Shuffle encryption secret is lost?
If the encryption secret is lost, saved app authentications in Shuffle break. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, and the configuration docs warn that losing or changing it breaks all saved app authentications. Recovery planning therefore comes before any hardening change. Store the value in your secrets store, restrict who can read it and keep a backup that is separate from the OpenSearch data it protects. Document which integrations would need to be reauthenticated and who would do it, then test a restore in a non-production environment before you rely on it.
Can DeployOpen certify a self-hosted Shuffle setup?
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 issue any attestation. For a Shuffle setup, the evidence can include a documented architecture, access control records, configuration baselines, secrets handling procedures, backup and restore test results and logs showing who changed what. Ask your assessor which evidence they expect and in what format before the work starts, so the setup is built to produce it. The written scope should name the control areas covered, and the assessor decides whether the evidence meets their criteria.
Which Shuffle version should we run before hardening?
Run a version that is still supported, and start hardening from the release you plan to keep. Shuffle stopped supporting versions older than v2.1.1 after January 31, 2026, so an older install should be upgraded before hardening is verified. The Shuffle docs recommend the latest Docker tag for stable releases and the nightly tag only for experimental changes. Pin image tags in your deployment files so the frontend, backend and worker images stay aligned, and record the exact version in your change log. Check the current release notes on the Shuffle GitHub releases page before choosing a target, because a hardening change tested on one version may need retesting after an upgrade.
How DeployOpen works on this
DeployOpen hardens self-hosted Shuffle inside your own infrastructure, starting from a written scope that names the exposed webhooks, runtime locations and integrations to review. Work covers the encryption secret for saved app credentials, TLS and network exposure, Docker socket access, OpenSearch security and least-privilege API keys. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- The written scope lists each Shuffle server, runtime location, webhook and integration in the hardening review.
- Scope records which deployment architecture applies, whether single server, Swarm, Kubernetes or hybrid with local Orborus.
- Access, secret handling and OpenSearch exposure are confirmed with your security team before any configuration changes begin.
How we build
- Build work covers the SHUFFLE_ENCRYPTION_MODIFIER secret, its storage and a documented recovery procedure before go-live.
- Webhook exposure is reduced through TLS termination, restricted network paths and firewall rules tested from outside the network.
- Docker socket access, OpenSearch authentication and API keys scoped to individual integrations are configured and tested as separate items.
How we hand over
- Handover includes a configuration record, network exposure map, and list of API keys with owner and permitted actions.
- Runbooks cover any change to the encryption secret, integration key rotation and OpenSearch restore from backup.
- Your team receives documentation and a walkthrough so administrators can operate the hardened settings without DeployOpen.
How we support
- Ongoing support is available as a retainer covering Shuffle version upgrades, image alignment and hardening review.
- Re-review is scoped after upgrades, new integrations or changes to webhook exposure, since each can alter the attack surface.
- Retainer scope and any follow-up testing are agreed in writing, with a quote following from that scope.
