Zum Inhalt springen
Farbschema wählenSprache wählen

Ports und Hosting-Domains

Das Docker-Compose-Deployment (docker-compose.yml) gibt folgende Ports frei:

Service Interner Port Host-gemappter Port Protokoll
web (SvelteKit) 3000 3001 HTTP
server (Rust/axum) 8080 8080 HTTP / WebSocket
postgres 5432 nicht veröffentlicht TCP (nur intern)

Der web-Container leitet Anfragen über das interne supacloud-Bridge-Netzwerk an server unter http://server:8080 weiter. PostgreSQL ist in der Standard-Compose-Konfiguration vom Host aus nicht erreichbar.

Netzwerk Zweck
supacloud Internes Bridge-Netzwerk: web, server und postgres kommunizieren hier.
supacloud-agents Isoliertes Bridge-Netzwerk für Agent-Container, die von server gestartet werden (Docker-Socket eingebunden unter /var/run/docker.sock).

SupaCloud verwendet zwei voneinander getrennte registrierbare Domains (ADR 0041 / Issue #410):

Domain-Rolle Umgebungsvariable Beispiel Liefert
Control Plane PUBLIC_URL https://app.supacloud.run API, Web-UI, Login, SPA
Gehostete App-Frontends SUPACLOUD_APPS_BASE_DOMAIN supacloud.net Deployete Plain-/React-/Svelte-Apps auf opaken Subdomains

Die Apps-Domain darf kein gemeinsames eTLD+1 mit dem Control-Plane-Host teilen. Eine Boot-Prüfung in secret_hydration.rs lehnt jeden SUPACLOUD_APPS_BASE_DOMAIN-Wert ab, der eine Geschwister-Subdomain, eine Obermenge oder eine Teilmenge des Control-Plane-Ursprungs darstellt (geprüft über die psl-Public-Suffix-Liste). Die Begründung für diese Einschränkung findet sich unter Warum separates App-Hosting.

Jedes deployete gehostete Frontend erhält eine stabile 80-Bit-Hex-Subdomain (app_deployments.subdomain, Migration 172), z. B. <opak>.supacloud.net. Die Apex-Domain (supacloud.net) gibt 404 zurück.

Die #113 Form-Renderer-App unterliegt nicht dieser Trennung — sie wird auf dem Control-Plane-Pfad (/a/{workspace_slug}/{route_path}) ausgeliefert und hat keine Subdomain.

interfaces/http/apps_host.rs ist als äußerste axum-Middleware eingebunden. Jede Anfrage, deren Host-Header zur Apps-Domain (oder einer Subdomain) passt, wird als App-Inhalt behandelt:

  • Es werden nur GET und HEAD akzeptiert; andere Methoden geben 405 zurück.
  • Die Anfrage erreicht den Control-Plane-Router (/api, SPA, Login) nicht.
  • HEAD-Antworten haben ihren Body in dieser Middleware entfernt (axums automatisches Entfernen greift auf Middleware-Ebene nicht).

Jede Datei, die vom Apps-Ursprung ausgeliefert wird, trägt den in services/app_deployments/artifact.rs definierten DEFAULT_CSP-Header:

default-src 'none';
script-src 'self';
style-src 'self' 'unsafe-inline';
img-src 'self' data: blob:;
font-src 'self' data:;
connect-src 'self';
media-src 'self' blob:;
manifest-src 'self';
worker-src 'self' blob:;
base-uri 'self';
form-action 'self';
frame-ancestors 'self'

Wenn SUPACLOUD_APPS_BASE_DOMAIN gesetzt ist, erweitert die ausgelieferte CSP frame-ancestors so, dass zusätzlich der Control-Plane-Ursprung erlaubt wird (csp_for_separate_origin), damit das WebIDE-Live-Vorschau-iframe die App ursprungsübergreifend laden kann. Die Basis-Direktive frame-ancestors 'self' bleibt erhalten, sodass ausschließlich der eigene Ursprung der App sowie dieser eine Control-Plane-Ursprung als Framer zugelassen sind; beliebige Drittseiten können die App weiterhin nicht einbetten.

X-Content-Type-Options: nosniff wird bei jeder ausgelieferten Datei gesetzt.

Der Pfad für gehostete Plain-/React-/Svelte-Frontends ist hinter einem Flag versteckt:

Variable Standard Effekt bei Aktivierung
SUPACLOUD_APPS_HOSTED_FRONTEND false Liefert gebaute dist/-Artefakte auf dem Apps-Ursprung aus.

Das Flag ist standardmäßig deaktiviert, bis das Build-Runner-Image mit vite --base=./ ausgeliefert wird. Die Form-Renderer-App ist von diesem Flag nicht betroffen.