Betrieb und Administration

Indiebox wird im eigenen Netzwerk betrieben und stellt Chat, Workflows, Agenten und Administration als Weboberflächen bereit.

Nach der Inbetriebnahme ist Chat sofort nutzbar. Agenten, Workflows und Automatisierungen lassen sich danach schrittweise ergänzen.

Inbetriebnahme: in wenigen Minuten arbeitsbereit

Die Inbetriebnahme ist auf einen schnellen Start ausgelegt.

Wenn die Box per Netzwerkkabel angeschlossen ist, ist sie nach dem Einschalten direkt erreichbar. Chat ist anschließend sofort nutzbar.

Wenn die Box per WLAN erreichbar sein soll, führt ein QR‑Code zum Installationsassistenten. Darüber wird die Box ins Netzwerk aufgenommen. Danach kann direkt im Chat gearbeitet werden und bei Bedarf werden die ersten Agenten oder Automatisierungen erstellt.

Anwendungen: getrennte Container, getrennt verwaltbar

Alle Anwendungen der Indiebox laufen in eigenen Containern. Das macht den Betrieb einfacher, weil Dienste unabhängig voneinander verwaltet werden können. Ein Neustart oder Update einer Anwendung betrifft nicht automatisch die anderen.

Typischerweise sind enthalten:

  • OpenWebUI als Chat‑Oberfläche
  • n8n für Workflows, Automatisierung und Integrationen
  • Letta als Agenten‑Umgebung, wenn Agenten genutzt werden
  • Eigene Anwendungen: ein zusätzlicher Container für vollständig eigene Lösungen

Alle Container sind über Dashboard und Admin‑Interface der Box steuerbar.

Dashboard und Admin‑Interface: Überblick und Steuerung

Das Dashboard ist der zentrale Einstieg für Betrieb und Diagnose. Es zeigt, welche Anwendungen laufen, wie die Box genutzt wird, und bietet direkte Steuerung.

Typische Aufgaben, die darüber abgedeckt sind:

  • Anwendungen starten, stoppen, neu starten
  • Status und Auslastung prüfen
  • Logs einsehen, um Probleme einzugrenzen
  • Einstellungen der Box verwalten

So bleibt der Normalbetrieb bei Weboberflächen. Es ist nicht nötig, im Alltag auf Betriebssystem‑Ebene zu arbeiten.

Zugriff: Browser, Mobilgerät und sicherer Zugriff von außen

Chat, Workflows, Dashboard und Administration sind Weboberflächen. Zugriff erfolgt per Browser, sowohl auf Desktop als auch auf Mobilgeräten.

Für Mobilgeräte kann OpenWebUI zusätzlich als installierbare Web‑App genutzt werden. Das fühlt sich wie eine App an, bleibt aber technisch eine Weboberfläche.

Wenn Zugriff von außerhalb des lokalen Netzes erforderlich ist, sind zwei saubere Wege üblich:

  • VPN, damit der Zugriff wie im internen Netz erfolgt
  • gezielte Freigabe definierter Endpunkte über eine lokale Firewall, statt die Box allgemein ins Internet zu stellen

Welche Variante passt, hängt vom Einsatz ab. Wichtig ist die Richtung: intern ist Standard, extern wird bewusst freigeschaltet.

Nutzer und Anmeldung: lokal starten, Business‑Login optional ergänzen

OpenWebUI und n8n sind Webanwendungen. Nutzer werden dort angelegt und verwaltet. Rollen und Rechte trennen normale Nutzung von Administration.

Im Business‑Kontext kann die Anmeldung an vorhandene Systeme angebunden werden. Das ist ein Integrationspunkt, kein Start‑Hindernis.

Workflows und Integrationen mit n8n

n8n ist die Oberfläche für Workflows, Automatisierungen und Integrationen. Workflows bestehen aus Auslösern und Schritten. Dadurch ist nachvollziehbar, wann Aktionen ausgeführt werden und wohin Daten fließen.

n8n bringt viele Konnektoren mit. Eine repräsentative Auswahl, die im Alltag häufig genutzt wird:

Die vollständige Übersicht der Integrationen: n8n Integrationen

Wichtig für den Betrieb: Externe Integrationen entstehen nicht “von selbst”, sondern werden in Workflows bewusst konfiguriert.

Updates: planbar, kontrolliert, optional automatisch

Updates werden über das Admin‑Interface angestoßen. Standard ist ein manueller Start, damit Updates in ein Wartungsfenster passen. Auf Wunsch sind automatische Updates möglich.

Durch die Container‑Trennung lassen sich Anwendungen unabhängig aktualisieren. Das reduziert Überraschungen: Wenn ein Update nur n8n betrifft, muss nicht gleichzeitig der Chat angefasst werden.

Modelle: vorinstalliert, passend zum Zweck, später erweiterbar

Indiebox wird mit mehreren Modellen für unterschiedliche Aufgaben ausgeliefert. Damit ist der Einstieg nicht “Modell suchen”, sondern “Aufgabe starten”.

Vorinstalliert sind:

  • gpt-oss:120b für komplexere Aufgaben mit hoher Anforderung an Begründung und mehrstufige Problemlösung
  • qwen3:30b für Alltagsaufgaben und Automatisierungen
  • qwen3-coder-next für Coding‑Aufgaben
  • granite-embedding:278m für Dokumente, Suche und RAG (Embeddings)

Plattenplatz vs Laufzeit: der entscheidende Punkt ist Arbeitsspeicher

Bei 2 TB Speicher ist Platz für mehrere Modelle im Alltag in der Regel ausreichend dimensioniert. Entscheidend ist weniger die Ablage auf der Platte, sondern der Speicherbedarf zur Laufzeit.

Indiebox ist auf Systeme mit 128 GB Shared Memory ausgelegt. Das ist ein praktischer Vorteil gegenüber klassischen GPU‑Setups, die häufig am GPU‑Speicher (VRAM) hängen. Durch den großen gemeinsamen Speicher werden auch sehr große Modelle in geeigneter Quantisierung realistisch nutzbar, wenn der Einsatzfall passt.

Modelle nachladen (Ollama): bewusst und reversibel

Zusätzlich zu den vorinstallierten Modellen können weitere Modelle über Ollama heruntergeladen und integriert werden.

Nachgeladene Modelle sind nicht Teil der vorkonfigurierten Indiebox‑Umgebung. Stabilität, Qualität und Eignung liegen deshalb in der Verantwortung des Betriebs. Das Risiko bleibt beherrschbar, weil Modelle jederzeit wieder entfernt werden können. Dadurch ist gezieltes Ausprobieren möglich, ohne das System dauerhaft zu verändern.

Datenbereiche, Backup und Wiederherstellung

Indiebox bündelt die persistenten Daten der Anwendungen in einem zentralen Datenbereich der Box. Innerhalb dieses Bereichs sind die Daten pro Anwendung getrennt. Das ist bewusst so gestaltet, damit Backup und Wiederherstellung einfach bleiben.

Im Betrieb heißt das:

  • Daten und Konfiguration sind nicht über viele Orte verteilt, sondern zentral organisiert.
  • Backup kann als Sicherung dieses Datenbereichs umgesetzt werden.
  • Wiederherstellung erfolgt über den Installer: Grundsystem installieren, Datenbereich zurückspielen, Anwendungen über das Dashboard starten.

Netzwerk und Datenfluss: vom Client bis zum lokalen Modell

Der Datenfluss ist im Kern einfach:

Externe Dienste, MCP und das Risiko durch manipulierte Inhalte

Wenn der Administrator externe Dienste freischaltet, kann die Box von innen nach außen auf diese Dienste zugreifen, zum Beispiel für Suche oder zusätzliche Tools über MCP.

Das erhöht die Möglichkeiten, bringt aber auch ein Risiko mit sich: Inhalte können so gestaltet sein, dass Agenten oder Automatisierungen zu unerwünschten Aktionen bewegt werden. Das wird häufig als Prompt Injection beschrieben. Kritisch wird es vor allem dann, wenn Workflows Schreibrechte haben oder Aktionen ohne Bestätigung ausführen.

Netzintegration und HTTPS

Für die Netzintegration gibt es eine Konfigurationsoberfläche. Darüber werden die relevanten Einstellungen gesetzt, ohne dass im Alltag am Betriebssystem gearbeitet werden muss.

Sobald die Box im Netzwerk ist und einen festen Namen hat, kann ein TLS‑Zertifikat für HTTPS erstellt oder hinterlegt werden. Damit ist der Zugriff im Browser sauber verschlüsselt.

Eigene Anwendungen, Partnerlösungen und OpenClaw

Der zusätzliche Container für eigene Anwendungen ist für vollständig eigene Lösungen gedacht. Damit können Partner oder interne Teams spezialisierte Anwendungen und Integrationen aufbauen, ohne die Standard‑Container zu verändern. Das kann von Branchen‑Workflows bis zu klar abgegrenzten internen Tools reichen.

Auch andere lokale Agent‑Anwendungen können in diesem Bereich betrieben werden. Ein Beispiel ist OpenClaw: OpenClaw

In Vorbereitung ist ein Indiebox‑Marktplatz, über den kuratierte Modelle und Lösungspakete installiert werden können. Ziel ist eine reproduzierbare Installation statt individueller Einzel‑Setups.