Django application stack for Kubernetes on Wodby

Deploy Django applications on Kubernetes with Wodby.

This repository defines the Wodby stack manifests and default service composition for Django.

• Browse Wodby application stacks
• Wodby stack documentation
• Stack manifest reference

Start from a boilerplate

Use one of the compatible boilerplates exposed by this stack's services to start with Wodby CI build configuration:

• Django boilerplate

Service definitions

• Python (Django) service
• PostgreSQL service
• Valkey service
• Mailpit service
• OpenSMTPD service
• Gotenberg service
• Cloud PostgreSQL service

What's included

Component / service	Default configuration
Python (django) django	required; enabled by default; main service; Celery worker derivative; links: db → postgres, redis → valkey, sendmail → mailpit
PostgreSQL (postgres) postgres	required; enabled by default; volumes: data 20 GB
Valkey valkey	required; enabled by default; persistent 5 GB volume; queue-safe noeviction policy
Mailpit mailpit	optional; disabled by default
OpenSMTPD opensmtpd	optional; disabled by default
Gotenberg gotenberg	optional; disabled by default
Cloud PostgreSQL (cloud-postgres) cloud-postgres	optional; disabled by default

Enabled optional services are selected by default but can be excluded when an app is created. Disabled optional services are available but not selected by default. Required services cannot be excluded.

Background jobs

The Django service includes a Celery worker derivative, and the boilerplate configures it through CELERY_BROKER_URL. Valkey is required because it stores queued and unacknowledged work; persistence and noeviction prevent broker messages from being treated as disposable cache entries.

The boilerplate deliberately does not use this Valkey instance for Django's cache. Add a separate optional cache service with an LRU policy when an application needs caching so cache pressure cannot block broker writes.

Deploy this stack

Start from Django boilerplate, or connect your own compatible source repository.

Review service versions, storage, links, and optional components when creating the application. The same stack can be reused across development, staging, and production environments.

Maintain a custom version

1. Fork this repository.
2. Edit the stack manifest.
3. Import the repository as a Git-backed stack.

When replacing or renaming a stack service, update every related link target and derivative reference. Stack-local names and referenced service names are distinct identifiers.

Validate the manifests with:

wodby stack validate-manifest stack.yml --org <org-id>

See the stack manifest reference and the managed services index.