Tines vs Shuffle: when each one fits
If your renewal is coming up, your Free edition has hit its three live workflow ceiling, or a data residency rule says security data cannot leave your environment, the deciding question is who will operate the platform. Tines is the better fit when your team wants a managed, no-code product and can accept hosting decisions made on Tines' side, with flexible deployment available on request. Shuffle fits when you need the platform inside your own infrastructure and have people to run it.
The decision turns on three things. First, who operates the platform: Shuffle's architecture docs describe a single server with Docker Compose, Docker Swarm, a hybrid with Shuffle Cloud and a local Orborus, or Kubernetes with Helm charts, and its configuration docs recommend an OpenSearch cluster, shared storage and several Orborus nodes for high availability. Someone must own upgrades, backups and the SHUFFLE_ENCRYPTION_MODIFIER secret, because losing or changing it breaks every saved app authentication. Second, where security data may live: confirm with Tines whether a self-hosted or private deployment meets your residency rules, and map Shuffle's data flows, including app containers that call external tools.
Third, how many live workflows and app runs you expect. Tines Free allows 3 live workflows, while Shuffle's pricing article says its licensing is metered on app runs, meaning actions that execute in a workflow, with users, apps and workflows unlimited. Estimate your app run volume from your current workflows before comparing quotes, and ask Tines what its paid editions cost for your workflow count and whether flexible hosting is included. Also confirm which Shuffle features differ between its open-source and enterprise editions, since its documentation says those limits are enforced since v2.1.1. Build a short proof of concept with two of your busiest workflows on each platform before you commit.
Which option fits which scenario
This table maps common team situations to the option that usually fits better and the facts behind that choice. Read each row against your own environment, since several answers depend on hosting rules, staffing and the number of live workflows you need. Treat the table as a starting point for your evaluation, not a verdict.
| Team situation | Better fit | Reason and what to confirm |
|---|---|---|
| Small team that can stay within the Tines Free edition | Tines Free | Tines Free includes unlimited users, spaces and connectors but only 3 live workflows. If your live automations fit under that cap, you avoid running any infrastructure. Confirm your live workflow count. |
| Team that must keep security data inside its own network | Shuffle (self-hosted) | Shuffle runs as a single server with Docker Compose, a distributed Docker Swarm, or Kubernetes with Helm charts. Confirm whether your rules allow the hybrid model, where Shuffle Cloud holds the UI and a local Orborus runs your jobs. |
| Team with no spare platform staff | Tines (hosted) | Self-hosting Shuffle means you run the backend, OpenSearch, Orborus and app containers, plus upgrades and backups. Hosted Tines removes that operating work. Ask Tines whether flexible hosting is available on your terms. |
| Team with many internal APIs to connect | Shuffle (self-hosted) | Shuffle's App Creator builds apps from OpenAPI specifications, and apps run as versioned Docker containers that you can review. Confirm that your internal API specifications are current and complete before you start. |
| Team that needs a commercial support contract for the platform | Tines (hosted or paid edition) | Shuffle says its paid tiers differ in feature limits, scaling and support. Ask Shuffle for the support terms of each tier and compare them with the Tines paid editions in writing. |
| Team running high availability across several sites | Depends on your environment | Shuffle's documentation recommends an OpenSearch cluster, shared NFS storage and more than one Orborus node. Your team must size and operate that layout, so confirm the staffing and hardware you can commit. |
| Team with a long-term need to avoid license-based limits on workflows | Shuffle (self-hosted) | Shuffle licensing is metered on app runs, and users, apps and workflows are unlimited. Confirm current enterprise limits with Shuffle, since its limits are enforced between editions. |
Where the data lives and who controls the platform
Tines and Shuffle differ most on where workflows, cases and execution data sit and who operates the platform underneath them. Each card below covers one decision point, with the checks a compliance or security team should complete before choosing a hosting model.
Tines hosting options
Tines is sold as a cloud service and, according to its pricing FAQ, flexible hosting options are available on request. The Free edition is cloud-based by default. Ask Tines in writing which deployment models a specific paid edition covers, where the control plane runs, and which region hosts your tenant. Confirm whether any self-hosted option needs outbound internet access from the host, since that affects segmented networks.
Shuffle hosting choices
Shuffle offers a hosted service at shuffler.io and self-hosting with Docker or Kubernetes. Its architecture also allows a hybrid model, where Shuffle Cloud runs the management layer and a local Orborus node runs workflow executions inside your network without inbound firewall ports. Decide which components must stay in your boundary before you choose, because the hybrid model splits data flow across two environments.
Where case and execution data is stored
In a self-hosted Shuffle deployment, workflow data, execution records and saved app credentials sit in the OpenSearch document database that you operate. Credentials are encrypted with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, and losing that secret breaks every saved app authentication. For Tines, ask where stories, cases, event history and credentials are stored in each hosting model, and how long event history is retained by default.
Single sign-on in Shuffle
Shuffle added SAML single sign-on in version 0.9.16 and OpenID Connect in 1.0.0, both available on-premises and in the cloud, with per-tenant SSO enforcement. SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect, so a new Shuffle Cloud tenant should plan for OpenID Connect from the start. Confirm which identity provider you will federate with and whether your access review process can cover Shuffle roles.
Who operates and patches the platform
With self-hosting, your team or an implementation partner handles upgrades, backups, scaling and the OpenSearch cluster, and the high availability guidance expects several backends and multiple Orborus nodes. With a vendor-hosted option, the operator is the vendor, so your review focuses on their change management, incident notification and support terms. Ask each vendor who patches the platform, how fast security fixes ship, and what you are responsible for under the shared responsibility model.
What compliance teams must confirm
Neither option comes with a certification from this page, and any attestation you need must come from the vendor's independent auditor or your own assessment. For each option, request the vendor's current security documentation, data processing terms, subprocessor list and data residency statement. For self-hosted Shuffle, your own assessor must review the host, network, backup and key management controls, since those are in your boundary and not the vendor's.
How Tines and Shuffle compare on capabilities
This table compares Tines and Shuffle on licensing, free tier, hosting, architecture, credentials and support, using only the facts we could confirm. Rows marked for confirmation depend on current Tines terms, so check those with the vendor before you decide.
| Capability | Tines | Shuffle |
|---|---|---|
| Licensing | Proprietary commercial product; confirm current terms with Tines | Backend under AGPLv3; workflows, documentation, apps and app specifications under MIT |
| Free tier | Free edition with unlimited users, spaces and connectors but 3 live workflows | Open-source edition, with all features available; paid tiers differ in limits, scaling and support |
| Workflow limits | Paid editions offer unlimited workflows; confirm current limits with Tines | Unlimited users, apps and workflows; licensing metric is app runs in enterprise terms |
| Hosting options | Cloud, with flexible hosting available on request; confirm options with Tines | Self-hosted via Docker or Kubernetes, or hosted cloud at shuffler.io |
| Minimum self-hosted footprint | Not applicable to a cloud-first product; confirm self-hosting requirements with Tines | Minimum 4 GB of RAM per the install guide; default Compose setup needs changes to scale |
| Database | Confirm with Tines | OpenSearch as the document database (Elasticsearch also works) |
| Deployment architectures | Confirm supported architectures with Tines | Single server with Docker Compose, Docker Swarm, hybrid with local Orborus, and Kubernetes with Helm |
| App building | Confirm connector and custom action options with Tines | App Creator builds integrations from OpenAPI specifications; apps run as versioned Docker containers |
| Credential encryption | Confirm encryption and key management with Tines | Saved credentials encrypted with AES-256 using a secret modifier; losing it breaks saved authentications |
| High availability | Confirm with Tines for self-hosted or cloud resilience | Documented pattern: OpenSearch cluster, shared cache, NFS and multiple Orborus nodes |
| Support model | Vendor-provided support on paid plans; confirm scope with Tines | Community plus paid tiers; confirm support terms with Shuffle |
How Shuffle builds apps from OpenAPI specifications
Shuffle's App Creator builds integrations from OpenAPI specifications, and it ships premade apps for common security tools. For most teams the first question is coverage: how many of the systems your analysts touch already have a Shuffle app, and how many need one built from an OpenAPI document. Check that inventory before you assume a Tines HTTP request action can be copied across. A Tines story calls endpoints directly, while a Shuffle app wraps each endpoint as a named action with typed parameters, so the work of mapping is different. Pull the list of internal APIs your playbooks call, note which ones publish a current OpenAPI specification, and mark the rest as work for a Python app.
For logic the App Creator cannot express, Shuffle offers the Python app SDK. Custom apps are written in Python and then run like any other app. Each app runs as a versioned Docker container, which has direct consequences for operations. You pin a workflow to a known app version, you test a new version before it replaces the old one, and you patch containers on your own schedule. Confirm with Shuffle how app images are published and updated in your deployment, and plan who owns rebuilds when a base image or an upstream library needs a fix. Saved app credentials also depend on the platform's encryption setting, so note which secrets must survive any rebuild.
Before deciding, run one representative integration end to end on each platform. Choose a tool your team uses every week, ideally one that needs authentication, pagination and error handling, and build the same action in a Tines story and in a Shuffle workflow. Measure how long the build takes, how the failure paths behave, and how easily a second person can read and change the result. Use the Tines export as your reference for the expected behavior. The result tells you more about the migration effort than any feature comparison, and it shows whether your internal APIs fit the OpenAPI route or need custom Python from the start.
What each option costs to run, and what drives it up
With Tines, most of the recurring cost is a subscription to a paid edition, and the platform operation sits with the vendor. The Free edition includes unlimited users, spaces and connectors, but it caps you at 3 live workflows, so any team that runs more than three live stories moves to a paid edition. Tines states that flexible deployment options are available on request, so hosting terms are part of the quote rather than a list price. Your internal costs are mostly one-time: building or migrating stories, configuring credentials and testing each one before switching triggers.
- Paid edition subscription (recurring): Ask which edition covers your live workflow count, user count and whether the hosting model you need is included.
- Hosting option (recurring, on request): If you need a self-hosted or dedicated deployment, request it in writing with its support and upgrade terms.
- Live workflow count (driver): Each live story you add can move you up a tier, so count live stories before you ask for a quote.
- Story rebuild and testing (one-time): Staff time to review stories, map credentials and run tests, which the vendor does not carry for you.
- Ongoing internal work (recurring): Story maintenance, access reviews and changes to connected tools stay with your team.
Before you sign, confirm the live workflow count the quote assumes, the hosting model, and what the price covers in support and upgrades.
Shuffle Cloud, hosted at shuffler.io, moves the server and OpenSearch operation to Shuffle while your team still builds and owns the workflows. Shuffle prices licensing on app runs, meaning actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. That makes app-run volume the main recurring driver, not seat count or workflow count. Confirm with Shuffle how its cloud tiers map to your expected app runs and what support level each tier includes.
- Cloud subscription (recurring): Priced on app runs, so ask for the expected run volume your use case produces, counting only executed actions.
- App run volume (driver): Loops, polling actions and high-frequency alerts increase executed actions quickly, so model them before you request a quote.
- Workflow rebuild (one-time): Recreating stories as Shuffle workflows, mapping credentials and testing each one is still your work or a services scope you agree in writing.
- App maintenance (recurring): Keeping custom apps built from OpenAPI specifications current as vendor APIs change remains your team's responsibility.
- Support time (recurring): Ask what support is included at your tier and what your internal staff must still handle.
Check the app-run assumptions behind the quote, whether unlimited workflows and users are confirmed in writing, and who handles upgrades and credential encryption key management.
Self-hosted Shuffle removes the vendor subscription from the platform layer, but you pay for infrastructure and operation yourself. The install guide states a minimum of 4 GB of RAM and notes the default Docker Compose setup is not scalable without changes. High availability, as the configuration docs describe it, needs an OpenSearch cluster, shared files, several backends and more than one Orborus node, which multiplies server and storage costs. Shuffle's open-source edition includes all features, and since v2.1.1 limits between editions are enforced, so check which limits apply to your run volume and scaling needs before you plan.
- Servers and storage (recurring): Compute for the frontend, backend, Orborus and OpenSearch, plus storage that grows with execution history.
- OpenSearch operation (recurring): Upgrades, index management, snapshots and capacity planning fall to your platform team.
- Backups and encryption key (one-time setup, recurring test): Back up OpenSearch and the SHUFFLE_ENCRYPTION_MODIFIER secret, since losing or changing it breaks saved app authentications.
- High availability (driver): Clustered OpenSearch, Memcached, NFS and extra Orborus nodes raise infrastructure and engineering cost.
- Workflow rebuild and app maintenance (one-time and recurring): Same story rebuild and OpenAPI app upkeep as the other options, plus your own support time.
Ask any implementation partner for a fixed-scope quote listing servers, OpenSearch sizing, backup design, high availability level and the staff hours each one assumes.
Licensing and editions: what the terms allow you to do
Shuffle splits its licensing by component, and that split decides what you can change and what you can run. The backend is licensed under AGPLv3, while the workflows, documentation, apps and app specifications are under MIT, as stated in the Shuffle GitHub repository. Shuffle says every feature is in the open-source edition, so the paid tiers differ in limits, scaling and support rather than in capability. Those limits have been actively enforced since v2.1.1, so a deployment that ran without caps on an older release may behave differently after an upgrade. Before you plan a rollout, confirm in writing which limits apply to the edition and version you intend to run, and how app runs are counted for paid use under the pricing article in the Shuffle documentation.
Tines is structured differently. Its pricing page lists a Free edition with unlimited users, spaces and connectors but 3 live workflows, and paid editions with unlimited workflows and flexible deployment options. The pricing FAQ states that flexible hosting is available on request, which means the self-hosted path is negotiated rather than published. For a fair comparison, ask Tines which deployment models, support terms and workflow limits each paid edition includes, and ask Shuffle the same questions for its paid tiers. Put both answers in the evaluation file so the comparison rests on contract terms, not on marketing summaries that may change between renewals.
The AGPLv3 backend needs legal review if you plan to modify it. Under the network provisions of that license, offering a modified version to users over a network can trigger obligations to make the corresponding source available to those users, and internal use is treated differently from providing a service to outside parties. The MIT-licensed workflows, apps and specifications carry fewer restrictions, but you should still confirm how custom apps, forks and patched backends are classified before they reach production. Ask counsel to review three cases: internal use only, a modified backend exposed to partners, and any hosted offering built on Shuffle for customers.
What moving from Tines to Shuffle involves
The sequence turns Tines stories into Shuffle workflows that run in your own infrastructure, with each live trigger switched over only after its replacement has been tested. The output is an inventory, a set of verified workflows and a documented cutover record that your team can audit.
Inventory stories and live triggers
Start by listing every Tines story, marking which ones are live, and recording each trigger type, such as webhooks, schedules and inbound email. Note which stories call external tools, which depend on other stories, and which rely on Tines-specific features such as pages. Assign an owner to each story. The step is complete when the list covers every live trigger and each entry has an owner and a target Shuffle workflow name. Confirm with your own team which stories are business critical, since these should move last.
Export story data and record the baseline
Export the Tines stories as story files from the interface or the API, and keep them in version control or a secured archive. Record the current run history for each live story so you have a baseline for later comparison. The check is that every exported file opens, that you can match each file to an inventory entry, and that you know what the file omits. Confirm which parts of the event history you need before you rely on the export alone.
Back up Shuffle encryption secret first
Before you store any credentials in Shuffle, back up the value of the SHUFFLE_ENCRYPTION_MODIFIER secret in a separate, access-controlled location. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using this secret, and the configuration docs warn that losing or changing it breaks all saved app authentications. Test the restore procedure on a non-production instance. The step is complete when the secret has a documented backup, a named custodian and a tested restore path, and when your change process prevents anyone from altering it casually.
Map HTTP actions and credentials to apps
For each Tines HTTP request action, identify the target system and decide whether a Shuffle app already covers it, whether to build one from an OpenAPI specification in the App Creator, or whether to write one with the Shuffle app SDK in Python. Re-enter credentials through Shuffle's authentication settings rather than copying secret values between tools. The output is a mapping table from each Tines action to a Shuffle app, action and credential, with gaps marked. Done when every action in the inventory has a mapped destination or a documented exception.
Rebuild webhooks and schedules
Recreate each inbound webhook and scheduled trigger as a Shuffle trigger, keeping the original payload format and authentication expectations so upstream senders need no change. Create the new endpoints but leave the source systems pointing at Tines until testing is complete. Confirm which Tines features have no direct Shuffle equivalent, and plan a replacement or an accepted gap for each one before the workflow is signed off. The step is complete when each new trigger is documented with its URL pattern, schedule and owner.
Run workflows in parallel with test data
Build each Shuffle workflow and run it against test or replayed data while the Tines original keeps handling live traffic. Compare outputs, ticket or case updates, notifications and error handling between the two. Test failure paths and credential failures as well as happy paths. Shuffle's high availability guidance includes more than one Orborus node and a scaled backend, so confirm that the test environment reflects the topology you plan to run in production. The check is a documented comparison showing matching results for each agreed test case.
Switch triggers one at a time
Move production triggers to Shuffle individually, starting with the lowest-impact stories, and keep the Tines version available for rollback until each story has run cleanly for a period your team agrees in advance. Record the cutover time, the owner who approved it and the observed results for each story. The sequence is complete when every inventory entry shows a cutover record, a rollback decision and a final owner sign-off. Retire the Tines story only after the record is filed.
Questions buyers ask before choosing Tines or Shuffle
What does a self-hosted Shuffle cost to run, and what drives that cost?
The software itself has no license fee for the open-source edition, so the recurring cost is the infrastructure and the people who keep it running. Shuffle's install guide sets a minimum of 4 GB of RAM for a single host, but that is a floor, not a sizing for production. Production sizing depends on execution volume, the number of Orborus nodes, and whether you run an OpenSearch cluster for high availability, as the configuration docs recommend. Ask any provider for a written breakdown covering servers, storage, backups, OpenSearch operations, upgrades and on-call support, and ask which of these are one-time and which recur each year. Shuffle's pricing article also describes a paid tier metered on app runs, so confirm which edition your quote assumes.
How long does a Tines to Shuffle migration take?
Duration depends on how many workflows you move, how many depend on credentials and webhooks, and how much testing each one needs. No fixed timeline is supplied for this migration, so treat any number you hear as a claim to verify. The main drivers are the count of live workflows, the number of distinct app integrations you must map to Shuffle apps, the need to rebuild schedules and webhook triggers, and whether each workflow is tested before its trigger is switched. Ask for a written scope that lists workflows by name, the integrations behind each one, the test method, and the cutover order.
How much of our own staff time does a Shuffle project need?
Expect your team to contribute time in three places: someone who knows each workflow's business logic, someone who owns credentials and access to each target system, and someone who approves tests and cutover. The implementation partner or internal engineers do the build, but the people who understand the incident response process must validate that rebuilt workflows behave the same way. Ask the provider to name the roles it needs from your side, the number of review sessions, and who signs off each workflow before it goes live.
Can an internal team run Shuffle without outside help?
Yes, many teams operate Shuffle internally, but it depends on skills in Docker or Kubernetes, OpenSearch administration, certificate and secret handling, and app development. Shuffle documents several architectures, from a single Docker Compose server to Kubernetes with Helm charts, and the default Compose setup is not scalable without changes. Note that losing or changing the SHUFFLE_ENCRYPTION_MODIFIER secret breaks every saved app authentication, so key management needs a documented owner. Assess your team against each of these areas and decide whether to contract for the build, the run, or a retainer for upgrades and support.
Do Shuffle's AGPL terms affect how we use it internally?
For most internal security automation use, the AGPL-3.0 license on Shuffle's backend governs what you owe if you modify the backend and make it available to others over a network. Shuffle states its workflows, documentation, apps and app specifications are under MIT, which is more permissive. Whether the AGPL creates an obligation depends on your modifications and how you deliver the service, so have your legal team review the license text and your planned changes before you build custom backend code. Ask your implementation partner to document every modification so the review is specific.
How does the Tines Free edition's 3-workflow limit affect our planning?
The Tines Free edition lists unlimited users, spaces and connectors but only 3 live workflows, so any team running more than three live automations will need a paid edition or another platform. Plan around the number of live workflows you need, not the number of users. Tines documents that its paid editions remove the workflow cap and that flexible hosting options are available on request. Ask Tines directly which hosting model and edition your count requires, and compare that quote with the cost of a self-hosted Shuffle over the same period.
What should we ask for in a written scope before hiring help?
Ask for a fixed-scope document that lists every deliverable: architecture, installation target, number of workflows and apps, credential migration method, webhook and schedule rebuild, test evidence, backup and upgrade procedure, and handover training. Require named acceptance criteria for each workflow and a cutover plan with a rollback step. Also ask what is excluded, such as ongoing support, upgrades or continuous testing, which DeployOpen offers as retainers. Confirm in writing who maintains the platform after handover.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the Tines vs Shuffle decision is tested against your environment before anything is committed. We start with the written scope, then build and hand over a Shuffle deployment you can run without us.
How we scope
- Inventory your current Tines stories, connectors, credentials and live workflow count before estimating any build.
- Confirm which hosting model fits your network, including whether a hybrid Shuffle Cloud and local Orborus setup is acceptable.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- Deploy Shuffle with Docker or Kubernetes in your cloud account, data center or air-gapped network, using a scalable layout rather than the default Compose setup.
- Build apps from OpenAPI specifications in the App Creator and test each workflow against sandbox systems before switching triggers.
- Configure SSO through SAML or OpenID Connect, set up the encryption secret handling and document the high-availability design.
How we hand over
- Deliver architecture, runbooks, workflow inventory and a test record for every rebuilt workflow in writing.
- Walk your operations and security teams through backup, upgrade and secret rotation procedures on your own systems.
- Document what remains manual, such as cases or features Shuffle does not cover, so your team can plan for them.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover Shuffle version upgrades, app updates and periodic security testing of the automation platform itself.
- Ask for a written quote based on your scope, since DeployOpen does not publish a price list.
