djevops generates and automatically renews SSL certificates for any domains you specify in Django setting ALLOWED_HOSTS. The domains need to be tied to your server's IP address.

When you fill in the mail section in the config file, then djevops sets up a local Postfix relay. This can be used to send emails from your server, for example via Django's send_mail function. If you additionally want to receive emails when errors occur on your server, set ADMINS and SERVER_EMAIL in Django's settings.py file, as follows:

ADMINS = [('Your Name', 'your@email.com')]
SERVER_EMAIL = 'sender@your.website.com'

In the above example, your@email.com receives an email from sender@your.website.com when an error occurs on the server. In order for this to work, the credentials configured in the mail section must be allowed to send emails as SERVER_EMAIL.

Error emails are only sent when Django setting DEBUG is False.

You can set up automatic database backups by adding a backup element to the db section in the djevops config file. For example:

db:
  type: sqlite
  backup:
    type: s3
    bucket: mybackup
    access-key-id: S3_BACKUP_ACCESS_KEY
    secret-access-key: S3_BACKUP_SECRET_KEY
    path: db
    region: us-east-1

Backups are created continuously while your server is running. If you ever re-install your server, then the latest backup is automatically restored.

For database type sqlite, djevops uses Litestream for backups. Litestream can store backups in S3, Azure Blob Storage and many others. The keys you add to the backup element above get copied into a replica element in Litestream's config. For more information about the available options, please see Litestream's documentation.

Djevops also supports database type postgres. For more information about this, please see below.

Instead of SQLite, you can use PostgreSQL by setting the database type to postgres:

db:
  type: postgres

You then configure the connection yourself in your settings.py:

import os

DATABASES['default'] = {
    'ENGINE': 'django.db.backends.postgresql',
    'NAME': 'myapp',
    'USER': 'myapp',
    'PASSWORD': os.environ['DB_PASSWORD'],
    'HOST': 'localhost'
}

djevops reads these settings and installs PostgreSQL on the server, creating the database and user with the password you specified. Keep the password out of Git by storing it in deploy/secrets.py. For example:

DB_PASSWORD = "<some strong password>"

Then reference it as a secret in the Django service's environment:

services:
  web:
    type: django
    env:
      secret:
        - DB_PASSWORD

You also need to add psycopg[binary] to your pyproject.toml or requirements.txt file.

As with SQLite, you can add a backup element to enable automatic backups. By default, PostgreSQL backups are taken once per day. You can customize this by setting sync-interval in the backup element, for example to 1h for hourly backups.

If your Django app uses the celery Python package, then you can add a Celery worker by adding the following item to the djevops config:

services:
  web:
    # as before
  celery:
    type: celery
    env:
      inherit: web

To install Redis on the server (which many Django apps use as Celery's backend), add an empty top-level redis block:

redis:

This setup lets you run Python functions asynchronously and on a schedule such as "every five hours". The service of type celery also runs the necessary beat scheduler.

djevops writes the log file for each service to /var/log/<service>.log. To read it, simply SSH into the server and do less, tail -f, etc. To prevent log files from filling up your server's disk space, djevops also rotates and compresses log files.

Very often, you have secrets that you need on the server but should not commit to Git. djevops lets you specify such values in the file deploy/secrets.py, and refer to them from your config file. The way this works is that secrets.py gets executed on your local machine, and the produced values then get uploaded as constants to the server. This gives you a lot of flexibility. You can hardcode values in secrets.py and not commit that file to Git. Or you can for example make secrets.py read from environment variables that are available when you do djevops deploy:

import os
MY_SECRET = os.environ['MY_SECRET']

You can also invoke password managers in secrets.py, etc.

djevops uses secure defaults whenever possible. For example, each service runs as a separate user. This means that environment variables cannot leak from one service to another. djevops also makes sure that no unintended ports are open, such as for example port 25 when using Postfix for sending emails.

djevops sets up automatic OS updates to keep your server up-to-date and secure. This does not apply major version upgrades, which could introduce potentially breaking changes.

Just type djevops shell to be dropped into a remote Django shell on your server. This uses the environment variables and user of the first service of type django in deploy/djevops.yml.

We saw several kinds of services above. Another one is type: command. For example:

services:
  myservice:
    type: command
    command: ./my-service.sh

This runs my-service.sh from your Git repository whenever your server is running. The command must not exit; if it does, djevops restarts it.

Sometimes your app needs things on the server that djevops does not know about, for example an apt package, a tool built from source, or an SSH key for one of your services. For such cases, you can create executable hooks next to deploy/djevops.yml. djevops runs them on the server at specific points during djevops deploy. The available hooks are:

• deploy/pre-install runs after your Git repository has been cloned into /srv/app but before your app's dependencies are installed.
• deploy/post-install runs after everything else has been set up and just before your services are started.

For example:

#!/bin/bash
set -euxo pipefail
apt-get install -yq faketime

Don't forget to chmod +x the hook. It can be any executable: a shell script as above, a Python script, a binary, etc. Hooks run as root in an empty temporary directory. The values from your deploy/secrets.py are available to them as environment variables.

To keep deploys fast, djevops only runs a hook when its contents or your secrets have changed since its last successful run. Because secrets sometimes do change, your hooks must be able to re-run over the results of a previous execution.