Which open-source option replaces Shopify Flow after you leave Shopify Plus
If your Shopify Plus store runs Flow workflows and you are weighing a self-hosted commerce platform, self-hosted n8n is the most common open-source replacement for Flow's trigger, condition and action model. Flow itself is a free app on the Basic, Grow, Advanced and Plus plans, but the Send HTTP Request action is limited to Grow, Advanced and Plus, and custom partner app tasks require Plus. Those limits matter less after migration, because you will call your own endpoints directly, but they show how much of your current logic depends on Shopify's event model and plan tier. Inventory every Flow workflow before you choose a target, and record the trigger, each condition and each action in a plain list.
The platform you pick decides what those workflows connect to. Magento Open Source, Medusa, Saleor, Sylius, PrestaShop and WooCommerce each expose a different surface for orders, customers and inventory, through REST, GraphQL, module hooks or plugin events. A Flow rule that fires on an order paid event needs a matching webhook or event source on the new platform, and a check on tags or metafields needs an API field that actually exists there. Confirm each trigger and field against the target platform's documentation, and mark any Flow trigger with no equivalent as a custom build or a manual step before the cutover.
Once n8n runs your automations, you own their monitoring and retries. n8n is fair-code, licensed under the Sustainable Use License, which permits internal business use. Files with .ee in their name or directory need a valid Enterprise License, and the Business plan's SAML single sign-on, Git environments and log streaming are paid features, so check which ones your operations team requires before you deploy. Queue mode, which splits triggers from workers through Redis and PostgreSQL, needs the same encryption key on every worker, and multi-main high availability is restricted to Enterprise self-hosted deployments. Ask your implementation partner to document failure alerts, the retry policy for each workflow and who receives them.
How Flow capabilities map to self-hosted n8n and your new platform
This table maps each Shopify Flow building block to its n8n equivalent and to the event or API it depends on in your new platform. Read the coverage column first: rows marked as custom code, platform-side events or manual steps are where rebuilt automations usually need the most review.
| Flow capability | Self-hosted equivalent | Coverage note |
|---|---|---|
| Event trigger (store event such as order created) | n8n Webhook node receiving the new platform's webhook, or a polling trigger on its API | Partial. Confirm each webhook event exists in your platform and fires on the same action Flow watched. Do not assume parity. |
| Optional condition (if/then branch) | n8n IF and Switch nodes operating on the event payload | Maps cleanly for field comparisons. Logic that depends on Shopify-specific data (tags, metafields) needs the same fields rebuilt on the new platform first. |
| Built-in action (tag, update field, send email) | n8n nodes for the new platform's API, or an HTTP Request node calling its REST or GraphQL endpoints | Mostly maps. Confirm the new platform exposes a write endpoint for each field you update, and whether it requires admin credentials. |
| Send HTTP Request action | n8n HTTP Request node with stored credentials | Maps cleanly. Flow limits this action to Grow, Advanced and Plus plans, so the self-hosted version has no plan gating, but credentials and retries become your responsibility. |
| Custom partner app task | Custom n8n workflow calling the partner's API, or a platform-side extension | Manual rebuild. There is no direct equivalent. Each partner integration needs its own review of data access, authentication and error handling. |
| Multi-step or scheduled workflow | n8n workflow with Schedule Trigger, wait nodes and error workflows | Maps with extra work. Execution history and retries must be configured and monitored by your team. |
| Execution logs and failure alerts | n8n execution list, error workflow and log streaming (Business or Enterprise plans) | Partial. Log streaming and Git environments require a Business or Enterprise plan according to n8n pricing, so confirm the tier you need before design. |
Which n8n deployment and which commerce platform fit Flow-style automation
Two decisions shape the rebuilt Flow workflows: which n8n edition your team runs, and which commerce platform emits the events and receives the actions. The cards below cover the n8n license and tier limits first, then how each candidate platform changes the work. Check both before you map a single Flow template.
Community edition for internal use
The free self-hosted Community edition of n8n is the lowest-cost starting point for a single internal team running your own store's automations. Its Sustainable Use License permits use for your own internal business purposes, so your own store operations fit. Confirm with counsel that your use, including any agency or partner access, stays inside that grant. Do not use it to offer automations as a service to other merchants.
Business and Enterprise tiers
SSO and LDAP, Git-based environments and log streaming are included only in the Business and Enterprise plans, so they are not part of the free build. Multi-main high availability is restricted to Enterprise self-hosted deployments. If your security team requires SAML sign-in with Okta or Azure AD, or promotion of workflows between dev and production, price the Business plan against the cost of building those controls yourself. Ask n8n for a written quote covering self-hosted terms.
.ee files need an Enterprise License
Any file with .ee in its name or directory falls outside the Sustainable Use License and needs a valid Enterprise License. Some features you might expect from the Business tier sit in those files, so a configuration that works on a test instance can become a licensing problem in production. Before go-live, list the enabled features, map each to a license file path, and confirm with n8n which features your contract covers.
Queue mode and shared encryption keys
At higher volume, queue mode separates the main instance, which handles triggers and webhooks, from workers that run executions through Redis and PostgreSQL. Every worker and webhook processor must share the main instance's encryption key to read stored credentials. Losing or rotating that key without a plan breaks every workflow at once. Decide who holds the key, where it is stored and how it is rotated before you add workers.
Medusa's workflow engine and modules
Medusa runs its own workflow engine inside the application, so cart, order and inventory logic can live in code next to the commerce modules. This keeps business rules close to the data and reduces the number of external webhooks you must trust. The trade-off is that a Flow-style rule for a merchant, such as tagging a delayed order, becomes a developer task rather than a visual change. Check whether your team can own those workflows in TypeScript.
Saleor's GraphQL API and webhooks
Saleor exposes its catalog, orders and channel-specific pricing through a GraphQL API and can send webhooks on store events, which n8n can receive and act on without custom backend code. This suits multi-channel merchants who want n8n to coordinate stock, pricing or fulfillment across markets. The trade-off is that you own the mapping from GraphQL objects to each Flow action and the error handling when a webhook is delivered twice or out of order. Confirm the webhook events you need in the current Saleor release.
Rebuilding Flow workflows in n8n step by step
This sequence turns each live Flow automation into a documented, tested n8n workflow on your new platform's APIs, so that every trigger, condition and action has a known owner and a known way to fail before Flow is switched off.
Inventory every live Flow workflow
Export or list every workflow that is enabled in Shopify Flow, and record for each one its trigger, its conditions, its actions and the apps or external services it calls. Include workflows that run rarely, such as those tied to refunds, fraud holds or seasonal events, because they are the ones most likely to be forgotten. Ask the merchant operations team to confirm which workflows they rely on, and check the Shopify Flow help documentation for the current list of triggers and actions. The step is done when the inventory has one row per workflow and every row has a named business owner.
Classify each workflow as template or custom
Mark each inventoried workflow as template-equivalent if its trigger, conditions and actions map to a standard event and API call on the new platform, or as custom if it depends on logic, data or a partner app that has no direct equivalent. Flow templates are the most likely to map cleanly, while custom workflows usually need a new webhook handler or an API call that your team writes and tests. Note any workflow that uses the Send HTTP Request action, since those calls move to n8n HTTP nodes with their own credentials. The step is done when every workflow has one classification and the custom ones have a short written description of the missing piece.
Stand up n8n with PostgreSQL and queue mode if needed
Deploy self-hosted n8n in your own infrastructure with a PostgreSQL database for workflow and execution data. If the volume of triggers or the need for separate webhook handling justifies it, configure queue mode, where the main instance receives triggers and webhooks, Redis passes executions to a worker pool, and workers read and write to PostgreSQL. Confirm with your platform team which edition you will run, because multi-main high availability is restricted to Enterprise self-hosted deployments, and SSO and LDAP, Git environments and log streaming are limited to the Business and Enterprise plans. The step is done when a test workflow runs end to end on the deployed instance and its execution appears in the log.
Recreate credentials and share the encryption key
Recreate each API credential that a workflow needs, such as the new platform's admin API token, the storefront webhook secret and any email or messaging account, inside n8n's credential store rather than in workflow code. In queue mode, share the main instance's encryption key with every worker and webhook processor so they can decrypt the stored credentials, and store that key in your secrets manager. Restrict who can view credentials and document which service account each one belongs to. The step is done when each worker can run a test execution that uses a credential, and the key location and access list are recorded in your runbook.
Build and test each flow against staging
Build each workflow against the new platform's staging environment, with the webhook or polling trigger pointed at a test endpoint and the actions writing only to test data. For each workflow, run the normal case, the conditional branch that the merchant expects least often, and a deliberately failing call such as an expired token or a timeout, and record the output. Add an error workflow or failure notification so that failed executions reach a named owner rather than disappearing. The step is done when each workflow has a test record showing the input, the expected result and the observed result, and each failure path has a notification that has been checked.
Set up monitoring and retry rules
Define which executions are monitored and how they are retried. Confirm whether your n8n edition exposes log streaming and how you will ship execution logs to your existing monitoring stack. For actions that write orders, customers or inventory, decide whether a retry is safe, since a repeated call can duplicate a refund or a tag, and build idempotency checks where it is not. Set alerts for failed executions and for triggers that stop arriving. The step is done when a deliberately failed execution produces an alert, a retry produces the expected result without duplicates, and the owner has acknowledged the runbook.
Cut over workflows one at a time
Move workflows to production in small groups, starting with low-risk template-equivalent workflows. For each workflow, disable the Flow version and enable the n8n version on the same day, then watch the first live executions and compare their results with the Flow history. Keep the Flow workflow disabled but not deleted until the n8n version has run cleanly through a full business cycle that includes the workflow's typical peak. Ask the operations team to confirm each cutover in writing. The step is done when every workflow has a recorded cutover date, an owner sign-off and no unexplained gaps in its execution history.
Decommission Flow and archive the record
Once every workflow has run on n8n without unexplained gaps, remove the Flow workflows and uninstall the Flow app on the Shopify store, while the store remains live until the rest of the migration is complete. Archive the inventory, classifications, test records, credential list, encryption key location and cutover sign-offs with the migration documentation. Confirm with your compliance lead which records must be retained and for how long. The step is done when Flow shows no active workflows, the archive is stored in your document system, and the n8n runbook names an owner for ongoing upgrades and support.
How to monitor and retry automations you now run yourself
Shopify Flow hid the operational side of automation: execution history, failure alerts and retries were part of the hosted service. After you move to n8n, those duties become yours. Before cutover, decide where execution history will be kept, who receives failure alerts, and how a failed run is re-driven without creating duplicate orders, refunds or customer emails. n8n counts an execution as one run of a whole workflow regardless of the number of steps, so a single failed run can contain several completed actions. Your handlers must be written so that repeating a run does not repeat a side effect.
Plan the observability features against your n8n edition. Log streaming and environments with Git are listed on n8n's pricing page as included only in the Business and Enterprise plans, so a Community edition deployment must rely on its own logging stack and on exporting workflow JSON through your own version control. In queue mode, the main instance handles triggers and webhooks and passes executions through Redis to workers that write to PostgreSQL, so monitor the trigger path, the Redis queue and the worker pool as separate components. Confirm with n8n which of these pieces your chosen edition supports, and check the exact retry settings in the n8n release notes for the version you deploy, because retry behavior can change between releases.
Design every handler to be idempotent by using a stable business key, such as an order ID plus the event name, and by recording processed keys before performing side effects. Send failed payloads to a dead-letter store, either a PostgreSQL table or a queue you operate, with the original payload, error and attempt count. Route alerts from that store to a named on-call owner, and review the dead-letter queue on a fixed schedule. Test each automation by replaying a captured Shopify webhook payload in a staging environment, and confirm that a second run changes nothing. Ask your implementation partner to document these steps in the runbook as part of the handover.
What rebuilding Shopify Flow in self-hosted n8n costs and requires
What are the cost components of running Flow replacements in self-hosted n8n?
The main components are the n8n licensing tier, the servers that run it, the PostgreSQL and Redis services it depends on, the engineering time to build the workflows, monitoring, and ongoing maintenance. The Community edition is free to download and self-host, according to the n8n pricing page, but its license limits use to your own internal business purposes, so confirm with n8n whether your use fits. Paid cloud plans, Starter and Pro at 20 and 50 euros per month billed annually, are hosted by n8n and are not what you run yourself. Ask your team to price each line separately so the self-hosted total is visible.
Which parts of the n8n cost are one-time and which recur?
Building the workflows is one-time work, but the infrastructure and upkeep recur every month. Servers, database and cache hosting, backups, monitoring and security patching continue for as long as the automations run. Changes to the new platform's webhooks and APIs also recur, because each platform upgrade may require workflow edits. Note that n8n's pricing page counts one execution as a full workflow run regardless of steps, so volume growth affects hosting load rather than a per-step fee. Plan a recurring line for maintenance from the start.
Does our team have the skills to run n8n internally?
A team with Node.js, Docker or Kubernetes, PostgreSQL and webhook experience can run n8n, but the work is more than building workflows. Self-hosted queue mode routes triggers and webhooks through a main instance, passes executions through Redis to workers, and stores data in PostgreSQL, according to the n8n queue mode docs. Someone must manage the shared encryption key across workers, backups and upgrades. Multi-main high availability is restricted to Enterprise self-hosted deployments, so confirm the resilience you need before deciding who carries the on-call duty.
How long does rebuilding Flow workflows take, and what drives the duration?
Duration depends mainly on how many Flow workflows exist, how many conditions and actions each one has, and how well the new platform's events and APIs cover them. Workflows that use Send HTTP Request, which Shopify Flow limits to Grow, Advanced and Plus plans, need a replacement endpoint on the new platform. Custom partner app tasks that required Plus need a new integration, which usually takes the longest. Ask for a timeline per workflow group, not one total, and confirm the order of cutover so both systems do not run the same automation.
What should we ask for in a fixed-scope quote for this work?
Ask for a written scope that lists every Flow workflow to migrate, each trigger, condition and action, and the new platform event or API each one uses. Request deliverables for the n8n installation, queue mode setup, secret and credential handling, monitoring, retry rules and runbooks, plus a testing plan with sample orders. Ask who handles upgrades and whether ongoing support is a separate retainer. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with a written quote following from the agreed scope.
How do we monitor and retry automations once we run them ourselves?
Plan for failed webhooks, timeouts and downstream API errors from day one. Each failed run should be logged, alerted on and retryable, with a documented owner for each workflow. Use the n8n log and queue setup to route executions to workers, and confirm that your monitoring stack can receive n8n logs. Log streaming is included only in n8n's Business and Enterprise plans, according to the n8n pricing page, so check whether your chosen tier includes it before relying on it. Document which actions are safe to retry, such as idempotent updates, and which need manual review, such as payment or refund steps.
Do we need SSO and an enterprise license for this rebuild?
Not always, but the decision affects cost. SAML single sign-on is available on n8n's Business and Enterprise plans, with setup guides for Okta Workforce Identity and Azure AD, according to the n8n SAML docs. Environments with Git and log streaming are also limited to those tiers. The Business plan at 667 euros per month billed annually is self-hosted only, and Enterprise is custom priced. Files with .ee in their name are covered only by an Enterprise license, so confirm which features your team will use before choosing a tier.
What changes for your team after the switch
Today Shopify owns Flow's runtime. Shopify hosts the event watcher, runs the trigger, condition and action steps, and patches the platform beneath them. After the switch, your team owns every layer that was invisible before: the n8n version you run and its upgrades, the secrets each workflow uses to call your new platform's API, the credential encryption key that protects those secrets in the database, the availability of the instance that receives webhooks, and the webhook configuration on the commerce platform itself. If a webhook stops firing after a storefront deploy, nobody at Shopify will be paged. Assign a named owner for each of these before cutover, and write down who rotates keys and who approves an n8n upgrade.
Check the license and plan before you design the setup. n8n's Sustainable Use License allows you to use and modify it for your own internal business purposes, but it does not allow you to redistribute it commercially, so an agency or internal team that packages n8n workflows for other companies needs to read the terms with counsel first. Single sign-on through SAML is available only on the Business and Enterprise plans, according to n8n's pricing and SAML documentation, so if your security policy requires SSO for every operator who edits automations, price that plan into the total. Confirm which plan covers your access model with n8n directly, since plan features change. Files with .ee in their name fall outside the Sustainable Use License and need a valid Enterprise License, so keep them out of any build you ship.
How DeployOpen scopes and supports Flow replacement
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure. For Flow replacement, we turn your existing Shopify Flow workflows into a written inventory, rebuild them in self-hosted n8n against your new commerce platform's webhooks and APIs, and hand over monitoring and retry procedures you can run yourselves.
How we scope
- Inventory every live Flow workflow, its trigger, conditions, actions and owner before any build starts.
- Mark which workflows map to standard templates and which need custom logic or partner app tasks.
- Agree the written scope, deliverables and timeline in writing before work begins, since engagements are fixed-scope.
How we build
- Deploy n8n in your own cloud account, data center or air-gapped network, with the license terms reviewed first.
- Rebuild each workflow against the new platform's webhooks and APIs, with credentials stored and encrypted in your environment.
- Test each automation with recorded sample events, including failure paths, duplicate events and partial API errors.
How we hand over
- Document each workflow's trigger, logic, dependencies and expected outputs in a runbook your team can maintain.
- Set up execution monitoring, alerting and retry handling, and document how operators respond to failed runs.
- Walk your operations and engineering staff through the setup, the backup routine and the upgrade process before handover closes.
How we support
- Offer ongoing support, n8n upgrades and continuous testing of automations as a retainer after handover.
- Re-test workflows after platform upgrades, API version changes or new Shopify-to-platform event mappings.
- Confirm with your own licensing and legal teams how n8n's Sustainable Use License applies to your internal use.
