CodingNic
Sign In Book Session

Deploying to a Cloud Platform

Custom Domains and Zero-Downtime Deploys

Deploying to a Cloud Platform 15 min read

Custom Domains and Zero-Downtime Deploys

Objectives

By the end of this lesson, you should be able to:

  • Point a custom domain at a live deployment
  • Explain what a zero-downtime deploy actually does differently from a naive restart
  • Explain how Module 2’s graceful shutdown becomes essential once real users depend on uptime during a release

💡 Why this matters: A platform-provided URL (Lesson 2) works, but notes-api-production.up.railway.app isn’t what a real product ships with, and a deploy that briefly takes the application offline is invisible during development, and a real, noticed problem once real users depend on it staying up.

⚠️ A note on verification: as in the last lesson, this reflects the stable, current, documented behavior shared by most modern hosting platforms and DNS providers, this course’s sandboxed tooling has no access to real domain registration or DNS infrastructure to demonstrate it directly.

Pointing a Custom Domain at a Deployment

Most platforms support adding a custom domain directly in their dashboard, the platform then asks for a DNS record to be added at wherever the domain is registered, typically a CNAME record pointing a subdomain (api.example.com) at the platform’s own address, or an A record for a root domain, once that DNS record propagates, usually within minutes to a few hours, requests to the custom domain reach the same deployment the platform URL always did. HTTPS for the custom domain is usually provisioned automatically too, most platforms handle certificate issuance the moment a domain is verified, Module 6 covers what’s actually happening there in more depth.

What a Naive Restart Does Wrong

Redeploying an application the simple way, stop the old process, start the new one, means a real gap between “old version stopped” and “new version ready to accept traffic,” any request arriving during that gap fails, for a low-traffic application this might be a handful of failed requests, for anything with meaningful, continuous traffic, it’s a real, visible outage on every single deploy.

Zero-Downtime Deploys

A zero-downtime deploy starts the new version before stopping the old one, routing traffic to the new instance only once it’s confirmed healthy, and only then, gracefully, shutting down the old one, exactly Module 2’s SIGTERM handling and server.close() pattern, finishing whatever the old version was already handling before it actually exits. Most PaaS platforms do this automatically, given a container that responds correctly to SIGTERM, this is precisely why Module 2’s graceful shutdown lesson matters beyond just “handling a crash gracefully,” it’s what makes an automatic, zero-downtime deploy actually work correctly, rather than dropping in-flight requests the moment the platform decides to stop the old instance.

Health Checks

Most platforms confirm a new instance is actually ready before routing real traffic to it, typically by polling a specific endpoint, often /health or /healthz, until it responds successfully. A minimal one:

javascript
app.get('/health', (req, res) => {
  res.json({ status: 'ok' });
});

A more thorough one might also confirm the application can actually reach its database, since being able to accept a connection isn’t the same as being ready to correctly serve real requests, module 9 of this course extends this idea further, into full observability.

Try It

  1. Add a /health endpoint to a real Express app, returning a simple success response.
  2. If you have access to a domain, add a DNS record pointing it at a real deployment, and confirm the application is reachable at the custom domain once it propagates.
  3. Explain, in your own words, why a health check endpoint needs to exist separately from an application’s actual business routes.
  4. Explain, in one or two sentences, how Module 2’s SIGTERM handling specifically enables a zero-downtime deploy, not just crash recovery.

Recap

  • A custom domain is connected through a DNS record pointing at a platform’s address, most platforms provision HTTPS for it automatically once verified.
  • A naive restart-based deploy causes a real, if brief, outage on every release, a zero-downtime deploy avoids it by starting the new version before stopping the old one.
  • Module 2’s graceful shutdown handling is what makes zero-downtime deploys actually work, finishing in-flight requests on the old instance while the new one takes over.

This is the final lesson of this module before exercises. Next lesson: exercises, deploying a real application and confirming it stays live during a release.