Why a Shuffle hybrid deployment with on-premises Orborus keeps internal tools reachable
The hybrid model exists because your workflows need to query systems that should not be exposed to the internet. A SOAR playbook that enriches an alert from an internal SIEM, pulls endpoint status from an EDR console or looks up a user in a directory service has to reach hosts inside your network. In the hybrid deployment, Shuffle Cloud hosts the control plane, and an Orborus instance that you run in your private network polls the backend for jobs. Because Orborus initiates the connection, the documented design needs no inbound firewall ports into the private network. That removes the most common objection, but it does not make the integration simple. Four issues decide whether the setup holds up: where credentials live, which egress rules apply, whether the runtime stays healthy and who owns the host.
Credential placement comes first. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, using the SHUFFLE_ENCRYPTION_MODIFIER secret, and losing or changing that secret breaks every saved app authentication. In a hybrid setup, the questions are where those credentials are stored, where the worker that uses them executes and whether the cloud side ever handles a plaintext secret. Confirm these points with Shuffle for your edition and version before you design the app inventory. A practical step is to list every integration, mark which ones need a service account for the SIEM, EDR or directory and decide whether each account can be limited to read-only actions. Record who holds the encryption secret and where its backup is kept, because recovery depends on it as much as daily operation does.
Egress rules are the second constraint. Orborus needs outbound connectivity to the Shuffle Cloud endpoints it polls, and that path may cross a proxy, a TLS inspection appliance or a default-deny firewall policy. Ask the network team to confirm the exact destination hosts, ports and protocols, and test long-lived polling through the same path that production will use. Separately, the app containers started by the worker need internal routes to each SIEM, EDR and directory endpoint, and those routes should be limited to the specific hosts and ports each app requires. Document both flows in a matrix that lists source, destination, port, purpose and owner. The matrix lets your reviewers check each app's reach when a new integration is added.
Runtime health and host ownership are where hybrid projects usually stall. Orborus turns a queued workflow into a running worker, so when it stops, executions wait or fail in ways that can look like a platform problem. The configuration guidance recommends more than one Orborus node so workflows keep running if one fails, which means the host plan needs a second location and a health check that alerts a person. Decide who owns the host operating system, who applies Orborus and worker image updates and who responds when polling stops. These owners often sit in different teams, such as infrastructure, platform engineering and the SOC. Write the answers into a runbook before go-live, and test one failover so that the first failure does not double as the first test.
Which Shuffle and Orborus components sit on each side of the boundary
The hybrid model splits Shuffle into a cloud-hosted control plane and an on-premises runtime. Orborus, the per-execution worker and the app containers run in your network, which is where they reach internal tools. The cards separate each component by side and list what to confirm with Shuffle before you choose this split.
Shuffle Cloud control plane
The server side is the frontend, the Go backend API on port 5001 and the OpenSearch document database. In the hybrid model these components are hosted by Shuffle Cloud, so workflow definitions, execution records and the web interface sit outside your network. Ask Shuffle which tenant data is stored there, where it is hosted, and whether the service terms meet your data handling requirements.
On-premises Orborus runtime
Orborus polls the Shuffle backend for jobs and starts a worker for each workflow execution. It runs in your network and the hybrid model needs no inbound firewall ports, so the connections are initiated from inside. Run more than one Orborus node so workflows keep running if one fails. Confirm the outbound destinations and ports with Shuffle before you submit the firewall change request.
Per-execution worker
For each workflow execution, Orborus starts a worker that carries out that run and starts the app containers the run needs. The worker is the component that handles internal tool traffic during a playbook, so its host placement matters. Ask Shuffle where workers run in your hybrid setup, what they must reach, and how long they keep execution data locally after a run finishes.
App containers
Each Shuffle app is a versioned Docker container, built from an OpenAPI specification or written with the Python app SDK. The worker starts these containers on your runtime hosts, so image pulls and API calls to SIEM, EDR and directory services originate inside your network. Confirm where app images are sourced from and whether your internal registry can supply them.
Internal tool credentials
Apps authenticate to internal tools with saved credentials and API keys. Shuffle encrypts these in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, and losing or changing that secret breaks every saved app authentication. Confirm with Shuffle in writing where these credentials are stored in a hybrid deployment, who holds the encryption secret, and whether any copy reaches Shuffle Cloud.
Network paths to internal tools
The connections from app containers to SIEM, EDR and directory endpoints are the paths your security team must approve. Record each source host, destination, port and protocol before go-live, and include the Orborus polling path to Shuffle Cloud. Confirm with Shuffle which calls, if any, originate from Shuffle Cloud into your network, so that each path has a named owner and an approval.
Choosing a Shuffle hybrid deployment over self-hosting the full stack
This table compares the hybrid model, with Shuffle Cloud and a local Orborus, against self-hosting the full stack on a single server, in Docker Swarm, or on Kubernetes with Helm charts. Read each row as a question your CISO or platform lead must answer before choosing. The main takeaway is that the hybrid model moves control plane operation and some data custody to the vendor, while every self-hosted option keeps those duties and their risks inside your organization.
| Decision point | Hybrid with local Orborus | Single server or Docker Swarm | Kubernetes with Helm charts |
|---|---|---|---|
| When it fits | Apps must reach internal SIEM, EDR or directory services without hosting the control plane. | Pilots, small teams or a few workflows in one trusted network zone. | An existing cluster platform team that already runs Helm-based workloads. |
| Who runs OpenSearch | Shuffle operates the hosted server side. Confirm the scope in writing. | Your team sizes, patches, monitors and snapshots OpenSearch. | Your team operates OpenSearch through the chart. Confirm what the chart manages. |
| Upgrades and patching | The hosted side is updated by the vendor. Your team upgrades the local Orborus and its apps. | Your team tracks releases, aligns frontend, backend and worker images, and tests before rollout. | Your team tracks chart and image versions and tests cluster upgrades before rollout. |
| Backups and recovery | Your team backs up the local Orborus setup and confirms what Shuffle Cloud retains. | Your team owns OpenSearch snapshots, shared file storage and a secure copy of the encryption secret. | Your team owns persistent volume backups, OpenSearch snapshots and the encryption secret. |
| Egress and inbound exposure | Orborus polls the backend, so no inbound firewall ports are needed on the local network. | The backend API on port 5001 and any webhook endpoints need controlled, protected inbound access. | Ingress, network policies and egress rules must be designed and reviewed for each cluster. |
| App credential location | Saved credentials sit in the hosted database. Confirm how Shuffle Cloud encrypts and isolates them. | Credentials sit in your OpenSearch, encrypted with your SHUFFLE_ENCRYPTION_MODIFIER secret. | Credentials sit in your OpenSearch, encrypted with your SHUFFLE_ENCRYPTION_MODIFIER secret. |
| Data custody | Workflow definitions and execution records are held in the hosted backend. Confirm retention and region. | All workflow data and execution history stay in your environment under your retention rules. | All workflow data and execution history stay in your cluster under your retention rules. |
How Orborus polls for jobs so private apps can reach internal systems
In the hybrid pattern, the backend does not reach into your network to find work. The backend queues each workflow execution, and a local Orborus node polls that queue and collects the jobs it can run. Because Orborus opens every connection itself, this design needs no inbound firewall ports on your side. Your network team therefore reviews a defined set of outbound connections from the Orborus host, and that rule set becomes the control that matters most. Assign an owner for it before the build starts so changes to it go through the same review as any other egress policy.
Once Orborus picks up a job, it starts a worker for that workflow execution. The worker then starts the app containers the workflow needs, and those containers call your internal SIEM, EDR and directory APIs over the private network. Each job follows the same order: queue, poll, worker, app container, internal call. The decision to make here is placement. Identify which hosts run Orborus, the workers and the app containers, and which internal networks each host can reach. Compare that reach with the systems each playbook touches. A playbook that only needs the SIEM should run on a host whose route covers the SIEM and nothing broader. Settle this during design, before the first run.
Before you approve the rule set, confirm three things in the current configuration documentation: the exact outbound destinations that Orborus and its workers contact, including backend endpoints and the registries that supply app images; whether Orborus supports an HTTP or HTTPS proxy and how that proxy is configured; and how the runtime behaves when TLS inspection sits in the path. Inspection devices re-sign certificates, so a connection that works in a lab can fail in production if the runtime does not trust the replacement certificate. Ask your network team to test each destination from the Orborus host under the same proxy and inspection policy that production uses. Record the results with the rule set so the approval stays traceable.
Plan for failure of the Orborus host itself. The Shuffle documentation recommends more than one Orborus node so that workflows keep running if one fails, and that recommendation matters more in a private network, where a single host may be the only route to an internal system. Decide which nodes can reach which internal systems, and confirm that a surviving node has the same reach. Then test it: stop one node during a scheduled run and check that the queued work completes on the other. Set monitoring on each node's connection to the backend as well, because a broken outbound path looks like a stalled queue, and the first symptom is often a late alert.
Build sequence for a Shuffle hybrid deployment with on-premises Orborus
This sequence adds an on-premises runtime location to a Shuffle Cloud tenant so workflows can reach internal tools without opening inbound firewall ports. Each step closes with a check, so the team confirms the runtime works before the next layer depends on it.
Confirm the Shuffle Cloud plan and edition limits
Before any infrastructure is requested, the tenant owner confirms which edition and plan apply and what limits they carry. Shuffle states that all features exist in the open-source edition, that paid tiers differ in feature limits, scaling and support, and that limits between editions are enforced since v2.1.1. Licensing is measured in app runs, so the team estimates how many executed workflow actions the local runtime will produce and asks the vendor to confirm how those runs are counted. Done when the edition, plan and run allowance are written down and approved by the people who fund them.
Choose the host and network zone
Select a host that can run Docker containers and sits in a network segment that reaches the SIEM, EDR and directory services the workflows need. Confirm with the platform team which subnets, DNS zones and proxies apply, and keep the host separate from the production systems it automates. Install the container runtime using the Docker guidance for your operating system, then give the host a fixed name and a documented owner. Done when the host resolves each internal service name it needs and a test container starts and stops cleanly.
Define outbound egress allow-lists
Orborus polls Shuffle Cloud for jobs, so the host needs outbound connections to the Shuffle Cloud endpoints and no inbound rules from the internet. Write an allow-list covering those outbound destinations, each internal API the apps will call, and any external vendor APIs. Ask the network team to enforce it at the firewall or proxy and to log denied attempts. Done when the allow-list is approved, enforced, and tests from the host reach every listed destination while no inbound rule has been opened for Orborus.
Deploy Orborus and register the runtime location
Deploy Orborus using the configuration in the Shuffle configuration documentation and pin the image tag to the release your team has approved. The docs recommend the latest Docker tag for stable releases and the nightly tag only for experimental changes, so production should run a pinned stable tag. Store the environment values in your secrets vault, and record the encryption secret used for saved app credentials, since changing it breaks existing app authentications. Register the on-premises location in Shuffle Cloud so workflows can target it. Done when the location shows as connected in Shuffle and the Orborus logs show polling without errors.
Install and version the apps for internal tools
Install the apps that connect to your SIEM, EDR and directory services. Shuffle apps run as versioned Docker containers, so pin each app to a specific version and record it in your change log. Confirm the host can pull those images from your approved registry, which may require egress rules from the previous step. Ask the app owner for the expected response fields from each internal system so the test can check them. Done when each app runs one action through the local runtime and returns the fields expected from the internal system.
Add least-privilege credentials for each integration
Create a dedicated service account or API key for each internal integration, limited to the read or response actions the workflows need. Enter the values into Shuffle's credential handling and keep them out of workflow notes, shared documents and chat channels. Assign each credential a named owner and a scheduled review. Test that each credential is refused when used for an action outside its scope, which confirms the permission boundary holds. Done when every credential has an owner, a documented scope, and out-of-scope calls are refused by the target system.
Run a test workflow through the local runtime
Build a small workflow that reads one non-sensitive record from an internal system, passes it through a transform step, and writes the result to a test ticket or log. Pin the workflow to the on-premises location so every action executes in the local runtime. Run it manually and confirm the job completes and the execution log shows the worker and app containers ran on the host. Then force a failure to confirm the error is recorded. Done when the workflow completes through the local runtime and the output matches the expected result.
What drives the effort and cost of a hybrid runtime
This table lists the factors that move effort and cost in a Shuffle hybrid deployment with an on-premises Orborus, with a way to keep each one under control. Use it to see which decisions in your scope matter most, then ask for effort figures in a written scope rather than relying on general estimates.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Internal tools needing network paths | Each tool such as a SIEM, EDR console or directory service needs a tested route from the on-premises Orborus, along with credentials, certificate trust and firewall review. | Start with the priority use cases, connect only the tools those workflows need, and group related tools behind shared service accounts with least-privilege access. |
| Runtime locations and environments | Each location or environment (for example production and test) needs its own Orborus setup, egress configuration and validation before workflows run there. | Limit locations to real separation needs, reuse one tested configuration across environments, and confirm with your network team whether test can share a network path. |
| Number of Orborus nodes | More nodes add hosts to build, patch and monitor, and they keep workflows running if one node fails, so the count reflects your availability requirement. | Agree on the redundancy level your processes require, then size nodes to that level and document the failover test. Confirm the node count with the Shuffle high availability guidance. |
| Change approvals for egress rules | Outbound rules from the private network usually pass through security and change boards, and each request can add review cycles before a workflow goes live. | Bundle rule requests by tool and destination, prepare the business justification and data flow in advance, and ask your change board which requests need formal approval. |
| Custom app development from OpenAPI or Python | Shuffle apps are built from OpenAPI specifications in the App Creator or written in Python with the app SDK, and each custom app needs design, testing, versioning and documentation. | Prefer existing apps where they fit, reuse one OpenAPI definition for several actions, and set a standard for testing and documentation before development starts. |
| App-run volume through the worker | Shuffle's licensing is measured in app runs, meaning actions that execute in a workflow, so volume affects licensing and worker capacity. Triggers and skipped actions are not counted. | Review which workflows run on schedules or high-volume triggers, remove redundant actions, and confirm how your licensing tier applies to your expected volume with Shuffle. |
| Compliance evidence requests | Auditors and internal assessors may ask for records of access paths, change approvals, secret handling and worker logs, which takes time to collect and explain. | Define the evidence list at the start of the project, keep change records and configuration in version control, and agree on the evidence format with your assessor before the request arrives. |
How the hybrid pattern changes for single, redundant and container-scheduled runtimes
A single Orborus host is the simplest hybrid layout. The host sits inside your private network, connects outbound to the Shuffle backend to pick up jobs, and starts a worker for each workflow execution. The worker then starts the app containers that call your internal tools. Because the hybrid model needs no inbound firewall ports, the network work is mainly an outbound review and a routing check to each target system.
- Network design: one outbound path to the backend, plus internal routes from the host to your SIEM, EDR and directory services.
- Failure handling: if the host or its Docker engine stops, no workflow runs at that location until it recovers, so the host is a single point of failure.
- Operations: one host to patch, monitor and restart, with one place to review container health and logs.
- Capacity: every worker and app container shares the CPU and memory of that machine, which limits how many executions can run at once.
- Change control: a configuration change or host reboot pauses all internal automations at that site.
Before choosing this layout, confirm with your team how long a pause in internal automations is acceptable, and check the configuration docs for the settings this host needs.
Running more than one Orborus node keeps workflows moving if one node fails. The Shuffle configuration documentation recommends multiple Orborus nodes for this purpose. Each node needs the same outbound path to the backend and the same internal routes, so the design work is mostly about placing nodes on separate hosts and confirming that each one can reach every system an app uses.
- Network design: duplicate the outbound and internal routes for every node, and check that no single firewall or switch carries all of them.
- Failure handling: a surviving node should take over new work. Confirm with Shuffle how jobs already in progress on a failed node are retried or reported.
- Operations: keep node configuration and Shuffle versions aligned, because a node that lags behind the backend can cause failures that are hard to trace.
- Capacity: plan each node to carry the full expected load during an outage, since it may need to absorb the work of a failed peer.
- Testing: stop one node during a test window and confirm that a scheduled workflow still completes.
Before choosing this layout, document which hosts run which nodes and who is alerted when one drops out.
Docker Swarm and Kubernetes change the runtime from fixed hosts to a scheduler. Shuffle documents distributed Docker Swarm and Kubernetes with Helm charts as deployment architectures. In both cases, Orborus runs as part of the cluster and launches worker and app containers through the orchestrator. The network and operations questions move from individual hosts to cluster networking, image distribution and scheduling policy.
- Network design: confirm that cluster networking reaches each internal system, and that nodes can reach the private registry that holds app images.
- Failure handling: a lost node causes its containers to be rescheduled. This depends on orchestrator behavior, so check the failure modes in the configuration documentation and test them.
- Operations: pin image tags deliberately. The Shuffle docs recommend the latest Docker tag for stable releases and the nightly tag only for experimental changes.
- Placement and concurrency: decide which nodes may run workers and apps, and set concurrency to match node capacity. Confirm the exact setting names in the configuration docs.
- Registry and caching: plan how app images are pulled, cached and versioned across nodes, so that a registry outage does not stop execution.
Before choosing this layout, confirm that your team already runs the orchestrator in production and can own its upgrades, backups and monitoring.
A fully self-hosted backend keeps the frontend, the Go backend API, OpenSearch and Orborus inside your environment, with no dependency on Shuffle Cloud. This matters for air-gapped networks and for sovereignty rules that restrict where security data and credentials may live. The design shifts from firewall exceptions to supply chain: images, apps and updates must reach the network through a path you control.
- Network design: plan image mirroring, app image sourcing and any update transfer across the boundary, since no outbound path to Shuffle Cloud is assumed.
- Failure handling: backend and OpenSearch availability become your responsibility. The Shuffle docs recommend an OpenSearch cluster for high availability.
- Secrets: the SHUFFLE_ENCRYPTION_MODIFIER value encrypts saved app credentials. Losing or changing it breaks all saved app authentications, so store it in a controlled vault with a tested recovery path.
- Identity: configure single sign-on with OpenID Connect or SAML against an identity provider you host, and confirm each provider works without internet access.
- Operations: document an offline upgrade procedure and test it in a non-production environment first.
Before choosing this layout, confirm with Shuffle which features depend on internet connectivity in your version, because that list determines how much you must rebuild locally.
Securing credentials, egress and the Docker host in a hybrid runtime
A hybrid runtime splits trust between Shuffle Cloud and an Orborus node inside your network. The controls below decide what that node can reach, which identities it uses, which images it runs and where secrets live. Review them together, because an overbroad key or an exposed host weakens the egress rules around it.
Outbound-only egress with allow-lists
Orborus connects out to Shuffle Cloud, so no inbound firewall ports need to open. Keep it that way by restricting outbound traffic from the host to the Shuffle endpoints it needs, plus the internal SIEM, EDR and directory services your apps call. Apps should reach only named destinations and ports. Ask your network team to confirm the full endpoint list against Shuffle's current documentation before writing the rules, since requirements can change between releases.
Least-privilege accounts for each integration
Create a separate service account or API key for each integration a workflow uses, scoped to the actions that playbook needs. A single shared administrator key for SIEM, EDR and directory lookups turns one compromised workflow into access to every connected system. Record which workflow owns each key, set expiry dates where the target system supports them, and review scopes whenever an app version changes the calls it makes.
Hardening the Docker host and Orborus container
Orborus starts worker and app containers through Docker, so the host is a privileged part of your automation. Limit who holds shell and Docker access, patch the host on a fixed schedule, and place it in a network segment that reaches only what the runtime needs. Confirm with your platform team how the Orborus container gets Docker access and whether a more restricted configuration fits your environment.
Image provenance for app containers
Apps run as versioned Docker containers, so the images you pull determine what code executes inside your network. Pin each app to a specific image version instead of relying on a moving tag. Pull from a registry you control or have scanned, record image digests, and keep copies of images your workflows depend on. Shuffle recommends the latest tag for stable releases and nightly for experimental changes, so production runtimes should follow a tested stable tag.
Where app credentials are held
Saved app authentications, meaning the keys and tokens workflows use to call other tools, are stored by the Shuffle platform. In a hybrid setup, establish which side holds them, whether Shuffle Cloud, the local runtime or both, and how they reach Orborus at execution time. Ask Shuffle to document this for your tenant in writing, and confirm how credentials are protected on the Shuffle Cloud side before you store production keys there.
Protecting the encryption secret for self-hosted storage
Where you run your own OpenSearch storage, Shuffle encrypts saved app credentials and API keys with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. Losing or changing this value breaks every saved app authentication, so keep it in a secrets manager, include it in your recovery procedure alongside OpenSearch backups, and document how it is rotated. This secret applies to self-hosted storage only, so confirm the Shuffle Cloud protection model separately.
How to test a Shuffle hybrid deployment before handover
A hybrid handover should prove three things before sign-off: the on-premises Orborus reaches the internal systems the playbooks depend on, workflows fail visibly when something breaks, and the network has no new inbound paths. Run the full set in a lab or staging tenant first, then repeat the functional subset in production using read-only actions. Write the expected result for every test in the test plan before running it, so the handover records observed results against a stated baseline. Record the Shuffle version, the Orborus image tag and each app version on both the cloud side and the Orborus host, so the results can be reproduced later.
Start with three functional tests that exercise the paths the playbooks will use. First, run a workflow that reads from the internal SIEM through an app authenticated with a read-only account, scoped to a known event set so the output can be checked by hand. Second, run a test action against the EDR in a lab tenant using a harmless read operation, such as listing hosts, so no endpoint is changed. Third, run a directory lookup for a known test account. For each test, the execution history should show the workflow run, each action with its status and output, and the worker started for that run. The Orborus host logs should show the job pickup and the app container start. Check returned data against the source system as well as the status, and confirm the app and credential used in the test plan.
Failure tests show whether the team will notice a broken runtime before an incident depends on it. Stop the Orborus host while a scheduled workflow is due, then start it again. Confirm in your version whether the run is held and completed after recovery or marked as failed in the execution history, and record which behavior you observed. Next, block one egress destination, such as the SIEM API, at the host firewall. The action should fail with a connection error that appears in the execution history and the app container logs, and the workflow should stop or follow its defined error path. Finally, revoke the credential at the source system. Expect an authentication error, check that the failure does not trigger a retry loop against the target, and confirm that your alerting receives it. Restore the block and the credential afterwards and log the time of each change.
Confirm that no inbound rules were opened. Before testing, record the firewall and security group rules for the network segment that hosts Orborus, along with the listening sockets on that host. After deployment, compare both snapshots and confirm that the new traffic is outbound from the Orborus host to the Shuffle backend and to the internal systems the apps call. Ask the network team to verify the same from their side, including any NAT or proxy rules that could permit return paths. Separately, identify where each trigger's webhook is hosted, because a trigger that must receive inbound traffic is its own exposure decision and should be approved and documented as one.
Record the evidence in the change record while the tests are still fresh. For each test, keep the test ID, the expected result, the observed result, the timestamp in UTC, the workflow and execution identifiers from the execution history, and the relevant log excerpt. Store the exported execution history and the firewall snapshots with the change ticket. Redact anything sensitive before filing. Keep the SHUFFLE_ENCRYPTION_MODIFIER value, API keys and passwords out of the evidence pack, and confirm the encryption secret is held in your secrets store with a tested backup, because losing or changing it breaks saved app authentications. Finish with a sign-off from the people who ran the tests and the owner who accepts the handover.
Running the hybrid runtime after go-live
This sequence keeps the on-premises Orborus runtime healthy, correctly metered and recoverable after go-live. Each step runs on a schedule the owning team sets, and each one leaves a dated record for the audit file. Ask the owning team to confirm the cadence for every item in writing before handover.
Monitor Orborus health and job backlog
Check that each Orborus node is connected to the Shuffle backend and picking up jobs, and watch the queue of pending workflow executions for signs that work is building up. Set alerts for node disconnects and for backlog growth, and confirm which team receives them and how they respond. Review the Orborus and container host logs after any alert. The step produces a monitoring record that lists the checks, the alert recipients and the most recent backlog review. It is done when a test alert reaches the named on-call group.
Track app-run volume against licensing
Shuffle prices on app runs, which are actions that execute in a workflow. Triggers and skipped actions are not counted, so base your tracking on that definition. Pull run counts from the Shuffle interface or your reporting tooling each month and compare them with the volume you planned or contracted. Record the method so anyone can reproduce the figure, and confirm with Shuffle how your edition enforces its limits, since limits are actively enforced from v2.1.1. The artifact is a monthly app-run log with method and totals. It is done when a sample you count by hand matches the logged figure.
Review egress rules and credential rotation
The hybrid model needs no inbound firewall ports, so review the outbound rules that allow Orborus to reach Shuffle Cloud and your internal SIEM, EDR and directory targets. Remove any rule that no named integration can justify. Rotate app credentials and API keys on the schedule your security policy sets, and keep each integration on its own least-privilege key. Confirm the current endpoint list with the Shuffle documentation before each review. The artifact is a review record with the exported rule set, the rotation log and the approver. It is done when every open rule maps to a named integration.
Align Orborus and app versions
Run the Orborus image tag that matches the Shuffle version your backend runs. The Shuffle docs recommend the latest Docker tag for stable releases and the nightly tag only for experimental changes. Versions older than v2.1.1 have not been supported since January 31, 2026, so plan any upgrade path before that gap grows. Test each app container version against the new release in a staging runtime before promoting it to production. The artifact is a version matrix listing the backend, Orborus and each app image tag, along with the staging test result. It is done when every tag matches and the staging workflows pass.
Back up configuration and runbook
Back up the Shuffle configuration, the Orborus runtime settings and the operations runbook, and store the copies apart from the running host. Keep the SHUFFLE_ENCRYPTION_MODIFIER value in a secrets vault with restricted access, because losing or changing it breaks every saved app authentication. Confirm with your team whether the OpenSearch snapshot process covers workflow data, and document it if it does not. Test a restore in a non-production environment. The artifact is a backup inventory with dates, storage locations, the custodian of the encryption value and the restore test record. It is done when a restored copy authenticates a saved app.
Document ownership of the on-premises host
Name the team that owns the host, including operating system patching, the Docker runtime, network placement and the service account that runs Orborus, and name a secondary contact for each. Record the escalation path to Shuffle support or DeployOpen, and state who can approve changes to egress rules and credentials. Review the record whenever staff or the host changes. The artifact is an ownership register signed by the service owner. It is done when the primary and secondary contacts each acknowledge their entries in writing.
Questions buyers ask before choosing a hybrid Shuffle runtime
Does a hybrid Shuffle runtime need inbound firewall ports?
No. Shuffle's architecture documentation describes the hybrid model, with Shuffle Cloud and a local Orborus, as needing no inbound firewall ports, because Orborus polls the backend for jobs and starts workers locally. Confirm the egress side before you commit. The Orborus host must be able to make outbound connections to the Shuffle backend endpoint, and proxies, egress filters or TLS inspection can break that path. Ask your security team to test the destination and protocol in a non-production segment, document the rule, and confirm with Shuffle how the version you plan to run behaves in an environment like yours.
How does implementation effort grow with integrations and runtime locations?
Effort grows with the number of integrations and the number of network segments that hold them. Each integration needs an app or configuration, a scoped service account, credential handling, and tests against the real system. Each runtime location adds a host build, Orborus setup, image access, a reachability test to every internal service it must reach, and a change request to the owning network team. An illustrative case: a SIEM and an EDR console in one segment usually take less coordination than the same two tools in three segments with separate firewall owners. Ask any partner to break the quote down by integration and by location.
What do our network and security teams need to provide for a hybrid runtime?
Plan for network, identity and change control work from your own teams. Network teams confirm the egress path, DNS resolution, proxy settings and any TLS inspection rules for the Orborus hosts, and they approve internal routes to each SIEM, EDR and directory service. Security teams approve the least-privilege accounts and API keys for each integration, set the rules for storing the SHUFFLE_ENCRYPTION_MODIFIER secret, and review logging. Platform teams provide the container hosts, storage and patch windows. Agree these owners and change windows in writing before the schedule is fixed, because approval lead times often set the pace more than the build does.
Can our own engineers run a hybrid Shuffle runtime after go-live?
Often yes, if the team already runs containers in production. Day-to-day operation needs people who can patch Orborus and the other Shuffle images to matching versions, watch worker health, rotate integration credentials, and restore OpenSearch from backup. Recurring work includes upgrades, app updates after each upgrade, and reviews of firewall and proxy rules. Resilience also needs more than one Orborus node, which doubles the operational surface. Before you decide, check your team against that list and against the skills needed to troubleshoot egress failures. If gaps exist, a support package or retainer can cover them, and the scope of that cover should be written down.
How does app-run licensing apply when runtimes sit on-premises?
Shuffle's pricing article says licensing uses one metric, app runs, which counts actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. The same article describes this metric without tying it to where a runtime is placed, so the cost driver is execution volume, not the number of locations. Ask Shuffle to confirm in writing whether any limit in your tier depends on runtime location, and how retries, loops and failed executions are counted. To size the metric, count planned executions per workflow from your inventory, and ask your partner to show those assumptions in the quote.
What does a fixed-scope hybrid engagement deliver?
A fixed-scope engagement delivers the items named in the written scope, agreed before work starts. Typical items include an architecture decision for each runtime location, Orborus deployment on agreed hosts, egress and reachability validation for each integration, credential handling set-up, a test plan with recorded results, a runbook, and handover with knowledge transfer to your engineers. Work outside the scope needs a written change. Ask for the exact list of hosts, integrations, locations and test cases, the acceptance criteria, and what is excluded. A quote follows from that written scope, so compare proposals on the same list of items.
Which Shuffle version and image tags should a hybrid runtime use?
Shuffle's docs recommend the latest Docker tag for stable releases and the nightly tag only for experimental changes. Keep the backend, frontend and Orborus images on matching versions, because a mismatch between the server and runtime can break job handling. Shuffle stopped supporting versions older than v2.1.1 after January 31, 2026, so any older deployment should be upgraded before a hybrid rollout. Pin the tags you test, record them in your change record, and re-test after each upgrade. Confirm the current release and any compatibility notes on the official GitHub releases page before you fix the image list.
What usually breaks in a hybrid Shuffle deployment after launch?
The most common failures come from the network path and the credentials, not from the workflows themselves. Look for proxy or firewall changes that cut the Orborus connection, TLS inspection that breaks certificate trust, DNS changes that move internal service names, and expired or rotated integration credentials. Version drift between the backend and Orborus causes job failures that look like app errors. A single Orborus node that stops leaves workflows waiting, which is why the docs recommend more than one. Losing or changing the encryption modifier breaks every saved app authentication. Monitor worker health, test egress after each network change, and keep the secret and a tested restore procedure under controlled custody.
How DeployOpen works on this
DeployOpen plans and builds Shuffle hybrid deployments with on-premises Orborus inside the client's own network, so workflows can reach internal SIEM, EDR and directory services. Each engagement starts from a written, fixed scope that names the runtime locations, integrations and workflows covered. Work is documented and handed over to the client's team, and ongoing support is available as a retainer.
How we scope
- The written scope lists which runtime locations, such as on-premises networks, are in and out of the engagement.
- Each target SIEM, EDR and directory service is named with its owner, access path and required app actions.
- App-run volume and the hosting model, Shuffle Cloud with local Orborus or fully self-hosted, are confirmed before work starts.
How we build
- Orborus is installed on the internal host, polls the backend for jobs and starts a worker for each execution.
- Outbound-only connectivity is tested first, confirming no inbound firewall ports are opened on the private network.
- Apps are built or configured as versioned Docker containers and tested against each internal service before go-live.
How we hand over
- The SHUFFLE_ENCRYPTION_MODIFIER secret is recorded in the client's secrets store, since losing or changing it breaks saved app authentications.
- Handover documents list each runtime location, Orborus node, workflow owner and the app versions in production.
- Runbooks cover restarting an Orborus node and checking that a test workflow still executes after the restart.
How we support
- Ongoing support, upgrades and updates to apps after a Shuffle upgrade are available as a retainer.
- Orborus image tags follow the same release line as the backend and frontend, so versions stay aligned.
- Retainer scope names the runtime locations, Orborus nodes and integrations that the support covers.
