Adds the live database, DigitalOcean Spaces and Google CSE settings supplied by
the repo owner, so the container needs nothing set in the Dokploy UI.
Three deliberate departures from the development .env this came from:
AUTH_ALLOW_ANY_LOGIN is false, not true. In development it is a convenience -
the password field is not checked, so any username signs in and `admin` reaches
the admin pages. On a host published to the internet it means anyone who finds
mcp.nearle.ai.in becomes admin by typing anything at all. The development file's
own comment says to turn it off before the backend leaves the laptop.
The auth secrets are the freshly generated ones, not the development values.
Those hashes are for the passwords DevAdmin!2026 and DevUser!2026, which sit in
plaintext in test_login_fix.py in this same repository - committing them would
have published working admin credentials alongside the hash that accepts them.
Verified: DevAdmin!2026 is now rejected with a 401.
USE_OLLAMA is false. The development value http://localhost:11434 cannot work
from inside a container, where localhost is the container rather than the VPS
host. Left on with nothing listening, /api/chat fails and every healthcheck
takes ~3s longer, because the health handler probes Ollama with a 3s timeout.
Enable it by pointing OLLAMA_BASE_URL at something the container can reach.
DB_NAME is stated explicitly rather than relying on settings.py's default,
which is what the development file was leaning on.
Verified booting from this file alone, with no environment variables: binds
3000 and 8000, mounts MCP, correct password returns a token, and both the
any-password bypass and the old development password return 401.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
At the repo owner's instruction, to stop the deploy depending on re-entering
config in the Dokploy UI - which is how the container ended up exiting at
startup on missing AUTH_SECRET_KEY and returning Bad Gateway.
The two database secrets are deliberately NOT in the file. settings.py calls
load_dotenv() without override=True, so a real environment variable wins over
the file; DB_HOST and DB_PASSWORD are set in Dokploy and never enter git. Two
fields to fill instead of seven.
The auth secrets ARE committed, which is worth being explicit about:
AUTH_SECRET_KEY signs every access token, so anyone with read access to this
repository can mint a valid admin token, and git history retains it after any
rotation. .gitignore records the same warning next to the exception that allows
the file. Regenerate with scripts/make_auth_secrets.py and redeploy if that
stops being an acceptable trade.
The generated sign-in passwords are written to SIGNIN_PASSWORDS.txt, which
stays ignored - only the PBKDF2 digests are in .env, and those cannot be
reversed.
Verified end to end: the app boots on 3000 and 8000 with DB_HOST/DB_PASSWORD
supplied as environment variables, and a login with the generated admin
password returns a token while a wrong password returns 401.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
