REPO=<fill-this-in>

Set up Django on this VM by following the exe.dev recipe at https://exe-staging.dev/deploy/django.md from top to bottom.

The values at the top of this message are mine:
- REPO: the GitHub repository to deploy, as owner/name or a URL, or `new` to start a fresh Django app
Ask me for any that still say <fill-this-in> before you need them.

The recipe's example VM name is my-django. This VM's name is the output of `hostname`: use it wherever the recipe writes my-django. Skip the step that creates the VM; you are on it.

You are done when all of these are true. Check each one yourself:
- Your Django app, or a new Django 6.1 project, served by gunicorn behind nginx on port 8000, under systemd and enabled to start after a reboot.
- `git push exe main` deploys: the pre-receive hook in `~/app.git` builds and migrates each push in a new `~/releases` directory and switches `~/app` to it only if every step passes, so a failing build rejects the push and the running release stays.
- Production settings for exe.dev's proxy in `~/app-settings` and `~/app.env`, with DEBUG off, a generated secret key, HTTPS detected, and allowed hosts and CSRF origins set; `manage check --deploy` reports no issues.
- SQLite in WAL mode at `~/data/db.sqlite3`, and uploads in `~/data/media` served at `/media/`.
- The owner's exe.dev account is a Django superuser and opens `/admin/` without a password.
- Nightly backups in `~/backups`, with a first one taken and checked.

Read the whole recipe, including the closed details, and follow "Set it
up by hand" in order, skipping "Create the VM"; the walkthrough above it
is for the owner. REPO=new takes "Start a new project"; anything else
takes "Bring your repository". If cloning from GitHub fails, the
repository is private: give the owner the `ssh exe.dev integrations add
github` command from that step, with this VM's name and the repository,
wait for them, and clone from github.int.exe.xyz.
Never overwrite an existing ~/app.env. Don't commit to the owner's code,
and don't push test commits to ~/app.git: read the hook to check it.
If their repository doesn't fit the deploy hook (manage.py not at the
top, Pipenv, a custom user model without a username field), adapt the
hook or the command and tell the owner what you changed.
Leave the VM private and don't reboot: check that app.service, nginx and
app-backup.timer are enabled instead. Skip the later Restore and Update
instructions; the restore check in setup uses a scratch copy only.
The URLs to give are https://<vm>.exe.xyz/ and /admin/. Of the two
commands at the end, give the owner only the one that fits REPO,
followed by `git push exe main`, and say what you adapted, if anything.

Finish with the URLs I should open and these commands, which only I can run, from my own computer (with this VM's name in them):
  git clone -o exe my-django.exe.xyz:app.git my-django  # if you started a new project
  git remote add exe my-django.exe.xyz:app.git          # or, in your own repository's checkout