Skip to content
PAASBOXPAASBOXPAASBOX

Example: a Django SaaS

A typical Django SaaS, such as the open-source SaaS Pegasus boilerplate, is one web process, one background worker, a migration step, a PostgreSQL database and a Redis-compatible broker for Celery. This page shows that shape as paas.paasbox.com objects. It is a worked example, not a published starter repository — there is no ready-made manifest set to clone yet.

apiVersion: paas.paasbox.com/v1alpha1
kind: ManagedPostgres
metadata: { name: db, namespace: shop }
spec:
  plan: s
  storage: 20Gi
  backup: { retention: 7d, objectStoreSecretRef: { name: s3-backups } }
---
apiVersion: paas.paasbox.com/v1alpha1
kind: ManagedValkey
metadata: { name: broker, namespace: shop }
spec:
  plan: xs
  persistence: true
---
apiVersion: paas.paasbox.com/v1alpha1
kind: App
metadata: { name: shop, namespace: shop }
spec:
  image: registry.example.com/acme/shop:1.4.2
  port: 8000
  envFrom: [{ secretRef: { name: shop-env } }]      # DJANGO_SETTINGS_MODULE, SECRET_KEY, …
  uses:
    - { name: db, kind: ManagedPostgres, prefix: DB_ }
    - { name: broker, kind: ManagedValkey, prefix: REDIS_ }
  scale: { min: 0, max: 5 }
  release:
    command: [python, manage.py]
    args: [migrate, --noinput]
    timeoutSeconds: 300
---
apiVersion: paas.paasbox.com/v1alpha1
kind: App
metadata: { name: shop-worker, namespace: shop }
spec:
  type: worker
  image: registry.example.com/acme/shop:1.4.2
  command: [celery]
  args: [-A, project, worker, -l, INFO]
  envFrom: [{ secretRef: { name: shop-env } }]
  uses:
    - { name: db, kind: ManagedPostgres, prefix: DB_ }
    - { name: broker, kind: ManagedValkey, prefix: REDIS_ }
  scale: { min: 2 }
Terminal window
kubectl apply -f shop.yaml
pb status

What this gets you, with the pieces already covered on their own pages:

  • The web App waits for db and broker to be Ready, runs the release Job (migrate --noinput) against the new image, and only then rolls the new revision out — release step.
  • Both apps read the same database and broker through DB_* and REDIS_* environment variables that are references into the credentials Secrets, never copies — databases, caches.
  • shop-worker runs a fixed two replicas, no port, no URL, no scale-to-zero — web and worker.
  • envFrom loads the app’s own settings, SECRET_KEY included, from a Secret you manage separately.
  • pb preview up shop --ref <branch> --from-prod gives a pull request its own web app, worker, database (restored from production) and broker — preview environments.

What is not built yet: a published, clone-and-go repository for this shape, and building the image from source rather than from your own CI — see what’s coming.