atelier-api — das Backend

atelier-api ist ein schlanker Bun-Service mit MongoDB als Datenbank. Assets liegen in einem Content-Addressed Store auf der Platte (per SHA-256 adressiert, dedupliziert). Standardmäßig lauscht der Server auf Port 3095.

• Discord-Login mit Freigabe-Workflow (pending → approved).
• Versionierte Pack-Revisionen, resumable Uploads, Team-Locks über WebSocket.
• Registry-Lane mit Service-Token, damit Webseiten veröffentlichte Packs abfragen können.
• Web-Admin-Dashboard unter /admin — Logs, Speicher, Build-Downloads und fxmanifest-Overrides.

Quellcode & Issues: atelier-api auf GitHub.

• Bun (1.x) — zum Starten des Servers.
• MongoDB — eine eigene Instanz oder MongoDB Atlas.
• Eine Discord-Anwendung für den Login (kostenlos im Discord Developer Portal).
• Persistenter Speicher für die Assets — siehe Storage & Volume.

Lokal starten

cd atelier-api
bun install
cp .env.example .env.local   # Werte ausfüllen
bun run dev                  # mit Auto-Reload

# Läuft? Health-Check:
curl http://127.0.0.1:3095/health

Konfiguriert wird über .env.local (lokal) bzw. die Umgebung des Hosters. Die wichtigsten Variablen:

Discord-Anwendung anlegen

1. 1
   Im Discord Developer Portal eine neue Application erstellen (Name z. B. „atelier").
2. 2
   Unter OAuth2 Client-ID und Client-Secret in deine Env übernehmen (ATELIER_DISCORD_CLIENT_ID / ATELIER_DISCORD_CLIENT_SECRET).
3. 3
   Als Redirects beide exakt eintragen — einen für die Desktop-App, einen fürs Web-Admin-Dashboard:

   {ATELIER_PUBLIC_ORIGIN}/api/v1/auth/discord/callback
   {ATELIER_PUBLIC_ORIGIN}/admin/callback

   Lokal also http://127.0.0.1:3095/api/v1/auth/discord/callback bzw. http://127.0.0.1:3095/admin/callback. Der Scope identify wird automatisch angefragt.

Freigabe-Workflow

Neue Mitglieder landen als pending und müssen einmalig freigeschaltet werden. Discord-IDs in ATELIER_ADMIN_DISCORD_IDS sind automatisch Admin und freigegeben — diese Admins schalten dann alle weiteren direkt in der App frei.

• pending — angemeldet, aber für Cloud-Aktionen gesperrt.
• approved — voller Zugriff auf Packs, Sync und Builds.
• locked — gesperrt, alle Geräte-Anmeldungen werden widerrufen.

Alle hochgeladenen Dateien liegen unter ATELIER_STORAGE_ROOT in einem Content- Addressed Store. Die MongoDB speichert nur die Metadaten und Verweise (per SHA-256).

cas/      finalisierte Assets (unveränderlich, per Hash)
tmp/      laufende Uploads
builds/   zwischengespeicherte Build-Artefakte

atelier-api bringt ein Dockerfile mit (oven/bun) und lässt sich so überall als Container betreiben. Mit Dokploy in Kürze:

1. 1
   In Dokploy eine neue Application aus dem atelier-api-Repository (oder dem Docker-Image) anlegen.
2. 2
   Die Environment-Variablen setzen — insbesondere MONGODB_URI, ATELIER_JWT_SECRET, ATELIER_SERVICE_TOKEN, die beiden Discord-Werte und HOST=0.0.0.0.
3. 3
   Ein persistentes Volume an ATELIER_STORAGE_ROOT mounten (z. B. /data). Das ist der wichtigste Schritt — ohne ihn verlierst du beim nächsten Deploy alle Assets.
4. 4
   Eine Domain zuweisen und Port 3095 freigeben. Trage dieselbe öffentliche HTTPS-URL als ATELIER_PUBLIC_ORIGIN ein und hinterlege sie als Discord-Redirect.
5. 5
   Deployen und mit GET /health prüfen.

docker run -d --name atelier-api \
  -p 3095:3095 \
  -v atelier-data:/data \
  --env-file .env \
  atelier-api

Der Server bringt unter /admin ein eigenes Web-Dashboard mit — Login nur für die Discord-IDs aus ATELIER_ADMIN_DISCORD_IDS. Die Anmeldung läuft über einen eigenen Discord-Web-Flow (getrennt von der Desktop-App), die Session steckt in einem HttpOnly-Cookie, und der Admin-Status wird bei jedem Request neu geprüft.

• Übersicht — Speichergröße (CAS/Builds/tmp) und Kennzahlen (Assets, Packs, Revisionen, Builds, Nutzer).
• Logs — Server-Logs live (SSE) plus Aktivitäts-Protokoll.
• Packs & Builds — Server-Builds pro Revision erzeugen oder neu bauen und die fertigen Pakete als ZIP herunterladen.
• fxmanifest — pro Pack den Resource-Namen und ein fxmanifest.lua-Template überschreiben. Greift beim nächsten Server-Build; ohne Override bleibt alles byte-identisch zum Desktop-Build.
• Nutzer — freischalten und sperren.

Alle Endpoints liegen unter /api/v1. Nutzer-Endpoints brauchen einen Bearer- Token (aus dem Login), die Registry-Lane einen Service-Token. Die wichtigsten Gruppen: