Theron-Server

Überblick

Der Theron-Server ist optional und läuft bei dir. Er verbindet alle deine Theron-Instanzen:

Web-UI: Tasks aller Apps, Headless-Worker und Konsolenläufe live verfolgen und Rückfragen von überall beantworten – auch die von THERON. Anmeldung mit Passwort und Pflicht-Zwei-Faktor.
Bibliothek: Auf Wunsch teilen alle Instanzen ihre Prozesse und Agents – optional mit Wissen, Memorys und Datenbanken.
Nutzung: Die Web-UI zeigt die Claude-Nutzung je App bzw. Worker.

Der Server ist ein Docker-Image (amd64 und ARM64); der Code darin ist kompilierter Maschinencode. Nichts davon läuft über uns.

Installieren

docker run -d --name theron-server --restart unless-stopped -p 8765:8765 -v theron-server:/data \
  -e THERON_ADMIN_USER=admin -e THERON_ADMIN_PASSWORD='ein-langes-passwort' \
  mibexx1985/theron-server
docker logs theron-server        # Adresse und Client-Token für die Apps

Offline: das Archiv von der Startseite mit docker load -i theron-server-image-amd64.tar.gz laden (Image theron-server:<version>).

Docker Compose (docker-compose.yml, Start mit docker compose up -d; Passwort und Token als Umgebungsvariablen oder in einer .env):

services:
  theron-server:
    image: mibexx1985/theron-server:latest
    restart: unless-stopped
    ports: ["8765:8765"]
    environment:
      THERON_ADMIN_USER: admin
      THERON_ADMIN_PASSWORD: ${THERON_ADMIN_PASSWORD:?set a password}
      THERON_CLIENT_TOKEN: ${THERON_CLIENT_TOKEN:?set a token}
    volumes: ["theron-server:/data"]
volumes:
  theron-server:

HTTPS: Betreibe den Server hinter einem Reverse-Proxy mit TLS (z. B. nginx, Traefik, ein Kubernetes-Ingress mit cert-manager). WebSockets müssen durchgereicht werden (/api/client für Apps, /api/web für die Web-UI). Alternativ direkt mit --ssl-certfile und --ssl-keyfile.
Daten: Benutzer, 2FA, Client-Token, letzter Status und die geteilte Bibliothek liegen in /data – als Volume einbinden.
Health-Check: GET /healthz → {"ok": true, "clients": n}.

Konfiguration

Variable / Option	Bedeutung
`THERON_ADMIN_USER`, `THERON_ADMIN_PASSWORD`	Legt den Admin beim Start an bzw. setzt sein Passwort.
`THERON_CLIENT_TOKEN`	Fester Client-Token für Apps, Worker und Konsole; ohne wird einer erzeugt und gespeichert.
`THERON_SERVER_HOME`	Konfigurationsordner (im Image `/data`).
`THERON_HOST`, `THERON_PORT`	Adresse und Port (Standard `0.0.0.0`, `8765`).
`serve --ssl-certfile … --ssl-keyfile …`	TLS direkt im Server statt im Proxy.
`serve --no-state`	Den letzten Status nicht auf Platte speichern.

Befehle

Befehl	Wirkung
`theron-server serve`	Server starten (das tut der Container).
`theron-server init`	Ersteinrichtung ohne Umgebungsvariablen: Admin und Passwort abfragen.
`theron-server user list`	Benutzer und ihr 2FA-Status.
`theron-server user add NAME` · `user remove NAME`	Benutzer anlegen (fragt das Passwort ab) bzw. entfernen.
`theron-server user reset-2fa NAME`	2FA zurücksetzen – beim nächsten Login wird sie neu eingerichtet.
`theron-server token` · `token --rotate`	Client-Token anzeigen bzw. neu erzeugen (verbundene Apps müssen den neuen eintragen).

Im Container: docker exec -it theron-server theron-server user add anna.

Anmelden & Zwei-Faktor

Beim ersten Login richtet jeder Benutzer 2FA ein: QR-Code mit einer Authenticator-App scannen (Apple Passwörter, Google Authenticator, 1Password, Authy …) und einen Code bestätigen. Vorher ist nichts sichtbar.
Danach zeigt der Server 10 Notfall-Codes – jeder einmal gültig. Gut aufbewahren.
Bei jedem weiteren Login folgt nach dem Passwort der aktuelle Code. Eine Sitzung gilt sieben Tage.
Handy weg: mit einem Notfall-Code anmelden oder theron-server user reset-2fa NAME.
Falsche Passwörter und Codes werden gebremst.

Apps, Worker & Konsole verbinden

Wer	Wie
Desktop-App	Einstellungen → Theron-Server: Adresse und Client-Token, „Status live synchronisieren“.
Konsole	`theron config server https://… TOKEN`
Slave	auf dem Slave-Rechner `theron config server https://… TOKEN` vor `theron --listen`
Headless-Worker	`THERON_SERVER_URL` und `THERON_SERVER_TOKEN`

Die Adresse darf host:port, http://… oder https://… sein. Den Token zeigt docker logs theron-server oder theron-server token. Eine App im Slave-Betrieb verbindet sich nicht selbst – das übernimmt ihr Slave.

Die Web-UI

Ein Tab je Client: jede App, jeder Worker und jeder Konsolenlauf (je Ordner) mit Online-Status und der Zahl offener Rückfragen.
Aktive Prozesse: links die Tasks des Clients, „Wartet auf dich“ zuerst; rechts Prozessfluss, Agent-Karten, Chat und die Claude-Nutzung des Clients.
Rückfragen beantworten: Fragen nacheinander mit Antwortvorschlägen, ★ empfohlen, eigene Antwort und optionale Nachricht. Was erlaubt ist, legt jede App selbst fest (Einstellungen → Theron-Server → Sicherheitsstufe): Keine Eingabe, Nur vordefinierte Antworten oder Freie Eingabe mit Sicherheitsprüfung – dann prüft der Rechner jede Antwort mit Regeln und einer isolierten KI-Prüfung, bevor Theron sie bekommt. Vom Server kommen nur Antworten auf offene Rückfragen, nie neue Aufträge.
Stopp hält einen Task an.
Reset (oben rechts) löscht den Status des Servers – Clients, Tasks, offene Rückfragen – und holt ihn sofort neu von den verbundenen Clients. Die geteilte Bibliothek bleibt.

Bibliothek teilen

Mit „Prozesse und Agents mit dem Server synchronisieren“ (App) bzw. theron config sync on (Konsole, Worker) teilen alle Instanzen ihre Prozesse und Agents. Neu, geändert oder gelöscht auf einem Gerät – auf allen anderen ebenso; bei gleichzeitigen Änderungen gewinnt die neuere.
Getrennt einschaltbar: das Wissen der Agents (Dokumente, Ordner, Links), die Memorys der Memory-Knoten und die ▤ Datenbanken (jeder Eintrag einzeln abgeglichen).
Projekte, Tasks und Task-Listen bleiben lokal, ebenso die temporären Prozesse und Agents von THERON.
Nach einem Zurücksetzen oder auf einem neuen Gerät kommt alles vom Server zurück – ein Zurücksetzen löscht dort nichts. Gleichnamige Agents und Prozesse auf zwei Geräten gelten als dieselben.

Sicherheit

Apps, Worker und Konsole melden sich mit dem Client-Token an; Menschen mit Passwort und Pflicht-2FA.
Betreibe den Server hinter HTTPS – sonst gehen Token, Chat und Ergebnisse unverschlüsselt durchs Netz.
Der Server sieht Laufstatus, Chat, Agent-Ergebnisse, Nutzung, Rechnername und Version – und bei eingeschaltetem Sync die geteilte Bibliothek. Er führt nichts aus; Antworten aus dem Web prüft der jeweilige Rechner.

Theron server

Overview

The Theron server is optional and runs on your side. It connects all your Theron instances:

Web UI: follow the tasks of every app, headless worker and console run live and answer questions from anywhere – THERON's, too. Login with password and mandatory two-factor authentication.
Library: if you like, all instances share their processes and agents – optionally with knowledge, memories and databases.
Usage: the web UI shows the Claude usage of every app or worker.

The server is a Docker image (amd64 and ARM64); the code inside is compiled machine code. None of it passes through us.

Install

docker run -d --name theron-server --restart unless-stopped -p 8765:8765 -v theron-server:/data \
  -e THERON_ADMIN_USER=admin -e THERON_ADMIN_PASSWORD='a-long-password' \
  mibexx1985/theron-server
docker logs theron-server        # address and client token for the apps

Offline: load the archive from the home page with docker load -i theron-server-image-amd64.tar.gz (image theron-server:<version>).

Docker Compose (docker-compose.yml, start with docker compose up -d; password and token as environment variables or in a .env):

services:
  theron-server:
    image: mibexx1985/theron-server:latest
    restart: unless-stopped
    ports: ["8765:8765"]
    environment:
      THERON_ADMIN_USER: admin
      THERON_ADMIN_PASSWORD: ${THERON_ADMIN_PASSWORD:?set a password}
      THERON_CLIENT_TOKEN: ${THERON_CLIENT_TOKEN:?set a token}
    volumes: ["theron-server:/data"]
volumes:
  theron-server:

HTTPS: run the server behind a reverse proxy with TLS (e.g. nginx, Traefik, a Kubernetes ingress with cert-manager). WebSockets must be passed through (/api/client for apps, /api/web for the web UI). Or directly with --ssl-certfile and --ssl-keyfile.
Data: users, 2FA, client token, the last state and the shared library live in /data – mount it as a volume.
Health check: GET /healthz → {"ok": true, "clients": n}.

Configuration

Variable / option	Meaning
`THERON_ADMIN_USER`, `THERON_ADMIN_PASSWORD`	Creates the admin at start or sets its password.
`THERON_CLIENT_TOKEN`	A fixed client token for apps, workers and console; otherwise one is created and kept.
`THERON_SERVER_HOME`	Configuration folder (`/data` in the image).
`THERON_HOST`, `THERON_PORT`	Address and port (default `0.0.0.0`, `8765`).
`serve --ssl-certfile … --ssl-keyfile …`	TLS in the server itself instead of a proxy.
`serve --no-state`	Don't keep the last state on disk.

Commands

Command	Effect
`theron-server serve`	Start the server (what the container does).
`theron-server init`	First setup without environment variables: asks for admin and password.
`theron-server user list`	Users and their 2FA state.
`theron-server user add NAME` · `user remove NAME`	Add a user (asks for the password) or remove one.
`theron-server user reset-2fa NAME`	Reset 2FA – it is set up again at the next login.
`theron-server token` · `token --rotate`	Show the client token or create a new one (connected apps must enter the new one).

In the container: docker exec -it theron-server theron-server user add anna.

At the first login every user sets up 2FA: scan the QR code with an authenticator app (Apple Passwords, Google Authenticator, 1Password, Authy …) and confirm a code. Nothing is visible before that.
Then the server shows 10 recovery codes – each valid once. Keep them safe.
At every later login the current code follows the password. A session lasts seven days.
Phone gone: log in with a recovery code or run theron-server user reset-2fa NAME.
Wrong passwords and codes are throttled.

Connecting apps, workers & console

Who	How
Desktop app	Settings → Theron server: address and client token, “Synchronise status live”.
Console	`theron config server https://… TOKEN`
Slave	on the slave machine `theron config server https://… TOKEN` before `theron --listen`
Headless worker	`THERON_SERVER_URL` and `THERON_SERVER_TOKEN`

The address may be host:port, http://… or https://…. docker logs theron-server or theron-server token shows the token. An app in slave mode doesn't connect itself – its slave does.

The web UI

One tab per client: every app, worker and console run (per folder) with online state and the number of open questions.
Active processes: the client's tasks on the left, “waiting for you” first; process flow, agent cards, chat and the client's Claude usage on the right.
Answering questions: one question after another with suggested answers, ★ recommended, an own answer and an optional message. What is allowed is set by each app itself (Settings → Theron server → security level): no input, predefined answers only or free input with a security check – then the computer checks every answer with rules and an isolated AI check before Theron gets it. The server only delivers answers to open questions, never new jobs.
Stop halts a task.
Reset (top right) clears the server's state – clients, tasks, open questions – and fetches it again from the connected clients right away. The shared library stays.

Sharing the library

With “Synchronise processes and agents with the server” (app) or theron config sync on (console, worker), all instances share their processes and agents. New, changed or deleted on one machine – the same on all others; with changes at the same time the newer one wins.
Switched on separately: the agents' knowledge (documents, folders, links), the memories of memory nodes and the ▤ databases (every entry compared on its own).
Projects, tasks and task lists stay local, as do THERON's temporary processes and agents.
After a reset or on a new machine everything comes back from the server – a reset never deletes anything there. Agents and processes with the same name on two machines count as the same.

Security

Apps, workers and console log in with the client token; people with password and mandatory 2FA.
Run the server behind HTTPS – otherwise token, chat and results travel unencrypted.
The server sees run status, chat, agent results, usage, machine name and version – and with sync on the shared library. It runs nothing; answers from the web are checked by the computer they go to.