n8n-Lizenz im Unternehmen: Nutzung, Hosting und Weiterverkauf

Lizenzmodell. n8n stellt Quellcode bereit, beschreibt sein Modell aber als „fair-code“ beziehungsweise source available. Die Sustainable Use License enthält Nutzungsbeschränkungen und ist daher nicht mit einer uneingeschränkten Open-Source-Lizenz gleichzusetzen. Die offizielle Lizenzübersicht erläutert diese Einordnung und verlinkt die eigentlichen Lizenztexte.

Beschaffung. Für die Beschaffung heißt das: Bewerten Sie nicht allein, ob sich die Software herunterladen lässt. Prüfen Sie, welche Edition verwendet wird, welche Funktionen aktiviert werden und welche Nutzung geplant ist. Ein technisch funktionierender Prototyp ist keine Bestätigung seiner vertraglichen Zulässigkeit.

Softwareliste. Tragen Sie in Ihrer Softwareliste deshalb die genaue Edition, Version, Vertragsgrundlage und verantwortliche Organisation ein. Eine pauschale Eintragung „n8n, kostenlos“ lässt später offen, ob ein interner Prozess oder ein an Kunden verkauftes Automationsprodukt gemeint war.

Lizenz-FAQ. Die aktuelle Lizenz-FAQ von n8n unterscheidet zwischen der Nutzung vorgefertigter Automatisierungen und dem Erstellen oder Konfigurieren von Workflows durch externe Endnutzer. Kundeneigene Zugangsdaten allein entscheiden diese Abgrenzung nicht. Auch ein eigenes Interface, eine API oder ein KI-Agent kann externen Nutzern faktisch Kontrolle über die Workflow-Logik geben.

Tatsächliche Möglichkeiten. Erfassen Sie daher nicht nur sichtbare Benutzeroberflächen, sondern die tatsächlichen Möglichkeiten: Kann der Kunde Bedingungen ändern, neue Aktionen kombinieren, Ziele auswählen oder einen Assistenten anweisen, den Ablauf umzubauen? Oder übermittelt er lediglich Daten an einen von Ihnen festgelegten Prozess?

Produktbeschreibungen. Diese Unterscheidung sollte in Produktbeschreibungen genauso auftauchen wie in technischen Diagrammen. „Der Kunde sieht n8n nicht“ ist für sich genommen keine belastbare Lizenzanalyse. Eine verborgene Workflow-Engine kann trotzdem einen für Kunden zugänglichen Workflow-Editor unterstützen.

Roadmap. Beziehen Sie auch die geplante Roadmap ein. Aus einer einfachen Einstellung kann später ein mächtiger Regeleditor werden. Plant das Unternehmen diese Funktion, nehmen Sie sie in das erste Gespräch mit dem Hersteller auf, statt anzunehmen, dass die Freigabe der ersten Version jede künftige Funktion abdeckt.

Fall A: interne Auftragskoordination. Ein Handwerksbetrieb betreibt n8n für seine eigenen Abläufe. Interne Mitarbeitende pflegen Regeln; Kunden erhalten Terminbestätigungen. Für die Prüfung werden Betreiber, Nutzerkreis, Edition und benötigte Funktionen dokumentiert. Dass die Automation geschäftlichen Zwecken dient, bedeutet nicht automatisch, dass sie ein an Kunden verkauftes Workflow-Produkt ist.

Fall B: betreuter Ergebnisdienst. Eine Agentur entwickelt festgelegte Abläufe und liefert ihren Kunden daraus entstehende Berichte. Der Kunde kann Eingabedaten liefern, aber keine eigenen Workflows erstellen oder verändern. Hier müssen neben der Lizenzfrage Mandantentrennung, Datenverarbeitung, Zugang zum System und der genaue Dienstleistungsumfang geklärt werden. Der Vertrag sollte die tatsächliche Architektur wiedergeben.

Fall C: Baukasten für Kunden. Ein Anbieter verkauft eine Oberfläche, in der Kunden Auslöser, Bedingungen und Aktionen selbst kombinieren. Dahinter führt n8n die Abläufe aus. Diese Gestaltung muss vor Markteinführung ausdrücklich mit n8n geklärt werden. Eine umbenannte Oberfläche ändert nicht, wer die Automationslogik bestimmt.

Status der Fälle. Die Fälle sind Entscheidungshilfen und keine Freigabe individueller Geschäftsmodelle. Insbesondere hybride Modelle können sich im Projektverlauf verändern: Ein zunächst fester Berichtsdienst erhält später einen Editor, wodurch eine frühere Bewertung nicht mehr ausreichen kann. Das gilt auch dann, wenn der zugrunde liegende Server identisch bleibt.

Grenzen je Fall. Ziehen Sie für jeden Fall die Grenze zwischen Mitarbeitenden, Dienstleistern und externen Nutzern. Die technische Beschreibung sollte zeigen, wer Workflows bauen, veröffentlichen, aufrufen und administrieren kann. Das sind unterschiedliche Fähigkeiten, die nicht in einem einzigen Kästchen „Nutzerzugriff“ zusammenfallen sollten.

Die folgenden zusätzlichen Architekturbeispiele sind konstruiert. Sie dienen dazu, eine Herstelleranfrage genauer zu formulieren. Aus ihnen folgt keine eigenständige Lizenzzusage durch modernagents.

Fester Bericht mit auswählbarem Zeitraum: Ein Kunde wählt Monat und vorhandenen Geschäftsbereich. Der Anbieter hat Datenquellen, Berechnung und Ausgabe festgelegt. Der Kunde liefert Parameter für eine definierte Leistung. Dokumentieren Sie trotzdem, ob weitere Auswahlmöglichkeiten existieren und wer den Ablauf verändern kann. Entscheidend ist die tatsächliche Funktion, nicht die Beschriftung „Filter“.

Fester Prozess mit kundeneigenem Konto: Ein Kunde verbindet sein CRM, damit ein vom Anbieter festgelegter Bericht Daten abrufen kann. Die aktuelle n8n-FAQ macht kundeneigene Zugangsdaten nicht allein zum Ausschlusskriterium. Es bleibt zu prüfen, ob der Kunde nur sein Konto verbindet oder darüber hinaus eigene Abläufe gestaltet. Die Verantwortung für Zugangsdaten, Datenverarbeitung und Widerruf der Verbindung ist zusätzlich zu regeln.

Konfigurierbarer Automationsassistent: Ein Nutzer schreibt „Wenn eine Anfrage aus Branche X kommt, prüfe Quelle Y und sende das Ergebnis an Ziel Z“. Ein Assistent erzeugt daraus neue Logik. Auch ohne sichtbaren Workflow-Editor kann der Nutzer damit die Automation gestalten. Beschreiben Sie diesen Fall ausdrücklich in der Lizenzanfrage. Die Verwendung eines Sprachmodells verändert die tatsächlichen Konfigurationsmöglichkeiten nicht.

Betreute Einzelinstanz: Eine Agentur pflegt eine Umgebung für einen bestimmten Kunden. Klären Sie, wer Vertragspartner und Betreiber ist, welche Mitarbeitenden des Kunden Zugriff erhalten und ob diese eigene Workflows erstellen. Dass die Instanz technisch getrennt ist, beantwortet weder alle Lizenzfragen noch automatisch die Abgrenzung zwischen interner Nutzung und angebotener Plattformleistung.

Ausgangsbasis. Die offizielle Lizenz-FAQ ist die Ausgangsbasis für diese Unterscheidungen. Bei einem hybriden Modell sollte die Anfrage alle Bedienwege enthalten: Benutzeroberfläche, API, Administrationszugang und KI-Assistent. Ein allein auf Screenshots beschriebener Fall kann wesentliche Möglichkeiten übersehen.

Funktionen und Edition. Ein zulässiger Einsatz der Community Edition beantwortet noch nicht, ob ihre Funktionen zu Ihrem Team passen. Rollen, Identitätsanbindung, Versionsverwaltung oder betriebliche Zusatzfunktionen können eine andere Edition erfordern. Vergleichen Sie Ihre Muss-Anforderungen mit der aktuellen Tarifübersicht und dem tatsächlich angebotenen Vertrag.

Funktionsliste. Erstellen Sie dazu eine kurze Funktionsliste mit einem klaren Grund je Zeile: „Zwei getrennte Projektteams dürfen keine gegenseitigen Zugangsdaten verwenden“ ist hilfreicher als „Enterprise Security gewünscht“. „Änderungen müssen vor Produktion geprüft werden“ ist konkreter als „Wir brauchen Git“. Aus dem tatsächlichen Bedarf lässt sich ableiten, welche Produktfunktion oder organisatorische Maßnahme erforderlich ist.

Tarif und Betriebsmodell. Prüfen Sie anschließend, ob der gewünschte Tarif diese Funktion im gewählten Betriebsmodell enthält. Cloud- und Self-Hosting-Angebote sind nicht beliebig austauschbare Etiketten. Ein Angebot sollte deshalb Edition, Betriebsmodell, Kontingente, Vertragsdauer und Leistungsgrenzen ausdrücklich benennen.

Inhaber des Abonnements. Prüfen Sie außerdem, wem das Abonnement gehört. Ein Umsetzungspartner kann ein Konto des Kunden administrieren oder den Dienst in seinen eigenen Vertrag aufnehmen. Diese Regelungen haben unterschiedliche Folgen für Ausstieg und Verlängerung, auch wenn der Editor für Projektbeteiligte gleich aussieht.

Eine gute Lizenzanfrage beschreibt die Architektur knapp und ohne Marketingbegriffe. Nutzen Sie für eine Lizenzanfrage an n8n beispielsweise diese Angaben:

• Betreiber und Eigentümer der Instanz sowie Anzahl getrennter Kundenumgebungen.
• Wer Workflows erstellt, verändert und veröffentlicht.
• Welche Möglichkeiten externe Nutzer über Oberfläche, API oder Assistent erhalten.
• Wem verbundene Konten gehören und wer Zugangsdaten verwaltet.
• Was genau verkauft wird: Beratung, Betrieb, Ergebnisse oder Workflow-Erstellung durch Nutzer.
• Welche Edition und besonderen Funktionen benötigt werden.

Konkreter Beispielvorgang. Fügen Sie einen konkreten Beispielvorgang bei. Der Unterschied zwischen „Kunde startet einen festen Export“ und „Kunde wählt frei Quelle, Transformation und Ziel“ ist für die Prüfung erheblich. Bitten Sie um eine schriftliche Einordnung des beschriebenen Modells und legen Sie die Antwort mit dem Vertragsstand ab.

Offene Entwurfsfragen. Ist ein Teil des Entwurfs noch nicht entschieden, sagen Sie das. Es ist besser, eine offene Entscheidung zu benennen, als eine Antwort zu einer Architektur zu erhalten, die das Team gar nicht bauen will. Der Entscheidungsvermerk sollte deutlich machen, von welchen Annahmen die Bewertung abhängt.

Aufzubewahrende Unterlagen. Bewahren Sie die relevante Lizenz- und Vertragsfassung, das Prüfdatum, die beschriebene Architektur und schriftliche Herstellerantworten auf. Hinterlegen Sie außerdem, wer Verlängerungen und Änderungen überwacht. Wenn ein Dienstleister Konten einrichtet, muss feststehen, auf wessen Namen der Vertrag läuft und wie ein Anbieterwechsel möglich bleibt.

Erneute Prüfung. Planen Sie eine erneute Prüfung bei wesentlichen Änderungen: externe Nutzer erhalten neue Konfigurationsmöglichkeiten, aus einer internen Lösung wird ein verkäufliches Produkt, oder mehrere Kunden werden auf einer gemeinsamen Plattform bedient. Die ursprüngliche Freigabe sollte nicht stillschweigend auf ein anderes Geschäftsmodell übertragen werden.

Zusammenfassung auf einer Seite. Als praktischen Abschluss erstellen Sie eine Seite mit Nutzungsmodell, Funktionsbedarf, offenen Fragen und zuständigem Entscheider. Damit kann Einkauf oder Rechtsberatung den Fall zielgerichtet prüfen. Der Aufwand ist meist deutlich kleiner, wenn die Architektur vor dem Verkauf klar beschrieben wird, als wenn ein fertiges Produkt später umgebaut werden muss.

Schrittweise Veränderung. Ein häufiger Grenzfall entsteht schrittweise. Anfangs liefert ein Dienstleister einen festen Bericht. Später darf der Kunde zusätzliche Quellen wählen. Danach kommen frei definierbare Bedingungen und benutzerbestimmte Ziele hinzu. Jede Erweiterung kann einzeln klein wirken, während das Gesamtprodukt zunehmend zu einer konfigurierbaren Automationsplattform wird.

Änderungsliste. Führen Sie deshalb eine kurze Änderungsliste mit der Frage, ob externe Nutzer neue Kontrolle erhalten. Der zuständige Produktverantwortliche sollte diese Frage vor der Freigabe beantworten. Falls eine Änderung die bisherige Herstellerbeschreibung verlässt, wird deren Einordnung erneuert, bevor das neue Leistungsversprechen verkauft wird.

Eingereichte Architekturversion. Eine schriftliche Antwort ist nur so belastbar wie der beschriebene Sachverhalt. Bewahren Sie deshalb auch die eingereichte Architekturversion auf. Sonst bleibt später unklar, ob die Rückmeldung das aktuelle Produkt oder eine frühere, wesentlich engere Variante betraf.

Wiederverkäufer und Subunternehmer. Nehmen Sie Regelungen mit Wiederverkäufern und Subunternehmern in diese Beschreibung auf, wenn sie Zugriff oder Betrieb berühren. Ein Diagramm, das nur den Endkunden und den Server zeigt, kann eine weitere Organisation verdecken, die das System administriert oder Zugriff verkauft. Der Hersteller sollte das tatsächliche Liefermodell bewerten, nicht eine der Einfachheit halber unvollständige Fassung.

Zwei eigenständige Bewertungen. Eine passende kommerzielle Vereinbarung kann eine Nutzungsfrage lösen, sagt aber nicht automatisch etwas über die Trennung Ihrer Kunden aus. Umgekehrt macht eine sauber getrennte technische Architektur ein unpassendes Nutzungsrecht nicht passend. Beides muss eigenständig bewertet werden.

Drei getrennte Ergebnisse. Für ein Angebot sollten daher drei Ergebnisse getrennt vorliegen: erlaubtes Nutzungsmodell, tatsächlich verfügbare Produktfunktionen und ein Betriebs- beziehungsweise Datenverarbeitungskonzept. Prüfen Sie beispielsweise, ob Kunden Zugriff auf gegenseitige Informationen erhalten könnten, wer Geheimnisse verwaltet und wie ein einzelner Kunde aus der gemeinsamen Umgebung ausscheidet. Diese Fragen bleiben auch bei bezahlter Software relevant.

Höherer Tarif. Ebenso wenig ist ein höherer Tarif automatisch die richtige Antwort auf jede Einbettung. Beschreiben Sie den tatsächlichen Endnutzerzugriff und lassen Sie bestätigen, welche Vereinbarung dafür vorgesehen ist. Eine Preiszeile aus der öffentlichen Tarifübersicht ersetzt keine Prüfung eines besonderen Vertriebsmodells.

Engere Architektur. Solange eine wesentliche Frage offen ist, kann das Team mit einer engeren, eindeutig beschriebenen Architektur weiterplanen. Beispielsweise wird zunächst nur ein interner Prozess umgesetzt, während ein externer Baukasten ausdrücklich außerhalb des beauftragten Umfangs bleibt. Diese Begrenzung muss technisch und im Angebot sichtbar sein; ein bloßer Hinweis im Projektprotokoll reicht nicht, wenn das Produkt bereits mehr ermöglicht.

Offene Herstellerantwort. Halten Sie für die Entscheidung fest, welche Herstellerantwort noch fehlt, wer sie einholt und welche Funktion davon abhängt. So lässt sich ein Prototyp sinnvoll weiterentwickeln, ohne eine ungeklärte Annahme als fertiges Nutzungsrecht auszugeben. Vor dem Verkauf der abhängigen Funktion muss der konkrete Vertragsfall geklärt sein.

Übergabe. Unterscheiden Sie bei der Übergabe bestätigte Fakten von Annahmen, die noch geprüft werden müssen. Der nächste Betreiber sollte den erlaubten Dienst, die Belege dafür und die Änderungen erkennen können, die eine erneute Bewertung auslösen. Dieser Vermerk beschleunigt spätere Produktentscheidungen, ohne aus einer früheren Antwort eine Pauschalerlaubnis zu machen.

Diese Seiten behandeln die Leistungsübersicht und die angrenzenden Entscheidungen zur n8n-Lizenz:

• n8n-Agentur: Umsetzung und Betrieb von Unternehmensworkflows
• n8n Cloud oder selbst hosten: Betriebsentscheidung für KMU
• n8n-Kosten: Cloud, Hosting und Wartung kalkulieren
• Agentur, Einstellung oder Software: wie die Umsetzung organisiert wird

Für eine konkrete Ablaufprüfung reichen zunächst eine Prozessbeschreibung, die beteiligten Systeme und typische Ausnahmen. Mit modernagents besprechen.