Statiska webbappar

En statisk webbapp serverar en katalog i ett Git-förråd över HTTPS, fil för fil, precis som den är incheckad. Ingenting byggs och ingen av din kod körs på servern: plattformen kopierar filerna till en webbserveravbild och serverar dem. Det du konfigurerar är var filerna kommer ifrån, hur förfrågningar routas och cachas, och vilken adress webbplatsen svarar på.

Statisk webbapp eller app?

• Använd en statisk webbapp när förrådet redan innehåller den färdiga webbplatsen: HTML, CSS, JavaScript och bilder, skrivna för hand eller skapade av ett bygge vars resultat du checkar in.
• Använd en app när webbplatsen först måste byggas — React, Vue, Astro, Next.js, Hugo, allt som har ett byggkommando — eller när den behöver serverkod, inställningar eller hemligheter medan den körs. Se Appar.

En statisk webbapp har inga bygginställningar, inga miljövariabler och inga referenser till hemligheter: det finns inget bygge att skicka dem till och ingen process som kan läsa dem.

Vad en driftsättning gör

Varje driftsättning paketerar webbplatsen på nytt:

1. Plattformen klonar förrådet på webbplatsens gren — på commiten från den senaste push som den tog emot för grenen, eller på grenens senaste commit om den inte har tagit emot någon — och tar Katalog att servera därifrån.
2. Den kontrollerar katalogen. Driftsättningen misslyckas om katalogen inte finns, är tom, saknar index.html eller innehåller en package.json med ett build-skript — tecknet på en webbplats som behöver byggas.
3. Den tar bort förråds- och verktygsfiler från katalogens översta nivå: .git, .github, .gitlab, .gitlab-ci.yml, .stackship, node_modules, package.json, låsfiler (package-lock.json, *-lock.yaml, *.lock, *.lockb), tsconfig.json och jsconfig.json, samt filer vars namn börjar med .env på de två översta nivåerna. Kopior längre ned i katalogen, till exempel en node_modules-mapp i en undermapp, paketeras och serveras som alla andra filer; bara namn som börjar med en punkt nekas alltid — se Andra regler.
4. Den bygger en avbild av det som är kvar, lagrar den i plattformens containerregister och rullar ut den.

Webbplatsen fortsätter att servera sin tidigare driftsättning tills den nya är klar. En driftsättning som misslyckas lämnar den tidigare kvar; webbplatsen visar då Degraded, eller Error när ingenting serverades tidigare, tills en senare driftsättning lyckas.

Obs

En driftsättning vars paketering misslyckas startas om automatiskt. Ungefär fem minuter efter felet paketerar plattformen samma källa igen, som en ny driftsättning, och fortsätter med det tills en driftsättning lyckas: varje försök lägger till ännu en rad med Failed på fliken Driftsättningar. Åtgärda orsaken — pusha rättningen, eller ändra webbplatsens källa eller katalog — för att få det att upphöra.

En webbplats driftsätts när den skapas, när du väljer Driftsätt eller startar om den med CLI:t eller API:t, när du ändrar dess källa eller katalog, och vid varje push till dess gren — se Automatiska driftsättningar.

Routing utan ny driftsättning

Fallback för single-page-app, 404-sidan och cacheförvalet ingår inte i avbilden. Plattformen gör om dem till webbserverns konfiguration, så en ändring börjar gälla inom några sekunder och webbplatsen paketeras inte om. Vad varje inställning gör, och de exakta cachehuvudena, finns i Routing och cachning.

Adress och certifikat

Varje webbplats får en plattformsadress under apps.example.com, byggd av boundaryn, resursgruppen och webbplatsens namn; guiden för att skapa visar den innan webbplatsen finns. Du kan lägga till en egen domän, och plattformsadressen fortsätter att fungera bredvid den.

En webbplats serveras alltid över HTTPS med ett certifikat från Let's Encrypt, och vanlig HTTP omdirigeras till HTTPS. Det finns inget läge för enbart HTTP.

Sidor

• Skapa en statisk webbapp
• Hantera en statisk webbapp — driftsättningar, servera en tidigare driftsättning, konfiguration, egen domän, stoppa och starta
• Routing och cachning
• Statusar
• Behörigheter