[Devops] : render.yaml deployment config is stale/non-functional — wrong entrypoint, wrong build path, irrelevant env vars

[Srejoye]

Description of the Bug

File: render.yaml (repo root)

render.yaml specifies startCommand: gunicorn app:app --bind 0.0.0.0:$PORT --workers 2, but there is no app.py or app:app import target anywhere in the repository — the actual FastAPI instance is app.main:app inside backend/app/main.py (confirmed by Dockerfile line 84: CMD ["uvicorn", "app.main:app", ...]). Additionally, buildCommand: pip install -r requirements.txt runs from the repo root, but requirements.txt lives at backend/requirements.txt; there is no root-level requirements.txt. The env var list also includes MONGO_URI, which is not referenced anywhere in backend/app/config.py (the app uses DATABASE_URL for SQLAlchemy/Postgres, not Mongo) — while genuinely required variables for production (DATABASE_URL, REDIS_URL/CELERY_BROKER_URL, JWT_ALGORITHM, CHROMA_PERSIST_DIR, UPLOAD_DIR, ALLOWED_EXTENSIONS) are absent.

Steps to Reproduce

Proposed fix approach: rewrite render.yaml to (1) set buildCommand: pip install -r backend/requirements.txt, (2) set startCommand: gunicorn app.main:app --bind 0.0.0.0:$PORT --workers 2 -k uvicorn.workers.UvicornWorker (gunicorn needs the uvicorn worker class for an ASGI app), (3) replace MONGO_URI with the actual required vars pulled from Settings in config.py, and (4) add a rootDir: backend or equivalent so relative paths resolve correctly.

Expected Behavior

A deploy from this file as-is would fail at build (missing requirements.txt) or, if that's worked around, fail at boot (gunicorn unable to locate app:app).

Screenshots / Logs

No response

Environment

Windows

GSSoC '26

• Yes, I am participating in GirlScript Summer of Code and would like to fix this.

[Srejoye]

This config appears to be a leftover/copy-pasted template from a different (Mongo-based) project and was never updated to match this repo's actual FastAPI/Postgres/Celery architecture — a documentation/deployment-config drift problem rather than a code bug, but one that breaks any Render.com deploy attempting to follow the repo's documented infra.

Affected file: render.yaml. Cross-reference: Dockerfile (correct entrypoint app.main:app), backend/requirements.txt (correct dependency path), backend/app/config.py (actual required env vars).

Proposed fix approach: rewrite render.yaml to (1) set buildCommand: pip install -r backend/requirements.txt, (2) set startCommand: gunicorn app.main:app --bind 0.0.0.0:$PORT --workers 2 -k uvicorn.workers.UvicornWorker (gunicorn needs the uvicorn worker class for an ASGI app), (3) replace MONGO_URI with the actual required vars pulled from Settings in config.py, and (4) add a rootDir: backend or equivalent so relative paths resolve correctly.

Regression/test considerations: this can't be unit-tested in the normal sense, but I'd propose a CI smoke step that runs the exact buildCommand/startCommand from render.yaml in a clean container and curls /api/health, so config drift like this fails CI instead of failing silently in production.

Would like to pick this up for GSSoC'26 — happy to validate the corrected config against an actual Render deploy or a local Docker stand-in.

[github-actions]

Hi @Srejoye! 👋

Thanks for opening this issue! We are thrilled to have you contribute to PDF-Assistant-RAG for GSSoC 2026.

📌 Before you start:

• Make sure you have read our Contributing Guidelines.
• Wait for a project admin to assign this issue to you before working on it.
• Remember to branch off dev and not main.

Happy Coding! 🚀