Tools and integrations

n8n process automation on a server that belongs to you

We build workflows that connect your systems and take the copy and paste work off people. n8n goes on your own server or in your own cloud, so customer data does not travel through an outside platform, and the Community licence for internal company use costs nothing. The first workflow runs 14 days after the workshop.

Diagram: a single AI agent wired at once into the systems a company already runs - CRM, Accounting and invoicing, Online sales, Team tools, Data and reporting, Instance hosting. The agent reads them as one whole instead of moving data between them by hand. AI agent CRM Accounting andinvoicing Online sales Team tools Data andreporting Instance hosting
  • EUR 0what the n8n licence costs once the instance sits on your own server. The Community edition is free for internal company use, so the only bill is the machine
  • 400+ appsservices n8n connects with ready nodes: CRM, accounting, shops, drive, SQL databases, language models. Anything else goes in over HTTP and the API
  • 14 daysfrom the workshop to the first workflow in production. A complex rollout with conditional logic and exception handling takes 2 to 4 weeks

The problem

Why does your customer data travel through servers you do not control?

A form submission goes out to a cloud platform, waits in a queue there, then comes back into your CRM. On the way it passes through a company nobody on the board could name. A data processing agreement exists somewhere, but nobody has read it, because marketing set the automation up on a Friday afternoon and it has simply been running since. In finance, healthcare or legal work that is not an oversight. It is a finding at the next audit.

The second thing is a bill that grows with use. The more steps a scenario has and the more often it fires, the further up the platform price list you climb. A workflow that loops over the lines of an order eats the quota faster than anyone worked out when they bought the plan. Automation that was meant to save time becomes a budget line someone watches every month, and the team quietly learns not to add steps.

n8n answers both of those differently, because the instance sits with you. The n8n documentation describes self-hosting as the default way to install it, through Docker on your own machine or in your own cloud (AWS, GCP, Azure). The data does not leave an environment your own IT department controls. The Community licence for internal company use costs nothing, and in the vendor cloud n8n bills a whole workflow execution rather than every step inside it.

  • Customer personal data passes through a platform that is missing from your record of processing activities
  • The automation bill climbs with every new step added to a scenario
  • A rule nobody can click together stays in a spreadsheet and in one person's head
  • Nobody knows who changed the scenario that stopped working on Wednesday, or when

Why now

What changed, so that your own instance no longer needs your own IT department?

Installing n8n today means one container and a database. Standing an instance up on a cloud machine, or on a server you already run, takes a few hours including the domain, the certificate and the backups. Nothing has to be built around it first, and nobody has to be hired for that one installation.

The second barrier that disappeared is connectors. n8n ships more than 400 ready nodes, and where a node is missing, an HTTP request to the system API does the job. When a rule is too involved to click together, a node with your own code sits inside the workflow: you write JavaScript or Python in it and work on the same data that flows through the run. The logic does not have to move out into a separate application.

The third change is language models. n8n calls them like any other API, so a workflow can categorise inbound requests, pull line items out of a PDF invoice or summarise a contract, and the data then goes only to the model provider. Questions about the processes themselves are a separate matter, the kind of question that sounds like how many invoices went through the automation yesterday. BOND, our company AI agent, answers those from your data in 5 to 10 seconds, with nobody logging into n8n.

What changes

What does a company get once n8n is running?

  • Customer data stays inside your network

    The instance runs on your server or in your cloud. Enquiries, contracts and CRM records pass through a machine your IT department grants access to, not through an outside platform.

    Installed with Docker on your own server, or in AWS, GCP or Azure

  • The bill does not grow with the number of steps

    With self-hosting you pay for the machine, not for executions. A workflow with twenty nodes and a loop over order lines costs the same as a workflow with three nodes.

    The Community licence for internal company use is free, the cost is the server

  • A rule you cannot click together still works

    When a condition needs a calculation, a fuzzy match on a company name or a rate worked out on the fly, a code node takes it. It stays in the same workflow, so no second application appears to maintain.

    JavaScript or Python in a Code node, on the data flowing through the run

  • Every change to a workflow has an author and a date

    Workflow history is a paid feature in n8n and Git sync needs the enterprise tier. On a Community install we version by exporting the workflow to a repository, so the previous version can be restored.

    Every workflow as a JSON file in a repository, with the author and the date of the change

  • A failure reports itself

    Every workflow has a separate branch for exceptions and a notification on a failed execution, sent to Slack, to Teams or by email. A broken integration does not wait for someone to notice a missing invoice.

    A notification within a minute of the error, naming the node that failed

  • Your team keeps it running without us

    After the rollout we train your people to read a workflow and make the simple changes: a different notification recipient, a new CRM field, a different time on the schedule. The documentation comes with the workflow.

    No black boxes: documentation and training inside the scope of the rollout

And in your company

What if n8n makes no sense for you?

Four sentences we hear most often. Two of them end with a recommendation for a different tool, and we say that at the consultation, before any quote goes out.

  • We have nobody to look after a server.

    Then self-hosted n8n is the wrong choice and we will tell you so. An instance needs updates, backups and someone who reacts when it stops responding on a Sunday evening. Without that person the answer is n8n in the vendor cloud or Make, where upkeep sits with the supplier. We build that too, and we do not push a private server to widen the scope.

  • Our system has no ready node in n8n.

    An HTTP request to its API usually covers it, and that is a matter of hours rather than weeks. The trouble starts when a niche system has no public API, or when another platform already has a ready connector to it and n8n does not. Then we work out which is cheaper to keep running, and sometimes the answer is Make or Zapier instead of our own service.

  • We have Zapier and it works.

    If the scenario joins two tools with one trigger and fires a few dozen times a month, migrating it makes no sense. The conversation gets interesting when a third system joins, or conditions, or customer personal data. Then the simple scenarios stay where they are and we move over only the ones that gain something.

  • Security will not let customer data go to the cloud.

    That is exactly why n8n comes up in this conversation. The instance sits in your network, so the data does not leave an environment you control. In the workshop we write down which fields each workflow actually needs and how long they are kept, so the security team gets a document rather than a reassurance.

CRM
HubSpot, Pipedrive, Salesforce, Zoho
Accounting and invoicing
Xero, sevDesk, QuickBooks, Fakturownia, Comarch Optima
Online sales
Shopify, WooCommerce, PrestaShop, BaseLinker, marketplaces
Team tools
Google Workspace, Microsoft 365, Slack, Notion, ClickUp, Jira, Asana
Data and reporting
BigQuery, Google Sheets, GA4, SQL databases
Instance hosting
Your own server through Docker, AWS, GCP, Azure

When n8n, and when a different tool

This table answers the question we put to ourselves in the workshop, before anything gets built. Not every situation ends with n8n, and that is fine.

Your situationWhat we recommendWhy
Customer personal data must not leave the companyn8n on your own serverthe instance sits in your network, the data never crosses an outside platform
A workflow with a dozen steps and thousands of runs a monthn8n on your own serverthe cost is the machine, not the number of steps executed
The rule cannot be clicked together, something has to be calculatedn8n with a code nodeJavaScript or Python inside the workflow, with no separate application
The workflow has to call a language model on data from your databasesn8n on your own serverthe data goes only to the model provider, not to an automation platform
Nobody on your side will run a server: updates, backups, monitoringn8n in the vendor cloud or Makewith self-hosting the upkeep is yours and that is a real cost
You need a ready connector to a niche system with no public APIMake or Zapierthere the connector is sometimes already built, in n8n it has to be written and maintained
Two tools, one trigger, a few dozen runs a monthZapier or Maken8n would mean a server to maintain for a ten minute job

The rows are a starting point, not a verdict. In the workshop we test them against your process, and it happens that one process produces two recommendations: some workflows move to n8n, the rest stay where they are.

How we work

Five steps from a process on paper to a workflow in production

Every step ends with something you can judge before you decide on the next one.

  1. Process workshop

    We map the process as it runs today: who does what, in which system, and how long it takes. We pick the part that eats the most hours and settle where the instance will live. The output is a document, not a promise.

  2. Design and instance

    We agree which systems get connected, what data passes through the workflow and which exceptions we handle. We stand the instance up on your server or in your cloud together with the domain, the certificate, the access rights and the backups.

  3. Build and testing

    Building a typical workflow takes 2 to 5 working days. We test on test data first, then on your own records from recent weeks, to surface the cases nobody thought of in the workshop.

  4. Production with monitoring

    The workflow goes live with an exception branch and a notification on failed executions. We export the starting version as JSON into a repository, so from day one there is a working state to go back to.

  5. Training and measurement

    We train your people to read a workflow and make simple changes, and we hand over the documentation. We measure the effect after 30 and after 90 days: executions, errors, and the hours that left the calendar.

Before and after

How the week changes for the person who retypes data today

Before

  • Monday starts with a CRM export pasted into a spreadsheet
  • The invoice is built from data somebody copies out of the order by hand
  • The board report is assembled from four files and one person's memory
  • You hear about a broken integration from the client who got no confirmation

After

  • Data moves between the CRM, the sheet and the database on its own, on a set schedule
  • The invoice is issued from the order data and a person only approves it
  • The report lands on Slack at eight on Monday, always from the same sources
  • The person on duty knows about a failed execution within a minute, with the node name

The first workflow runs 14 days after the workshop. We judge the effect on working time after 30 and after 90 days, on the execution count and on the hours taken off the calendar, not on an impression.

For the person signing this off

What an operations director gets out of it

The question of where your data sits stops being open. You can answer it with the name of a machine and show the workshop document that states which fields pass through each workflow and how long they are kept. That is the difference between talking to an auditor and explaining yourself to one.

The second point weighs more when next year's budget is set. With self-hosting the cost of automation is a machine, not a line that grows with the number of executions. In October you know what it will cost in December, and you are not watching an operations quota ahead of the busy season.

  • The instance in your infrastructure, access granted by your IT department
  • No licence fee with self-hosting, and the bill does not rise with usage
  • Every workflow documented and exported to a repository, independent of any one person
  • The workshop ends with a document that stands up without us and without our rollout

What it costs

The workshop has a published price, the rollout is quoted after it

The process workshop costs EUR 3,500 net per week, and runs from 1 to 7 weeks depending on how many processes are in scope. We quote the rollout after the workshop, because only then is it clear how many systems get connected, how many exceptions have to be handled and what state the data is in.

You pay for the instance directly to the supplier: a machine at your hosting provider or in your own cloud, and the Community licence for internal company use costs nothing. If a workflow calls a language model, you pay the model provider for that usage, roughly EUR 0.005 to 0.07 per query. There is no margin of ours on any of those bills.

  • Process workshop

    EUR 3,500 net

    per week, from 1 to 7 weeks depending on scope

    A self-contained piece of work. It ends with a process map, a tool recommendation and a rollout plan you could carry out without us.

    • A process map as it stands today, with the time and the owner of every step
    • A recommendation: self-hosted n8n, n8n in the vendor cloud or a different tool
    • The list of systems to connect and the data that passes through the workflow
    • The metrics to measure against after 30 and after 90 days
    Start with the workshop
  • Most popular

    Workshop and n8n rollout

    Quoted after the workshop

    scope follows from the number of systems and exceptions

    The option most companies choose. The first workflow in production 14 days after the workshop, a complex rollout 2 to 4 weeks.

    • Everything in the workshop
    • An n8n instance on your server or in your cloud, with backups
    • Workflows wired to the CRM, accounting, the shop and your databases, with an exception branch
    • Error notifications and workflow export to a repository
    • Team training and documentation for every workflow
    Talk about a rollout
  • n8n and an AI agent

    Quoted after the workshop

    for companies that ask about process status several times a day

    Everything in the rollout plus BOND, the company AI agent that answers from your data in a plain sentence.

    • Everything in the n8n rollout
    • BOND wired to the systems that feed the workflows, rollout around 2 months
    • An answer from company data in 5 to 10 seconds, with no login to n8n
    • AI nodes inside workflows: request categorisation, data out of PDFs, summaries
    Ask about the AI agent

The workshop ends with a document holding the process map, the recommendation and the rollout plan, and you can carry it out with your own hands or with anyone else. If it turns out that n8n makes no sense for you, because there is nobody to run the server or because a ready scenario in Make is enough, we say so and the matter ends at the workshop.

Frequently asked questions

What is n8n and how does it differ from Make and Zapier?

n8n is an open source automation tool you can install on your own server or in a private cloud. Make and Zapier run only as a service at the vendor, so the data always passes through their infrastructure. With self-hosted n8n you pay for the machine rather than for executions, and you can drop a node with your own code inside the workflow. For simple scenarios joining two tools, Make and Zapier are faster to set up.

Does our customer data leave the company?

With the instance on your server, the workflow processes data inside your network. It leaves only where you send it yourselves: to the API of a system you connect to, or to a language model provider if the workflow calls one. In the workshop we write down which fields each workflow genuinely needs, so nothing more than the decision requires gets sent.

How long does an n8n rollout take?

Building a typical workflow takes 2 to 5 working days, and from the workshop to the first automation in production is usually 14 days. A complex rollout with conditional logic, exception handling and several data sources runs 2 to 4 weeks. Standing up the instance itself, with the domain and the backups, is a matter of hours rather than days.

How much does an n8n licence cost?

The Community edition is free for internal company use, so with self-hosting there is no licence fee and you pay only for the machine. The vendor cloud version is a paid subscription and bills whole workflow executions rather than single steps. Workflow history and Git sync are features of the paid plans.

What if we have nobody to run the server?

Then self-hosting is not for you, and we say that at the consultation rather than after a contract is signed. An instance needs updates, backups and someone who reacts to a failure outside working hours. The alternative is n8n in the vendor cloud or Make, where upkeep sits with the supplier, and we run that kind of rollout too.

What about a system with no ready node in n8n?

If it has a public API, we connect to it with an HTTP request and that is usually a few hours of work. It gets harder when a niche system has no API at all, because then it comes down to file exports or an integration at the database level. It also happens that a ready connector exists in Make and not in n8n, and then we recommend that tool honestly.

How do you version workflows so we can go back to one that worked?

We export every workflow as a JSON file into a repository, so each change carries an author, a date and the option to restore the previous version. That works on a Community install too, where built in workflow history and Git sync only arrive with the paid plans. For changes in production we keep one rule: first a copy of the state that worked, then the edit.

Can we move scenarios we already have in Make or Zapier?

Yes, but we move only the ones that gain from it: those touching personal data, multi step ones, or ones firing thousands of times a month. A scenario does not migrate automatically, because the nodes carry different names, so we rebuild it in n8n and compare the output of both versions on the same data before switching the old one off. Simple two tool scenarios we usually leave alone, and we say so plainly.

Let us work out which process is worth moving first

The free consultation takes 30 minutes. You describe what gets done by hand today and where your data passes through outside platforms. We show what can be closed in n8n within the first 14 days, and what needs the data tidied up first. You do not have to share any systems at this stage.

We run at most two rollouts at a time, so that someone is genuinely sitting on each of them.

Book a free consultation

PS. If somebody in your company spent this month copying data from one system into another, that is exactly the process. Moved into n8n on your own server it stops taking up anyone's mornings, and customer data stays in the company. You write directly to Pawel, the founder of JustAutomate. Process first. Tools second.

Tell us your challenge

You write directly to Paweł. No spam.