← All posts
Buyer guide · 25 September 2026 · 6 min read

Self-hosted or hosted AI connector? The data boundary, the cost and the control

There are two routes to the same outcome: a hosted connector someone else runs, or one you deploy into your own account. The decision turns on three things, and price is the least interesting of them.

1. The data boundary

This is the one that actually matters. With a hosted connector, your orders and customer records travel through a third party’s infrastructure on the way to your assistant. That party becomes someone you have to describe: in your data map, in your due diligence answers, in the conversation with whoever asks where customer data goes.

With a self-hosted connector, the path is your assistant, your Worker, your order management system. No additional party. For a UK or EU business holding customer names, addresses and order histories, that is a materially shorter answer to a question you will be asked.

Neither is automatically wrong. A hosted connector from a serious supplier with a proper data processing agreement is a perfectly defensible choice. It is just a choice you have to document, and self-hosting is a choice you mostly do not.

2. Cost over time, not cost today

Hosted connectors are usually priced per month, often per seat. That is attractive at the start and it compounds. A self-hosted connector is a one-off: you buy the code, you deploy it, and from then on your running cost is whatever your own hosting costs. On Cloudflare Workers that is typically nothing at normal query volumes — it scales to zero when nobody is asking — but check Cloudflare’s own pricing rather than taking anyone’s word for it, including ours.

Do the three-year sum, not the first-month sum. And be honest about the other side of the ledger: self-hosting costs you an afternoon of setup and the ongoing, small obligation of being the person who owns a deployed thing.

3. Control, and what you can change

A hosted connector gives you the tools it gives you. If you need one more, you ask and you wait. If you need one fewer — say you want the write operations gone entirely before anyone is allowed near it — you need that to be a supported setting.

With the source in hand you simply delete them. That is the single most useful consequence of self-hosting in practice: the ability to make the connector smaller. Four write tools removed before deployment, and the blast radius of the whole exercise becomes disclosure rather than damage.

Who should pick which

Choose hosted if you have no technical person at all, you want it working this afternoon, and your appetite for owning infrastructure is zero. That is a reasonable set of constraints and there is no shame in it.

Choose self-hosted if you have someone who can run a deploy command, you expect to be asked where the data goes, you want the write tools gone, or you are an agency doing this for more than one client.

The agency case

For agencies and dev shops the calculation is barely a calculation. A per-client hosted subscription is a margin you do not keep and a dependency you cannot control. One purchase of source, deployed separately into each client’s own account, keeps every instance isolated and the relationship yours.

If the self-hosted route is the one that fits, you can self-host the Linnworks connector from production-tested TypeScript rather than building it — £249 one-off, twelve months of updates, unlimited deployments. The security questions worth asking first apply either way.

Questions, or want a tool we don't have yet? Email hello@grafto.co.uk — a real person replies.