Does self-hosted Shuffle cost less than Tines?
Shuffle's software costs nothing to license for the self-hosted core, but running it is not free. Shuffle's code is licensed under AGPL-3.0, and its open-source edition includes all features. If you run the platform yourself, you pay no subscription to Shuffle for the software, and no Tines paid edition fee applies. Your costs are the servers or cluster, storage, the time to rebuild your Tines stories as Shuffle workflows, and the staff who patch, back up, upgrade and support the platform. Shuffle's paid tiers, by contrast, are priced on app runs, meaning actions that actually execute in a workflow, while users, apps and workflows stay unlimited. If your renewal is driven by a workflow cap, the question is whether your run volume and staffing cost less than the Tines paid edition you would otherwise buy.
Tines paid pricing is not stated in the facts behind this page, so get the figure from Tines before you compare. Tines lists a Free edition with 3 live workflows and describes paid editions with unlimited workflows and flexible deployment options, and its Tines pricing page is the place to confirm current terms. Ask Tines in writing which edition gives you self-hosting or a private deployment, what it includes in support and upgrades, and whether pricing depends on users, actions or workflows. Then price the Shuffle side with the same scope: the servers for a production backend, OpenSearch and the Orborus runtime nodes needed for availability, backup storage, and the engineering hours for installation, the workflow rebuild and ongoing operations.
Your cost of ownership is driven by staffing and resilience choices more than by licensing. Shuffle's install guide sets a minimum of 4 GB of RAM for its setup, but its configuration docs recommend an OpenSearch cluster, more than one Orborus node and shared files for high availability, and the default Docker Compose setup is not scalable without changes. Each of these adds hardware and operator time that recurs every year. Also plan for the encryption modifier, SHUFFLE_ENCRYPTION_MODIFIER, which protects saved app credentials; losing it breaks every saved authentication, so it belongs in your backup and key management process. Ask any implementation partner for a written scope covering architecture, rebuild effort, testing and the retained support you actually need.
Which cost components each side carries
This table lists each cost component for Tines paid editions and self-hosted Shuffle, with who gets paid, whether the cost is one-time or recurring, and what drives it. Read it as a checklist to bring into a quote request, since the components are the same on both sides even though the payees differ. The main takeaway is that self-hosted Shuffle moves the platform, hosting and upkeep costs onto your own team or a partner, while Tines bundles most of them into its subscription.
| Cost component | Tines (paid, cloud or self-hosted) | Self-hosted Shuffle |
|---|---|---|
| Subscription or license | Recurring fee paid to Tines for a paid edition with unlimited workflows. Ask Tines for current pricing and whether flexible hosting is included. | Shuffle's open-source edition is free to use. Paid tiers are priced on app runs, meaning actions that actually execute, with users, apps and workflows unlimited. Confirm which tier applies to your volume. |
| Infrastructure | Included in the subscription on Tines Cloud. On Tines self-hosted, you pay for the servers and storage Tines requires; confirm sizing with Tines. | Recurring cost you pay your cloud or data center provider for servers, storage and networking. Shuffle's install guide sets a minimum of 4 GB of RAM for a single host, and high availability adds more nodes. |
| Implementation and setup | One-time effort to configure spaces, connectors and access, paid to your team or a partner. | One-time effort to install Docker or Kubernetes, configure OpenSearch, secrets and SSO, paid to your team or a partner. Confirm the scope in writing. |
| Workflow rebuild | One-time effort to recreate any stories you move between platforms. Stories that already exist in Tines carry no rebuild cost if you stay on Tines. | One-time effort to rebuild each Tines story as a Shuffle workflow, paid to your team or a partner. Cost grows with the number and complexity of workflows and their app connections. |
| Migration and testing | One-time effort to test each workflow and switch triggers, paid to your team. | One-time effort to re-create webhooks and schedules, re-enter credentials and test each workflow before cutover, paid to your team or a partner. Losing the encryption modifier secret breaks saved credentials, so plan key handling early. |
| Support | Recurring, included in the paid subscription terms. Confirm the support level and response commitments in your contract. | Recurring if you buy vendor support from Shuffle's paid tiers, or recurring retainer fees if you use a partner. Internal on-call time for a self-hosted platform is an ongoing cost in either case. |
| Upgrades and maintenance | Handled by Tines on Tines Cloud. On self-hosted Tines, upgrades are your responsibility and should be confirmed in the contract. | Recurring effort to apply new releases, test them and back up OpenSearch data. Pinning versions and testing before upgrade reduces risk, paid to your team or a partner. |
| Internal skills | Recurring time for administrators and workflow builders who learn the Tines editor. | Recurring time for staff who run Docker, Kubernetes, OpenSearch and Orborus, and who maintain app containers. Often the largest hidden cost, so count it in the comparison. |
What moves the cost comparison most
Tines cost and self-hosted Shuffle cost respond to different levers. Some drivers are set by how many workflows you run and how often they execute, while others come from the infrastructure you must size and staff yourself. Model each one before comparing totals.
Live workflows against the Free cap
Tines Free includes 3 live workflows, while its paid editions remove that cap. Each additional live workflow pushes a Tines team toward a paid edition, but on Shuffle the workflow count does not change the licence. Count the workflows you need live today and those planned for the next renewal period, then compare that number with the Free limit and the paid tier quote. Shuffle's cost moves with the infrastructure and rebuild effort those workflows require.
App runs per month
Shuffle's licence is priced 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. Higher run volume raises the licence cost on paid Shuffle tiers and also drives compute and container load on your servers. Pull run counts from your execution history for a representative month, including peak alert days, and ask the vendor how they count runs in writing.
Data volume in OpenSearch
Shuffle stores its workflows, execution records and saved data in OpenSearch, so retained execution history grows storage and memory needs over time. Retention settings and the number of stored executions decide how much disk you provision and how often you add nodes. Estimate the storage per workflow run from a pilot, then multiply by your retention window. Tell your team who owns index lifecycle and backups, because that work is recurring staff time.
High availability requirements
The Shuffle docs recommend an OpenSearch cluster, optional Memcached for a shared cache, NFS for shared files when several backends run, scaled backend and frontend servers, and more than one Orborus node so workflows keep running if one fails. Each element adds hardware, licences for underlying infrastructure, and operator time. If your service levels require continuous automation, this is often the largest infrastructure line. Confirm the exact sizing with your architect rather than assuming a single server suffices.
Shuffle edition tier
Shuffle says all features are available in the open-source edition, while its paid tiers differ in feature limits, scaling and support. Since v2.1.1, the limits between the open-source and enterprise editions are actively enforced. Decide which limits matter for your scale, such as scaling or support terms, before you compare costs. Ask Shuffle for the current tier definitions in writing, because the enforced limits determine whether you can stay on the open-source edition.
Internal skills and support time
Self-hosting moves operating work to your team: upgrades, OpenSearch care, secret rotation for the encryption modifier, SSO configuration and building or testing apps. Tines bills for the hosted service, while you pay staff time or an implementation and support partner for Shuffle. Estimate hours per month for patching, on-call coverage and app maintenance, then add the rebuild effort of moving existing stories. If the team lacks container or OpenSearch experience, price training or outside support into the first year.
How to build the comparison with your own numbers
This sequence turns the Tines price list and the Shuffle architecture into a side-by-side model built on your own workflow count, app run volume and staffing. The output is a stated-period comparison that finance, security and platform teams can check line by line.
Inventory live workflows and expected app runs
Start by listing every workflow that must run live, separating it from drafts and test stories. For each one, estimate how many actions will actually execute per month, since Shuffle licensing counts app runs (actions that execute), not triggers or skipped actions, and does not limit users, apps or workflows. Ask the platform owner for recent action counts from the existing tool where they exist. The step is done when you have one table with workflow name, owner, trigger type and monthly app run estimate, and a second column that shows how each figure was derived. An illustrative example: a team with five live workflows and a few thousand runs a month would record each workflow's trigger and action volume separately so the totals can be audited later.
Get the Tines paid quote for your edition
Tines lists a Free edition with unlimited users, spaces and connectors but 3 live workflows, and paid editions with unlimited workflows and flexible deployment options. Hosting options beyond the listed plans are available on request, so ask Tines in writing which edition, which deployment model (cloud or self-hosted) and which support terms your workflow count requires. Record the quote as a recurring line with its billing period and renewal terms, and note any one-time onboarding or migration fees separately. The step is done when you hold a written quote that names the edition, hosting option, term and what is included, and you can state the annual recurring cost it implies.
Size Shuffle hosting from the documented architectures
Shuffle documents four deployment architectures: a single server with Docker Compose, distributed Docker Swarm, a hybrid with Shuffle Cloud and a local Orborus that needs no inbound firewall ports, and Kubernetes with Helm charts. The install guide sets a minimum of 4 GB of RAM and notes that the default Docker Compose setup is not scalable without changes. Choose the architecture your availability target needs, then size servers, OpenSearch storage and any Orborus nodes against your run volume. For high availability, the configuration docs recommend an OpenSearch cluster, shared Memcached and NFS where several backends run, and more than one Orborus node. The step is done when you have a bill of materials for compute, storage, backups and network, with each line tied to an architecture decision. Prices come from your cloud or hardware vendor, not from Shuffle.
Estimate rebuild effort per workflow
Export each live Tines story as a story file so the inventory reflects what actually runs, then review each one for HTTP actions, credentials, webhooks, schedules and any logic that needs a custom app. Shuffle apps can be built from OpenAPI specifications in the App Creator or written in Python with the app SDK, and each app runs as a versioned Docker container, so mark which integrations already have premade Shuffle apps and which need a new build. Score each workflow by complexity (simple lookup, multi-branch, custom integration) and assign a staff-hours range based on your team's own past migration work. The step is done when every workflow has a complexity rating, a list of apps to build or verify, and an effort estimate that the team has agreed to. Label the effort figures as your team's assumptions, since no supplied source gives a rebuild duration.
Add support, upgrades and security operations time
Self-hosting moves several recurring tasks to your team: applying Shuffle releases (check the release notes and choose a tagged Docker image rather than nightly builds for stable use), operating OpenSearch, rotating the SHUFFLE_ENCRYPTION_MODIFIER secret with care, since losing or changing it breaks saved app authentications, and maintaining SAML or OpenID Connect single sign-on. Estimate monthly operator time for patching, backup testing, capacity checks and incident response on the automation platform itself, and add any paid support you choose. The step is done when you have a monthly staffing line with named roles, plus a list of the vendor support terms you asked for in the Tines quote so both sides are compared on equal terms.
Confirm licensing terms for the Shuffle tier
Shuffle states that all features are available in the open-source edition, while paid tiers differ in feature limits, scaling and support, and that limits between editions are enforced since v2.1.1. Confirm with Shuffle which tier you would need once your app run volume is known, and whether any feature your workflows depend on sits behind a paid limit. Note that the backend is AGPL-3.0 and that workflows and apps are MIT licensed, and have legal review your use. The step is done when you have written confirmation of the tier, the app run limits it carries, and a legal sign-off on the licensing terms relevant to your deployment.
Compare totals over a stated period
Build one spreadsheet with two columns, Tines and Shuffle, and a common period, such as 36 months, stated at the top so the comparison is reproducible. Include one-time costs (migration, testing, initial hosting setup, training) and recurring costs (Tines subscription, cloud or hardware, staff time, support). Show the sensitivity of the result to the largest drivers: workflow count, app run volume and staff rate. Ask two colleagues in security and platform engineering to review the assumptions before anyone signs. The step is done when the sheet shows totals for each option, the assumptions behind each line, and the number of workflows and app runs at which the ranking changes. Label the resulting example as illustrative when you share it internally.
How Shuffle deployment choice changes the bill
The simplest Shuffle layout runs the frontend, backend, OpenSearch and Orborus on one host with Docker Compose. It suits evaluation and small teams. The install guide sets a minimum of 4 GB of RAM for the host, and the default Compose setup is not scalable without changes.
- Servers: one Linux host that meets the 4 GB minimum, sized up for your execution volume. Confirm the sizing with the Shuffle install guide before you commit.
- Storage: local disk for OpenSearch indices, workflow execution history and container images. Storage grows with the history you keep, so set a retention decision early.
- Staff effort: one administrator can usually install and upgrade the stack, but backups, OpenSearch maintenance and safe handling of the
SHUFFLE_ENCRYPTION_MODIFIERsecret all fall to that person. - What it does not cover: high availability. If the host fails, workflows stop until you restore it, and the default layout gives you no failover.
Check whether your expected execution volume and retention fit one host before you treat this setup as production.
Docker Swarm spreads Shuffle services across several Docker hosts. It is the step between one server and a clustered design, and it is one of the four documented architectures. The cost moves from a single machine to a small cluster plus the shared components that keep it consistent.
- Servers: several Docker hosts. The count depends on execution load and the availability you require, so ask for a sizing review tied to your workflow count and run volume.
- Storage: an OpenSearch cluster instead of one node, and shared file storage such as NFS when several backends run. Plan the storage for replicas and backups, not only for the first copy of the data.
- Staff effort: someone must own Swarm operations, node patching, service placement and cluster-level monitoring, on top of Shuffle administration.
- What it does not cover: the Shuffle high availability guidance lists components such as Memcached for a shared cache and more than one Orborus node. Swarm does not deploy or test those for you, and it does not provide backup and restore procedures.
Ask whether your team already runs Swarm in production, because an orchestrator your staff do not know adds recurring work to every upgrade.
Kubernetes with Helm charts is the most scalable self-hosted path and the one with the highest skill requirement. It fits organizations that already operate clusters and want Shuffle to follow the same deployment, monitoring and access controls as other workloads.
- Servers: a cluster with enough worker capacity for the backend, frontend, OpenSearch and Orborus pods. If you already run the cluster, the marginal cost is capacity and the time your platform team spends on it.
- Storage: persistent volumes for OpenSearch and shared files. The storage class you choose affects backup, snapshot and recovery options, so confirm them before go-live.
- Staff effort: Helm values, ingress, secret management for the encryption modifier, and review of each chart upgrade. This work is ongoing and usually sits with platform engineering.
- What it does not cover: the chart does not replace cluster hardening, network policy design, image provenance checks or the evidence an assessor will request. Those remain your responsibility or a separate scope.
Confirm who signs off Helm upgrades and whether the platform team has capacity for them before you choose this model for production.
The hybrid model uses the hosted Shuffle Cloud service for the control plane and runs a local Orborus inside your network to execute actions. According to the Shuffle architecture docs, the local Orborus needs no inbound firewall ports, because it polls the backend for jobs. The operating burden drops, but so does control over where data sits.
- Servers: only the Orborus host or hosts inside your network. You do not run the backend, frontend or OpenSearch yourself.
- Storage: limited local storage for runtime. Workflow definitions, execution records and saved app credentials sit in the hosted service, so confirm where each of them is stored.
- Staff effort: lower day-to-day effort, but you still patch the Orborus hosts, manage egress rules to the backend and rotate app credentials.
- What it does not cover: a self-hosted data residency requirement. Hosted control planes are a different risk profile, and any subscription cost recurs and needs a written quote, which this page does not estimate.
Before you choose this model, ask the vendor in writing where workflow data, credentials and logs are stored and who can access them.
Questions buyers ask before comparing Tines and Shuffle costs
How much staff time does running a self-hosted Shuffle take?
The honest answer depends on how many workflows, apps and environments you run, and no fixed figure is supplied here, so ask for it in writing. Self-hosting shifts work to your team: installing and upgrading the frontend, the Go backend on port 5001, the OpenSearch database and the Orborus runtime nodes, plus patching, backups and monitoring. Shuffle's own docs say the default Docker Compose setup is not scalable without changes, and high availability adds an OpenSearch cluster, shared files and more than one Orborus node. Ask your team to estimate the recurring operations hours for those components, and confirm the rate at which upgrades are tested in your environment.
Can our team run Shuffle without outside help?
A team with container and database experience can often deploy Shuffle on Docker or Kubernetes from the install guide, but production readiness is a different bar. The install guide requires at least 4 GB of RAM as a minimum, and the architecture docs describe four deployment patterns, from a single Compose server to Kubernetes with Helm. Gaps usually appear in SSO setup, credential encryption key handling, high availability and rebuilding workflows from Tines stories. If those skills are thin in-house, a fixed-scope engagement from DeployOpen can plan, implement, harden and document the platform, and a retainer can cover upgrades and support afterward.
How long does rebuilding Tines workflows in Shuffle take, and what drives it?
No rebuild duration is supplied, so treat any number from a vendor as an estimate to verify against your own inventory. The main drivers are the number of live stories, how many HTTP actions and credentials each one uses, whether apps must be built from OpenAPI specifications in the App Creator or written with the Shuffle app SDK, and how much testing each workflow needs before its triggers move. Webhooks and schedules must be re-created, and saved credentials must be re-entered, because Shuffle encrypts them with the SHUFFLE_ENCRYPTION_MODIFIER secret. Ask for a per-workflow breakdown in the written scope.
Does Shuffle Cloud remove the server cost?
Shuffle Cloud, hosted at shuffler.io, removes the cost of running the Shuffle backend and database for you, but it is not the same as owning nothing. Shuffle's architecture docs describe a hybrid model in which the cloud hosts the platform while a local Orborus needs no inbound firewall ports, so you still run the runtime and the apps' network access inside your environment. Shuffle's pricing article says licensing is metered by app runs, meaning actions that execute in a workflow, while users, apps and workflows are unlimited. Ask for the app run volume your workflows generate, because that drives the license cost in either model.
What does Tines Free's limit of 3 live workflows mean in practice?
It means the Free edition can keep only three workflows running live at once, while users, spaces and connectors are unlimited. Whether that ceiling matters depends on how many automations your security team needs in production, not on how many you build or test. Tines' pricing page describes paid editions with unlimited workflows and says flexible hosting is available on request, so confirm current terms and hosting options directly with Tines. Shuffle's pricing article describes a different metric, so compare total cost on app runs, staffing and hosting rather than workflow counts alone.
Is Shuffle's AGPL license a problem for internal use?
For most internal security operations use, the AGPL license on the Shuffle backend is a question for your legal team rather than a blocker. Shuffle's workflows, documentation, apps and app specifications are under MIT, and the backend is under AGPLv3, so confirm with counsel how your modifications and hosting arrangements apply. Also check the license of any third-party app you wire in. Record the decision alongside your cost comparison so procurement sees it in one place.
What should we ask for in a quote before comparing costs?
Ask for a written scope that lists every deliverable, the components covered, and the assumptions behind the numbers. For the Shuffle side, request the infrastructure sizing, the OpenSearch and Orborus topology, the high availability design, the workflow inventory and rebuild plan, the testing approach, and the upgrade and support model, with each item priced separately. For Tines, request the edition, the hosting option, the workflow count and the terms in writing from Tines. DeployOpen does not publish a price list, and a quote follows from the written scope. Ask which items are one-time and which recur each year.
Which Shuffle version should we plan around?
Plan around the current release you verify on the Shuffle GitHub releases page, not a version named in a blog post. The Shuffle docs recommend the latest Docker tag for stable releases and the nightly tag only for experimental changes, so pin a tagged version in production. Since v2.1.1, the limits between the open-source and enterprise editions are enforced, so check which limits apply to your setup before you size the deployment. Ask your partner how upgrades are tested against your workflows.
What rebuilding Tines workflows in Shuffle costs in effort
Most of the effort in moving from Tines to self-hosted Shuffle is per-workflow rebuild work, not platform installation. Each live Tines story has to be recreated as a Shuffle workflow, its actions mapped to Shuffle apps, its credentials entered again in Shuffle's app authentication, and its webhooks and schedules re-created so that the same events still reach the right place. Budget this as labor that scales with the number of workflows, the number of distinct external tools they call, and how many of those tools lack a ready-made app. Ask any services partner to price the work per workflow and per integration, and confirm whether credential remapping and trigger cutover are in scope.
Shuffle's App Creator can build an integration from an OpenAPI specification, and it ships premade apps for many security tools. Where a Tines HTTP request action calls a documented API, a team can often generate the app from that specification and reuse it across workflows. Where no specification exists or the API is poorly documented, the work moves to Python apps written with the Shuffle app SDK, which are then packaged and run as versioned Docker containers. Ask which of your integrations already have a premade app, which need an OpenAPI-based app, and which need custom Python code. That split usually drives more of the schedule than the workflow count does.
Plan the rebuild as a parallel run, not a single cutover. Keep Tines live for each workflow until the Shuffle version has processed real events and produced matching outcomes, then switch that trigger. The step-by-step method for exporting stories, mapping actions and testing each workflow before switching is covered in the sibling page on migrating from Tines to Shuffle, so this section only sets the effort expectations. Record which integrations need secret rotation after the move, and make sure the SHUFFLE_ENCRYPTION_MODIFIER value is backed up before any credentials are entered, since changing it breaks saved app authentications.
How DeployOpen scopes a fixed-price Shuffle implementation
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For a Tines cost vs self-hosted Shuffle decision, we start with a written scope that names the workflows, app runs, hosting model and support terms before any build work begins.
How we scope
- We inventory the live Tines workflows you plan to move and the apps and credentials each one uses.
- We size the Shuffle architecture (single server, Swarm, hybrid or Kubernetes) against your hosting and availability needs.
- We agree deliverables, timelines and support terms in writing, since most engagements are fixed-scope before work starts.
How we build
- We install Shuffle on your chosen infrastructure and configure OpenSearch, Orborus nodes and encryption secrets.
- We build missing integrations with the App Creator from OpenAPI specifications or the Python app SDK where needed.
- We test each rebuilt workflow against its original behavior before any trigger or schedule is switched over.
How we hand over
- We document the deployment, configuration, backup and upgrade steps so your team can run the platform.
- We record the app-run volume and resource settings so you can compare licensing and hosting costs over time.
- We provide evidence and documentation for your own auditors, though DeployOpen does not issue audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer scope is agreed in writing, covering which Shuffle releases, apps and environments are included.
- Ask any provider to confirm in writing how they handle upgrades, backups and secret rotation for your environment.
