Automation you actually own.
n8n runs on your own infrastructure, inside your own network boundary. We use it when the data cannot leave the estate, or when a hosted tool starts billing by the task and the volume stops making sense. The workflows live in version control and are deployed like the rest of your software.
The automation layer is somebody else's tenant.
Records leave your network to be transformed and come back. The logic sits in a vendor's editor with no diff and no history. The bill scales with the number of steps, so the cheapest way to run a job is to write worse workflows. None of that is a problem until it is all three at once.
Your data, your boundary.
n8nWhat a self-hosted instance needs.
The instance itself
n8n deployed inside your network with queue mode, a managed Postgres behind it and workers that scale separately from the editor. Credentials come from your secret store, not from a field somebody typed once.
Workflows kept in git
Every workflow exported, reviewed and promoted from staging to production like code. A change to a live automation has an author, a diff and a way back.
Retries and a dead letter path
Failures are caught, backed off and parked somewhere a person can see them, with the payload intact. A job that fails overnight is a queue item somebody works through, not a silence.
Integrations without a public node
Internal APIs, legacy endpoints and databases reached over private networking, with the request and response shapes pinned so a partner's change breaks a test rather than a Monday.
Volume work off the per-task meter
Enrichment, file processing, scheduled syncs and anything that runs per record moved onto compute you already pay for, where the marginal run costs nothing.
Observability an operator can read
Execution logs shipped to the same place as the rest of your systems, with alerting on the workflow that matters rather than on every error the instance emits.
Sort, stand up, migrate, hand over.
Sort
Which automations have to stay inside the boundary, which are expensive per task, and which are fine where they are. Not everything needs to move.
Stand up
The instance, the queue, the database, the secrets and the deploy path, built so a workflow reaches production the same way any other change does.
Migrate
Workflows moved one at a time and run in parallel with what they replace, until the outputs match on real volume and the old one can be switched off.
Hand over
Runbooks for the failure modes, the upgrade path written down, and your team building workflows themselves while we are still there to review them.
Self-hosted means somebody has to host it.
An instance on a single box with the database on the same disk works beautifully until the day it does not. Upgrades, backups, queue depth and credential rotation are now yours. We build it so those are boring, and we say plainly when a hosted tool is still the better answer.
Moving to HubSpot, or joining the two.
Tell us what your automation bill meters.
Tell us what you are running
What the system does today, where it breaks, and when it has to work. An engineer reads it — you get an answer inside one business day, not a sequence.