ADR-022: Public landing host

Status: Accepted

Kontext

Öffentliche Hosts tragen zwei verschiedene Seiten: die ByteBite-Landingpage und die Restaurant-Storefront.

staging.getbytebite.co ist der Apex unter *.staging.getbytebite.co. Eine DNS-Wildcard trifft diesen Apex nicht. Für diesen Host gibt es keine Zeile in restaurant_domains. Die Landing-App apps/landing zeigt dort vorerst nur „Coming Soon“ plus Umgebung.

Restaurant-Bestellungen hängen an eigenen Hosts (luigi.staging.getbytebite.co, mario.staging.getbytebite.co, später <slug>.getbytebite.co und Custom Domains). Der lokale neutrale Host storefront.bytebite.test ist ein Entwicklungsplatzhalter, keine Landingpage.

Entscheidung

staging.getbytebite.co ist der Staging-Host der Marketing-Landingpage.

In Produktion sind getbytebite.co und www.getbytebite.co dieselbe Landingpage, keine Storefront.

Restaurant-Storefronts bleiben auf <slug>.staging.getbytebite.co, <slug>.getbytebite.co und verifizierten Custom Domains. Der Apex wird nicht als Restaurant-Domain geseedet und nicht als Tenant aufgelöst.

Die Landingpage ist die App apps/landing. Solange keine Marketing-Seite existiert, ist der Inhalt eine H1: Coming Soon, Staging wenn BYTEBITE_DEPLOY_ENV=staging, sonst Coming Soon, Production. getbytebite.co und www.getbytebite.co werden nicht an den Staging-Stack gehängt.

Konsequenzen

• staging.getbytebite.co routet Compose mit Priority 200 auf landing. Die Dokploy-UI-Domain soll auf denselben Service umgezogen werden; bis dahin gewinnt die Compose-Priority.
• Wildcard-Routing in compose.deploy.yml gilt für Tenant-Slugs, nicht für staging.getbytebite.co.
• Eine echte Marketing-Seite bleibt offen (Known gaps). Produktion setzt BYTEBITE_DEPLOY_ENV=production, weil der Compose-Default staging ist.