Chapter 1 — The Big Picture

Before diving into specific technologies, you need a mental model of what happens when someone visits a website — and what your role is in making that happen reliably, securely, and at scale.

What Happens When a User Visits a Website

User types "example.com" in browser │ ▼ ┌─────────────────┐ │ DNS Resolution │ Browser asks: "What IP is example.com?" │ (Recursive) │ Checks: browser cache → OS cache → resolver → root → TLD → authoritative └────────┬────────┘ │ Returns: 93.184.216.34 ▼ ┌─────────────────┐ │ TCP Connection │ Three-way handshake (SYN → SYN-ACK → ACK) │ + TLS Handshake │ Certificate verification, key exchange, cipher negotiation └────────┬────────┘ │ Encrypted tunnel established ▼ ┌─────────────────┐ │ HTTP Request │ GET / HTTP/2 │ │ Host: example.com │ │ Accept: text/html └────────┬────────┘ │ ▼ ┌─────────────────────────────────────────────────────────┐ │ YOUR DOMAIN │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ │ │ Load │───▶│ Reverse │───▶│ Application │ │ │ │ Balancer │ │ Proxy │ │ Server │ │ │ └──────────┘ └──────────┘ │ (your backend) │ │ │ └────────┬─────────┘ │ │ │ │ │ ┌────────▼─────────┐ │ │ │ Database / Cache │ │ │ └──────────────────┘ │ └─────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────┐ │ HTTP Response │ 200 OK + HTML/JSON/assets │ (via CDN maybe) │ Cached at edge if configured └────────┬────────┘ │ ▼ ┌─────────────────┐ │ Browser Render │ Parse HTML → fetch CSS/JS → render page └─────────────────┘

The Roles in Professional Web Operations

RoleResponsibilityCares About
Frontend DeveloperHTML, CSS, JavaScript, UI/UXUser experience, browser compatibility, performance
Backend DeveloperAPIs, business logic, databasesData integrity, API design, scalability, security
DevOps / SRECI/CD, infrastructure, reliabilityUptime, deployment speed, automation, monitoring
System AdministratorServer management, networking, securityPatching, hardening, backups, capacity
Platform EngineerInternal developer platforms, toolingDeveloper productivity, self-service infrastructure
Your role in this guide: You're the backend developer who also handles deployment, operations, and maintenance. In smaller teams, this is extremely common. In larger organizations, these responsibilities are split across dedicated teams — but understanding the full picture makes you far more effective regardless of team size.

Environments: Dev → Staging → Production

Professional deployments never go straight from a developer's laptop to users. There's a pipeline:

EnvironmentPurposeWho Uses ItData
Local / DevActive development, debuggingIndividual developerFake/seed data
CIAutomated testing on every commitMachines (automated)Test fixtures
StagingPre-production validation, QAQA team, stakeholdersProduction-like (anonymized)
ProductionReal users, real dataEveryone (end users)Real data
Never test in production. This sounds obvious, but the temptation is real when "it works on my machine." Staging exists to catch the things that only break in production-like conditions: different OS versions, network latency, real database sizes, concurrent users.

What "Deploying a Website" Actually Means

Deployment is not just "putting files on a server." It's a repeatable, automated process that includes:

  1. Build — Compile code, bundle assets, run optimizations
  2. Test — Unit tests, integration tests, security scans
  3. Package — Create a deployable artifact (Docker image, binary, archive)
  4. Deploy — Push artifact to target environment
  5. Verify — Health checks, smoke tests, monitoring
  6. Rollback plan — If something breaks, revert instantly

The Infrastructure Stack

┌─────────────────────────────────────────────────────────────┐ │ YOUR APPLICATION │ ├─────────────────────────────────────────────────────────────┤ │ Runtime (Node.js, Python, Go, Java, etc.) │ ├─────────────────────────────────────────────────────────────┤ │ Container / Process Manager (Docker, systemd, PM2) │ ├─────────────────────────────────────────────────────────────┤ │ Operating System (Ubuntu, Debian, Alpine, RHEL) │ ├─────────────────────────────────────────────────────────────┤ │ Virtualization / Bare Metal (KVM, Xen, physical hardware) │ ├─────────────────────────────────────────────────────────────┤ │ Network (VPC, firewall, load balancer, DNS) │ ├─────────────────────────────────────────────────────────────┤ │ Physical Infrastructure (data center, power, cooling) │ └─────────────────────────────────────────────────────────────┘ ▲ More abstraction = less control, less work │ Less abstraction = more control, more responsibility ▼
The key insight: every hosting option in this guide simply draws the line at a different layer. Shared hosting gives you only the top layer. Bare metal gives you everything. PaaS gives you the top two. IaaS gives you the top four. Your job is to pick where to draw that line for each project.