Render · Deployment guide
Render deployment environment issues
Short answer
Render env vars come from three places: service settings, environment groups, and render.yaml. When they disagree, the last one wins — and that's almost always the bug.
Symptoms
- Deploy succeeds but service crashes on first request.
- DATABASE_URL works in one service but not another linked to the same database.
- render.yaml updates don't take effect after redeploy.
- Service URL is stale after renaming the service.
Common causes
- Environment group is attached but variables shadow service-level ones.
- render.yaml envVarGroups not declared in the deployed blueprint.
- DATABASE_URL points at an internal address from a service in a different region.
- Service URL is hard-coded in code instead of read from process.env.RENDER_EXTERNAL_URL.
How DeployDoc checks this
- Reconciles env vars across service settings, environment groups, and render.yaml.
- Verifies cross-service DATABASE_URLs are reachable within the same region.
- Flags hard-coded onrender.com URLs that won't survive a service rename.
- Detects build-only vars accessed at runtime in long-running services.
Fix it manually
- Open Render → Service → Environment, then attached Environment Groups.
- Resolve any conflicts — service-level overrides group, group overrides render.yaml.
- Replace hard-coded URLs with
process.env.RENDER_EXTERNAL_URL. - For DB connections, confirm both services are in the same region.
- Trigger a Manual Deploy → Clear build cache.
When to run a DeployDoc diagnosis
Any time a Render deploy succeeds but the service crashes at runtime, or after attaching an environment group to multiple services.