Deployment DE

Deployment

🌐 English · Deutsch

Für Produktion baust du die SvelteKit-App mit adapter-node und startest sie mit node build statt npm run dev. Der schnellste Weg ist der fertige systemd-Installer; Docker und ein manueller Build werden ebenfalls unterstützt. Diese Seite behandelt den Produktions-Build, den Installer, die systemd-Unit, Docker, einen nginx-Reverse-Proxy und die fünf Stolpersteine, die in echten Deployments zubeißen. Konfiguriere zuerst deine .env (Konfiguration).

Produktions-Build (manuell)

npm ci
npm run build
node -r dotenv/config build      # startet adapter-node (Default Port 3000)

node build liest die .env NICHT. adapter-node nutzt nur echte Umgebungsvariablen. Lade sie mit node -r dotenv/config build (braucht npm i dotenv), set -a; . ./.env; set +a oder einer systemd-EnvironmentFile= (unten). Das ist der häufigste Produktionsfehler.

Fertiger systemd-Service (empfohlen)

Im Projektordner auf dem Server:

cp .env.example .env && nano .env     # einmalig konfigurieren
sudo bash deploy/install-service.sh   # baut + richtet systemd-Service ein + startet

Das Skript ist idempotent: legt bei Bedarf den System-User dks an, führt npm ci && npm run build aus, schreibt die systemd-Unit, aktiviert und startet sie. Konfigurierbar über Umgebungsvariablen:

APP_DIR=/opt/dks/redbot-dks-dashboard SERVICE_USER=dks SERVICE_NAME=dks-dashboard \
  sudo -E bash deploy/install-service.sh

Danach:

journalctl -u dks-dashboard -f          # Live-Logs
sudo systemctl restart dks-dashboard    # Neustart
sudo bash deploy/update.sh              # Update: fetch + build + restart

Die systemd-Unit

Der Installer schreibt eine Unit wie diese. Beachte die Zeile EnvironmentFile= – so erreicht die .env in Produktion das node build:

# /etc/systemd/system/dks-dashboard.service
[Unit]
Description=PDC Redbot Webapp (SvelteKit/adapter-node)
After=network.target

[Service]
Type=simple
WorkingDirectory=/opt/dks/redbot-dks-dashboard
EnvironmentFile=/opt/dks/redbot-dks-dashboard/.env
ExecStart=/usr/bin/node build
Restart=on-failure
RestartSec=5
User=dks
Group=dks
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=true

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload && sudo systemctl enable --now dks-dashboard

Das systemd-.env-Format ist eine KEY=value-Zeile – ohne export, ohne Anführungszeichen.

Docker

cp .env.example .env
docker compose up -d --build      # http://localhost:3000

Läuft der Bot auf dem Host, während die App im Container läuft, zeige das Gateway auf den Host:

GATEWAY_URL=http://host.docker.internal:6970

Die Compose-Datei mappt host.docker.internal per extra_hosts, das funktioniert also auch unter Linux.

Die docker-compose.yml ist ein kompletter Stack: Sie startet Red-DiscordBot (offizielles Image) und die Webapp zusammen — nach dem ersten Start installierst und bindest du das Cog pdc_webdashboard in Red ([p]pdcdashboard bind 0.0.0.0 6970), damit der Webapp-Container das Gateway erreicht. Die komplette Anleitung — Discord-App-Setup, Red + Cogs, Compose, Reverse Proxy, Troubleshooting — steht in docs/SELF-HOSTING.md im Repo (englisch).

nginx-Reverse-Proxy

Eine einzige Catch-all-location / zum Node-Port genügt. Kein root/try_files, das /_app/… abfängt.

server {
    server_name deine-domain;
    location / {
        proxy_pass http://127.0.0.1:3000;
        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-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
    }
}

Hinter HTTPS zusätzlich die Reverse-Proxy-Variablen in der .env setzen (sonst z. B. 403 beim Logout):

ORIGIN=https://deine-domain
PROTOCOL_HEADER=x-forwarded-proto
HOST_HEADER=x-forwarded-host

Die fünf Stolpersteine

1. node build liest die .env nicht. Nutze node -r dotenv/config build, set -a; . ./.env; set +a oder systemd EnvironmentFile=.
2. Hinter HTTPS-Reverse-Proxy ORIGIN, PROTOCOL_HEADER und HOST_HEADER setzen, sonst scheitern Aktionen wie der Logout mit 403.
3. Eine Tailwind-Config muss existieren. Ohne tailwind.config.(cjs|js) baut Tailwind nur das Base-Layer und die Seite ist (fast) ungestylt. Nie löschen; ins Git committen. Bei "type":"module" ist tailwind.config.cjs (CommonJS) am robustesten.
4. Der Proxy muss /_app/ durchreichen. Eine einzige Catch-all-location / zum Node-Port genügt; kein root/try_files, das /_app/... abfängt.
5. CDN-Cache (z. B. Cloudflare): Assets sind immutable gecacht. Beim Iterieren nach Rebuilds ggf. Cache purgen oder „Development Mode" nutzen.

Verwandte Seiten

• Konfiguration – Env-Laden und Reverse-Proxy-Variablen
• Self-Update – das laufende Deployment aus GitHub aktualisieren
• Erste Schritte – lokales Entwicklungs-Setup