diff --git a/docs/runner-setup.md b/docs/runner-setup.md
index b39b5a2..1615955 100644
--- a/docs/runner-setup.md
+++ b/docs/runner-setup.md
@@ -20,6 +20,14 @@ Damit der Runner Reusable-Workflows aus `idf-ci` lesen kann, muss das Repo für
 - **Limited** — lesbar für alle eingeloggten Gitea-User. In neueren Gitea-Versionen verfügbar. Für unseren Fall äquivalent zu Public, weil der Runner eh mit Token angemeldet ist.
 - **Private** — funktioniert nicht, weil der Job-Token keinen Repo-übergreifenden Lesezugriff hat.
 
+**Zusätzlich:** Gitea-weite Einstellung `REQUIRE_SIGNIN_VIEW` muss auf `false` stehen. Sonst überschreibt sie die per-Repo-Sichtbarkeit und erzwingt Login auch für Public-Repos. Bei Docker-Setups wird die `app.ini` oft aus Environment-Variablen regeneriert — Änderungen direkt in der Datei gehen beim Container-Neustart verloren. Korrekter Weg: Environment-Variable setzen:
+
+```
+GITEA__service__REQUIRE_SIGNIN_VIEW=false
+```
+
+Je nach Setup in der `docker-compose.yml`, im systemd-Unit oder in der Plesk-Gitea-Extension. Container neu starten.
+
 ### Ist das ein Sicherheitsproblem?
 
 Das Risiko ist niedrig, weil das Repo ausschließlich CI-Baustoff enthält:
@@ -32,7 +40,7 @@ Das Risiko ist niedrig, weil das Repo ausschließlich CI-Baustoff enthält:
 
 Falls der Gitea-Server aus dem Internet erreichbar ist, bedeutet „Public" tatsächlich weltweit lesbar. Ist der Gitea-Server nur intern/VPN-gebunden erreichbar, ist „Public" effektiv identisch mit „intern lesbar". Im Zweifel: Sichtbarkeit auf „Limited" setzen, dann muss man wenigstens angemeldet sein, um zu lesen.
 
-### Umstellung
+### Umstellung der Repo-Sichtbarkeit
 
 1. Repo öffnen: https://git.ihre-ideenfabrik.de/ideenfabrik/idf-ci
 2. Settings → ganz runterscrollen → „Danger Zone"
@@ -44,7 +52,13 @@ Einmalige Aktion pro Instanz.
 ## Voraussetzungen auf dem Server
 
 - Linux (Debian/Ubuntu; der IDF-Plesk-Host reicht)
-- Outbound-HTTPS zu `git.ihre-ideenfabrik.de`
+- Outbound-HTTPS zu `git.ihre-ideenfabrik.de` und zu `github.com` (für standard Gitea-/GitHub-Actions wie `actions/checkout`)
+- **Node.js 20 (LTS) oder neuer** — zahlreiche Actions (`actions/checkout`, viele weitere) sind JavaScript-basiert und benötigen Node zur Ausführung. Installation (Debian/Ubuntu):
+  ```bash
+  curl -fsSL https://deb.nodesource.com/setup_20.x | sudo bash -
+  sudo apt install -y nodejs
+  ```
+  Prüfen: `node --version` (mindestens `v20.x`).
 - Standard-Tools verfügbar: `bash`, `python3`, `zip`, `unzip`, `rsync`, `curl`, `jq`, `git`
   Falls einzelne Tools fehlen: `sudo apt install -y python3 zip unzip rsync curl jq git`
 - systemd (Standard bei Debian/Ubuntu)
@@ -186,7 +200,10 @@ Damit ist das komplette Build-System portabel: die Bauanleitung lebt in diesem R
 Du hast `--labels …` als CLI-Flag gesetzt, aber `act_runner` nimmt Labels nur aus der Config. Schritt 2 durchgehen, Labels in `config.yaml` eintragen. Dann `sudo rm /opt/act_runner/.runner`, neuen Token holen, Registrierung ohne `--labels`-Flag erneut ausführen.
 
 **Run bricht ab mit `Unable to clone … authentication required`.**
-`idf-ci` steht auf Private. Abschnitt „Voraussetzungen in Gitea" durchgehen und Sichtbarkeit auf Public (oder Limited) setzen. Danach den Run über den Re-run-Button in der Gitea-Actions-UI neu starten — kein Re-Tagging nötig.
+Entweder `idf-ci` steht auf Private, oder Gitea-weit ist `REQUIRE_SIGNIN_VIEW = true` aktiv. Abschnitt „Voraussetzungen in Gitea" durchgehen. Bei Docker-Setup die Environment-Variable `GITEA__service__REQUIRE_SIGNIN_VIEW=false` setzen und Container neu starten. Danach den Run über den Re-run-Button in der Gitea-Actions-UI neu starten.
+
+**Run bricht ab mit `Cannot find: node in PATH`.**
+Node.js ist nicht installiert oder nicht im PATH. Abschnitt „Voraussetzungen auf dem Server" durchgehen und Node 20 LTS installieren. Nach `sudo apt install -y nodejs` läuft der nächste Re-run.
 
 **Runs hängen auf `queued`, Runner steht aber auf Online.**
 Label-Mismatch. Der Workflow schreibt `runs-on: self-hosted`, der Runner muss dasselbe Label anbieten. In der Gitea-UI die Labels des Runners prüfen — stehen dort nicht `self-hosted, linux, x64`, liegt es an Schritt 2.