When Shuffle Cloud or self-hosted Shuffle fits your SOC
Shuffle Cloud fits a team that wants SOAR running quickly and does not want to own container operations. It suits small or fast-start SOC teams, and it suits organizations whose data can live in a Google Cloud region the vendor lists: europe-west2 (London) is the default, and customers can be placed in europe-west3 (Frankfurt), us-west2 (California), na-northeast1 (Quebec) or australia-southeast1 (Sydney), according to Shuffle's privacy policy. The trade-off is that new features reach shuffler.io first and arrive in on-premises releases only after on-premises scale testing, per Shuffle's open source article. Confirm with Shuffle, in writing, which region your tenant lands in and how data is handled in transit and at rest before you rely on it for regulated alerts.
Self-hosting fits when residency, connectivity or change control rules out a listed region or a hosted control plane. Examples include a requirement to keep case data in a country outside those regions, an air-gapped network, or a policy that every upgrade is approved internally before it reaches production. Shuffle's architecture docs state the platform does not require internet access to run, and they describe Docker Compose, Docker Swarm and Kubernetes with Helm charts as deployment options. You take on the Docker or Kubernetes work, the OpenSearch backend, upgrades and backups, so make sure your platform team has that capacity before committing.
The hybrid model is the middle path. Shuffle Cloud hosts the control plane while an Orborus runner sits in your private VPC or data center, and the architecture docs say it needs no inbound firewall ports. Execution then stays in your network, though the control plane does not. Ask Shuffle to confirm exactly which data passes through the cloud control plane, since that determines whether hybrid meets your residency rule. Also confirm what the paid licenses add for hybrid, because Shuffle's pricing and configuration docs describe enforced limits that differ between the open-source and enterprise editions.
How Shuffle Cloud and self-hosted Shuffle compare on the factors that matter
This table compares Shuffle Cloud at shuffler.io with self-hosting Shuffle across hosting, region, feature timing, deployment, sign-in, licensing and operating work. Read each row as a question to answer for your own environment, and confirm the rows marked for vendor confirmation before you commit to either model.
| Factor | Shuffle Cloud | Self-hosted Shuffle |
|---|---|---|
| Who runs the platform | Shuffle operates a multi-tenant SaaS on Google Cloud Platform, so your team does not run servers or upgrades. | Your team runs the platform in its own infrastructure and owns patching, backups, scaling and upgrades. |
| Default region and data location | europe-west2 (London) is the default. Customers can be moved to europe-west3 (Frankfurt), us-west2 (California), na-northeast1 (Quebec) or australia-southeast1 (Sydney). | Data stays wherever you deploy it, such as your own cloud account, data center or private network. Confirm residency with your own controls. |
| Feature timing | New features reach shuffler.io first, according to Shuffle's open source article. | New features reach on-premises releases after on-premises scale testing, so expect a lag before the same functions are available. |
| Single server or Docker Compose | Not applicable. Shuffle manages the control plane. | Supported as a single server with Docker Compose, the simplest self-hosted option. |
| Docker Swarm or Kubernetes | Not applicable. Shuffle manages the infrastructure behind the platform. | Distributed Docker Swarm and Kubernetes with Helm charts are documented. Your team operates the cluster and its scaling. |
| Hybrid Orborus runner | The control plane runs in Shuffle Cloud while an Orborus runner sits in your private VPC or data center, with no inbound firewall ports required. | Orborus can run on your own infrastructure as part of a full self-hosted setup. Confirm the networking model for your environment with Shuffle. |
| Internet requirement | Requires access to Shuffle Cloud for the control plane. | The docs state Shuffle does not require internet access to work. Confirm this for your app and update workflow before relying on it in an isolated network. |
| Single sign-on | SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect. Per-tenant SSO enforcement is available. | SAML and OpenID Connect are both available on-premises. Confirm the supported SSO set for your version with Shuffle. |
| Software license | Shuffle code is licensed under AGPL-3.0. Workflows and modular app content are MIT, per the repository. | Same code license and MIT content terms apply to the code you run yourself. Confirm your obligations under AGPL-3.0 with counsel. |
| Pricing metric | Licensing is based on app runs, meaning actions that execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. | The same app-run metric applies to paid tiers. Confirm which limits are enforced in your self-hosted edition, since limits are enforced from v2.1.1. |
| Operating work | Shuffle handles hosting, availability and platform upgrades. Your team still manages app credentials, workflows and integrations. | Your team owns the server, OpenSearch, backups, the encryption secret and high availability, including several Orborus nodes. Plan for this in staffing. |
Where your data sits and who controls access in each model
Shuffle Cloud and a self-hosted Shuffle install put your data in different places and under different controls. The cards below cover where cloud data lives, what you can change, which encryption secret you own in a self-hosted deployment, and the compliance evidence that stays with your team in either model.
Default cloud region is London
Shuffle's privacy policy names Google Cloud Platform with europe-west2 (London) as the default region for Shuffle Cloud. Before you sign up, confirm which region your tenant will use, whether the region can be chosen at onboarding, and where backups, logs and OpenSearch data are held. If your data protection rules name a specific country or region, put that question in writing before any workflow carries real case data.
Alternative cloud regions
The privacy policy says customers can be moved to europe-west3 (Frankfurt), us-west2 (California), na-northeast1 (Quebec) or australia-southeast1 (Sydney). A move between regions is a provider-side change, so ask Shuffle how a move is requested, how long it takes, whether data is copied or deleted in the old region, and who approves it. Treat any move as a data transfer that your records of processing should reflect.
Multi-tenant residency statement
Shuffle's getting started docs describe Shuffle Cloud as a multi-tenant SaaS with data residency in a region near the customer. Multi-tenant means your workflows, execution records and saved credentials share a platform with other customers, separated by tenant boundaries rather than dedicated hosts. Ask Shuffle to describe that tenant isolation in writing and to confirm whether any dedicated tenancy option exists.
Self-hosted location and key control
A self-hosted Shuffle keeps data in the cloud account, data center or network you choose. Saved app credentials and API keys are encrypted with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. Generate it once, store it in your secrets manager, and back it up with the database, because the configuration docs warn that losing or changing it breaks every saved app authentication.
Compliance evidence your team produces
In either model, your team must collect evidence for its own controls: access reviews, change records, data flow diagrams and retention settings. In a self-hosted install, all of this is yours to generate. DeployOpen can plan, document and prepare these controls and evidence, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.
Confirm Shuffle's provider assurance reports
For Shuffle Cloud, the Google Cloud infrastructure underneath is covered by the provider's own assurance material, but what Shuffle itself has been independently assessed for is a separate question. Request Shuffle's current assurance reports and scope statements directly from the vendor, check their dates and the systems they cover, and confirm whether they apply to the London region. Do not assume a provider report covers the application layer.
Why new features reach shuffler.io before on-premises releases
New features come to shuffler.io first and reach on-premises releases only after on-premises scale testing. For a self-hosting team, that means a feature you want will arrive later than it does on Shuffle Cloud, but it arrives in a version you choose and pin. You decide when to pull a new Docker tag, and the Shuffle docs recommend the latest tag for stable releases and the nightly tag only for experimental changes. Before you upgrade, confirm which tag your environment uses, test the release against your own apps and credentials, and check the Shuffle GitHub releases page for the version notes that match it. For a cloud team, the trade-off runs the other way. You get earlier access to new capabilities, but Shuffle sets the timing of each change to the shared cloud service, and you have less say over when it lands in your tenant. If a workflow depends on a behavior that might change, ask the vendor how cloud changes are announced, whether any are scheduled into a maintenance window, and how you would test against a change before it reaches production. The hybrid model with a local Orborus runner does not change this, because the control plane stays in Shuffle Cloud. Shuffle states that all features are available in the open-source edition, and that its paid tiers differ in feature limits, scaling and support. Since v2.1.1, those limits are actively enforced. Self-hosters should therefore confirm which limits apply to their deployment, such as app runs, tenants and high availability, before they plan a rollout that depends on them. Ask Shuffle to confirm current enforcement for your license tier, because a feature being present in the open-source edition does not mean its scale limits are absent.
Which self-hosted architecture a team takes on with the Docker or Kubernetes work
The single server option runs Shuffle with Docker Compose on one host. The server side includes the frontend, the Go backend API on port 5001 and an OpenSearch document database, and Orborus starts a worker for each workflow execution, which in turn starts app containers. This is the simplest self-hosted footprint, and the operating work sits with one machine that your team patches, backs up and monitors.
- Servers: one host carries the frontend, backend, OpenSearch and runtime, so a host failure stops every workflow.
- OpenSearch: you own its sizing, snapshots and upgrades alongside Shuffle.
- Credentials: back up
SHUFFLE_ENCRYPTION_MODIFIERwith the stack, because changing it breaks saved app authentications. - Upgrades: you choose the image tag yourself, with the docs recommending the latest Docker tag for stable releases.
- Scaling: capacity grows only by resizing the host, not by adding nodes.
A single server suits a small team with a modest number of executions and a tolerance for planned downtime. Consider cloud or hybrid once you need workflows to survive a host failure, or when nobody on the team wants to operate OpenSearch.
Distributed Docker Swarm spreads the Shuffle services across several hosts. The Shuffle configuration docs recommend an OpenSearch cluster, scaling the backend and frontend across all servers, NFS for shared files when several backends run, optional Memcached for a shared cache, and more than one Orborus node so workflows keep running if one fails. The operating work moves from patching one machine to keeping a cluster healthy.
- OpenSearch cluster: you size, secure and upgrade a multi-node cluster rather than a single container.
- NFS: you run and back up the shared file store that several backends depend on.
- Memcached: optional, but adds one more service to monitor if you enable it for a shared cache.
- Orborus nodes: you place at least two runners so executions continue when one fails, and you own their network paths to app containers.
- Network and storage: Swarm needs the ports and permissions you verify in the sibling deployment comparison before you commit.
Swarm fits a team that needs redundancy across hosts but wants to stay within Docker tooling. Ask whether your platform team already runs Swarm, because an unfamiliar orchestrator adds more work than the cluster itself. The sibling deployment comparison covers the ports and permissions in detail.
Kubernetes deploys Shuffle with the official Helm chart. The cluster takes over scheduling, restarts and rolling changes, but your team now operates the cluster, the storage classes, the ingress and the OpenSearch deployment. Scaling is described as static in the sibling deployment comparison, so capacity changes are planned rather than automatic.
- Cluster ownership: you keep the Kubernetes control plane, node pools and upgrades on your own schedule.
- OpenSearch: persistent volumes, snapshots and version compatibility stay with your team.
- Orborus and workers: you decide where runners sit relative to the systems they act on, and you monitor their health.
- Scaling: confirm which scaling features need a paid Shuffle license before you design for them.
- Secrets: store the encryption modifier and app credentials in your cluster secret management, not in chart values committed to source control.
Kubernetes suits an organization that already runs clusters, has platform engineers on call, and wants Shuffle managed alongside other workloads. Without that base, the cluster is the largest cost in the project. Ask your team to name who patches the cluster and who restores OpenSearch before you choose this path.
The hybrid model keeps the control plane in Shuffle Cloud while you deploy the Orborus runner in a private VPC or on-premises data center. Shuffle documents that no inbound firewall ports are required for this runner. Your team still operates the runner, but the frontend, backend and OpenSearch become the vendor's responsibility under the cloud service terms.
- Runner only: you operate the Orborus host or nodes, including their patching and outbound connectivity.
- No inbound ports: the architecture docs describe the runner as reaching out, which simplifies perimeter review.
- Data location: confirm what execution data leaves your network and which Google Cloud region holds the control plane, which the privacy policy lists with London as the default.
- Cloud features: new features reach shuffler.io first, so check the release timing your use case depends on.
- Exit path: plan how you would move the control plane in-house if policy later requires it.
Hybrid suits a team that needs executions to stay close to internal systems but does not want to run OpenSearch or the control plane. Confirm the data residency and audit requirements of your regulator with Shuffle and your compliance lead before you rely on it.
What your team runs in each hosting model
This table lists the recurring tasks a team owns under Shuffle Cloud, under the hybrid model with a local Orborus runner, and under a fully self-hosted deployment. Read each row as a question: if the task sits with the vendor in one column, the team's staff time moves to the next column. Confirm the exact responsibility split with Shuffle in writing before you commit.
| Ongoing task | Shuffle Cloud | Hybrid (Cloud with local Orborus) | Self-hosted Shuffle |
|---|---|---|---|
| Patching and upgrades | Handled on the Shuffle Cloud side; confirm the update window with Shuffle | Control plane handled by Shuffle; team patches and upgrades the local Orborus runner | Team applies every release, choosing the latest tag for stable or nightly for experimental |
| Upgrade timing | Set by Shuffle; new features reach shuffler.io first | Runner upgrades follow the team's own schedule; confirm version compatibility with Shuffle | Set by the team; latest tag for stable releases, nightly for experimental changes |
| Backend and frontend scaling | Handled by Shuffle | Not applicable to the control plane; team sizes the Orborus host | Team scales the backend and frontend across all servers under Docker Compose, Swarm or Helm |
| OpenSearch cluster care | Handled by Shuffle | Handled by Shuffle | Team runs the OpenSearch cluster, including capacity, snapshots and version updates |
| Orborus node management | Not applicable; no local runner | Team runs at least one local Orborus node and, for high availability, more than one | Team runs one or more Orborus nodes and sizes them for execution volume |
| Backups | Confirm backup scope and restore testing with Shuffle | Team backs up the local runner configuration; confirm what Shuffle retains for the cloud side | Team backs up OpenSearch and configuration, and NFS shared files when running several backends |
| Encryption secret custody | Shuffle manages the platform secrets; confirm key handling in writing | Team protects its local runner secrets; cloud-side secrets stay with Shuffle | Team stores SHUFFLE_ENCRYPTION_MODIFIER; losing or changing it breaks all saved app authentications |
| SSO configuration | Set up per tenant with Shuffle; SAML is being deprecated in favor of OpenID Connect | Configured per tenant on the cloud side with Shuffle | Team configures SAML or OpenID Connect on its own instance, with per-tenant enforcement |
| Monitoring of the platform | Vendor-side monitoring; confirm what status and alerting the customer receives | Team monitors the local Orborus host and its connectivity to the cloud | Team monitors containers, OpenSearch health, backend availability and worker execution |
| Incident response on the platform | Shuffle responds to platform incidents; agree notification terms in writing | Shared: Shuffle handles the control plane, the team handles the local runner and its network | Team owns response end to end, including containment, recovery and evidence |
What you pay for in each model and what drives the total
Shuffle Cloud and self-hosted Shuffle are priced differently at the licensing layer, but the paid license is the same metric in both. Shuffle's pricing article measures licensing by app runs, meaning actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. So the variable that moves the license bill is how many actions your playbooks execute, not how many analysts or integrations you have. Shuffle's open-source edition includes all features, and the paid tiers differ in feature limits, scaling and support. Ask Shuffle to confirm in writing which limits apply to your chosen edition, how app runs are counted for your workflows, and whether a self-hosted deployment is priced the same way as Shuffle Cloud.
Self-hosting removes the subscription to Shuffle Cloud's hosting but adds infrastructure and staff time that you pay for directly. Your costs include the servers or Kubernetes capacity for the OpenSearch cluster, the backend, the frontend and the Orborus nodes you need for high availability, along with backups and the time to patch Docker or Helm releases. Shuffle does not publish a self-hosting cost in the material we rely on, so you should estimate these components with your own platform team. Key drivers are the number of Orborus nodes, the size of OpenSearch and how often you upgrade. The hybrid model shifts some of this: Shuffle Cloud runs the control plane, and your local Orborus runs in your VPC or data center.
If you use DeployOpen, the labor for scoping, installing, hardening and documenting the deployment is a separate, one-time engagement that we price from a written scope. We do not publish a price list, so the quote depends on which architecture you choose, how many environments you run, and whether you want ongoing upgrades or support as a retainer. Ask for the quote to separate one-time implementation from recurring retainer fees, and to state what your side must provide. Plan for ongoing costs in every model: a Shuffle Cloud subscription recurs with your app run volume, while self-hosting recurs through infrastructure, staff time and any retainer.
Moving between Shuffle Cloud and self-hosted Shuffle
This sequence moves a Shuffle deployment from one hosting model to the other while keeping saved app authentications, SSO and workflow logic intact. The supplied documentation does not describe a migration tool, so each step ends with a check you can confirm before you cut over.
Confirm the target region or hosting model
Decide whether the destination is Shuffle Cloud or a self-hosted deployment, and for Shuffle Cloud, which region you need. Shuffle's privacy policy lists europe-west2 (London) as the default Google Cloud region, with europe-west3 (Frankfurt), us-west2 (California), na-northeast1 (Quebec) and australia-southeast1 (Sydney) as options. Ask Shuffle to confirm in writing which region your tenant will be placed in and whether a move between regions is supported. The step is done when the region, the hosting model and any Cloud Hybrid runner location are recorded in your change record and approved by data protection and security owners.
Export workflows and app configurations
Ask Shuffle which export path exists for workflows, app configurations and tenant settings in your current environment, since the supplied facts do not describe a migration tool. Export workflows to version control or files where the platform allows it, and list every app, its version and the workflows that depend on it. Record which workflows use Orborus runners, webhooks or schedules, because those trigger points must be re-created on the destination. The step is done when you have an inventory that a second person can match against the destination tenant.
Plan the encryption secret transfer
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. The configuration docs warn that losing or changing this value breaks all saved app authentications. For a move to self-hosting, your team owns this secret and must store it in your secrets manager before any data is loaded. For a move to Shuffle Cloud, confirm with Shuffle how credentials are handled during the transfer. The step is done when the secret is stored, access is restricted, and a test decryption of one saved credential succeeds on the destination.
Re-create or re-authenticate apps
Install the same app versions on the destination and re-enter or re-authenticate each saved credential, starting with apps that touch production systems. Shuffle apps are built from OpenAPI specifications or written with the Shuffle app SDK and run as versioned Docker containers, so pin versions to match the source. Where credentials cannot be carried over, expect to re-issue API keys in the source systems. The step is done when every app in the inventory returns a successful authentication test on the destination.
Move SSO configuration and note SAML deprecation
Recreate single sign-on on the destination. Shuffle added SAML in version 0.9.16 and OpenID Connect in 1.0.0, with per-tenant SSO enforcement. SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect, so if your current setup uses SAML, plan to move to OpenID Connect rather than copy the SAML configuration as-is. Confirm with Shuffle the status of SAML on the destination model. Test sign-in with a named administrator and a standard user, and confirm enforcement settings. The step is done when both test accounts sign in through the intended identity provider and no local fallback path is left open unintentionally.
Validate runs in a test tenant
Run the migrated workflows in a test tenant or on a non-production copy before any live trigger is enabled. Compare outputs with the source for a set of representative alerts, including failure paths and at least one app that calls an external system. On a self-hosted target, confirm Orborus is running and able to execute workers, and that the backend and OpenSearch respond as expected. Illustrative example: a phishing enrichment workflow should produce the same case fields on both sides before it is switched on. The step is done when the test results are signed off by the workflow owner.
Cut over and retire the source
Switch triggers, webhooks and schedules to the destination in a planned window, and disable the matching triggers on the source so that alerts are not processed twice. Keep the source readable for a period agreed with Shuffle and your own change board, in case a workflow needs to be checked against old results. Once every workflow has run successfully on the destination, remove copies of the old secrets and credentials according to your retention policy. The step is done when the source shows no active triggers, the destination is handling live executions, and the change record is closed.
Questions buyers ask before choosing a hosting model
Is Shuffle Cloud the right first step before self-hosting?
For many teams, yes. Shuffle Cloud is a multi-tenant SaaS with data residency in a region near the customer, so you can begin building workflows without standing up servers. The Shuffle open source article recommends Shuffle Cloud for teams unsure about setting up Shuffle themselves, and that is a sound test to apply. The drivers are whether your data may leave your environment, how much control over upgrades and networking you need, and whether you have people to operate the stack. If you start in the cloud, confirm which features are available there first, because the open source article states that new features reach shuffler.io first and reach on-premises releases after on-premises scale testing.
What does self-hosting Shuffle require from our staff?
Self-hosting moves operating work onto your team. The architecture docs describe three self-hosted options: a single server with Docker Compose, distributed Docker Swarm, and Kubernetes with Helm charts. Each needs people who can run container platforms, manage the OpenSearch data store, back up secrets and rotate them carefully, and upgrade versions. The configuration docs warn that losing or changing the SHUFFLE_ENCRYPTION_MODIFIER secret breaks all saved app authentications, so key handling is an operating duty, not a one-time setup step. Ask your engineers which of these skills they already hold before choosing a model.
How long does a self-hosted Shuffle build take?
No duration has been established for your environment, so confirm it rather than plan on a number. The time depends on the deployment option you pick, the size of your OpenSearch cluster, how many Orborus nodes you run, your network approvals, your identity provider setup for SSO, and how many app integrations you need to build or validate. A single-server Docker Compose trial is generally quicker than a multi-node high availability build. Ask any implementation partner, including DeployOpen, for a written scope with deliverables and a timeline before work starts, because most engagements are fixed-scope and agreed in writing.
Can a small team run self-hosted Shuffle on its own?
A small team can run a single-server test or a modest deployment alone if it already operates Docker and has an on-call route for incidents. Production high availability is harder. The configuration docs recommend an OpenSearch cluster, optional Memcached for a shared cache, NFS for shared files across several backends, scaled backend and frontend services, and more than one Orborus node so workflows keep running if one fails. Each of those components needs monitoring and patching. If your team cannot cover that, a retainer for ongoing support and upgrades is one option to compare against the cloud service.
What changes if our data must stay in one country?
Shuffle Cloud residency is set by region, and the privacy policy names europe-west2 (London) as the default, with customers able to be moved to europe-west3 (Frankfurt), us-west2 (California), na-northeast1 (Quebec) or australia-southeast1 (Sydney). If your rule requires a country that is not on that list, or requires that case data never leave your own infrastructure, self-hosting is the path to evaluate. Confirm with Shuffle which region fits your legal basis, and document where OpenSearch data, backups and Orborus workers run in a self-hosted design, since those locations become your responsibility.
How does a hybrid Orborus runner reduce inbound exposure?
The hybrid model keeps the control plane in Shuffle Cloud and places the Orborus runner inside your private VPC or on-premises data center. The architecture docs state that no inbound firewall ports are required, because Orborus polls the backend for jobs rather than accepting connections from outside. Workflow executions and the app containers they start therefore run on your side, close to the systems they touch. The reduction is in inbound exposure, not total exposure: outbound paths, credentials stored in the platform, and the security of the runner host still need review. Confirm the outbound endpoints and firewall rules with Shuffle and your network team.
How do we move from Shuffle Cloud to self-hosting later, or the reverse?
Plan the move around three items: workflows, app credentials and execution history. Workflows and apps are defined in Shuffle and can be exported, but saved app credentials are encrypted in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, so the same key must be available to the new environment or every saved authentication must be re-entered. Hybrid mode offers a staged route, since you can keep the cloud control plane while moving runners first. Before committing, ask Shuffle to confirm the export and import steps, the supported version match between environments, and how long a cutover would need, since no duration has been supplied for this.
How DeployOpen scopes, delivers and supports self-hosted Shuffle
DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For Shuffle, that means starting from your data residency, identity and runner requirements, then deciding with you whether the control plane stays in Shuffle Cloud or moves fully into your environment.
How we scope
- Written scope fixes the Shuffle deployment model, whether single server, Docker Swarm, Kubernetes or a hybrid Orborus runner.
- We record which data residency, network boundary and identity provider requirements the deployment must meet before work starts.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any build begins.
How we build
- We install and configure the Shuffle backend, frontend, OpenSearch store and Orborus runners inside your chosen infrastructure.
- Single sign-on is configured against your identity provider, and app credentials are handled under your encryption key management process.
- Apps, workflows and integrations are tested in a non-production environment before they are promoted to production.
How we hand over
- Deliverables include documentation of the architecture, network paths, ports, configuration keys and runner placement for your team.
- Backup and restore procedures cover OpenSearch data and the encryption secret, so saved app authentications survive a recovery.
- Your operators receive a walkthrough of upgrade steps, so future Shuffle releases can be tested against your own environment first.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Upgrade work follows the Shuffle release channel you choose, with changes tested before they reach your production runners.
- Ask any provider to confirm in writing which Shuffle features need a paid license in your edition before the scope is signed.
