Jak działa deploy — Dokumentacja Saplo

Trzy drogi wdrożenia

Saplo obsługuje trzy niezależne metody deployu. Możesz ich używać zamiennie - każda tworzy deployment widoczny w tym samym panelu i na tej samej domenie aplikacji.

Panel webowy

Kliknij, wypełnij formularz, gotowe. Bez terminala, bez konfiguracji plików.

Saplo CLI

Narzędzie wiersza poleceń. Instalujesz raz, deployujesz z terminala lub CI/CD.

Git Push Deploy

Podepnij repo GitHub - każdy git push do brancha produkcyjnego uruchomi automatyczny deploy.

Kiedy co wybrać

Metoda	Kiedy używać	Wymagania
Panel	Pierwsze uruchomienie, szybki test, klient bez terminala	Konto Saplo
CLI	Codzienna praca dewelopera, skrypty, CI/CD poza GitHubem	Node.js 18+, token API
Git Push	Projekt na GitHubie, automatyzacja, zespół	Repo na GitHubie, plik `saplo.yaml`

Zalecana kolejność wdrożenia

Najpierw CLI, potem GitHub - ta kolejność daje najszybszą drogę od zera do działającej, automatycznie wdrażanej aplikacji.

Utwórz aplikację w panelu - wybierz stack i nazwę. Aplikacja dostaje swoje App ID.
saplo init w katalogu projektu - generuje plik saplo.yaml z App ID. Zacommituj saplo.yaml do repozytorium.
saplo deploy - pierwsze wdrożenie z CLI. Masz szybki feedback i logi prosto w terminalu, dopracowujesz aż aplikacja wstanie.
Podłącz repozytorium na stronie Git / CI-CD (format owner/repo). Od tego momentu każdy git push na gałąź produkcyjną uruchamia automatyczny deploy.

CLI i Git Push to nie konkurencja, tylko podział ról:

CLI - generuje manifest (saplo init), pierwsze wdrożenie, deploye ad-hoc i ręczne, wdrożenia z maszyny bez powiązania z repo.
Git Push - ciągły deployment dla projektów w repozytorium, docelowy standard pracy zespołowej.
saplo.yaml - wspólny manifest obu metod, źródło prawdy o stacku i buildzie.

Deploy z prywatnego repozytorium wymaga zainstalowanej aplikacji GitHub Saplo Deploy - bez niej platforma nie sklonuje kodu.

Frontend + backend

Aplikacja składa się z frontendu (np. Next.js) i backendu (np. Django)? To są dwie osobne aplikacje Saplo - każda ma własny saplo.yaml, własny kontener i własną subdomenę.

Jedna aplikacja = jeden folder. Frontend i backend muszą być w osobnych folderach (a dla Git Push - w osobnych repozytoriach). saplo deploy pakuje cały folder, w którym go uruchomisz - jeśli backend jest zagnieżdżony w folderze frontendu, trafi do paczki frontendu. Nie trzymaj ich razem - rozdziel projekt zanim zaczniesz wdrażać.

Poprawna struktura - frontend i backend obok siebie:

moj-projekt/
  frontend/      # tu: saplo deploy  (aplikacja 1)
    saplo.yaml
    package.json
  backend/       # tu: saplo deploy  (aplikacja 2)
    saplo.yaml
    manage.py

Zalecana kolejność wdrożenia:

Wdróż backend (saplo deploy w katalogu backendu). Zanotuj adres, np. moj-backend.saploapp.pl.
Wdróż frontend - ustaw w sekcji env zmienną z URL backendu, np. NEXT_PUBLIC_API_URL: https://moj-backend.saploapp.pl.
W backendzie ustaw CORS_ALLOWED_ORIGINS na adres frontendu, np. https://moj-frontend.saploapp.pl. Zrób redeploy backendu.

Wspólne elementy

Niezależnie od metody deployu, każda aplikacja Saplo:

dostaje subdomenę <nazwa>.saploapp.pl automatycznie,
może mieć podpięte własne domeny (przez panel lub CLI),
jest izolowana w osobnym kontenerze LXC,
konfigurowana jest przez plik saplo.yaml (generowany automatycznie lub ręcznie).

Plik saplo.yaml jest opcjonalny przy deployu z panelu - ale wymagany przy Git Push Deploy. Szczegóły w referencji saplo.yaml.

Obsługiwane stacki

Wszystkie trzy metody deployu obsługują te same stacki technologiczne:

Next.js React Vue 3 Nuxt 3 SvelteKit Angular Astro Django Node.js Static Docker

Szczegóły każdego stacka znajdziesz w dokumentacji stacków.