- new DEPLOYMENT.md: security model, env vars, first deploy, DB reset - README: clarify demo accounts are dev-only, link to DEPLOYMENT.md Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
3.3 KiB
Deployment (Dokploy)
Guide for deploying Space Booking to production via Dokploy. The app ships as a
Docker Compose stack (docker-compose.yml): a backend (FastAPI/SQLite) and a
frontend (Vue, served behind Traefik).
Security model (read first)
- No demo accounts in production. The demo seed (
backend/seed_db.py) only runs whenRUN_SEED=1is set — never set it in production. - First user becomes admin. The first account to register on a fresh
database is automatically made
superadminand is activated immediately (no email verification needed). Register your own account first, right after the first deploy. - SECRET_KEY is enforced. With
DEBUG=false(the production default) the backend refuses to start unlessSECRET_KEYis a strong, random value (≥ 32 chars, not a known placeholder). Tokens are forgeable with a weak key. - CORS is restricted to
FRONTEND_URLin production;localhostis allowed only in dev (DEBUG=true).
Required environment variables (Dokploy → service → Environment)
SECRET_KEY=<openssl rand -hex 32>
FRONTEND_URL=https://space.roa.romfast.ro
DOMAIN=space.roa.romfast.ro
Do not set DEBUG (defaults to false = production) and do not set
RUN_SEED.
Optional (email/SMTP — needed so non-admin users can verify their accounts):
SMTP_ENABLED=true
SMTP_HOST=smtp.example.com
SMTP_PORT=587
SMTP_USER=user@example.com
SMTP_PASSWORD=...
SMTP_FROM_ADDRESS=rezervari@romfast.ro
Without SMTP, only the first user (the admin, auto-activated) can log in; other registrations stay inactive until email verification.
First deploy
- Push the latest code to the git remote that Dokploy tracks (
master). - In Dokploy, set the environment variables above.
- Deploy / Redeploy. Tables are created automatically on boot.
- Open the site → Register with your own email → you become
superadmin.
Resetting the database (start clean)
The production DB lives in the Docker volume backend_data, mounted at
/data/space_booking.db.
⚠️ Deleting the DB file while the container is running has no immediate effect — the app holds the file open and keeps using it. You must restart the container afterwards so it creates a fresh, empty database.
# 1. Find the backend container
docker ps | grep backend
# e.g. constanta-space-booking-mnsx1b-backend-1
# 2. Delete the database file
docker exec -it <container> rm -f /data/space_booking.db
# 3. Restart so the app recreates an empty DB
docker restart <container>
# 4. Verify it is empty (should print: users: [])
docker exec -it <container> \
python3 -c "import sqlite3; c=sqlite3.connect('/data/space_booking.db'); print('users:', list(c.execute('select id,email,role,is_active from users')))"
Then go to the site and register your admin account again.
Inspecting users in production
docker exec -it <container> \
python3 -c "import sqlite3; c=sqlite3.connect('/data/space_booking.db'); [print(r) for r in c.execute('select id,email,role,is_active from users')]"
Local development
For local dev with demo data, set DEBUG=true and RUN_SEED=1. The seed reads
account passwords from ADMIN_PASSWORD / MANAGER_PASSWORD / USER_PASSWORD
(weak defaults if unset). See backend/.env.example.