daybook/docs/deployment.md
peter 4a5ea8944b Add generic deployment docs and fix stale references
Adds docs/deployment.md, a platform-agnostic guide (any Linux host with
Docker) built around a git-pull based fast-redeploy workflow, replacing the
Proxmox-specific deploy/proxmox_llm_deploy.md which was also stale (old
`persona` field, single-shared-token model predating multi-user auth).

Also: drops the unused DAYBOOK_API_TOKEN from deploy/env.example, documents
the new DELETE endpoint and capabilities `methods` field in docs/api.md and
docs/agent_quickstart.md, and fixes CLAUDE.md's OpenCode note now that
opencode.json is untracked (machine-specific MCP config).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-01 22:14:34 +01:00

5.3 KiB

Deployment

Daybook deploys the same way on any Linux host with Docker: a cloud VM, a home server, a Proxmox guest, whatever. It runs as a single Docker container (Gunicorn) with all persistent state — the SQLite database and artifact files — on a bind-mounted ./data directory outside the image.

Target host (cloud VM, home server, ...)
  Docker Engine
    daybook container
      /app     application code baked into the image
      /data    persistent volume: db.sqlite3, artifacts_store/

Files In deploy/

File Purpose
Dockerfile Builds the Daybook image.
docker-compose.yml Runs Daybook with a persistent ./data:/data bind mount.
entrypoint.sh Runs migrations, collects static files, then starts Gunicorn.
env.example Template for deployment environment variables.

Prerequisites On The Target Host

  • Docker Engine + the Docker Compose plugin
  • Git (for the clone-and-pull workflow below)
docker --version
docker compose version

First-Time Setup

Clone the repo onto the host at a stable path:

git clone <REPO_URL> /opt/daybook
cd /opt/daybook

Create the environment file:

cp deploy/env.example deploy/.env

Generate a secret key:

python3 -c "import secrets; print('DJANGO_SECRET_KEY=' + secrets.token_urlsafe(50))"

Edit deploy/.env and set at minimum:

DJANGO_DEBUG=0
DJANGO_SECRET_KEY=<generated-secret>
DJANGO_ALLOWED_HOSTS=<vm-ip-or-dns-name>,localhost,127.0.0.1
DAYBOOK_DATA_DIR=/data
DATABASE_PATH=/data/db.sqlite3
ARTIFACTS_ROOT=/data/artifacts_store

There is no shared API token to configure — Daybook uses per-user tokens (DRF Token model) issued from Settings → Account once a user exists. Do not commit deploy/.env.

Create the persistent data directory and bring the stack up:

mkdir -p deploy/data
docker compose -f deploy/docker-compose.yml up -d --build

Create your first login (superuser) so you have something to log in with and a personal API token to post through:

docker compose -f deploy/docker-compose.yml exec daybook python manage.py createsuperuser

Verify Deployment

docker compose -f deploy/docker-compose.yml ps
curl -fsS http://127.0.0.1:8000/api/capabilities

An unauthenticated capabilities check returns 403 (login/token required) — that's expected; it confirms the app is up and enforcing auth. Open http://<vm-ip>:8000/ in a browser and log in with the superuser you just created, then grab a personal token from Settings → Account and use it for a smoke-test post:

curl -fsS -X POST http://127.0.0.1:8000/api/artifacts \
  -H "Authorization: Bearer <your-personal-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "source": "deploy-smoke",
    "kind": "markdown",
    "title": "Deployment Smoke Test",
    "content": "# Deployment Smoke Test\n\nDaybook accepted an artifact."
  }'

Fast Redeploys

Once the host has a git clone, shipping a new version is two commands:

cd /opt/daybook
git pull
docker compose -f deploy/docker-compose.yml up -d --build

The entrypoint runs Django migrations on every start, so schema changes are picked up automatically. deploy/.env and deploy/data/ are untouched by git pull since they aren't tracked in the repo.

Operational Commands

docker compose -f deploy/docker-compose.yml logs -f daybook
docker compose -f deploy/docker-compose.yml restart daybook
docker compose -f deploy/docker-compose.yml down
docker compose -f deploy/docker-compose.yml up -d
docker compose -f deploy/docker-compose.yml exec daybook python manage.py check
docker compose -f deploy/docker-compose.yml exec daybook sh

Backup And Restore

Back up deploy/data/ — it contains the SQLite database and all artifact files:

tar -czf daybook-data-$(date +%Y%m%d-%H%M%S).tar.gz -C /opt/daybook/deploy data

For a consistent snapshot during heavy writes, stop the container first:

docker compose -f deploy/docker-compose.yml down
tar -czf daybook-data-$(date +%Y%m%d-%H%M%S).tar.gz -C /opt/daybook/deploy data
docker compose -f deploy/docker-compose.yml up -d

To restore: stop Daybook, replace deploy/data/ with the backup contents, then start it again.

Reverse Proxy Notes

If putting Daybook behind Nginx, Caddy, Traefik, or a cloud load balancer:

  • Proxy to http://<vm-ip>:8000.
  • Add the public hostname to DJANGO_ALLOWED_HOSTS.
  • Terminate TLS at the proxy; keep DJANGO_DEBUG=0.
DJANGO_ALLOWED_HOSTS=daybook.example.com,localhost,127.0.0.1

Deployment Checklist

  • deploy/.env exists with a real (non-placeholder) DJANGO_SECRET_KEY.
  • DJANGO_DEBUG=0.
  • DJANGO_ALLOWED_HOSTS includes the hostname/IP being used.
  • deploy/data/ exists and persists across git pull + rebuild.
  • docker compose -f deploy/docker-compose.yml ps shows daybook healthy.
  • curl -fsS http://127.0.0.1:8000/api/capabilities returns 403 without auth, 200 with a valid token or session.
  • At least one superuser exists (manage.py createsuperuser) with a token from Settings → Account.

Known MVP Constraints

  • SQLite is used by default — fine for a single-VM self-hosted deployment.
  • Per-user ingest tokens; no shared/global token.
  • Reader/browser access requires login; feeds are private per user.
  • Manual drag/drop upload and content revisions are deferred.