n8n + Strapi

PostgreSQL, unless you already run MySQL. The deciding detail is n8n, not Strapi: Strapi works well on all three, but n8n only stores its own data in SQLite or PostgreSQL. With PostgreSQL, both tools share one database server (in separate databases), so there is a single service to back up and monitor. With MySQL, Strapi's content sits in MySQL while n8n keeps its history elsewhere, which is fine when MySQL is already part of your infrastructure but means two database systems to look after. SQLite is for trying the integration locally; move Strapi to a server database before real editors start using it.

Filter inside n8n. Strapi's webhook settings let you pick which events fire (entry create, update, publish, unpublish, delete, and media events), but not which content types, so every webhook sends events for every collection. Each payload names its content type in the model field, so the first node after the Webhook trigger should be a Switch or IF node that routes on it and drops the rest. It also pays to choose publish and unpublish over update when the workflow only cares about live content, since update also fires on every draft save.

Yes: n8n's built-in Strapi node creates, reads, updates, and deletes entries using a Strapi API token, and the HTTP Request node covers any endpoint it doesn't. The trap is that n8n's own update fires Strapi's webhook again, so a workflow that listens for updates and then writes a field back will trigger itself. Either have the workflow check whether the field already holds the value before writing, or listen for publish events while writing to the draft. Create a dedicated API token for n8n with access limited to the content types it actually edits.

Self-host when you are already running a server for n8n: adding Strapi to the same machine costs almost nothing extra, and both tools can share one PostgreSQL server. Strapi Cloud makes sense when nobody wants to own Strapi upgrades, database backups, and media storage, all of which it handles. Two things change with Cloud: n8n's webhook URL must be reachable from the internet, so a self-hosted n8n needs a public endpoint, and the database stays on Strapi's side, so there is no shared server. The Pricing section has the Cloud plan figures.

Same automation layer, different kind of CMS. Strapi is open source and runs on your own server, so the CMS costs a server rather than a subscription, the content lives in your database, and you can change the CMS itself with custom code. Contentful is fully managed: nothing to operate, but its first paid plan is a big step up from the free one, and content lives on Contentful's platform. Pick this stack when you want to own the CMS and its data; pick the Contentful variant when a content team wants a hosted editor with no operations work. The n8n side is similar, but the webhook payloads differ, so workflows need adapting when moving between them.