Everyone wants to build "Zapier for X" on an open-source engine right now. n8n just raised at a $2.5B valuation, AI agents need somewhere to run their tool calls, and every vertical (clinics, realtors, agencies) is begging for automations they don't have to configure themselves.
I've shipped a few of these. The engineering is the easy half. The half that bites is a decision most tutorials skip: will your customers build workflows, or only benefit from them? That single answer decides your license, your architecture and your margins.
This post walks through both architectures, the license line for n8n and Activepieces, and the parts of multi-tenancy nobody mentions until production.
The license line, in one table
| n8n | Activepieces CE | |
|---|---|---|
| License | Sustainable Use License (fair-code) | MIT (paid features in packages/ee/ are commercial) |
| Run your own business on it | Yes | Yes |
| Build workflows for clients on your instance, charge for it | Yes, if clients get outputs, not access | Yes |
| Hidden backend, end users never configure workflows | Yes | Yes |
| Customers build or edit their own workflows in your product | Needs an Enterprise license | MIT core allows it; embedding their builder UI is a paid deal |
| Fork and rebrand as your own automation product | No | MIT allows forking; keep the notice; paid features excluded |
Sources: the n8n license FAQ states that free use applies when "workflows are only created or modified by you or people in your organization," and that letting external users build or configure workflows (including through your own UI, API, MCP or an AI agent) is not allowed without an Enterprise license. Activepieces documents its MIT core and commercial ee folder. Not legal advice; get it in writing from the vendor for anything customer-facing.
So:
- Pattern A, "Outcomes as a service": you design the workflows, customers just turn them on. n8n works great here.
- Pattern B, "Customers build": customers drag their own steps. Start from Activepieces CE or budget for an n8n Enterprise license.
Pattern A: n8n as a hidden engine
Your app owns the UI, tenants, billing and credentials. n8n only ever talks to your backend.
Customer UI (your app)
| toggles "Missed-call text back" for Clinic #42
v
Your API ──> Template registry (versioned workflow JSON)
| |
| instantiate with tenant params (phone, calendar id, timezone)
v v
n8n (queue mode: main + workers + Redis) <── webhook in from Twilio/Calendar
|
v
Your API callback ──> tenant DB (Postgres, row-level security)
Key implementation points:
1. Templates, not ad-hoc workflows. Store each automation as versioned workflow JSON in your repo. When a tenant enables it, your API creates (or updates) a workflow through the n8n API with tenant-specific values injected. Never let tenant-specific edits drift outside version control.
2. Tenant context travels in every execution. Pass tenant_id in the trigger payload and keep it on every downstream call. Your callbacks validate it against a signed token, not trust it.
3. Credentials never live in n8n per tenant if you can avoid it. Keep OAuth tokens in your own vault (encrypted columns or a secrets manager) and have the workflow call your API to perform the action. n8n then needs one credential: your internal API key. This keeps tenant offboarding to a single DELETE in your database.
4. Run queue mode from day one. A single n8n process will stall when one tenant's workflow loops. Main instance plus workers plus Redis lets you scale workers horizontally and isolate noisy tenants onto their own worker pool later.
5. Idempotency on every webhook. Phone systems and calendars retry. Hash the event ID and drop duplicates before the workflow runs, or you'll text a patient three times.
Pattern B: customers build their own flows
If the product is the builder, you inherit everything Zapier solves:
- Tenant isolation: separate projects or namespaces per tenant, and an enforcement layer in your API so one tenant can't trigger another's flows.
- Rate limits per tenant: executions per minute and per month, enforced before the engine, not after.
- Connector sandboxing: custom code steps run untrusted code. Run them in isolated workers with CPU, memory and network egress limits.
- Usage metering for billing: count task runs per tenant from execution logs, push them to your billing system nightly.
This is real platform engineering. Price it accordingly, or start with Pattern A and graduate.
Where AI agents fit
The fun part: an LLM step is just another node. The patterns that hold up in production:
- Classify, then act. Use a small, cheap model call to classify the incoming event ("reschedule request", "complaint", "new lead"), then route to deterministic steps. Don't let a model free-run your customer's calendar.
- Tool calls go through your API. If an agent can book, cancel or refund, those are your endpoints with your validation and audit log, never direct third-party calls from the model.
- Human-in-the-loop for money and messages. Anything that sends money or an outbound message on a customer's behalf gets an approval step until the error rate is proven.
- Log the prompt, the output and the decision per tenant. When a clinic asks "why did it text that patient?", you need the answer in one query.
Cost sketch for 50 tenants (Pattern A)
Rough monthly numbers for a modest deployment, illustrative only:
- n8n main + 2 workers + Redis on small instances: low hundreds of dollars.
- Managed Postgres: tens to low hundreds.
- LLM classification calls: cents per tenant per day if you use a small model and cache aggressively.
- SMS and telephony: usually your biggest variable cost, pass it through.
At $199 per tenant per month, 50 tenants is roughly $10K MRR on a stack with no license fees for Pattern A. The expensive line item is engineering time for onboarding integrations, not compute.
Checklist before you write code
- [ ] Decide Pattern A or B, and confirm the license in writing for B.
- [ ] Versioned workflow templates in Git.
- [ ] Tenant credentials in your vault, not the engine.
- [ ] Queue mode and per-tenant rate limits.
- [ ] Idempotent webhooks.
- [ ] LLM steps classify, your API acts, humans approve money and messages.
- [ ] Per-tenant execution logs for support and billing.
Get those right and "Zapier for clinics" stops being a weekend demo and becomes a business.
I run Axionry, an AI product development studio. We build exactly these products: custom AI agents, multi-tenant automation platforms and vertical SaaS MVPs. If you want a second pair of eyes on your architecture or license choice, book a call.
Top comments (0)