Overview
When PORT environment variable issues, slow down and isolate the failure: build, runtime, networking, DNS, credentials, or resources. Better-PaaS gives you logs, deployment history, server tools, and configuration screens to work through the problem systematically.
Start here
First, make the app listen on the platform-provided PORT value. Then check the most recent deployment logs and confirm whether the app failed during build, startup, health check, or routing.
Step-by-step checks
Work from the app outward: source code, build output, runtime command, env vars, container health, router, DNS, then external services.
- Read the latest logs
- Confirm the app listens on the expected port
- Verify required environment variables
- Check database or service containers
- Retry after fixing one variable at a time
Prevent it next time
Keep build scripts explicit, document env vars, set backups for stateful apps, and verify a staging deployment before switching a production domain.
Fix PORT binding in common frameworks
Better-PaaS sets PORT at runtime. Bind to 0.0.0.0, not 127.0.0.1, so the reverse proxy can reach the process inside the container.
- Node/Express: const port = process.env.PORT || 3000; app.listen(port, "0.0.0.0")
- Python/Uvicorn: uvicorn main:app --host 0.0.0.0 --port ${PORT:-8000}
- Rails: ensure Puma binds 0.0.0.0 per platform docs
- After changing code, redeploy and confirm listening in logs
FAQ
Can Better-PaaS show logs for PORT environment variable issues?
Yes. Better-PaaS streams container logs in the dashboard and stores logs on disk for troubleshooting.
Should I redeploy immediately?
Only after changing one likely cause. Repeated redeploys without reading logs usually hide the real issue.