Django to dojrzały framework do budowy aplikacji webowych i API w Pythonie, z ORM, systemem migracji i panelem admina wbudowanym od ręki. Własna aplikacja Django potrzebuje jednak działającego procesu WSGI (zwykle gunicorn) trzymanego w tle, nie tylko katalogu z plikami - dokładnie tak jak Next.js potrzebuje procesu Node. Na zwykłym hostingu współdzielonym takiego procesu się nie uruchomi. Na Saplo Django uruchamiasz jako usługę zarządzaną z automatycznym restartem, a nginx serwuje pliki statyczne i media obok niej.
Dla kogo jest Django na Saplo
Zanim zaczniesz instalację, sprawdź, czy to dobry wybór dla Twojego projektu:
- masz własny projekt Django - Saplo uruchamia gunicorn jako usługę zarządzaną, nie musisz sam pisać configu systemd,
- API pod aplikację mobilną albo osobny frontend SPA - Django Rest Framework albo zwykłe widoki JSON, frontend (React, Vue) stawiasz osobno z tego samego katalogu,
- projekt, który wyrósł z darmowego planu Heroku, Render czy PythonAnywhere - migrujesz kod bez zmian w samej aplikacji, dopisujesz tylko
saplo.yaml, - chcesz wdrożeń z
git pushzamiast ręcznego wgrywania plików - podpinasz repozytorium raz, a Saplo buduje, migruje i restartuje usługę automatycznie.
Wymagania
Żeby postawić Django na Saplo, potrzebujesz:
- Boxa w planie L lub wyższym, jeśli projekt ma korzystać z własnej bazy Postgres i realnego ruchu - starter z SQLite zmieści się na niższym planie, ale produkcyjna baza i większy ruch potrzebują zapasu RAM,
- minimum 256 MB wolnego RAM i 2 GB miejsca na dysku pod sam proces aplikacji (starter),
- wersji Pythona 3.11 albo 3.12 przy instalacji z katalogu, 3.13 dostępnej przy wdrożeniach przez git,
- domeny albo subdomeny
*.saploapp.plw cenie każdego planu, - repozytorium Git, jeśli chcesz korzystać z automatycznego wdrażania (opcjonalne na start, aplikację możesz też wgrać archiwum
.zipprzez panel).
Instalacja krok po kroku
- W panelu Saplo wejdź w Katalog aplikacji i wybierz Django (kategoria "Aplikacje").
- Wskaż Box oraz nazwę aplikacji - z niej powstaje domyślna subdomena
<nazwa>.saploapp.pl. - Wybierz wersję Pythona (3.11 albo 3.12, domyślnie 3.12) i zatwierdź instalację.
- Silnik tworzy nowy projekt Django z bazą SQLite (wystarcza do startu i testów), konfiguruje gunicorn przez supervisora na porcie 8000, a nginx proxy'uje ruch z domeny na ten port.
- Po zakończeniu instalacji domena z kroku 2 pokazuje działający szkielet Django - od tego momentu wdrażasz na nią własny projekt.
Wdrożenie własnego kodu przez Git
- W szczegółach aplikacji znajdź sekcję Git / CI-CD i kliknij "Połącz GitHub", potwierdź instalację aplikacji "Saplo Deploy" i wskaż repozytorium z projektem Django.
- W katalogu głównym repozytorium umieść plik
saplo.yamlz komendą builda (np.collectstatic) i ewentualnymi pakietami systemowymi (np.libpq-dev, jeśli łączysz się z Postgresem). - Migracje uruchomisz hookiem
hooks.post_deploy: python manage.py migrate- wykonuje się po buildzie, przed startem aplikacji, więc nie musisz łączyć się po SSH po każdym wdrożeniu. - Własną bazę Postgres stawiasz jako osobną aplikację z katalogu (Bazy danych), a przy tworzeniu aplikacji Django zaznaczasz ją w sekcji Połącz z bazą - zmienna
DATABASE_URLtrafia do procesu aplikacji automatycznie. - Zacommituj i wypchnij
saplo.yamlna gałąź produkcyjną (domyślniemain). Każdy kolejnygit pushbuduje, migruje i restartuje usługę, status widzisz w zakładce Deploymenty.
Przykład minimalnego pliku saplo.yaml dla Django:
name: moj-projekt
stack: django
runtime:
python: "3.13"
build:
install: pip install -r requirements.txt
command: python manage.py collectstatic --noinput
packages:
- libpq-dev
env:
DJANGO_SETTINGS_MODULE: config.settings.production
hooks:
post_deploy: python manage.py migrate
start:
command: gunicorn config.wsgi:application
port: 8000
Masz w projekcie własny Dockerfile i wolisz pełną kontrolę nad środowiskiem uruchomieniowym? Wybierz w katalogu stack Docker zamiast Django - wtedy Saplo nie zrobi natywnego build+gunicorn+nginx dla /static/, tylko uruchomi Twój obraz tak jak go zbudowałeś.
Django na Saplo kontra alternatywy
| PythonAnywhere | Heroku / Render | Django na Saplo | |
|---|---|---|---|
| Model rozliczenia | limit CPU na darmowym planie, płatne wyższe | zużycie zasobów, rośnie z ruchem | stały koszt Boxa |
| Wdrożenia z Gita | ograniczone, głównie ręczny upload | tak, natywnie | tak, git push na gałąź produkcyjną |
| Migracje po deployu | ręcznie przez konsolę | release phase w Procfile | hook post_deploy w saplo.yaml |
| Własna baza Postgres | osobna usługa, dodatkowy koszt | osobny dodatek, rozliczany oddzielnie | osobna aplikacja z tego samego katalogu |
Najczęstsze pytania
Czy baza SQLite ze startera nadaje się do produkcji? Do małego ruchu i testów tak, ale przy większym ruchu podepnij Postgres z katalogu aplikacji (sekcja Bazy danych) i zaznacz go przy tworzeniu aplikacji Django.
Czy migracje uruchamiają się same przy każdym wdrożeniu?
Tak, jeśli dodasz hook hooks.post_deploy: python manage.py migrate w saplo.yaml - wykonuje się po buildzie, przed startem aplikacji.
Czy mogę mieć obok Django dodatkowy proces, np. Celery workera?
Tak, pole processes w saplo.yaml pozwala zdefiniować dodatkowe procesy uruchamiane razem z głównym.
Co jeśli mój projekt łączy się z Postgresem i potrzebuje libpq?
Wpisz pakiet systemowy w sekcji packages pliku saplo.yaml - zostanie zainstalowany przed buildem.
Czy dostanę SSL i własną domenę?
Tak, certyfikat SSL jest automatyczny, a domenę albo subdomenę *.saploapp.pl masz w cenie każdego planu.
Django na Saplo stawiasz od zera do działającej domeny w kilka minut, a każdy kolejny git push buduje, migruje i restartuje usługę bez Twojego udziału. Jeśli projekt potrzebuje pełnej kontroli nad środowiskiem uruchomieniowym przez własny Dockerfile, w tym samym katalogu znajdziesz stack Docker.