n8n Self-Hosting Guide: Own Your Automation on EU Infrastructure

What Self-Hosting n8n Means

Self-hosting n8n means running the n8n workflow automation engine on a server you control, instead of paying for n8n Cloud or a per-task SaaS like Zapier. You install n8n on a virtual private server (VPS), point it at your own database and every workflow execution happens on hardware you own. Your customer data, API keys and webhook payloads never leave your infrastructure.

n8n is a node-based automation tool: you connect triggers (a webhook, a schedule, a new CRM record) to actions (send an email, write to a database, call an API, run an AI model) by wiring nodes together on a visual canvas. The difference from Zapier or Make is not the canvas. It is where the engine runs and how you pay for it.

This guide covers why companies self-host n8n, the licensing reality (it is not what most people assume), what the free Community Edition lacks, a Docker-based setup outline, how to secure it properly and keep it updated, how to scale it with queue mode and the honest tradeoff between doing it yourself and having it managed. Every statement was checked against the official documentation as of 26 September 2026 and is linked.

If you want the implementation done for you on German servers or if you are weighing custom automation infrastructure against SaaS more broadly, see our n8n automation service.

Why Self-Host n8n at All

There are three concrete reasons and they compound.

Reason 1: No Per-Execution Fees

This is the cost argument and it is the sharpest one. n8n counts one entire workflow run as a single execution, no matter how many steps it contains (n8n pricing page). Zapier charges per task: every successfully completed action step is one task, the trigger itself does not count and some actions cost more than one task (Zapier pricing page).

Work through the math on a realistic workflow:

Workflow: 10 nodes (trigger + 9 actions)
Volume:   10,000 runs per month

n8n  (self-hosted): 10,000 executions -> server cost only
Zapier (per task):  9 actions x 10,000 = 90,000 tasks billed

That is nine times as many billable units for identical work. On Zapier or Make, cost scales with how much you automate, which quietly punishes success. On self-hosted n8n, cost is the server and the server does not care whether you run 1,000 or 1,000,000 executions until you genuinely outgrow the hardware.

For comparison, the n8n Cloud prices: the Starter plan costs 20 EUR per month for 2,500 executions, the Pro plan 50 EUR per month for 10,000 executions, both billed annually. The Business plan at 667 EUR per month for 40,000 executions is not a cloud plan but a licence for self-hosted instances. The self-hosted Community Edition is free; you pay only for the VPS.

What a suitable VPS costs is shown by the Hetzner Cloud price list for the German locations Falkenstein and Nuremberg (as of 26 September 2026, monthly, including IPv4; VAT depends on the country setting on the page):

Plan	vCPU	RAM	Storage	Price per month
CX23 (Cost-Optimized)	2	4 GB	40 GB NVMe	5.99 EUR
CX33 (Cost-Optimized)	4	8 GB	80 GB NVMe	8.99 EUR
CPX22 (Regular Performance)	2	4 GB	80 GB NVMe	19.99 EUR
CPX32 (Regular Performance)	4	8 GB	160 GB NVMe	35.99 EUR

The Cost-Optimized line was marked as temporarily unavailable on the Hetzner page at the time of checking, so verify current availability. n8n names at least 2 vCPUs and 4 GB of RAM as the floor for its own Docker Compose setup (Docker Compose guide). For n8n with PostgreSQL and a task runner container, the 8 GB class is the more relaxed choice.

Reason 2: Data Sovereignty and GDPR

When you self-host n8n on an EU or German server, the data flowing through your workflows stays on your infrastructure. There is no third-party SaaS processor sitting between your CRM and your database, which means no Auftragsverarbeitungsvertrag (data processing agreement) with a US cloud vendor and no question about transatlantic data transfers. n8n itself puts it this way in its privacy documentation: for self-hosted versions, n8n is neither a controller nor a processor, because the company does not manage your data.

In fairness: n8n Cloud itself runs on Microsoft Azure in EU regions according to the list of sub-processors. The big difference arises against per-task SaaS providers headquartered and processing in the US. Self-hosting goes one step further and takes the processor out of the chain entirely.

This matters most when workflows touch personal data: lead records, support tickets, invoices, anything with a name and an email. Keeping that processing inside your own perimeter is a materially simpler compliance story than routing it through a US-headquartered automation cloud. This is fachliche Einordnung, not legal advice, but it removes an entire category of data-transfer questions from the table.

Two duties stay with you: you are responsible for deletions and n8n recommends pruning old execution data automatically for that reason. You control this with EXECUTIONS_DATA_PRUNE and EXECUTIONS_DATA_MAX_AGE (default: 336 hours, which is 14 days), described under Manage execution data. And a self-hosted instance sends anonymous telemetry to n8n by default; how to switch that off is in the hardening section.

For teams whose whole reason for being on EU infrastructure is compliance, this is often the decisive factor before cost even enters the conversation.

Reason 3: No Vendor Lock-In

Your workflows are JSON. Your engine is software you can move between servers. Your database is standard PostgreSQL. With n8n export:workflow --backup and n8n export:credentials --backup you export workflows and credentials as readable JSON files and import them on another instance (Back up and restore). If you outgrow one VPS, you move to a bigger one or to a cluster. Nothing about your automation logic is trapped inside a proprietary platform you cannot export from.

The Licensing Reality: n8n Is Fair-Code, Not Open Source

This is the single most misunderstood thing about n8n and getting it wrong leads to bad decisions.

n8n is not open source in the OSI sense. It is fair-code, published under the Sustainable Use License version 1.0. Files with .ee. in their name fall under the separate n8n Enterprise License. The source is available on GitHub and the Community Edition is free to run, but the licence carries restrictions that a true open-source licence would not. n8n itself writes in its licence documentation that it therefore does not call itself open source.

What the Sustainable Use License allows according to the n8n licence FAQ:

• Running n8n for internal business purposes at no cost, including several instances
• Running it for personal projects, learning and research
• Modifying the source for your own use
• Building automations for clients on your instance and charging for it, as long as the clients cannot create or edit the workflows themselves
• Using n8n as an invisible backend engine in your own product, as long as end users do not build or configure workflows

What it forbids:

• Hosting n8n as a service in which your clients build workflows themselves
• Letting end users build or configure their own workflows through your product, whether via a custom UI, API, MCP or an AI agent
• Forking the code to launch your own automation product
• Offering n8n white-labelled without its branding as your own product
• Using enterprise features that ask for a licence key without an Enterprise licence

For the overwhelming majority of companies, this distinction is irrelevant in practice: if you are running n8n to automate your own operations, you are squarely inside what the licence permits, for free. The restriction only bites if your business model is to resell n8n itself. For anything beyond that, n8n requires a separate commercial agreement.

One point matters for service providers and their clients: according to the FAQ, a provider may install, configure and maintain n8n on your own server and charge fees for it. It may not provide you with an instance it hosts in which you build workflows yourself, because that would compete with n8n Cloud. That is exactly why a managed setup runs cleanly on infrastructure that is in your name.

The practical takeaway: do not describe n8n as “open source” in contracts, RFPs or compliance documents. Describe it accurately as “fair-code, source-available, under the Sustainable Use License”. It avoids a credibility problem and it is simply correct.

What the Community Edition Lacks

According to the n8n edition comparison, the free Community Edition includes almost the complete feature set. These features are missing and reserved for the paid Business and Enterprise plans:

• Sharing workflows and credentials between users: in the Community Edition only the instance owner and the respective creator can see a workflow or credential
• Projects with role-based permissions
• Single sign-on via SAML, OIDC or LDAP
• Version control with Git and separate environments (dev, staging, prod)
• External secret stores and external storage for binary data
• Log streaming to external systems (standard logging is included)
• Multi-main mode for high availability (queue mode itself is included)
• Custom variables

If you register your Community instance for free with an email address, you additionally get folders, debugging in the editor and custom execution data. Paid plans are unlocked with a licence key that you enter in the settings UI or set via N8N_LICENSE_ACTIVATION_KEY (Manage your license). According to n8n, the pricing page is the definitive source for the current feature set per plan.

The missing sharing between users is the point most likely to surprise small teams: two colleagues with their own accounts cannot edit each other’s workflows in the Community Edition.

Docker Setup Outline

Docker is the cleanest way to run n8n and from n8n 3.0 the only one: n8n announces in its one-line setup that from version 3.0 (launching October 2026) n8n is only distributed through Docker and that npm installs are deprecated. Docker isolates the runtime, makes upgrades a one-line operation and keeps your host server tidy. The reference setup is n8n plus a PostgreSQL database plus a task runner container, behind a reverse proxy that handles HTTPS.

Do not run a production n8n on the default SQLite database. SQLite is fine for a five-minute test and a liability for anything real. According to its database documentation, n8n fully supports PostgreSQL 17 and 18 and 16 for compatibility (as of July 2026). Use PostgreSQL from day one.

Here is a minimal docker-compose.yml skeleton that captures the right shape. It follows the official PostgreSQL example from the n8n hosting repository:

services:
  postgres:
    image: postgres:18
    restart: always
    environment:
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=change-me-strong
      - POSTGRES_DB=n8n
      - PGDATA=/var/lib/postgresql/data
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -h localhost -U n8n -d n8n"]
      interval: 5s
      timeout: 5s
      retries: 10

  n8n:
    image: docker.n8n.io/n8nio/n8n:2.40.7
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=change-me-strong
      - N8N_HOST=automation.example.com
      - N8N_PROTOCOL=https
      - N8N_WEBHOOK_URL=https://automation.example.com/
      - N8N_PROXY_HOPS=1
      - N8N_ENCRYPTION_KEY=generate-a-long-random-secret
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - N8N_RUNNERS_MODE=external
      - N8N_RUNNERS_AUTH_TOKEN=generate-another-random-secret
      - N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0
      - GENERIC_TIMEZONE=Europe/Berlin
      - TZ=Europe/Berlin
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy

  n8n-runner:
    image: n8nio/runners:2.40.7
    restart: always
    environment:
      - N8N_RUNNERS_AUTH_TOKEN=generate-another-random-secret
      - N8N_RUNNERS_TASK_BROKER_URI=http://n8n:5679
    depends_on:
      - n8n

volumes:
  postgres_data:
  n8n_data:

A few decisions in there are deliberate:

• The image tags are pinned to one version (2.40.7 was the current stable release at the time of checking according to the Docker installation page). According to the task runner documentation, the runner image must carry exactly the same version as the n8n image. You find the current version number in the GitHub releases.
• PGDATA is set because PostgreSQL 18 moved its data directory; without this line the database starts with an empty volume according to the n8n documentation.
• N8N_WEBHOOK_URL replaces the older WEBHOOK_URL, which is deprecated since n8n 2.35.0 and triggers a warning in the log. Together with N8N_PROXY_HOPS=1 it tells n8n that exactly one reverse proxy sits in front of it (Configure webhook URLs with reverse proxy).
• The task runner runs as its own container in external mode. Task runners execute the code from your Code nodes and according to n8n are the only isolation layer between user-provided code and the instance including its credentials. Internal mode (runner as a child process of n8n) is not recommended for production and is marked deprecated from n8n 3.0. The older N8N_RUNNERS_ENABLED is no longer needed since n8n 2.0.
• N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true sets the configuration file holding the encryption key to permissions 0600 (security environment variables).
• GENERIC_TIMEZONE drives schedule nodes, TZ the system time inside the container; the default would be America/New_York.

Two values in there are not optional:

• N8N_ENCRYPTION_KEY encrypts your stored credentials. If you do not set it, n8n generates a random key on first start and stores it in the config file inside the .n8n folder (Set a custom encryption key). If you lose it, every saved credential becomes unreadable. Generate it once with openssl rand -hex 32, store it in your password manager and never change it. If you must rotate keys periodically, use the separate data key rotation, which leaves the instance key unchanged.
• N8N_WEBHOOK_URL must be the public HTTPS address external services will call back to. If this is wrong, n8n registers wrong webhook addresses with external services and inbound webhooks silently fail.

Note that the n8n port is bound to 127.0.0.1, not 0.0.0.0. The engine should never face the public internet directly. A reverse proxy in front of it terminates TLS and is the only thing exposed. For a quick trial without your own Compose file there is the official one-line setup with curl -fsSL https://get.n8n.io | sh; it starts with SQLite though, which makes it a test setup, not a production one.

Securing Your n8n Instance

A self-hosted automation engine holds the keys to your entire stack: CRM credentials, payment-provider tokens, email API keys. Securing it is not optional polish. Treat it like production infrastructure, because it is.

HTTPS via a Reverse Proxy

In its SSL documentation, n8n recommends a reverse proxy such as Traefik in front of the instance, which also takes care of certificate renewals. Caddy is the fastest to stand up because it provisions and renews Let’s Encrypt certificates automatically:

automation.example.com {
    reverse_proxy 127.0.0.1:5678
}

That is the entire Caddy config for a working HTTPS frontend. According to its reverse_proxy documentation, Caddy sets the headers X-Forwarded-For, X-Forwarded-Proto and X-Forwarded-Host by default, exactly the three that n8n expects behind a proxy. n8n itself stays on localhost; the proxy is the only public surface. Without HTTPS, by the way, login does not work out of the box, because n8n sends its session cookie over HTTPS only by default (N8N_SECURE_COOKIE, default true).

Authentication

n8n’s user management (email plus password, with role-based access) is the baseline. Strengthen it:

• Use strong, unique credentials and enable two-factor authentication via an authenticator app; it is available to every user in all editions. Enforcing 2FA for all users requires a Business or Enterprise licence according to the security policies documentation.
• Restrict the admin UI to known IP ranges at the firewall or proxy layer where feasible
• For teams, give people their own accounts rather than sharing one login, so you have an audit trail. Keep the Community Edition limitation in mind: workflows cannot be shared between accounts.
• Keep the instance off the public internet entirely if it only serves internal automations, reachable via VPN

Hardening via Environment Variables

The n8n security overview lists several switches that should be set on a production instance:

• N8N_BLOCK_ENV_ACCESS_IN_NODE=true prevents expressions and Code nodes from reading environment variables, including the database password and encryption key
• N8N_PUBLIC_API_DISABLED=true if you do not use the public REST API
• N8N_DIAGNOSTICS_ENABLED=false and N8N_VERSION_NOTIFICATIONS_ENABLED=false switch off telemetry and the connection to n8n servers
• N8N_SSRF_PROTECTION_ENABLED=true blocks requests from workflows to private network ranges and cloud metadata endpoints since n8n 2.12.0 (SSRF protection); for internal targets you maintain an allowlist
• NODES_EXCLUDE blocks risky nodes such as Execute Command, which is already blocked by default (Block specific nodes)

Then run n8n audit: the security audit reports unused credentials, unprotected webhooks, risky nodes and an outdated instance.

Backups

According to the n8n backup documentation, a complete backup consists of three parts and you need all of them:

1. The PostgreSQL database holds your workflows, execution history, users and encrypted credentials. Back it up with scheduled pg_dump runs (a nightly cron is the minimum).
2. The .n8n folder in the n8n_data volume with the config file that contains the encryption key, in case you do not set it via environment variable.
3. Your deployment configuration, meaning the Compose file and environment variables including N8N_ENCRYPTION_KEY. A database backup without the key is a backup of encrypted garbage.

The nightly database dump runs from the Compose directory through the database container:

docker compose exec -T postgres pg_dump -U n8n n8n | gzip > /backups/n8n-$(date +%F).sql.gz

Store backups off the host, ideally on separate EU storage and test a restore at least once. An untested backup is a hope, not a backup. n8n also recommends taking a full backup before every update.

Updates and Version Pinning

According to the Docker installation page, n8n releases a new minor version most weeks. The n8n update recommendations are: update at least once a month so you never have to jump several versions at once, check the release notes for breaking changes beforehand and take a backup first.

With pinned tags an update is deliberate and traceable: you change the version number on both images in the Compose file, pull the images with docker compose pull and restart with docker compose up -d. n8n runs database migrations itself on startup. The latest tag saves you the editing but turns every docker compose pull into an uncontrolled version jump. For production the fixed tag is the better choice.

Scaling n8n with Queue Mode

A default n8n runs in a single process. That is fine until you hit volume, long-running jobs or many concurrent webhooks. When you do, the answer is queue mode.

In queue mode, n8n separates the role that receives triggers (the main instance) from the roles that actually run workflows (worker instances), coordinated through a Redis queue:

                +----------------+
   webhooks --> |  main instance | --> Redis queue
                +----------------+          |
                                            v
                              +-------------------------+
                              |  worker 1   worker 2 ...|  (horizontally scalable)
                              +-------------------------+
                                            |
                                            v
                                   PostgreSQL (shared)

The main instance stays responsive because it is not blocked running heavy workflows. Workers pull jobs off the queue and execute them in parallel. Need more throughput? Add more workers. This is how a self-hosted instance handles serious production load without touching the per-execution wall that a SaaS tool would.

The configuration is manageable: EXECUTIONS_MODE=queue on the main instance and workers, QUEUE_BULL_REDIS_HOST and QUEUE_BULL_REDIS_PORT point to Redis, you start workers with the command n8n worker and control parallel jobs with --concurrency (default 10, n8n recommends at least 5). All instances need the same N8N_ENCRYPTION_KEY, access to Redis and access to the database. Queue mode is not supported with SQLite and every worker needs its own task runner container. Several main instances for high availability (multi-main) are an Enterprise feature.

You do not need queue mode on day one. Start single-process and move to queue mode when execution backlog or webhook latency tells you it is time. The migration is configuration, not a rewrite.

Use Cases: What Companies Actually Automate

Self-hosted n8n earns its place on common, high-frequency business workflows:

• Lead capture and routing: a form submission or inbound webhook creates a CRM record, assigns an owner and posts a notification, in seconds and without manual triage.
• Lead enrichment and scoring: incoming leads get enriched from external data sources and scored, so sales spends time on the right contacts.
• CRM data hygiene: scheduled workflows deduplicate records, normalize fields and flag stale entries automatically.
• Document and invoice workflows: generate, route and file documents; push invoice data between billing and accounting systems.
• Internal ops and IT: provisioning, alerting, syncing data between internal tools and the long tail of glue work that otherwise eats engineering hours.

The documented enterprise ROI is real. According to the n8n case study, Delivery Hero saves 200 hours per month with a single IT ops workflow for account recovery. According to its case study, StepStone runs over 700 active workflows in production and parses two to three million job documents per month with them. Both use the Enterprise variant, but it is the same engine you can self-host.

AI Workflows on Your Own Server

This is where self-hosting becomes a genuine strategic advantage rather than just a cost play.

n8n ships a whole family of AI nodes built on LangChain: agents, chains, memory, tools, output parsers and vector stores, listed in the documentation as cluster nodes. Among them are vector store nodes for Pinecone, Qdrant, Weaviate, Chroma, PGVector, Milvus, Supabase and Redis as well as chat model nodes for OpenAI, Anthropic, Google Gemini, Mistral, AWS Bedrock, Azure OpenAI and further providers. Critically, it supports local models via the Ollama Chat Model node and a matching Ollama embeddings node.

That last point is the unlock. You can build a complete LLM pipeline, document ingestion, embedding, vector search, generation, that runs entirely on your own server, with the model itself running locally through Ollama. Your prompts and your documents never touch OpenAI or any external API. For companies handling sensitive or regulated data, this is sovereign AI: the intelligence layer lives inside the same EU perimeter as everything else.

A typical RAG-on-your-own-infrastructure shape looks like this:

documents --> [embed via local model] --> [vector DB: Qdrant]
user query --> [retrieve relevant chunks] --> [local LLM via Ollama] --> answer
                                  (all nodes running inside your n8n instance)

n8n publishes the Self-hosted AI Starter Kit for this, a Docker Compose template with n8n, Ollama, Qdrant and PostgreSQL. n8n itself classifies it in the documentation as a test environment that must be secured and hardened before production use. If a chatbot, internal knowledge assistant or document-processing agent is on your roadmap and the data is sensitive, this architecture lets you build it without exporting that data anywhere.

DIY vs Managed: The Honest Tradeoff

Self-hosting n8n is genuinely accessible. A basic Docker setup is a one-to-three-hour job for someone comfortable on a Linux server. n8n itself explicitly recommends self-hosting for experienced users, because mistakes can lead to data loss, security issues and downtime. So when does it make sense to manage it yourself and when not?

DIY makes sense when:

• You have in-house ops or DevOps capacity
• The workflows are internal and not business-critical at first
• You want to learn the platform deeply
• Downtime on automation is an annoyance, not a revenue event

Managed makes sense when:

• Automation is load-bearing and downtime costs real money
• Nobody on the team wants to own server patching, backups, monitoring and version upgrades
• You need the GDPR and security posture to be demonstrably correct, not improvised
• You would rather your people build workflows than babysit infrastructure

The hidden cost of DIY is not the initial setup; it is the ongoing operational tax. Weekly releases, backup verification, monitoring, security patches, queue-mode tuning and incident response add up. The engine is free. Running it well, indefinitely, is the actual work.

If you want n8n self-hosted on German infrastructure with the security, backups, monitoring and updates handled, that is exactly what our n8n automation service delivers, licence-compliant on infrastructure that is in your name. And if your bigger question is whether to build custom automation infrastructure at all versus stitching together SaaS tools, our automation service walks through that decision.

Frequently Asked Questions

Is n8n free?

The self-hosted Community Edition is free. You pay only for the server it runs on; at Hetzner a suitable VPS starts at 5.99 EUR per month for 2 vCPUs and 4 GB of RAM according to the price list. n8n Cloud and the Business and Enterprise plans are paid, with cloud plans starting at 20 EUR per month for 2,500 executions when billed annually.

Is n8n open source?

No. n8n is fair-code, source-available under the Sustainable Use License. You can run it free for internal business use, but you cannot offer it as a hosted service in which clients build workflows themselves. Describe it as “fair-code”, not “open source”, to stay accurate.

Is self-hosted n8n GDPR-compliant?

Self-hosting on an EU or German server keeps your data inside your own infrastructure, which removes the data-transfer and processor questions that come with US SaaS automation. The setup itself does not make you compliant; how you secure it, operate it and prune execution data does. This is fachliche Einordnung, not legal advice.

Do I need Docker to self-host n8n?

From n8n 3.0, yes: n8n then distributes n8n through Docker only and classifies npm installs as deprecated. Docker makes installation, isolation and upgrades dramatically simpler anyway and n8n’s own documentation centers on it.

When do I need queue mode?

When a single process can no longer keep up: execution backlogs, slow webhook responses or many concurrent long-running workflows. Start single-process and move to queue mode (main instance plus workers plus Redis) when volume demands it.

Can I run AI workflows without sending data to OpenAI?

Yes. n8n supports local models via Ollama alongside its LangChain-based AI nodes and major vector databases. You can run a full RAG pipeline entirely on your own server, so prompts and documents never leave your infrastructure.

What happens if I lose the encryption key?

Every stored credential becomes unreadable. The N8N_ENCRYPTION_KEY is as important as the database itself. Generate it once, store it in a password manager and include it in your disaster-recovery plan. A database backup without the key is useless.

Summary: Self-Hosting Checklist

• Provision a VPS on EU or German infrastructure, at least 2 vCPUs and 4 GB of RAM
• Deploy n8n with Docker, backed by PostgreSQL 17 or 18 (never SQLite in production)
• Pin image tags to a fixed version, n8n and runner on the same version
• Generate and safely store the N8N_ENCRYPTION_KEY
• Set N8N_WEBHOOK_URL and N8N_PROXY_HOPS=1 and put a reverse proxy (Caddy, Traefik, nginx) in front for HTTPS
• Run task runners in external mode as their own container
• Enable user management and two-factor authentication
• Set the hardening variables and run n8n audit
• Set up nightly database backups plus the .n8n folder, stored off-host and test a restore
• Update monthly; read the release notes and back up first
• Let execution data be pruned automatically
• Move to queue mode when volume requires it
• For AI workflows with sensitive data, run local models via Ollama
• Decide DIY vs managed based on how load-bearing your automation is

Self-hosted n8n gives you automation without per-execution fees, on infrastructure you control, with a clean GDPR story and a real path to sovereign AI. The engine is free. The value is in running it well and in deciding whether that is your team’s job or ours.

If automation is becoming load-bearing for your business, see our n8n automation service for a managed setup on German servers or our automation service to weigh custom infrastructure against SaaS. If you would rather scope what makes sense in your case first, book a free initial consultation.