Django 4.2+ z gunicorn i Postgresem - wdrożysz aplikację albo API.
Środowisko
| Runtime | Python 3.13, gunicorn, usługa zarządzana przez Saplo, nginx |
| Zalecany plan | Box L+ (Python + baza) |
Przykładowy saplo.yaml
Plik saplo.yaml w katalogu głównym repozytorium opisuje, jak Saplo ma zbudować i uruchomić aplikację. Wygeneruje go też komenda saplo init.
version: 1
name: my-django-api
stack: django
app_id: 1234
build:
command: python manage.py collectstatic --noinput
packages:
- libpq
env:
DJANGO_SETTINGS_MODULE: config.settings
Pełny opis wszystkich pól znajdziesz na stronie Plik saplo.yaml.
Jak wdrożyć
Ten stack wdrożysz na trzy sposoby - wybierz wygodny dla siebie:
- Z panelu - tworzysz aplikację klikami, kod wgrywasz później przez CLI lub Git.
- Saplo CLI - z katalogu projektu:
saplo init, potemsaplo deploy. - Deploy z GitHub - podłączasz repo raz, każdy push wdraża się sam.
# Najszybsza droga - z katalogu projektu
$ npm install -g @saplo/cli
$ saplo login
$ saplo init
$ saplo deploy
Dobrze wiedzieć
- Pole packages: instaluje pakiety systemowe (np. libpq) przed buildem.
- Migracje uruchom hookiem: hooks.post_deploy: python manage.py migrate - wykonuje się po buildzie, przed startem aplikacji.
- Bazę Postgres stawiasz jako osobną aplikację (katalog → Bazy danych), a przy tworzeniu aplikacji Django zaznaczasz ją w sekcji Połącz z bazą. Zmienna DATABASE_URL trafia do procesu aplikacji automatycznie. Szczegóły w sekcji Bazy danych.
- Masz w projekcie Django i Dockerfile? Wybierz stack django - Saplo zbuduje natywnie (gunicorn, nginx dla /static/). Stack docker wybierz tylko gdy chcesz pełnej kontroli przez własny Dockerfile.
- nginx serwuje /static/ i /media/ - resztę przejmuje gunicorn.
Gotowy na deploy?
Wybierz plan Box i postaw aplikację Django jeszcze dziś.