How Deploying a Site Works

1) What you’re deploying: source vs. built output

Most websites start as source code: HTML/CSS/JavaScript, frameworks, images, configuration files, and dependencies. Many modern sites also require a build step that transforms source into deployable output:

• Static sites (e.g., marketing sites, documentation): a build may generate a folder of HTML/CSS/JS files that can be served directly.
• Server-rendered apps: the deployment may include server code that runs on a host (Node, Python, Ruby, PHP, etc.).
• Single-page apps (SPAs): the build produces static assets, but the app often relies on separate APIs.

The key idea: you typically don’t deploy your raw project folder; you deploy either built artifacts (static assets) or a packaged runtime (application + dependencies + configuration).

2) The common deployment pipeline (from commit to production)

In many teams, deployment follows a predictable pipeline:

1. Change is made in a local dev environment.
2. Code is pushed to a repository (e.g., Git).
3. Continuous Integration (CI) runs automated checks (linting, tests, security scanning).
4. Build step compiles/transpiles/bundles code and produces artifacts.
5. Artifacts are stored (container registry, object storage, build cache, release bundle).
6. Release is deployed to a target environment (staging, then production).
7. Verification (health checks, smoke tests, monitoring) confirms the deployment is healthy.
8. Rollback plan exists if something goes wrong.

This pipeline can be fully automated (CI/CD) or partly manual, but the stages are similar even for small projects.

3) Where the site runs: hosting targets

Deployment differs based on where your site will be served from:

• Static hosting / CDN: you upload built files to a platform that serves them via a content delivery network. This is fast and simple for static content.
• Virtual machine (VM): you deploy to a server you manage. You install runtime dependencies, configure a web server, and run your app process.
• Containers: you package the app and dependencies into an image, then run it on a container platform (managed services or Kubernetes).
• Serverless functions: you deploy functions that run on demand, often paired with static assets and managed APIs.
• Platform-as-a-Service (PaaS): you push code and the platform builds and runs it, abstracting server management.

The hosting target determines what “deploy” means operationally: copying files, restarting services, rolling out containers, or publishing functions.

4) DNS and how users reach your site

Even after code is deployed, users need a way to find it. That’s where DNS (Domain Name System) comes in:

• You buy or manage a domain (like example.com).
• You configure DNS records that map the domain to your hosting provider.
• Common record types include A/AAAA (point to an IP address) and CNAME (alias one name to another).

DNS changes can take time to propagate due to caching (TTL). Deployment workflows often coordinate DNS changes carefully, especially when switching providers or doing cutovers.

5) HTTPS, certificates, and secure traffic

Modern sites almost always use HTTPS. Deployment typically includes setting up TLS certificates and ensuring traffic is encrypted end-to-end:

• Certificate issuance: often automated via Let’s Encrypt or managed certificates from the host.
• Termination point: TLS can be terminated at a CDN, load balancer, ingress controller, or directly on the server.
• Redirects and HSTS: you commonly redirect HTTP to HTTPS and may enable HSTS to enforce secure connections.

Certificates expire, so automation is important; many platforms renew them automatically.

6) Configuration: environment variables and secrets

Deployed code usually needs environment-specific configuration:

• Environment variables for settings like API endpoints, feature flags, and runtime options.
• Secrets for database passwords, API keys, and tokens. These should be stored in a secrets manager or encrypted configuration, not committed to the repo.
• Config separation between development, staging, and production to avoid accidental cross-environment mistakes.

A good deployment keeps configuration flexible and secure, so the same build artifact can be promoted across environments without code changes.

7) Databases and migrations (for dynamic sites)

If your site uses a database, deployment may also involve schema changes:

• Migrations apply incremental database changes in a controlled way.
• Compatibility matters: a safe rollout often requires the new app version to work with both the old and new schema during transition.
• Backups should be taken and verified before high-risk changes.

Many incidents happen when application code and database schema get out of sync, so teams often treat migrations as a first-class part of the release process.

8) Zero-downtime and safe rollout strategies

Professional deployments aim to reduce risk and avoid downtime. Common strategies include:

• Rolling deployments: gradually replace old instances with new ones.
• Blue/green deployments: run two environments (blue and green) and switch traffic when the new one is ready.
• Canary releases: send a small percentage of traffic to the new version, then expand if metrics look good.
• Feature flags: ship code disabled, then enable features gradually without redeploying.

These approaches pair well with automated health checks and clear rollback procedures.

9) Caching and CDNs: why changes may not appear immediately

After deployment, users might still see old content due to caching:

• Browser cache: users’ browsers may reuse assets until they expire.
• CDN cache: edge servers may serve cached files for performance.
• Server-side cache: application caches may retain old data or templates.

To manage this, deployments often use cache-busting filenames (e.g., hashed assets like app.4f3c2.js) and controlled cache headers. When necessary, CDNs can be purged or invalidated.

10) Observability: confirming the deployment worked

A deployment isn’t truly finished when the upload completes; it’s finished when the system is stable. Teams rely on observability to confirm that:

• Logs show normal operation and no spike in errors.
• Metrics (latency, error rate, CPU/memory, request volume) remain within expected ranges.
• Tracing helps diagnose slow or failing requests across services.
• Alerts notify you quickly if something regresses.

Many deployment systems automatically run post-deploy health checks and will halt or roll back if thresholds are breached.

11) Rollbacks: what happens when something goes wrong

Even with careful testing, production can differ from staging. A rollback plan typically includes:

• Re-deploying the previous version (often as simple as switching a release pointer or redeploying an earlier artifact).
• Reverting configuration changes if the issue is in environment settings.
• Handling database changes cautiously—schema rollbacks can be harder than code rollbacks, which is why forward-compatible migrations are preferred.

The best rollback is quick, predictable, and practiced, not improvised during an incident.

12) A simple mental model

If you want a compact way to remember how deployment works, think of it as four steps:

1. Prepare: build and test the software.
2. Publish: put the built artifact where production can fetch it.
3. Run: start the new version behind your domain with correct config and secrets.
4. Verify: monitor, test critical paths, and be ready to roll back.

Whether you’re uploading static files to a CDN or rolling out containers across a cluster, the same fundamentals apply: move from source to artifact, connect it to a domain securely, and release changes safely.