Brauche ich Programmierkenntnisse?

Nein, grundlegende Computerkenntnisse reichen aus. Wir führen dich Schritt für Schritt durch die Einrichtung des Servers und die Installation via Kommandozeile. Alle Befehle kannst du einfach kopieren (Copy-Paste).

Welche laufenden Kosten entstehen?

Du benötigst einen Hetzner Cloud Server (CX22 für ca. 5€ im Monat). Dazu kommen die API-Kosten für KI-Modelle wie Claude oder OpenAI nach Verbrauch. Für reines OpenClaw Hosting fallen keine weiteren Kosten an.

Ist der Kurs auch für Mac/Windows nutzbar?

Ja, OpenClaw läuft auf einem Linux-Server (Hetzner). Du kannst deinen Server von jedem Betriebssystem (Mac, Windows, Linux) aus verwalten.

Wie lange habe ich auf den Kurs Zugriff?

Du erhältst lebenslangen (Lifetime) Zugriff auf alle Inhalte. Auch wenn wir Module aktualisieren, zahlst du keinen Cent extra.

Ist OpenClaw DSGVO konform?

Indem du OpenClaw auf deinem eigenen Server in Deutschland (z.B. Hetzner) hostest, hast du die volle Kontrolle über deine Daten. Im Kurs gibt es ein eigenes Modul zum Thema DSGVO & Datensicherheit.

systemd erklärt — Linux Service-Manager für OpenClaw

Direkte Antwort: systemd ist der zentrale Service-Manager moderner Linux-Distributionen. Mit einem unit-File (.service) machst du aus dem OpenClaw-Gateway einen 24/7-Service mit Auto-Restart, Boot-Persistenz und gebündelten Logs via journalctl.

Was ist systemd?

systemd ist das Init-System und Service-Management-Tool, das auf praktisch allen modernen Linux-Distributionen läuft (Ubuntu, Debian, Fedora, RHEL, Arch). Es startet Dienste beim Boot, hält sie am Leben, sammelt deren Logs und verwaltet Abhängigkeiten zwischen ihnen.

Wer auf einem Hetzner-VPS einen 24/7-Dienst betreiben will (z.B. das OpenClaw Gateway), kommt an systemd nicht vorbei. Es ist der saubere und stabile Weg, im Vergleich zu Hacks wie nohup oder screen.

Kontext

Vor systemd herrschte Chaos: SysV-Init, Upstart, BSD-Init, alle mit eigenen Konventionen. systemd hat seit etwa 2014 die Linux-Welt standardisiert. Heute ist es Standard und de-facto Pflicht für serverseitige Workloads.

systemd ist mehr als nur ein Init-System. Es deckt Logging (journald), Timer (Cron-Ersatz), Networking, Mounts, Sockets, Login-Sessions und vieles mehr ab. Manche kritisieren das als "zu mächtig", praktisch sparst du dir aber 5 verschiedene Tools.

Funktionsweise

systemd verwaltet Units. Eine Unit ist eine Konfigurationsdatei, die einen Service, Timer, Mount, Socket oder ähnliches beschreibt. Service-Units enden auf .service.

Service-Units können sein:

System-weit: /etc/systemd/system/foo.service — laufen mit Root-Rechten oder unter dem User, der im Unit-File steht
Pro-User: ~/.config/systemd/user/foo.service — laufen nur, wenn der User eingeloggt ist (oder lingering aktiviert)

Die wichtigsten Befehle:

sudo systemctl daemon-reload          # nach Unit-Aenderungen einlesen
sudo systemctl enable openclaw        # bei Boot starten
sudo systemctl start openclaw         # jetzt starten
sudo systemctl stop openclaw          # jetzt stoppen
sudo systemctl restart openclaw       # neu starten
sudo systemctl status openclaw        # Status anzeigen
journalctl -u openclaw -f             # Logs live tailen
journalctl -u openclaw --since "1h ago"

Praxis-Beispiel

Ein vollständiges Unit-File für das OpenClaw-Gateway:

# /etc/systemd/system/openclaw.service
[Unit]
Description=OpenClaw Gateway
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=openclaw
Group=openclaw
WorkingDirectory=/home/openclaw/agent
EnvironmentFile=/home/openclaw/agent/.env
ExecStart=/usr/bin/openclaw gateway
Restart=always
RestartSec=10
StandardOutput=journal
StandardError=journal

# Hardening
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=read-only
ReadWritePaths=/home/openclaw/agent
ReadWritePaths=/var/log/openclaw

[Install]
WantedBy=multi-user.target

Aktivieren und starten:

sudo systemctl daemon-reload
sudo systemctl enable openclaw
sudo systemctl start openclaw
sudo systemctl status openclaw

Wenn alles gut ist, siehst du active (running). Logs schaust du mit:

journalctl -u openclaw -f

Wichtige Optionen erklärt

| Option | Bedeutung | | --- | --- | | Type=simple | Service läuft im Vordergrund, systemd merkt sich PID | | Restart=always | Bei Crash sofort wieder starten | | RestartSec=10 | 10 Sekunden warten vor Restart (verhindert Crash-Loop) | | EnvironmentFile | API-Keys etc. aus separater .env-Datei laden | | NoNewPrivileges | Service kann keine zusätzlichen Rechte erlangen | | ProtectSystem=strict | Filesystem read-only, außer ReadWritePaths |

systemd User Services

Wenn du keinen Root-Zugriff hast oder den Service einfach lieber unter deinem Nutzer betreiben willst, gibt es User-Services:

mkdir -p ~/.config/systemd/user
nano ~/.config/systemd/user/openclaw.service

systemctl --user daemon-reload
systemctl --user enable openclaw
systemctl --user start openclaw
systemctl --user status openclaw

# Damit Service auch ohne Login laeuft
sudo loginctl enable-linger $USER

Praxis-Tipp: Auf einem dedizierten OpenClaw-Server sind User-Services oft sauberer als System-Services, weil du keine Root-Rechte für Updates und Konfig brauchst.

Logging mit journalctl

systemd-Logs liegen nicht in /var/log/ als Textfiles, sondern in einer binären Journal-Datenbank. Zugriff per journalctl:

journalctl -u openclaw                # alle Logs
journalctl -u openclaw -f             # live tail
journalctl -u openclaw --since today  # heute
journalctl -u openclaw -p err         # nur Errors
journalctl -u openclaw --since "1h ago" --until "30min ago"

Vorteile gegenüber Plaintext-Logs: strukturiert (JSON), durchsuchbar, mit Metadaten (PID, User, Boot-ID).

Häufige Fehler / Stolperfallen

daemon-reload vergessen: Wenn du das Unit-File änderst, muss systemctl daemon-reload laufen. Sonst nutzt systemd die alte Version.
EnvironmentFile-Pfad falsch: Wenn die .env-Datei nicht existiert oder Permissions falsch sind, startet der Service nicht. systemctl status zeigt den Fehler.
PATH-Problem: systemd-Services bekommen ein anderes PATH als interaktive Shells. Wenn dein Skript node oder andere Binaries nutzt, schreibe vollständige Pfade.
Restart-Loop: Wenn dein Service immer wieder crasht und sofort neustartet, kannst du Logs verpassen. journalctl -u service --since "5 min ago" durchsuchen.
Keine Berechtigung: Wenn der User aus dem Unit-File auf gewisse Pfade nicht schreiben darf, schlägt der Service fehl. Permissions prüfen.

systemd-Timer als Cron-Alternative

Neben .service-Units gibt es .timer-Units, die als Cron-Ersatz dienen. Beispiel-Timer für ein Backup alle 6 Stunden:

# /etc/systemd/system/openclaw-backup.timer
[Unit]
Description=Backup OpenClaw config alle 6h

[Timer]
OnBootSec=15min
OnUnitActiveSec=6h
Persistent=true

[Install]
WantedBy=timers.target

Plus eine openclaw-backup.service-Unit, die den Backup-Befehl ausführt. Vorteil ggü. Cron: Persistent=true holt verpasste Runs nach (z.B. nach Reboot), Logs sind im Journal.

Restart-Verhalten feinjustieren

Restart=always ist okay, aber bei manchen Bugs landest du in einem Crash-Loop. Sicherer:

Restart=on-failure
RestartSec=10
StartLimitIntervalSec=300
StartLimitBurst=5

Damit: 5 Crashes in 5 Minuten -> systemd gibt auf und stopt. Du wirst per Monitoring informiert und kannst den Bug fixen, statt dass der Service ewig im Crash-Loop hängt.