KI Agent selbst hosten: Wie gelingt das auf dem eigenen Server?

KI Agent selbst hosten: Was bedeutet das und wie funktioniert es?

Einen KI Agent selbst hosten heißt, eine Software auf dem eigenen Server zu betreiben, die ein Sprachmodell mit Werkzeugen, Gedächtnis und Workflows verbindet. Konkret installieren Sie Docker auf einem VPS, starten einen Orchestrator wie n8n und bei Bedarf einen lokalen Modellserver wie Ollama. Danach sichern Sie alles mit HTTPS, Geheimnisverwaltung und klaren Rechten ab.

Wir, Talha Aslan und Team, arbeiten im digitalen Marketing und in der Webentwicklung; wir sind kein Hostinganbieter. Deshalb stützen wir alle Befehle und Einstellungen in dieser Anleitung auf die offiziellen Dokumentationen von n8n, Ollama, Docker und OWASP. Unser Ziel: Entwickler mit eigenem VPS und technisch versierte Websitebetreiber sollen jeden Schritt nachvollziehen können.

Wo Agenten im Marketing helfen und welche Szenarien Zeit sparen, beschreiben wir in einem eigenen Beitrag: KI Agenten im Marketing entwickeln und integrieren. Diese Szenarien wiederholen wir hier nicht. Stattdessen geht es um die Serverseite, also um Architektur, Installation, Sicherheit und Wartung.

Worin unterscheidet sich ein KI Agent von Chatbot und klassischer Automatisierung?

Ein Chatbot beantwortet eine Frage mit Text und hört dann meist auf. Klassische Automatisierung folgt dagegen einem festen Pfad. Ein Formular kommt an, eine Zeile landet in der Tabelle, eine E-Mail geht raus. Jeden Schritt legen Sie fest, das System trifft keine Entscheidungen.

Ein KI Agent liegt dazwischen. Er erhält ein Ziel, entscheidet mithilfe eines Sprachmodells, welches Werkzeug er in welcher Reihenfolge nutzt, prüft das Ergebnis und wählt dann den nächsten Schritt. Zum Beispiel liest er ein Supportticket, fragt das Bestellsystem ab und entwirft danach eine Antwort.

Genau diese Entscheidungsfreiheit ist allerdings auch die Quelle des Risikos. Der Agent ruft Werkzeuge auf, die Sie nicht einzeln freigegeben haben. Wer einen Agenten auf dem eigenen Server betreibt, hostet also nicht bloß eine App. Sie betreiben eine Software, deren Entscheidungen Sie begrenzen müssen. Wie Sprachmodelle grundsätzlich arbeiten, erklären wir in unserem Leitfaden zu großen Sprachmodellen.

Warum sollten Sie einen KI Agent selbst hosten?

Der Wunsch nach einem eigenen Server entsteht meist aus drei Gründen. Eine fertige Plattform für Agenten bringt Sie schnell an den Start. Allerdings haben Sie dort wenig Kontrolle darüber, wohin Daten fließen, was Sie zahlen und was passiert, wenn die Plattform ihre Bedingungen ändert.

• Datenschutz: Workflows, Kundendaten und Zugangsdaten liegen in einer Datenbank auf Ihrem Server. Mit einem lokalen Modell verlässt zudem der Prompt selbst den Server nicht.
• Kostenkontrolle: Sie zahlen eine feste Servergebühr. Sie hängen nicht von Preisen pro Workflow oder pro Ausführung ab und behalten den Tokenverbrauch einer Modell API selbst im Blick.
• Weniger Abhängigkeit: Mit einem quelloffenen Orchestrator exportieren Sie Workflows, wechseln den Modellanbieter oder ziehen mit dem Server zu einem anderen Hoster um.

Keiner dieser Vorteile stellt sich jedoch von selbst ein. Der Datenschutzvorteil gilt zum Beispiel nur, solange der Server gut abgesichert bleibt. Ein offen erreichbares Admin Panel ist ein deutlich größeres Risiko als jede gehostete Plattform.

Wann ist der eigene Server die falsche Wahl?

Ehrlich gesagt ist ein eigener Agentenserver für viele Unternehmen unnötiger Aufwand. Sogar die offizielle Installationsanleitung von n8n empfiehlt Self Hosting nur erfahrenen Nutzern. Sie nennt außerdem klar die Folgen von Fehlern: Datenverlust, Sicherheitsprobleme und Ausfälle.

In diesen Fällen raten wir zu einem verwalteten Dienst:

• Wartungsaufwand: Kümmert sich niemand um Systemupdates, Docker Images und Backups, entwickelt sich der Server mit der Zeit zur Sicherheitslücke.
• Modellqualität: Lokale Modelle, die auf einen kleinen VPS passen, erreichen beim logischen Schließen oft nicht das Niveau großer Cloudmodelle. Bei komplexen Aufgaben macht der Agent dann mehr Fehler.
• Sicherheitsverantwortung: Jeder Vorfall auf Ihrem Server liegt in Ihrer Verantwortung. Dazu gehören Angriffserkennung, Logauswertung und Reaktion auf Vorfälle.
• Kritische Prozesse: Bei Zahlungen, Rechnungen oder Gesundheitsdaten ist der Spielraum für Fehler klein; hier braucht es ein erfahrenes Team.

Kurz gesagt: Der eigene Server ist nur dann ein Vorteil, wenn Sie Zeit und Wissen für den Betrieb haben.

Aus welchen Bausteinen besteht ein selbst gehosteter Agent?

Es hilft, einen selbst gehosteten Agenten in vier Schichten zu denken. Jede Schicht kann in einem eigenen Container oder als externer Dienst laufen. Daher bleibt der Rest stabil, wenn Sie einen Teil austauschen.

1. Orchestrator: Diese Schicht führt die Logik des Agenten aus. Sie bauen entweder visuell mit einem quelloffenen Workflow Werkzeug wie n8n oder schreiben Code mit einem Agenten Framework für Python oder JavaScript.
2. Modell: Das Sprachmodell trifft die Entscheidungen. Sie binden die API eines Cloudanbieters an oder betreiben einen lokalen Modellserver wie Ollama.
3. Werkzeuge und Integrationen: Das sind die Systeme, die der Agent berührt. CRM, E-Mail, Kalender, Tabellen, eigene APIs und Websuche gehören in diese Schicht.
4. Gedächtnis und Datenbank: Hier liegen Workflow Definitionen, Ausführungsverlauf, Zugangsdaten und bei Bedarf das Gesprächsgedächtnis. Standardmäßig nutzt n8n SQLite, PostgreSQL unterstützt es ebenfalls.

In dieser Anleitung dienen n8n und Ollama als Beispiel, denn beide sind quelloffen und beide haben eine ausführliche Docker Dokumentation. Trotzdem gilt dieselbe Architektur auch für ein codebasiertes Framework. Entscheidend ist, dass Sie den Zugriff jeder Schicht einzeln begrenzen.

Cloud API oder lokales Modell: Was passt besser?

Die Modellschicht bestimmt am stärksten, welche Hardware Sie brauchen und wie privat Ihre Daten bleiben. Die Tabelle vergleicht beide Ansätze grob. Zahlen nennen wir bewusst nicht, denn Preise und Hardwarebedarf hängen vom gewählten Modell ab.

Für viele Projekte lohnt sich ein hybrider Weg. Sie fassen zum Beispiel sensible Texte mit einem lokalen Modell zusammen und nutzen ein Cloudmodell nur für Schritte mit anspruchsvoller Logik. In diesem Fall sollten Sie allerdings genau dokumentieren, welche Daten den Server verlassen.

Welche Hardware brauchen Sie, um einen KI Agent selbst hosten zu können?

Wer einen KI Agent selbst hosten möchte, richtet die Hardware danach aus, wo das Modell läuft. Nutzen Sie nur eine Cloud API, trägt der Server Orchestrator, Datenbank und Reverse Proxy. Dann genügt für die meisten Workflows ein kleiner VPS, weil die schwere Rechenarbeit beim Anbieter stattfindet.

Ein lokales Modell ändert das Bild deutlich. Das Modell lädt während der Arbeit in den Speicher. Folglich brauchen Sie freien RAM oder GPU Speicher etwa in der Größenordnung des Modells. Die offizielle Docker Anleitung von Ollama verlangt für GPU Betrieb zudem zuerst das NVIDIA Container Toolkit. Ohne GPU läuft es ebenfalls, allerdings dauern Antworten spürbar länger.

Feste Zahlen nennen wir nicht, denn der Bedarf schwankt je nach Modell. Gehen Sie stattdessen so vor: Zunächst prüfen Sie die Größenangabe auf der Modellseite. Dann vergleichen Sie sie mit dem freien Speicher Ihres Servers. Schließlich machen Sie einen Lasttest mit einem echten Workflow.

Den Unterschied zwischen VPS, VDS und Cloudserver erklären wir in unserer Entscheidungshilfe zu VPS und Cloudserver. Auf kleinen Servern nahe am Speicherlimit hilft außerdem eine Swap Datei. Echten RAM für ein lokales Modell ersetzt Swap dennoch nicht.

Was sollten Sie vor der Installation vorbereiten?

Wenn die Grundlagen vor dem ersten Befehl stehen, sparen Sie sich spätere Nacharbeit. Wir empfehlen, diese Liste der Reihe nach abzuarbeiten:

1. Server: Ein VPS mit aktueller Linux Distribution, auf den Sie mit einem sudo Benutzer statt mit root zugreifen.
2. Docker und Docker Compose: Installieren Sie beides über das offizielle Paketrepository von Docker. Sind Container neu für Sie, lesen Sie zuerst unseren Docker Leitfaden.
3. Domain und DNS: Legen Sie eine Subdomain für den Agenten an und richten Sie den A Record auf die IP Adresse des Servers. Die Verbreitung prüfen Sie mit unserer DNS Abfrage.
4. SSH absichern: Schalten Sie die Anmeldung per Passwort ab und nutzen Sie Schlüssel. Die Schritte stehen in unserer Anleitung zu Swap Datei und SSH Absicherung.
5. Modellzugang: Planen Sie ein Cloudmodell, erstellen Sie beim Anbieter einen Schlüssel für die API und setzen Sie ein Ausgabenlimit.

Möchten Sie nicht direkt mit Docker Befehlen arbeiten, ist ein quelloffenes PaaS Panel eine Alternative. Diesen Weg beschreiben wir in unserem Coolify Leitfaden. Die folgenden Sicherheitsregeln gelten trotzdem auch mit Panel.

Wie sieht ein Docker Compose Gerüst aus, um einen KI Agent selbst hosten zu können?

Die folgende Datei startet n8n und Ollama in einem gemeinsamen Compose Projekt. Imagenamen, Port und Datenpfade stammen aus den offiziellen Docker Anleitungen von n8n und Ollama. Statt einer echten Domain steht dort example.com; tragen Sie Ihre eigenen Werte ein.

services:
  n8n:
    image: n8nio/n8n
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=agent.example.com
      - N8N_PROTOCOL=https
      - N8N_WEBHOOK_URL=https://agent.example.com/
      - N8N_PROXY_HOPS=1
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - GENERIC_TIMEZONE=Europe/Berlin
      - TZ=Europe/Berlin
    volumes:
      - n8n_data:/home/node/.n8n
  ollama:
    image: ollama/ollama
    restart: always
    volumes:
      - ollama:/root/.ollama
volumes:
  n8n_data:
  ollama:

Beachten Sie: Den Port von n8n binden wir nur an 127.0.0.1, genau wie das offizielle Compose Beispiel von n8n. Für Ollama veröffentlichen wir gar keinen Port. Das funktioniert, weil n8n Ollama über den Dienstnamen im gemeinsamen Compose Netzwerk erreicht.

Im Produktivbetrieb sollten Sie Images an ein festes Versionstag binden; so bestimmen Sie selbst, wann ein Update kommt. Für PostgreSQL nehmen Sie am besten das PostgreSQL Beispiel aus dem offiziellen Hosting Repository von n8n als Basis. Danach starten Sie alles mit docker compose up -d und verfolgen die Logs mit docker compose logs -f n8n.

Wie speichern Sie Geheimnisse in Umgebungsvariablen?

Schreiben Sie Schlüssel für APIs, Verschlüsselungsschlüssel und Datenbankpasswörter nie direkt in die Compose Datei. Legen Sie stattdessen im selben Ordner eine .env Datei an und verweisen Sie in der Compose Datei per Variablenname darauf. Somit bleiben die Geheimnisse privat, selbst wenn Sie die Compose Datei in einem Git Repository teilen.

# .env (nur Beispiel, keine echten Werte eintragen)
N8N_ENCRYPTION_KEY=hier-einen-langen-zufallswert-eintragen

# Zufallswert erzeugen
openssl rand -hex 32

# Dateirechte einschränken
chmod 600 .env

Laut offizieller Dokumentation erzeugt n8n beim ersten Start einen zufälligen Verschlüsselungsschlüssel und legt ihn im Datenordner ab. Mit diesem Schlüssel verschlüsselt n8n Zugangsdaten, bevor sie in die Datenbank gelangen. Verlieren Sie den Schlüssel, können Sie die Zugangsdaten einer wiederhergestellten Datenbank also nicht mehr lesen.

Halten Sie deshalb drei Regeln ein. Erstens gehört .env in die .gitignore. Zweitens bewahren Sie den Verschlüsselungsschlüssel zusätzlich im Passwortmanager auf. Drittens tragen Sie Schlüssel für Cloudmodelle über die Zugangsdatenmaske von n8n ein. Legen Sie außerdem pro Projekt einen eigenen Schlüssel beim Modellanbieter an, dann sperren Sie bei einem Leck nur diesen einen.

Wie richten Sie Reverse Proxy und HTTPS ein?

Statt n8n direkt ins Internet zu stellen, setzen Sie einen Reverse Proxy davor. Der Proxy nimmt HTTPS auf Port 443 an und leitet den Verkehr an den n8n Container weiter, der nur lokal lauscht. Für diesen Aufbau verlangt die offizielle Dokumentation von n8n, N8N_PROXY_HOPS auf 1 zu setzen und die X Forwarded Header weiterzureichen.

server {
    listen 443 ssl;
    server_name agent.example.com;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Die Zertifikatszeilen ergänzt das nginx Plugin von Certbot mit sudo certbot --nginx -d agent.example.com. Die Upgrade Header halten die Liveverbindung des Editors offen. Für eine Neuinstallation hilft unsere Anleitung zur nginx Installation. Wer lieber mit Oberfläche arbeitet, findet Hilfe in unserem Beitrag zu nginx Reverse Proxy und Nginx Proxy Manager. Anschließend prüfen Sie das Zertifikat mit unserem SSL Check.

Wie binden Sie ein lokales Modell über Ollama an?

Sobald der Ollama Container läuft, laden Sie ein Modell herunter. Den Modellnamen wählen Sie aus der Modellbibliothek von Ollama; die Befehle unten nutzen einen Platzhalter.

docker compose exec ollama ollama pull MODELLNAME
docker compose exec ollama ollama list

Danach legen Sie in n8n die Zugangsdaten für Ollama an und tragen als Basisadresse http://ollama:11434 ein. Diese Adresse funktioniert nur innerhalb des Compose Netzwerks; von außen kommt niemand heran. Auch die offizielle FAQ von Ollama hält fest, dass der Server standardmäßig nur an 127.0.0.1 bindet. Für Zugriff aus dem Netzwerk müssten Sie die Variable OLLAMA_HOST ändern.

Unser Rat: Lassen Sie Ollama komplett aus dem Internet heraus. Braucht ein anderer Rechner Zugriff, setzen Sie einen Reverse Proxy mit Authentifizierung davor oder verbinden Sie sich per VPN. Prüfen Sie zudem in der offiziellen Dokumentation die Optionen, die steuern, wie lange ein Modell im Speicher bleibt. So belegt ein ungenutztes Modell keinen RAM ohne Grund.

Starten Sie den ersten Workflow schließlich mit einem kleinen Test. Bauen Sie etwa einen Ablauf, der nur einen Text zusammenfasst und kein Werkzeug berührt. Antwortet das Modell, ergänzen Sie die Werkzeuge einzeln.

Wie schützen Sie SSH, Firewall und Docker Ports?

Die Basis der Serversicherheit lautet: nur die nötigen Ports offen lassen. Ein Agentenserver braucht in der Regel SSH, HTTP und HTTPS. Unter Ubuntu erledigen Sie das mit ufw:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Hier lauert allerdings eine wichtige Falle. Die offizielle Docker Dokumentation schreibt, dass Docker den Verkehr zu veröffentlichten Containerports umleitet, bevor er die Regeln von ufw erreicht. Veröffentlichen Sie also einen Port auf 0.0.0.0, kann er von außen erreichbar sein, obwohl ufw ihn als geschlossen zeigt. Deshalb bindet unser Gerüst n8n an 127.0.0.1 und veröffentlicht für Ollama keinen Port.

Gegen Brute Force Versuche auf SSH empfehlen wir außerdem Fail2ban. Die Einrichtung zeigt unsere Fail2ban Anleitung. Nach der Installation scannen Sie die Ports von außen und prüfen, ob wirklich nur die erwarteten offen sind.

Warum ist Prompt Injection das größte Risiko für Ihren Agenten?

Prompt Injection liegt vor, wenn eine Eingabe das Verhalten des Modells auf unerwünschte Weise verändert. Die OWASP Seite zu LLM01 Prompt Injection setzt dieses Risiko auf Platz eins ihrer Liste für Anwendungen mit Sprachmodellen. Außerdem unterscheidet sie zwei Arten.

Bei der direkten Variante steuert ein Nutzer das Modell über den Text im Chatfenster. Bei der indirekten Variante steckt der Angriff in einer Webseite, E-Mail oder einem Dokument, das der Agent liest. Beim Verarbeiten hält der Agent die versteckten Anweisungen dann womöglich für seine eigene Aufgabe.

Genau hier unterscheidet sich ein Agent vom Chatbot. Ein getäuschter Chatbot gibt eine falsche Antwort. Ein getäuschter Agent mit Werkzeugen verschickt dagegen Nachrichten per E-Mail, löscht Datensätze oder exportiert Daten. Zudem gibt es keine bekannte Methode, die indirekte Injection vollständig verhindert. Auch OWASP versteht seine Empfehlungen als Schichten, die das Risiko senken.

Kurz gesagt: Verlassen Sie sich nie darauf, dass das Modell Ihre Anweisungen immer befolgt. Stützen Sie die Sicherheit auf Server und Workflow Regeln, die den Handlungsspielraum des Agenten begrenzen.

Wie setzen Sie minimale Rechte und menschliche Freigaben um?

Unter den OWASP Empfehlungen stechen das Prinzip der minimalen Rechte und menschliche Freigaben für riskante Aktionen hervor. Dieselbe Liste führt zudem übermäßige Handlungsfreiheit als eigenes Risiko, also einen Agenten mit mehr Funktionen, als seine Aufgabe verlangt. Konkret können Sie so vorgehen:

• Legen Sie für jede Integration ein eigenes Konto oder einen eigenen Schlüssel mit reinen Leserechten an. Schreibrechte erhält nur der Workflow, der sie wirklich braucht.
• Bauen Sie vor unumkehrbaren Aktionen wie Löschen, Zahlungen, Massenmails und externem Teilen einen Freigabeschritt ein.
• Begrenzen Sie den Ordner, auf den der Agent zugreifen darf. Das offizielle Compose Beispiel von n8n nutzt dafür eine Variable, die den Dateizugriff auf einen einzigen Ordner beschränkt.
• Halten Sie Inhalte von außen, also Webseiten, Mailinhalte und Dokumente, getrennt von Systemanweisungen und kennzeichnen Sie sie klar.
• Prüfen Sie, ob die Ausgabe des Agenten dem erwarteten Format entspricht, bevor sie an das nächste Werkzeug geht.

Diese Regeln bremsen den Agenten, das stimmt. In den ersten Wochen zeigen Ihnen die Freigabeprotokolle allerdings, welche Aktionen sich sicher automatisieren lassen. Somit erweitern Sie Rechte auf Basis von Belegen.

Wie sollten Protokollierung, Überwachung und Backups aussehen?

Ein Agent trifft Entscheidungen, die Sie nicht einzeln beobachten. Daher müssen Sie später nachlesen können, was er wann mit welcher Eingabe getan hat. n8n speichert den Ausführungsverlauf in der eigenen Datenbank, und docker compose logs zeigt die Ausgabe der Container. Begrenzen Sie außerdem Aufbewahrungsdauer und Einstellungen des Docker Logtreibers gemäß offizieller Dokumentation, damit die Logs die Festplatte nicht füllen.

Bei Backups denken Sie drei Teile zusammen:

1. Datenvolume: Das Volume n8n_data enthält die SQLite Datenbank und den Verschlüsselungsschlüssel.
2. Konfiguration: Compose Datei, Proxy Einstellungen und die .env Datei. Letztere lagern Sie verschlüsselt.
3. Workflows: Ein zusätzlicher Export über die Kommandozeilenbefehle von n8n hilft bei der Versionskontrolle.

Lagern Sie Backups nie auf demselben Server, denn fällt der Server aus, ist auch das Backup weg. Zu Häufigkeit und Aufbewahrung lesen Sie unsere Backup Strategie für Websites. Testen Sie außerdem regelmäßig die Wiederherstellung. Einem nie zurückgespielten Backup können Sie nicht vertrauen.

Wie spielen Sie Updates sicher ein?

Laut Dokumentation veröffentlicht n8n häufig neue Versionen und empfiehlt für den Produktivbetrieb den stabilen Kanal. Dieses Tempo ist eine gute Nachricht, denn Sicherheitskorrekturen kommen schnell. Andererseits kann ein Update ohne Blick in die Versionshinweise einen laufenden Workflow beschädigen.

Eine sichere Reihenfolge sieht so aus. Zunächst erstellen Sie ein Backup. Dann prüfen Sie die Versionshinweise auf inkompatible Änderungen. Danach ändern Sie das Versionstag in der Compose Datei und führen diese Befehle aus:

docker compose pull
docker compose up -d
docker compose logs -f n8n

Nach dem Update lösen Sie kritische Workflows einmal von Hand aus und kontrollieren das Ergebnis. Auch Namen von Umgebungsvariablen können sich ändern. Die Dokumentation von n8n vermerkt zum Beispiel, dass die alte Variable für die Webhook Adresse veraltet ist und einen neuen Namen hat.

Vergessen Sie die Updates des Betriebssystems nicht. Ebenso aktualisieren Sie das Ollama Image und die geladenen Modelle mit derselben Disziplin. Geht etwas schief, kehren Sie zum vorherigen Tag zurück. Auch deshalb ist ein festes Tag sicherer als das Tag für die neueste Version.

Was gilt beim Datenschutz nach DSGVO?

Verarbeitet der Agent personenbezogene Daten, befreit Sie der eigene Server nicht von Datenschutzpflichten. Im Gegenteil: Als Verantwortlicher tragen Sie die volle Verantwortung. Dieser Abschnitt bietet nur allgemeine Informationen und ist keine Rechtsberatung.

Grundsätzlich sollten Sie folgende Fragen beantworten können. Welche personenbezogenen Daten liest der Agent? Bei einem Cloudmodell: Welcher Anbieter in welchem Land erhält diese Daten? Wie lange bleiben personenbezogene Daten im Ausführungsverlauf? Verlangt jemand die Löschung seiner Daten, können Sie diese auch aus den Protokollen des Agenten entfernen?

Ein lokales Modell kann die Frage nach der Übermittlung von Prompts ins Ausland erledigen. Standort des Servers, Ort der Backups und Zugriffsprotokolle bleiben trotzdem wichtig. Zudem müssen Sie die Verarbeitung mit KI eventuell in Ihrer Datenschutzerklärung beschreiben. Allgemeine Schritte für Websites erklären wir im DSGVO Leitfaden für Websites. Für einen Agenten mit personenbezogenen Daten empfehlen wir, eine Rechtsberatung hinzuzuziehen.

Welche Kosten entstehen, wenn Sie einen KI Agent selbst hosten?

Wer einen KI Agent selbst hosten will, zahlt mehr als nur eine Serverrechnung. Konkrete Beträge nennen wir nicht, denn Preise hängen von Anbieter und Nutzung ab; prüfen Sie die aktuelle Preisseite des jeweiligen Anbieters. Für das Budget empfehlen wir dennoch, diese Posten getrennt aufzuführen:

• Server: Miete für VPS oder GPU Server. Mit lokalem Modell wächst dieser Posten deutlich.
• Modellnutzung: Gebühren pro Token bei einer Cloud API. Setzen Sie im Dashboard des Anbieters ein Ausgabenlimit.
• Speicher und Backup: Externer Speicher für Ihre Sicherungen.
• Domain und Zertifikat: Die Verlängerungsgebühr der Domain; Zertifikate von Let's Encrypt sind kostenlos.
• Lizenz: Prüfen Sie die Lizenzbedingungen der genutzten Funktionen auf der offiziellen Seite des Orchestrators.
• Arbeitszeit: Stunden für Einrichtung, Updates, Logauswertung und Reaktion auf Vorfälle. Oft ist das der größte Posten.

Auch wenn die monatliche Servergebühr niedrig wirkt, rechnen Sie also zu knapp, wenn Sie einige Stunden Wartung pro Monat weglassen.

Wann sollten Sie die Einrichtung Fachleuten überlassen?

Nicht jede Agenteninstallation ist ein Wochenendprojekt. Trifft einer dieser Punkte auf Sie zu, raten wir zu einem erfahrenen Team oder einem verwalteten Dienst:

• Sie wissen nicht, was im Fall eines Sicherheitsvorfalls auf dem Server zu tun ist.
• Der Agent greift auf Kundendaten, ein Zahlungssystem oder einen Kanal für Massennachrichten zu.
• Niemand könnte das System übernehmen, wenn die Person geht, die es aufgebaut hat.
• Für wöchentliche Updates und Logkontrollen fehlt Ihnen die Zeit.

Dann gibt es zwei Wege. Erstens nutzen Sie den Clouddienst des Orchestrators, bei dem der Anbieter die Wartung übernimmt. Zweitens übergeben Sie Einrichtung und Pflege an ein Team. Mit unserer KI Automatisierung konzentrieren wir uns auf Workflow Design und sichere Konfiguration; auf der Serverseite arbeiten wir mit Ihrem Hostinganbieter zusammen.

Welchen Weg Sie auch wählen: Halten Sie schriftlich fest, worauf der Agent zugreifen darf und welche Aktionen eine Freigabe brauchen. Damit bleiben die Grenzen gleich, egal wer das System betreut.

Kurze Checkliste für die erste Woche

Nach der Einrichtung empfehlen wir in der ersten Woche folgende Prüfungen. Die Liste fasst die Schritte oben zusammen:

1. Bestätigen Sie, dass von außen nur die Ports für SSH, HTTP und HTTPS offen sind.
2. Testen Sie, dass niemand die Ports von n8n und Ollama aus dem Internet erreicht.
3. Bewahren Sie eine sichere Kopie von Verschlüsselungsschlüssel und .env Datei außerhalb des Servers auf.
4. Erstellen Sie das erste Backup und spielen Sie es testweise auf einem anderen Rechner zurück.
5. Prüfen Sie die Rechte jeder Integration und entziehen Sie unnötige Schreibrechte.
6. Stellen Sie sicher, dass jede unumkehrbare Aktion einen Freigabeschritt hat.
7. Aktivieren Sie beim Modellanbieter Ausgabenlimit und Warnungen.

Zusammengefasst: Einen Agenten auf dem eigenen Server zu starten, kostet nur wenige Befehle. Die eigentliche Arbeit besteht darin, ihn sicher, gesichert und begrenzt zu halten. Die offizielle Docker Compose Anleitung von n8n, die FAQ von Ollama und die Docker Dokumentation zu Paketfilterung und Firewalls sind dabei die wichtigsten Quellen.