DEV Community: Andrey Tverdomed

n8n 3.0 Upgrade: What Breaks in Production Workflows and How to Prepare

Andrey Tverdomed — Mon, 02 Nov 2026 21:47:24 +0000

Originally published on integrationstars.com.

The n8n 3.0 upgrade is one-way. n8n released the 3.0 beta on October 27, 2026 and plans the stable release for early December. There is no rollback from 3.x to 2.x except restoring a backup. Before you upgrade, run the Migration Report (Settings > Migration Report, n8n 2.39 or later), fix what it flags, take a full backup and test on a staging copy.

The timeline

Date	What happens
Oct 27, 2026	3.0.0 beta, opt-in
Early Dec 2026	Stable 3.x planned
Dec 31, 2026	Support for 1.x ends (no direct 1.x → 3.x path)
12 months after stable	2.x security and critical fixes end

What breaks, sorted by what it does to a running integration

Change	Effect	Where it hides
Cron and Interval removed	Published workflow won't activate	Older polling syncs. Use Schedule Trigger
Function, Function Item, Item Lists removed	Executions fail	Pre-1.0 workflows. Report can convert to Code
`$getPairedItem` removed	Code fails	Use `$('<node>').item`, `.itemMatching()`, `.pairedItem()`
Code task timeout 300 → 60 s	Long Code steps time out	Big transforms. Set `N8N_RUNNERS_TASK_TIMEOUT`
Execute Sub-workflow Local File / URL sources removed	Child can't load	Use Database or Define Below
AI Agent v1 removed	Old agent types stop	Rebuild on the latest Tools Agent
Slack credential needs Signature Secret	Slack Trigger stops	Approval / alert flows
Unverified community packages off by default	Nodes stop loading	`N8N_UNVERIFIED_PACKAGES_ENABLED=true` only if you accept the risk
Larger SSRF block list (with `default`)	Some private ranges refused	Adds `100.64.0.0/10`; allow-list with `N8N_SSRF_ALLOWED_IP_RANGES`

Self-hosted: Docker or nothing

3.0 doesn't publish a runnable n8n package to npm, and npm / npx n8n installs are unsupported. Move to Docker first, as its own change. Also: ~/.n8n/binaryData becomes ~/.n8n/storage (n8n won't start if both exist), encryption key rotation is on by default, and the Compression node limits drop to 256 MiB / 1,000 entries.

A six-step plan

Check your version (Settings > Personal). On 1.x, go to 2.x first.
Run the Migration Report; read both "Workflow issues" and "Instance issues".
Fix the workflows that create orders, invoices, payments or stock movements first. Review auto-migrated versions before publishing.
Search Code nodes for $getPairedItem, $evaluateExpression and anything running over a minute.
Back up, restore to staging, upgrade the copy, replay a day of real inputs and compare record counts.
Upgrade in a quiet window; confirm every scheduled workflow activated and your error workflow still fires.

The full version, with the Cloud notes and FAQ, is on our blog. Sources: n8n blog, v3.0 breaking changes, migration tool, n8n support FAQ.

Celigo vs Boomi for NetSuite: What the Vendor Docs Actually Say

Andrey Tverdomed — Fri, 30 Oct 2026 22:50:12 +0000

Originally published on integrationstars.com. Checked against each vendor's documentation on October 23, 2026.

Short answer: if NetSuite is the centre of your stack and most of your integrations are common pairings such as Shopify, Salesforce, Amazon or EDI trading partners, Celigo usually gets you to production faster, because much of the flow logic ships prebuilt. If NetSuite is one system among many, you need on-premise runtimes, or you also want API management and master data on the same platform, Boomi is the broader fit. That is our view as a Celigo partner; the facts below come from each vendor’s own pages, linked at the end.

Celigo vs Boomi at a glance

Category	Celigo	Boomi
Ownership	Privately held	Privately held by Francisco Partners and TPG, which bought Boomi from Dell in 2021
NetSuite connectivity	Hundreds of prebuilt NetSuite integration apps and templates, plus a dedicated NetSuite bundle	A NetSuite connector (SuiteTalk SOAP) and a NetSuite REST connector; flows are built as Boomi processes
Where it runs	Celigo’s hosted platform (integrator.io)	Atom runtimes that can be Boomi-hosted or installed on your own servers, with clustered runtimes for high availability
EDI	Native through B2B Manager (X12 and EDIFACT), with NetSuite EDI templates	Native B2B/EDI (X12, EDIFACT, TRADACOMS, HL7 and others), enabled as its own edition
Beyond integration	AI agents and MCP Management for governed AI access	API management, Data Hub (master data) and data integration product lines
Pricing	Not published; quoted by plan and volume	Not published; subscription tiers or pay-as-you-go usage pricing, with a 30-day trial
Typical NetSuite setup (our projects)	4–8 weeks with a prebuilt app	8–16 weeks for a custom process build

How each platform connects to NetSuite

Celigo describes three layers for NetSuite: fully managed integration apps, integration templates that act as starter blueprints, and flows you build yourself on the platform, with a dedicated NetSuite bundle installed in your account. Celigo lists NetSuite-specific features such as using saved searches as the source of an export, dynamic record lookups during imports, real-time triggers on NetSuite events, and concurrency controls that keep requests inside your NetSuite account limits. In practice, a NetSuite–Shopify or NetSuite–Salesforce project starts from a prebuilt app and becomes a mapping and edge-case exercise.

Boomi offers two NetSuite connectors. The original NetSuite connector uses the SuiteTalk SOAP web services API. The newer NetSuite REST connector calls NetSuite’s REST record API and supports OAuth 2.0 (client credentials with a certificate-signed JWT) or token-based authentication. Either way, you build the order, customer and inventory logic as Boomi processes on the canvas, which gives you more control and more work.

One date matters for both: Oracle plans to retire SOAP web services by NetSuite 2028.2, and new token-based authentication integrations can no longer be created from 2027.1. If an existing Boomi integration runs on the SOAP connector, plan a move to REST; whichever platform you use, start new NetSuite connections on OAuth 2.0. Our TBA deprecation guide covers the dates.

Where each one runs

Celigo runs as a hosted cloud platform, and Celigo says it can also reach on-premises and legacy systems. Boomi’s runtime is the Atom, a lightweight Java application that executes your processes. It can run in Boomi’s cloud or on your own infrastructure, it needs outbound HTTPS to Boomi but no inbound firewall ports, and for high volume or high availability Boomi offers a clustered runtime (formerly called a Molecule). If you have systems that must stay inside your network, such as an on-premise ERP or a database that cannot be exposed, that runtime model is one of Boomi’s real strengths.

EDI on both platforms

Both handle EDI natively, which older comparisons often get wrong. Celigo’s B2B Manager runs inside the Celigo platform, supports X12 and EDIFACT with trading partner profiles and validation, and includes NetSuite EDI templates for order-to-cash and procure-to-pay. Boomi’s B2B/EDI management uses trading partner components and supports X12, EDIFACT, TRADACOMS, HL7 and other standards over AS2, SFTP and web services; Boomi’s documentation notes that these features come in their own edition, enabled through your account representative. For NetSuite retail EDI (Walmart, Target, Amazon vendor), Celigo’s NetSuite templates shorten the work; for a large partner network across many back-end systems, Boomi’s breadth of standards counts. See our NetSuite EDI integration page for how we approach it.

How each vendor prices

Neither vendor publishes a price list. Celigo quotes platform licensing based on your plan and volume. Boomi’s pricing page lists subscription tiers by product line (for integration: Professional, Professional Plus, Enterprise and Enterprise Plus), a pay-as-you-go option billed on usage, and a 30-day trial of the full platform; Boomi also notes that some enterprise connectors cost extra. The practical way to compare is to get both quotes for the same list of flows and add the implementation effort, which is usually where the bigger difference sits for NetSuite: a prebuilt app needs less build time than a process built from scratch.

Which one to choose

Choose Celigo when NetSuite is the hub, your integrations are mostly common SaaS and ecommerce pairings, and your team wants prebuilt flows with monitoring rather than a blank canvas.
Choose Boomi when NetSuite is one of many systems, some of them on-premise, or when you want API management and master data management on the same platform as your integrations.
Either works for EDI; pick on the rest of your estate, not on EDI alone.

Moving from one to the other means rebuilding the flows, since flow logic is not portable between platforms. In our projects that typically takes 6–12 weeks depending on the number of flows, even when the connected systems stay the same.

Common NetSuite integration errors on either platform

Authentication failures. An expired or revoked token, a rotated certificate, or a role that lost a permission. Check the connection first, then the integration role’s permissions in NetSuite.

Boomi Atom offline. The runtime lost its connection to Boomi’s platform. Restart the Atom and check that outbound HTTPS is still allowed.

“Invalid value for field”. Usually a NetSuite internal ID mapped against an external ID field, or a list value that does not exist in the target account. Use a lookup in the mapping rather than a direct field-to-field map.

Duplicate records after retries. A webhook fires twice or a retry repeats a write that already succeeded. Check for an existing record by external ID or order number before creating a new one.

Other platforms to consider

If neither fits, the usual shortlist adds Workato for cross-department automation (see Celigo vs Workato), MuleSoft for API-led enterprise architecture (see Celigo vs MuleSoft) and n8n for developer-led teams that want open-source flexibility (see our n8n practice). For a wider comparison, see best iPaaS for NetSuite.

FAQs

Which is better for NetSuite integration, Celigo or Boomi?

For NetSuite-centric mid-market stacks, Celigo usually gets to production faster because it offers hundreds of prebuilt NetSuite integration apps and templates. Boomi connects to NetSuite through its NetSuite SOAP and REST connectors, but the flow logic is built as Boomi processes, so it fits better when NetSuite is one of many systems or some systems are on-premise.

Is Celigo cheaper than Boomi?

Neither vendor publishes a price list. Celigo quotes by plan and volume; Boomi offers subscription tiers or pay-as-you-go usage pricing. For common NetSuite pairings the total cost is often lower with Celigo because prebuilt apps reduce implementation work, but compare quotes for your own flows.

Do Celigo and Boomi both support EDI?

Yes. Celigo handles EDI natively through B2B Manager, with X12 and EDIFACT and NetSuite EDI templates. Boomi has native B2B/EDI management covering X12, EDIFACT, TRADACOMS, HL7 and other standards, enabled as its own edition.

Can Boomi run on-premise?

Yes. Boomi's runtime, the Atom, can run in Boomi's cloud or on your own infrastructure, needs only outbound HTTPS, and can be clustered for high availability. Celigo runs as a hosted cloud platform.

Who owns Boomi now?

Boomi was part of Dell (the product was long known as Dell Boomi). In 2021 Dell sold it to the private equity firms Francisco Partners and TPG, and it now operates as an independent, privately held company.

How long does it take to switch from Boomi to Celigo, or the reverse?

In Entech's projects, typically 6-12 weeks depending on the number of flows. Flow logic is not portable between the platforms, so every integration is rebuilt even when the connected systems stay the same.

Sources

Celigo NetSuite integration (celigo.com)
NetSuite EDI for B2B Manager (Celigo Help Center)
NetSuite REST connection and NetSuite connector (Boomi documentation)
Trading Partners and B2B/EDI platform (Boomi)
Boomi pricing (boomi.com)
Francisco Partners and TPG acquire Boomi from Dell (Technical.ly, 2021)

Vendor pages change; we checked these on October 23, 2026. Setup times are from Entech’s own projects.

Need help deciding between Celigo and Boomi for your stack? Entech Solutions is a certified Celigo partner. Talk to an integration expert.

NetSuite Next and Your Integrations: What Changes and What Doesn't

Andrey Tverdomed — Mon, 26 Oct 2026 15:52:10 +0000

Originally published on integrationstars.com. Based on Oracle's NetSuite Next FAQ as read on October 23, 2026.

NetSuite Next is Oracle's AI-powered next generation of NetSuite, with a refreshed interface and an assistant called Ask Oracle. For integrations, Oracle's FAQ says it is the same platform: the same data, roles, permissions, workflows and customizations, and the same connectivity through pre-built NetSuite connectors, SuiteCloud and the NetSuite Integration Platform. Most custom scripts are not expected to need changes, but some client scripts, form customizations and portlet scripts that manipulate page HTML may need review.

Our view: API-based integrations are the lowest-risk part, and anything that touches the NetSuite user interface is what to test first.

At a glance

What it is: a reimagined, AI-powered version of NetSuite with a refreshed user experience, built on the same platform and the same underlying account
Integrations: Oracle says NetSuite Next supports the same connectivity as the current experience: pre-built NetSuite connectors, custom integrations through SuiteCloud and the NetSuite Integration Platform
Review first: client scripts, form customizations and portlet scripts that directly change page HTML or structure; Oracle expects most other custom scripts to need no changes
AI: Ask Oracle is included with the NetSuite license; the NetSuite AI Connector Service works alongside it, and external AI services connected through it do not use AI units
Rollout: in phases, access granted per role, with preview accounts available for 30 days and sandboxes enabled at the same time as production
Our rule of thumb: test every integration in a sandbox with a NetSuite Next role before your users switch

What NetSuite Next is, and what it is not

Oracle describes NetSuite Next as the next generation of NetSuite: an AI-powered ERP that puts AI at the center of how the business runs and adds a refreshed user experience. It is not a separate product to migrate to. Oracle's FAQ says it is the same platform used by thousands of organizations today, and that transactions and other data stay in the same underlying account, so a record saved in one experience is visible in the other.

The headline feature is Ask Oracle, a conversational assistant that can answer questions, give insights and take action using natural language. Oracle says it is included with your NetSuite license, so you do not need a separate ChatGPT or Claude license for it, and that it does not browse the public internet.

What Oracle says stays the same for integrations

For anyone who owns an integration, the useful part of the FAQ is what does not change. Oracle states that you continue to use the same data, roles, permissions, workflows and customizations, and that NetSuite Next supports the same connectivity and integrations as the current NetSuite experience:

pre-built NetSuite connectors for common applications
custom integrations built through SuiteCloud
the NetSuite Integration Platform, for more complex or custom integrations

That covers the usual ways a Celigo or n8n integration reaches NetSuite. Because the data and roles are the same, an integration that reads and writes records through an API user does not obviously depend on which interface people click around in. Oracle's FAQ does not go into API details, which we come back to below.

What may need review: scripts that touch the page

Oracle says scripts, custom records, workflows and other customizations are expected to continue working. It makes one specific exception: some client scripts, form customizations or portlet scripts that directly manipulate HTML or page structure may need review. Here is how we would sort an integration estate against that statement.

What the integration uses	What Oracle says	What we would test
API calls from Celigo, n8n or another platform	Same connectivity as today; the FAQ does not discuss API specifics	The full happy path and an error path in a sandbox, plus scheduled runs
Server-side scripts (user events, scheduled scripts, Suitelets, RESTlets)	Most custom scripts do not require changes	One run of each script that your integration triggers or depends on
Client scripts, form customizations, portlets that change HTML or page structure	May need review	Open the form or dashboard in NetSuite Next with the real role and check the behaviour
Workflows	Expected to continue working	Trigger one workflow end to end, including its approval steps
Pre-built connectors	Same connectivity	A test order or record through each connector

How the rollout works, and how to test your integrations

Oracle says NetSuite Next is made available in phases, so the features may not yet be in your account. Account administrators see an in-application banner when the account is eligible. Access is granted per role: a user whose role has access sees a Switch to NetSuite Next option in the roles dropdown. A NetSuite Next preview account can be used for 30 days once it is set up, and for eligible customers the sandbox accounts get NetSuite Next at the same time as the primary account.

That gives integration owners a window. Here is the checklist we would work through (this part is our recommendation, not Oracle's):

List every integration and what it touches: API only, server-side scripts, or anything that depends on a form, portlet or client script.
Check whether your account shows the eligibility banner, and ask for a preview account if it does not.
In the sandbox, sign in with a role that has NetSuite Next and run each integration's normal flow and one failure case.
Review the client scripts, form customizations and portlets that change page HTML, and fix only what actually breaks.
Decide which user roles get NetSuite Next first. Integration-only roles have no need for the new interface, so in our view they can stay as they are.
Keep your integration monitoring on during the switch, so a change in behaviour shows up as an error and not as missing data.

NetSuite Next is not the only change worth planning for. Authentication is moving too; see our guide to the NetSuite TBA deprecation.

Where AI access fits: Ask Oracle, the AI Connector Service, Celigo and n8n

Ask Oracle is for people working inside NetSuite. If you want an AI assistant such as Claude or ChatGPT to work with NetSuite from outside, that is a different route. Oracle's FAQ says the NetSuite AI Connector Service works alongside Ask Oracle, and that external AI services connected through it do not consume AI units. Oracle also says AI operates within your existing roles and permissions, so it cannot access or act beyond what the user is authorized to do.

When the access needs to span NetSuite and other systems, or needs tighter, narrower tools, Celigo's MCP Server or n8n are the alternatives. We compare all three in NetSuite MCP: AI Connector vs Celigo vs n8n.

What we could not verify

Oracle's FAQ page shows no date, so we cannot say when it was last updated.
It does not discuss SuiteTalk, REST API behaviour, API versions or rate limits for NetSuite Next. Treat "same connectivity" as Oracle's statement of intent and confirm it in your own sandbox.
It mentions agents only in the overview, with no detail on how they work or are licensed.
Features arrive in phases, so what your account can do today may differ from what the FAQ describes.

Source

NetSuite Next FAQ (Oracle NetSuite Help), read October 23, 2026

Entech Solutions is a certified Celigo partner that builds and tests NetSuite integrations. If you want a second pair of eyes on your integrations before NetSuite Next reaches your account, see our NetSuite integration page or get in touch.

NetSuite MCP in 2026: Native AI Connector, Celigo MCP Server or n8n?

Andrey Tverdomed — Tue, 20 Oct 2026 13:32:20 +0000

Originally published on integrationstars.com. Based on Oracle's documentation as reviewed on October 15, 2026.

NetSuite MCP means letting an AI assistant such as Claude or ChatGPT work with NetSuite through the Model Context Protocol. NetSuite now does this natively: its AI Connector Service, with the MCP Standard Tools SuiteApp, gives an AI client tools for records, reports, saved searches and SuiteQL under the signed-in user's role. Celigo's MCP Server and n8n's MCP Server Trigger are the alternatives when the tools need to span other systems or be narrower and more tightly controlled. Our view: native for NetSuite-only, role-based work; Celigo or n8n when you need purpose-built tools.

What NetSuite's native MCP support is

Oracle's documentation says NetSuite has adopted the Model Context Protocol so that supported AI clients can access and interact with NetSuite data and functionality. In practice that is two pieces. The NetSuite AI Connector Service is the MCP endpoint. The MCP Standard Tools SuiteApp is the set of tools NetSuite ships for it, and you can build your own custom tools as well.

Oracle lists the standard tools in four groups:

Records: create a record, get a record, update a record, and get record-type metadata including fields and data types.
Reports: list all standard and custom reports, run a report, and list the accounting books, accounting contexts, nexuses and subsidiaries used to filter report results.
Saved searches: list saved searches and run an existing one.
SuiteQL: run a custom SuiteQL query (Oracle says only read-only queries are supported) and get SuiteQL metadata.

Two points from Oracle's pages matter most. First, the SuiteApp "includes tools that can create and update records in NetSuite using REST Web Services," so a connected assistant is not read-only by default. Second, access follows the role: the tools use the same access controls as the NetSuite UI and don't provide access beyond what the role allows, and a tool shows up in the AI client only if the role has all the permissions it needs.

What Oracle says about roles, setup and logging

Permissions. Roles that already have the MCP Server Connection permission can perform actions on any records available through REST, if their permissions allow. Oracle suggests reviewing which users and roles hold that permission before installing the SuiteApp, and creating a separate role with the permission plus specific record permissions.
Which role you sign in with. For ChatGPT, Oracle's instructions say to select a non-administrator role. For Claude, Oracle says you need the Pro plan or higher.
Integration record. The first connection from Claude installs an integration record (Public Client, Authorization Code Grant, with the AI Connector Service scope). Its State and Concurrency Limit fields can be edited.
Logging. An AI Connector Service (MCP) subtab in the execution log shows call date and time, duration, status, user email, HTTP status code, method and URL path, kept for 21 days in production and 7 in sandbox.
Compliance. Oracle states the service has not been assessed for HIPAA compliance and must not be used for ePHI unless you have independently determined that use is consistent with your obligations.

NetSuite AI Connector vs Celigo MCP Server vs n8n

The three are not interchangeable. The difference is who decides what the AI can ask for.

	NetSuite AI Connector	Celigo MCP Server	n8n MCP Server Trigger
What it reaches	NetSuite, through the MCP Standard Tools SuiteApp or your own custom tools	Systems connected in Celigo, such as NetSuite and Salesforce	Whatever your workflows touch
Who defines the tools	Oracle ships the standard tools; you can build custom ones	You, as a set of queries with fixed inputs and outputs	You, as workflows
Access control	The signed-in user's NetSuite role, via the MCP Server Connection permission	A scoped token managed by Celigo; read-only enforced at the MCP layer	Bearer token on the trigger endpoint; OAuth for instance-level access
Can it write?	Yes, create and update tools exist; SuiteQL is read-only	Only if you define a write; read-only tokens block writes	Only if you build one; best added behind validation and approval
Logging	Execution log: time, duration, status, user email, HTTP status, method, URL path	Each query: timestamp, model or token identity, input parameters, response hash	n8n's execution history for each workflow run
Setup effort	Install the SuiteApp, set up a role, connect the client	Define the queries and tokens in Celigo	Build and test the workflows

Which one to use

Start native when the work is NetSuite-only and the users already have the right roles. Finance and operations staff asking questions of their own data, with NetSuite's permissions doing the gatekeeping, is what it is built for.
Choose Celigo's MCP Server when the tools must be narrow and read-only by design, or span systems. "Order status by order number" and "inventory by SKU" as fixed queries are a smaller surface than a role that can reach every record.
Choose n8n when the tool needs logic. Validation, joining NetSuite with another system, transformation, or a human approval step before a write are workflow jobs.
Combine them. Native for exploratory questions, Celigo or n8n for the governed tools an agent uses repeatedly.

What stays your problem with any of them

Whatever sits between the AI and NetSuite, the AI reads what is in NetSuite. A customer memo or item description containing hidden instructions can steer a model, and a role that can reach too much quietly undoes the scoping. Our MCP security article covers the risks, and our system of record vs system of action guide explains why we put the control in a layer you own.

Need help choosing?

Entech Solutions is a certified Celigo partner and builds n8n workflows, including governed AI access to NetSuite. See our AI Agents and MCP Server page, or talk to an integration expert.

Sources (Oracle NetSuite Help): Get Started with the NetSuite AI Connector Service, MCP Standard Tools SuiteApp, Available Tools in the MCP Standard Tools SuiteApp, Connect to the NetSuite AI Connector Service.

n8n Pricing in 2026: What Each Plan Costs and What You Actually Get

Andrey Tverdomed — Fri, 16 Oct 2026 16:35:46 +0000

Originally published on integrationstars.com. Figures checked on n8n.io/pricing on October 15, 2026.

n8n pricing in one paragraph: n8n Cloud costs €20 a month (Starter, 2,500 workflow executions), €50 a month (Pro, 10,000) or €667 a month (Business, 40,000, self-hosted only), all billed annually, and Enterprise is by quote. The self-hosted Community Edition is free to download, but you pay for the server and for running it. n8n counts one execution per workflow run, however many steps it has.

n8n pricing at a glance

These are the plans on n8n's own pricing page as of October 15, 2026. The page shows prices in euros, defaults to annual billing, and doesn't show an effective date, so confirm on the live page before you buy.

Plan	Price	Executions a month	Hosting	Shared projects	Concurrent executions	Max run time
Starter	€20 a month, billed annually	2,500	Hosted by n8n	1	5	5 minutes
Pro	€50 a month, billed annually	10,000	Hosted by n8n	3	Up to 50	40 minutes
Business	€667 a month, billed annually	40,000	Self-hosted only (cloud on a waitlist)	6	Not listed	Not listed
Enterprise	Contact sales	Custom	Hosted by n8n or self-hosted	Unlimited	200+	40 minutes
Community Edition	Free	Not metered	Self-hosted	n/a	n/a	n/a

All plans list unlimited users and unlimited active workflows. Starter support is forum-only. The Cloud free trial includes 1,000 executions. Companies under 20 employees may qualify for a startup plan that n8n describes as 50% off Business.

How n8n counts an execution

An execution is one run of the entire workflow. n8n's pricing page states that it doesn't matter how many steps the workflow has or how much data it processes, and it does not bill per step. A workflow with twelve nodes that fires 2,000 times in a month is 2,000 executions. A loop that handles 500 records inside one run is still one execution.

That is the opposite of per-task billing, where every action in a run counts. Our n8n vs Zapier and n8n vs Make comparisons show how the three tools meter usage and what that does to the bill.

How often a workflow runs decides the plan

Because each run is one execution, the schedule matters more than the number of nodes. These are straight multiplications for one workflow over a 30-day month:

Runs	Executions a month	Fits within
Every 30 minutes	1,440	Starter (2,500)
Every 15 minutes	2,880	Pro (10,000)
Every 5 minutes	8,640	Pro (10,000)
Every minute	43,200	Above Business (40,000)

So a single polling workflow can outgrow Starter. Webhook-triggered workflows count one execution per incoming event, which makes volume harder to predict. If you can switch a poll to a webhook, or poll less often, you can stay on a smaller plan.

Three worked examples

These are illustrations built from the plan limits above, not quotes.

Small team, three light workflows. Lead routing runs 1,200 times a month, invoice notifications 600 and a weekly report 4. That is 1,804 executions, inside Starter's 2,500. Cost: €20 a month, or €240 a year billed annually.
One production sync every 5 minutes. 288 runs a day over 30 days is 8,640 executions. That is over Starter and inside Pro's 10,000, with about 1,360 left for everything else. Cost: €50 a month, or €600 a year.
An agent that answers every customer message. At 15,000 messages a month, one execution each, you are above Pro's 10,000. Business covers 40,000 but is self-hosted only, at €667 a month, about €8,004 a year, plus your own infrastructure. Enterprise is by quote. Batching or filtering messages before they trigger a run can change the answer.

What happens if you go over

According to n8n's pricing page, workflows keep running after you pass the quota, and overage charges may apply if you don't upgrade. Unpaid overages are invoiced 45 days after they occur. On Business, the page lists an overage of €4,000 for each extra bucket of 300,000 executions. Monthly plans can be cancelled at any time, effective at the end of the billing cycle. Annual plans run to the end of the term, and n8n states that it offers no pro-rata refunds.

Self-hosted n8n: free software, not free to run

The Community Edition is a standard self-hosted version of n8n available on GitHub, and downloading it costs nothing. What you pay for is everything around it: a server, backups, updates, security patches, monitoring, and someone responsible when it goes down. As a rule of thumb, self-hosting tends to win when you have in-house DevOps skills, high run volumes, or data you must keep on your own infrastructure. Hosted plans win when you want no maintenance.

One detail worth knowing before you commit: n8n says Business and Enterprise license keys must contact its license server daily, and that this ping includes production execution counts. Telemetry is on by default and can be turned off.

Limits to check before you buy

Polling schedules. See the table above. Add up every scheduled workflow, not just the biggest.
Concurrency and run time. Starter allows 5 concurrent executions and 5-minute runs, which long AI or batch workflows can exceed.
Log retention. 7 days on Starter and 30 days on Pro, per the page. Debugging an old failure needs enough retention.
AI Assistant credits. Starter lists 1,600 a month and Pro up to 9,600, and they refresh monthly without rolling over.
The page contradicts itself in places. The Pro card says up to 50 concurrent executions while the feature table shows "20 / 50", and the FAQ gives Assistant credits as "4,000 or 9,600, depending on your plan size". Confirm the figure that matters to you before paying.

Need help choosing or running n8n?

Entech Solutions has built on n8n for over two years, including AI-agent and NetSuite workflows. See our n8n automation services, our guide to n8n error handling, or get in touch and we'll tell you which plan, or which hosting model, fits your volume.

Source: n8n pricing page, checked October 15, 2026.

Celigo MCP Server Security: What It Blocks, What It Doesn't

Andrey Tverdomed — Thu, 15 Oct 2026 17:30:18 +0000

Originally published on integrationstars.com.

Security teams are right to be wary of connecting AI agents to real business systems. Every tool an agent can call widens what an attacker can reach through it, and security researchers have spent 2026 documenting exactly how: prompt injection (instructions hidden in content the AI reads) and tool poisoning (instructions hidden in a tool's own description). If you're deciding whether to let an AI assistant query NetSuite through Celigo's MCP Server, the useful question isn't "is MCP safe?" It's "which of these risks does Celigo's layer close, and which ones are still mine to design around?"

At a glance

Closed by the platform: credential exposure (the AI authenticates with a scoped token; NetSuite credentials never reach the model), write damage (read-only tokens are enforced at the MCP layer), and unlimited reach (the AI can only call the tools you defined)
Visible by default: every query is logged with timestamp, model/token identity, input parameters and a response hash, and rate limits cap how hard any client can hit NetSuite
Still yours to design: prompt injection hidden in ERP data the AI reads, data leaving through other tools connected to the same AI client, and over-broad tools that undo the scoping
The single riskiest combination: an assistant that can both read ERP data and send it somewhere (email, web, chat) without a human approving it

What Celigo's MCP layer closes by design

A direct AI-to-NetSuite connection puts API credentials into the model's context, prompts and logs, lets the AI do anything those credentials allow, and leaves no audit trail. Celigo's MCP Server (covered in detail in our MCP Server overview) removes each of those by construction:

No credentials in the model. The AI client authenticates with a scoped token managed by Celigo. A leaked prompt or log exposes a token you can revoke, not NetSuite access.
Read-only where you want it. Read-only tokens are enforced at the MCP layer, not by an instruction in the prompt, so even a fully manipulated model can't create, edit or delete records.
Only the tools you defined. Tools are built in Celigo with fixed inputs and outputs. The AI can call "order status by order number"; it can't improvise a query you never exposed.
Logged and rate-limited. Every call is recorded with who made it and what it asked, and rate limits stop a misbehaving client from hammering NetSuite.

That's most of what our AI agent governance article calls identity, access control and monitoring. What's left are attacks that work through a correctly authenticated, correctly scoped connection.

What it doesn't close on its own

Prompt injection hidden in ERP data

The MCP Server returns what's in NetSuite, faithfully. If a customer memo, an item description or a vendor note contains text like "ignore your previous instructions and...", the AI client reads it as part of the answer, and the model decides what to do with it. Celigo can't tell an innocent memo from a malicious one; nothing at the transport layer can. Microsoft's developer guidance on MCP covers this under the name indirect prompt injection.

Data leaving through other tools on the same assistant

Read-only stops the AI from changing NetSuite. It doesn't stop the AI from repeating what it read somewhere else. If the same assistant also has an email tool, a web-fetch tool or a chat integration, an injected instruction can turn "look up this customer's balance" into "look it up and send it out." The leak happens in the AI client, entirely outside Celigo.

Tool poisoning from servers you don't control

Tools you build in Celigo are under your control. A third-party MCP server added to the same AI client is not, and its tool descriptions are read by the same model that holds your ERP data. A poisoned description from one server can steer how the model uses another.

Tools that are wider than the question

Scoping only works if the tools are narrow. A tool like "run any saved search" or "return the full customer record" quietly hands back most of what the token restrictions were meant to withhold, including the free-text fields where injected instructions live.

The line, in one sentence. Celigo's MCP Server controls what the AI can reach and do in NetSuite. It can't control what the AI does with what it read. That's decided by the AI client and the other tools connected to it.

The design choices that close the gap

One question per tool. "Inventory by SKU" returning quantity and location, not "item lookup" returning everything. Fewer fields returned means less room for hidden instructions and less to leak.
Leave free-text fields out unless the question needs them. Memos, notes and descriptions are where injected text lives. Numbers, dates and statuses are safe to return; prose is a decision.
Keep ERP access off assistants with outbound tools, or require a person to approve anything that assistant sends, posts or emails.
Don't mix servers casually. An assistant that queries NetSuite shouldn't also load arbitrary third-party MCP servers.
One token per AI client. Then every line in Celigo's query log points to a single assistant, and revoking one doesn't break the others.
Actually read the log. A weekly look at query volume and unusual parameters catches misuse that no single call would flag.

FAQ

Is Celigo's MCP Server secure enough to connect an AI assistant to NetSuite? It removes the biggest risks of a direct connection: no credentials in the model, read-only enforcement, every query logged. Prompt injection in returned data and leaks through other tools on the same assistant depend on how the tools and client are set up.

What is prompt injection in an MCP setup? Instructions hidden in content the AI reads, which in an ERP setup is often a free-text field on a record. Narrow tools that return only the fields a question needs shrink the risk.

What is tool poisoning? Malicious instructions in a tool's name or description. The risk mostly comes from third-party MCP servers connected to the same AI client, not from tools you define in Celigo.

Should the AI that queries NetSuite also be able to send email or browse? Not without a human approval step. Read access plus an outbound channel is what turns an injection into a data leak.

Need this built?

Entech Solutions builds governed AI access to NetSuite and Salesforce on Celigo, including the tool design and client setup that decide how exposed you actually are. See our AI Agents and MCP page, or get in touch to review a planned setup before it goes live.

Further reading: Microsoft: Protecting against indirect prompt injection attacks in MCP and Cloud Security Alliance: Agentic MCP Security Best Practices.

Race Conditions in n8n AI Agent Workflows (and the Fix)

Andrey Tverdomed — Tue, 13 Oct 2026 16:22:39 +0000

Originally published on integrationstars.com.

The short version: check shared state (a calendar, a stock count, a CRM record), then act on it, with nothing stopping a second execution from checking in between. An AI step stretches that window from milliseconds to seconds. The fix is to claim before you act, give every business action an idempotency key, and re-check the real system right before the final write. A better prompt, a stricter model or n8n queue mode will not fix it, and queue mode makes races more likely because it adds parallelism.

Why this keeps happening

A popular n8n appointment-booking workflow shared on LinkedIn this month drew the same comment from at least seven different engineers: what happens when two people ask for the same slot at once? The answer, in almost every check-then-act workflow, is that both get it.

n8n runs every incoming request as its own execution, and executions run in parallel. Execution A reads the calendar: 3pm free. Execution B reads the calendar: 3pm free. A books 3pm. B books 3pm. Each step did exactly what it was built to do. The failure lives in the gap between them, which is why it never shows up in testing, where requests arrive one at a time.

Why the AI step makes it worse

In a plain workflow, check and act might sit a few hundred milliseconds apart. Put an AI Agent node between them (reading the request, deciding which slot fits, calling a tool, maybe confirming with the user) and that gap grows to several seconds, sometimes much longer when there's a conversation in between. The probability of a collision grows with that window. An agent that works flawlessly in a demo can double-book within its first busy hour.

Agents also add their own duplicates: a model may call the same booking tool twice in one run, or a timeout makes the workflow retry a call that actually succeeded. Neither is the model "making a mistake" in a way a better prompt fixes. They're ordinary distributed-systems problems arriving through a new door.

Where duplicate and parallel runs come from

Simultaneous requests: two users, two webhook calls, two executions, same resource
Webhook redelivery: senders like Stripe, and most webhook providers, resend an event if they don't get a fast enough response
Retry On Fail: n8n's node-level retry re-runs a step after a timeout, even if the first attempt actually went through on the other side
Agent tool calls: the model calls the same tool twice, or a second agent run picks up the same task
Queue mode with multiple workers: more executions in parallel by design

The fix: claim first, key every action, re-check before writing

1. Claim the resource before acting on it

Instead of "check, then book", the workflow first tries to claim the slot in a store that refuses a second claim. Only the execution that wins the claim continues. In Postgres that's a single insert against a unique constraint:

INSERT INTO slot_claims (slot_id, execution_id)
VALUES ('2026-10-08T15:00', 'EXECUTION_ID')
ON CONFLICT (slot_id) DO NOTHING
RETURNING slot_id;

(In n8n, EXECUTION_ID is the expression for the current execution's id.)

If a row comes back, this execution owns the slot. If nothing comes back, someone else got there first, so route to a clean "that time was just taken" response. A Redis key set only if it doesn't already exist does the same job. What matters is that the database or Redis makes the decision atomically, not an IF node comparing two values that may already be stale.

2. Give every business action an idempotency key

Build one ID per real-world action (the booking request ID, the order ID, the webhook event ID), record it before the side effect, and check it first on every attempt. When the webhook resends, the retry fires, or the agent calls the tool again, the second attempt sees the key is already done and stops instead of booking or charging twice. Where the downstream API accepts an idempotency key of its own (Stripe does), pass it through as well.

3. Re-check the real system right before the final write

Your claim table protects against other runs of this workflow. It doesn't know about someone booking the same slot directly in the calendar app. A last read immediately before the write, and a clear failure path if the slot is gone, covers what the claim can't.

Let the agent decide, not commit. The cleanest structure keeps the AI out of the critical section entirely: the agent figures out what the user wants, then hands a structured request to a plain, deterministic sub-workflow that does claim, re-check, book. The slow, unpredictable part stays outside the window where races happen.

When the booking fails: release the claim, confirm the key

Added October 15, 2026, after a reader pointed out that the fix above leaves two failure paths open.

The claim and the idempotency key both prevent duplicates, but each can leave a stuck record if the booking call fails or times out after them. Close both.

Give the claim a status and a clock

If an execution wins the claim and the calendar call then fails, the plain insert above leaves the row behind and the slot is blocked for everyone until someone deletes it by hand. Add a status and a timestamp, and let a lost claim be taken again:

CREATE TABLE slot_claims (
  slot_id      text PRIMARY KEY,
  execution_id text NOT NULL,
  status       text NOT NULL DEFAULT 'claimed',  -- claimed, booked, released
  claimed_at   timestamptz NOT NULL DEFAULT now()
);

-- claim: succeeds on a new slot, or on a slot that was released
INSERT INTO slot_claims (slot_id, execution_id)
VALUES ('2026-10-08T15:00', 'EXECUTION_ID')
ON CONFLICT (slot_id) DO UPDATE
  SET execution_id = EXCLUDED.execution_id, status = 'claimed', claimed_at = now()
  WHERE slot_claims.status = 'released'
RETURNING slot_id;

Then use the status on every path. When the booking succeeds, set it to booked. When it fails, the error path sets it to released so the slot comes back. For claims that never reached either (the workflow crashed, or the call hung), run a scheduled cleanup that frees claims still claimed after longer than a booking should take. One caution: a timeout does not prove the booking failed, so check the real calendar before releasing, or you will free a slot that was in fact booked.

Record the key as pending, mark it done after confirmation

The mirror problem: if the key is recorded before the side effect and the side effect fails, the retry sees the key and stops, and the booking is lost without a trace. Record the key as pending first and mark it done only after the API confirms. A retry then behaves by what it finds:

Key is done: stop, the action already happened.
Key is pending and recent: another run is working on it, so wait or stop.
Key is pending and old: check the real system for the booking first. If it exists, mark the key done. If not, retry the action.

How to test for it before customers do

Fire the same request at the webhook twenty times at once (a short script or a load-testing tool does it in seconds) and count the bookings. One is the right answer. Then resend a single webhook event three times and check that nothing happens twice. Then test the failure path: kill the booking call halfway (a timeout or an error injected after the claim) and check that the slot comes back and that a retry neither double-books nor loses the booking. All three tests take minutes and catch failures that ordinary click-through testing never will.

Need this built?

Entech Solutions builds n8n agent workflows that hold up under real traffic: claim-first concurrency, idempotent side effects, and load tests before launch. See our n8n AI and agentic workflow design page, our guide to n8n error handling, or get in touch to review a workflow you already run.