Produkty

Sites — automatyzacja i potok wdrożeń

Kreator, hostbase.json, kroki przed/po wdrożeniu, testy dymne, auto-rollback, harmonogramy, Lighthouse, grupy zmiennych i skrypty.

Sites potrafi więcej niż „wgraj i opublikuj”: każde wdrożenie może przejść przez potok z testami, bramką jakości, zatwierdzeniem i automatycznym wycofaniem. Całość definiujesz w panelu (zakładka Potok) albo jako kod w hostbase.json.

Kreator nowej witryny

Import z Gita — repozytoria widoczne dla połączenia GitHub (także prywatne; to z integracji dostaje push-to-deploy) lub dowolny publiczny adres z github.com, gitlab.com, bitbucket.org, codeberg.org (także /tree/gałąź/podkatalog). Archiwum do 24 MB.
Wgraj pliki — przeciągnij folder (pomijamy node_modules, .git, .next) albo .zip / .tar.gz.
Szablony — ponad 20 starterów (Next.js z logowaniem Supabase, SaaS, sklep ze Stripe, Astro, SvelteKit, Nuxt, Vite React/Vue/Solid/Svelte, VitePress, Docusaurus, Eleventy, Hono, Express…).
Wykrywamy framework, menedżer pakietów (npm, pnpm, yarn, bun), wersję Node i monorepo (wybierasz katalog aplikacji). Wszystko możesz zmienić. Zmienne wczytasz z pliku .env; klucze Supabase wstrzykujemy same.
Na końcu widzisz log budowania na żywo i postęp wdrożenia.

Potok wdrożenia

Budowanie — preBuild (po instalacji) i postBuild to polecenia powłoki w kontenerze budowania (gVisor). Cache (.next/cache, .astro, .svelte-kit, node_modules/.cache itd.) jest zachowywany między buildami osobno dla każdej witryny (do 1 GB na katalog); w logu zobaczysz „build cache restored”.
Kontrole (opcjonalnie) — Lighthouse i różnice wizualne na adresie wdrożenia.
Bramka preDeploy — kroki smoke (HTTP: status, tekst), sql (migracja bazy projektu), script (polecenie w kontenerze) i webhook. Dopóki trwa bramka, wdrożenie jest tylko podglądem; błąd = produkcja się nie zmienia.
Zatwierdzenie (requireApproval) — promocję zatwierdza właściciel lub administrator w panelu lub komendą hostbase sites approve.
Promocja i kroki postDeploy na adresie produkcyjnym. Nieudany test = automatyczny rollback do poprzedniego wdrożenia i powiadomienie.
Nadzór 5xx (autoRollback) — przez minutes minut porównujemy liczbę odpowiedzi 5xx z żądaniami po promocji (logi Traefika); przekroczenie progu errorRate przy co najmniej minRequests żądań = rollback.

{
  "sites": {
    "web": {
      "framework": "nextjs",
      "pipeline": {
        "preBuild": ["npm run lint"],
        "postBuild": [],
        "cache": true,
        "preDeploy": [
          { "name": "Migracja", "sql": "alter table public.posts add column if not exists slug text;" },
          { "name": "Podgląd działa", "smoke": { "path": "/", "status": 200 } }
        ],
        "postDeploy": [
          { "smoke": { "path": "/", "status": 200, "contains": "Hello" } },
          { "smoke": { "path": "/api/health", "status": 200 } }
        ]
      },
      "triggers": {
        "productionBranch": "main",
        "previewBranches": ["feat/*"],
        "prPreviews": true,
        "schedule": "0 3 * * *",
        "onSchemaChange": false,
        "requireApproval": false
      },
      "autoRollback": { "enabled": true, "errorRate": 0.05, "minutes": 10, "minRequests": 20 },
      "checks": { "lighthouse": true, "visual": true, "minScores": { "performance": 70, "accessibility": 90 }, "gate": false },
      "scripts": [{ "name": "sitemap", "command": "node scripts/sitemap.mjs", "schedule": "30 4 * * *" }],
      "notify": { "onFailure": true, "onRollback": true, "webhook": null }
    }
  }
}

Plik hostbase.json w korzeniu archiwum (GitHub, hostbase sites deploy, kreator) jest wczytywany przy każdym wdrożeniu z kodu i zastępuje sekcje, które definiuje. Ustawienia budowania w pliku: framework, installCommand, buildCommand, outputDir, rootDir, startCommand, node, spa. Klucz "*" w sites dotyczy każdej witryny. Szkielet: hostbase sites init.

Wyzwalacze

Push do productionBranch → produkcja; push do gałęzi pasujących do previewBranches (np. feat/*) → podgląd z własnym adresem.
Pull requesty z tego samego repozytorium → podgląd, status commita i komentarz z adresem oraz wynikami Lighthouse (prPreviews).
Hook wdrożeniowy (POST …/api/hooks/sites/<token>) i API/CLI.
Harmonogram (schedule, cron 5-polowy w UTC) — np. nocna przebudowa strony statycznej generowanej z bazy.
Zmiana schematu bazy (onSchemaChange) lub bucketów Storage (onStorageChange) — sprawdzamy sygnaturę co 5 minut.
Zatwierdzanie — z włączonym requireApproval tylko owner/admin może też ręcznie promować wdrożenia.

Skrypty i zadania

Skrypty (scripts) to polecenia uruchamiane w obrazie budowania na kodzie ostatniego wdrożenia: regeneracja sitemapy, czyszczenie lub rozgrzewanie cache, importy. Mogą mieć schedule. Wynik i log trafiają do historii w zakładce Skrypty. Skrypt nie dostaje klucza service_role, chyba że owner/admin zaznaczy to wprost.

Kontrole jakości

Lighthouse (wydajność, dostępność, SEO, dobre praktyki; mobile lub desktop), zrzut ekranu i porównanie pikseli z produkcją (pixelmatch) w headless Chromium w osobnym, izolowanym kontenerze. Wyniki widać na liście wdrożeń, w zakładce Kontrole i w komentarzu PR. Progi minScores ostrzegają, a z gate: true blokują promocję.

Grupy zmiennych środowiskowych

Oprócz zmiennych wspólnych masz grupy production, preview i development (sekrety są maskowane). Produkcyjne wdrożenia dostają grupę production, podglądy i PR — preview. Do pracy lokalnej: hostbase sites env pull web --group development zapisuje .env.local z kluczami Supabase, zmiennymi wspólnymi i grupą.

Web Vitals (opcjonalnie)

Zakładka Analityka → Web Vitals: po włączeniu dostajesz fragment <script defer src="…/api/rum/<klucz>/v.js"> (~1 KB, bez cookies). Mierzymy LCP, INP, CLS, FCP i TTFB per ścieżka.

CLI

hostbase sites init web                              # szkielet hostbase.json
hostbase sites config push web                       # zastosuj hostbase.json
hostbase sites config pull web                       # zapisz konfigurację z panelu do pliku
hostbase sites pipeline web                          # przebiegi potoku z krokami
hostbase sites approve web pr_ab12cd34ef56           # zatwierdź promocję
hostbase sites scripts run web sitemap               # skrypt z konfiguracji (log na żywo)
hostbase sites scripts run web --command "npm run purge"
hostbase sites checks run web --deployment d12       # Lighthouse + zrzut + diff
hostbase sites env pull web --group development      # .env.local
hostbase sites env group web preview API_URL=https://staging.example --secret
hostbase sites rum web on

API i MCP

GET|PUT /api/v1/projects/{ref}/sites/{name}/auto/automation
GET|PUT /api/v1/projects/{ref}/sites/{name}/auto/env-groups        # ?reveal=1
GET     /api/v1/projects/{ref}/sites/{name}/auto/env-pull?group=development
GET     /api/v1/projects/{ref}/sites/{name}/auto/pipeline-runs
POST    /api/v1/projects/{ref}/sites/{name}/auto/pipeline-runs/{id}/approve|reject
GET|POST /api/v1/projects/{ref}/sites/{name}/auto/scripts          # {script} | {command}
GET|POST /api/v1/projects/{ref}/sites/{name}/auto/checks           # {deployment, form_factor}
GET     /api/v1/projects/{ref}/sites/{name}/auto/runs/{id}[/shot.png|diff.png|base.png]
GET|PUT /api/v1/projects/{ref}/sites/{name}/auto/rum

Narzędzia MCP: site_automation, site_env_groups, site_pipeline_runs, site_scripts, site_checks, site_rum.

Rozliczanie

Skrypty, kontrole Lighthouse i zrzuty ekranu zużywają minuty budowania Sites (czas pracy kontenera) — tak jak zwykłe buildy. Kontrola Lighthouse trwa zwykle około minuty; miniatury w przeglądzie to krótkie zrzuty (kilkanaście sekund) robione raz na wdrożenie produkcyjne. Powiadomienia o błędach, rollbacku i zatwierdzeniach trafiają do dzwonka i do kanałów organizacji (Slack, Discord, e-mail, webhook).

PoprzedniSites — hosting frontendu Następny Własne domeny