1. DNS points the name; it does not run the application
Cloudflare or another DNS provider decides which IP receives traffic for a domain. It can also proxy, cache and provide security features, but it does not know which container should serve the request inside the VPS.
When a domain points to the correct server but opens the wrong system, the problem is often in Nginx or container routing, not in the DNS record itself.
- Check A/CNAME records and proxy mode deliberately.
- Keep mail records separate from web proxy decisions.
- Document which domains live on the VPS.
- Validate SSL mode and certificate behavior.
- Avoid changing DNS and application routing at the same time without a rollback plan.
2. Nginx should be the public boundary
On a VPS with multiple systems, Nginx usually receives public HTTP traffic and decides which internal service should handle each host or path. That boundary is what allows several containers to coexist safely.
A clean Nginx configuration separates domains, preserves proxy headers, handles SPA fallback correctly and avoids exposing unnecessary container ports to the host.
- Route by server_name when multiple domains share a VPS.
- Proxy API paths to the backend service.
- Serve React or Vite SPA routes with an index.html fallback.
- Preserve Host, X-Forwarded-For and X-Forwarded-Proto headers.
- Keep error logs visible during the first deploy validation.
3. Docker isolates services, but names and networks still matter
Docker Compose makes deployment repeatable, but it does not automatically make architecture clear. Project names, networks, service names, volumes and exposed ports need discipline.
A common mistake is exposing every service port on the host. In many deployments, only Nginx should face the public internet, while application containers communicate inside a Docker network.
- Use clear Compose project names to avoid collisions.
- Expose only ports that must be public.
- Use internal service names for container-to-container traffic.
- Persist database volumes intentionally.
- Keep environment variables out of the image and in managed configuration.
4. Deployment ends after validation, not after containers start
A container can be running while the site is still broken. The real deployment checklist includes home page, internal routes, API, contact form, sitemap, robots, ads.txt, logs and conversion tracking when relevant.
If the VPS hosts more than one system, every deployment should also check that the other domains still respond correctly.
- Open the home page and several deep routes.
- Test API health and a real form submission.
- Confirm sitemap, robots and ads.txt.
- Check Nginx and backend logs after the first requests.
- Validate rollback before the next urgent deploy.
How to use this article
Treat this page as a decision aid. Use it with the related hub, checklist or service route when the topic affects production, customer experience, deployment, security or business continuity.