Deployment na Vercel – konfiguracja krok po kroku

Vercel to platforma hostingowa stworzona z myślą o frameworkach frontendowych – Next.js, Astro, SvelteKit, ale też statycznych projektach. Po podpięciu repozytorium Git każdy push buduje i publikuje stronę, a każdy pull request dostaje osobne preview. Ten artykuł przeprowadza Cię przez pełną konfigurację: import projektu, ustawienia buildu, zmienne środowiskowe, domeny, edge functions, monitoring i rollback.

Dlaczego Vercel

Najważniejsze zalety w praktyce:

• Zero konfiguracji serwera – build, SSL, CDN i cache działają od razu po imporcie repozytorium.
• Preview deployments – każda gałąź i każdy PR dostaje własny, publiczny URL.
• Globalny CDN – strona jest serwowana z najbliższego regionu (sieć Vercel obejmuje ponad 30 lokalizacji).
• Szeroka integracja z Git – GitHub, GitLab i Bitbucket.
• Edge Functions – lekka logika serwerowa bez osobnego backendu.

Import projektu z GitHuba

1. Załóż konto na vercel.com i zaloguj się przez GitHub.
2. Kliknij Add New → Project.
3. Wybierz repozytorium z listy – Vercel automatycznie wykrywa framework i ustawia domyślne polecenia (np. bun install i astro build dla projektu Astro).
4. Jeśli framework nie zostanie wykryty, ustaw build ręcznie w sekcji Build and Output Settings:

{
  "buildCommand": "bun run build",
  "outputDirectory": "dist",
  "installCommand": "bun install",
  "framework": "astro"
}

5. Kliknij Deploy – pierwszy build rusza od razu, a po kilkudziesięciu sekundach strona jest dostępna pod projekt.vercel.app.

Jeśli projekt ma własny plik vercel.json w repozytorium, jego ustawienia mają pierwszeństwo przed wartościami z panelu – dzięki temu konfiguracja jest wersjonowana razem z kodem.

Konfiguracja buildu przez vercel.json

Plik vercel.json w katalogu głównym projektu pozwala precyzyjnie sterować buildem i routingiem. Przykład dla strony statycznej:

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "buildCommand": "bun run build",
  "outputDirectory": "dist",
  "rewrites": [
    { "source": "/api/:path*", "destination": "/api/:path*" }
  ],
  "headers": [
    {
      "source": "/assets/(.*)",
      "headers": [
        { "key": "Cache-Control", "value": "public, max-age=31536000, immutable" }
      ]
    }
  ]
}

Najczęściej używane sekcje:

• buildCommand / installCommand / outputDirectory – nadpisują domyślne polecenia wykryte dla frameworka.
• rewrites / redirects – przekierowania 301/302 i mapowanie tras (np. dla funkcji serwerowych).
• headers – nagłówki cache i bezpieczeństwa per ścieżka.
• functions – limity czasu i pamięci dla funkcji serwerowych.

Zmienne środowiskowe (env vars)

Zmienne konfigurujesz w Settings → Environment Variables projektu, osobno dla środowisk Production, Preview i Development:

• PUBLIC_SITE_URL – adres strony; używany do canonical, sitemap i Open Graph,
• PUBLIC_GTM_ID – identyfikator Google Tag Manager (jeśli jest),
• RESEND_API_KEY, OPENAI_API_KEY – sekrety używane wyłącznie po stronie serwera (API routes).

Zasady, których warto pilnować:

• Nazwy z prefiksem PUBLIC_ są wbudowywane w JavaScript po stronie klienta – nigdy nie wkładaj tam kluczy.
• Sekrety bez prefiksu dostępne są tylko w funkcjach serwerowych i w buildzie; nie trafiają do przeglądarki.
• Wartości dla Production i Preview mogą się różnić (np. osobny adres API do testów).

Preview deployments

Każdy push na gałąź inną niż produkcyjna tworzy preview deployment z unikalnym URL (nazwa-projektu-git-branch-hash. vercel.app). Vercel automatycznie komentuje link w GitHub Actions i w pull requestcie. Preview pozwala sprawdzić zmiany zanim trafią na produkcję, a w ustawieniach Git możesz włączyć dodatkowo:

• blokowanie merge’a, dopóki preview nie przejdzie pomyślnie,
• automatyczne usuwanie preview po zamknięciu PR (domyślne),
• wstrzykiwanie zmiennych środowiskowych osobnych dla preview.

Własna domena i SSL

W Settings → Domains dodajesz domenę, np. mahawir.pl i www.mahawir.pl:

• Vercel pokaże dokładne rekordy DNS do ustawienia u rejestratora (najczęściej A na adres IP Vercel oraz CNAME dla www).
• Po dodaniu rekordów SSL (Let’s Encrypt) wystawiany jest automatycznie, z automatycznym odnawianiem.
• Warto ustawić przekierowanie z www na główną domenę (lub odwrotnie) w sekcji Redirects, aby nie dzielić sygnałów SEO.

Dla projektów w fazie przedprodukcyjnej przydaje się Deployment Protection: w ustawieniach projektu można wymusić logowanie (hasło lub konto Vercel) dla wszystkich preview, zanim strona zostanie upubliczniona. Dzięki temu klient i zespół widzą postęp prac, a treści nie są indeksowane przez wyszukiwarki przed startem. Po uruchomieniu produkcji ochronę wyłączasz tylko dla gałęzi produkcyjnej – jeden przełącznik w sekcji Deployment Protection, a całość działa niezależnie dla preview i produkcji.

Edge Functions i monitoring

Edge Functions to funkcje uruchamiane na brzegu sieci, blisko użytkownika – idealne do geolokalizacji, nagłówków czy lekkiej personalizacji. W Astro włączasz je przez adapter Vercel i wyłączasz prerendering dla danej trasy; w Next.js wystarczy eksport runtime = 'edge' z route handlera.

Zarządzanie po wdrożeniu:

• Dashboard projektu pokazuje buildy, logi i status każdego deploymentu; każdy build ma unikalny URL i można do niego wrócić.
• Analytics (plan Pro) mierzy Core Web Vitals na prawdziwych użytkownikach – LCP, INP, CLS.
• Speed Insights pokazuje metryki wydajności w czasie rzeczywistym.
• Rollback – w zakładce Deployments wybierasz poprzedni udany build i klikasz Promote to Production; trwa to sekundy i nie wymaga zmian w kodzie.

Podsumowanie

Vercel redukuje deployment strony do połączenia repozytorium z platformą: automatyczny build, preview dla każdej zmiany, SSL i CDN w cenie. Kluczowe decyzje konfiguracyjne – zmienne środowiskowe, vercel.json i domeny – warto zrobić świadomie na starcie, a wersjonować razem z kodem. Do pełnej automatyzacji (sekrety w CI, pipeline z testami) podepnij deployment do workflow GitHub Actions – opisany w artykule o CI/CD.