Module -12: Deployment & Hosting — Design & Code Foundations

01

Web Hosting Fundamentals

Every website needs a server. Understanding hosting types helps you choose the right solution for your project.

💻

Your Computer

localhost:3000

→

Deploy

→

🌐

Web Server

yoursite.com

A web server is a computer that's always on, connected to the internet, and configured to serve your website files to anyone who requests them.

Where Websites Live

Web hosting means putting your website files on a server that's accessible via the internet. Your computer (localhost) is only accessible to you. A web server has a public IP address and domain name that anyone can access 24/7.

Core concept: Hosting = your files on a public server

📄

Static Hosting

HTML, CSS, JS files only. No backend. Fast & cheap.

Free - $20/mo

⚙️

Platform as a Service (PaaS)

Managed server. You deploy code, they handle infrastructure.

$5 - $100/mo

🖥️

Virtual Private Server (VPS)

Your own virtual machine. Full control, more work.

$5 - $200/mo

☁️

Cloud (AWS, GCP, Azure)

Pay for what you use. Scales infinitely. Complex.

$0 - $$$

Hosting Types Compared

Static hosting is simplest — just files served directly. PaaS (Heroku, Railway) manages servers for you. VPS gives you a virtual machine to configure. Cloud (AWS) offers infinite flexibility but requires expertise.

Progression: Start with static hosting. Move up as needs grow.

▲

Vercel

Best for Next.js, React. Instant previews. Edge functions.

Netlify

Great for static sites. Forms, functions, identity built-in.

Cloudflare Pages

Global CDN. Fast builds. Free tier generous.

🐙

GitHub Pages

Free for public repos. Perfect for portfolios & docs.

Modern Hosting Platforms

Vercel is optimized for React/Next.js. Netlify pioneered the JAMstack approach. Cloudflare Pages offers global edge deployment. GitHub Pages is free and perfect for static sites and documentation.

Options: All offer free tiers. Try them to find your preference.

Static Sites

• Pre-built HTML files
• Same content for everyone
• No server processing
• Extremely fast
• Very secure
• Cheap/free hosting

Portfolios, blogs, documentation

Dynamic Sites

• Generated on request
• Personalized content
• Server/database needed
• Slower (processing time)
• More attack surface
• More expensive

Dashboards, e-commerce, social apps

Static vs Dynamic Websites

Static sites are pre-built and served as-is — fast, secure, cheap. Dynamic sites generate pages on request, allowing personalization and databases. Many modern sites use a hybrid approach.

Strategy: Start static. Add dynamic features only when needed.

02

CI/CD: Automated Deployments

Continuous Integration and Continuous Deployment automate the process of testing and deploying your code.

📝

Push Code

→

🔄

CI: Build & Test

→

🚀

CD: Deploy

CI (Continuous Integration): Automatically build and test every code change
CD (Continuous Deployment): Automatically deploy successful builds to production

The Automation Pipeline

CI automatically runs your build and tests when you push code — catching bugs before they reach production. CD automatically deploys passing builds. Together, they create a reliable pipeline from code to live site.

Automation: CI/CD catches problems early and deploys consistently

✓

Consistency

Same process every time. No "works on my machine" issues.

⚡

Speed

Deploy in minutes, not hours. Ship features faster.

🛡️

Safety

Tests run before deploy. Broken code doesn't ship.

📜

History

Every deployment tracked. Easy rollback if needed.

Why Automate Deployments

Manual deployments are error-prone and slow. CI/CD ensures every deployment follows the same steps, catches bugs before they ship, and creates a history of what was deployed when. It's especially valuable for teams.

Value: Automation removes human error from repetitive tasks

1

Developer pushes code to GitHub

2

GitHub Actions triggers workflow

3

Install dependencies: npm install

4

Run tests: npm test

5

Build production: npm run build

6

Deploy to production server ✓

Typical CI/CD Workflow

A typical workflow: push code → install dependencies → run linting → run tests → build production assets → deploy. Each step must pass before the next runs. If anything fails, deployment stops and you get notified.

Pipeline: Each step is a gate that prevents bad code from shipping

03

GitHub Actions

GitHub's built-in CI/CD platform. Automate workflows directly from your repository.

🐙

GitHub Actions

Automate your software development workflows right in your repository.

What you can automate:
• Build and test on every push
• Deploy to hosting platforms
• Publish packages to npm
• Send notifications
• Scheduled tasks (cron jobs)
• Label and manage issues

GitHub's Automation Platform

GitHub Actions runs workflows in response to events (push, pull request, schedule). Workflows are defined in YAML files in your repo. GitHub provides free runners (virtual machines) to execute your jobs.

Definition: Actions = automation defined as code in your repo

Understanding the GitHub email you received: When your workflows run, they use "runners" (virtual machines). You're charged in "minutes" — the time each runner spends executing your job.

Free Tier (Public Repos)

• Unlimited minutes
• Linux, Windows, macOS runners
• Most open source uses this

Paid (Private Repos)

• 2,000 minutes/month (free tier)
• Linux: 1x, Windows: 2x, macOS: 10x
• Overage billed per minute

Example: A 5-minute workflow on macOS uses 50 minutes of your quota (5 × 10x multiplier).

How Actions Billing Works

Runners are the virtual machines that execute your jobs. Minutes are how you're billed. Public repos get unlimited free minutes. Private repos have quotas. macOS runners cost 10x Linux due to licensing.

Billing: Public repos = free. Private repos = watch your usage.

# .github/workflows/deploy.yml

name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm run build
      - run: npm run deploy

A Simple Deploy Workflow

Workflows are YAML files in .github/workflows/. This workflow runs on every push to main: checks out code, installs dependencies, builds, and deploys. runs-on specifies the runner type.

Example: Start simple. Add complexity as needed.

actions/checkoutClone your repository

actions/setup-nodeInstall specific Node.js version

actions/cacheCache dependencies for faster builds

peaceiris/actions-gh-pagesDeploy to GitHub Pages

Marketplace has 15,000+ pre-built actions. Don't reinvent the wheel.

Popular Pre-built Actions

The Actions Marketplace has thousands of pre-built actions for common tasks. Instead of writing shell scripts, use tested, maintained actions. Always pin to a specific version for security.

Ecosystem: Use official actions when available

04

Deployment Strategies

Different ways to release updates. Each strategy has trade-offs between speed, safety, and complexity.

Old Version

→

New Version

Pros: Simple, fast, no infrastructure overhead
Cons: Downtime during deploy, risky for large changes
Best for: Small sites, personal projects, low-traffic apps

Simple Direct Deployment

The simplest approach: replace the old version with the new version directly. There may be a brief moment of downtime or inconsistency. Fine for small sites, risky for large applications.

Trade-off: Simple but offers no safety net

Blue (Live)

Current production

Load Balancer

Green (New)

Deploy here first

1. Deploy new version to Green
2. Test Green environment
3. Switch traffic Blue → Green
4. Blue becomes standby (instant rollback)

Blue-Green Deployment

Blue-Green maintains two identical environments. Deploy to the inactive one, test it, then switch traffic. Rollback is instant — just switch back. Requires double the infrastructure.

Safe: Instant rollback, but double the cost

Traffic distribution over time:

Stage 1:

Stage 2:

Stage 3:

Complete:

Old version

New version

Canary Deployment

Canary deployment gradually shifts traffic: 5% → 25% → 50% → 100%. Monitor for errors at each stage. If problems arise, you've only affected a small percentage of users. Named after canaries in coal mines.

Gradual: Minimize blast radius of bugs

PR

#42: Add new feature

Preview deployment ready:

https://pr-42--mysite.netlify.app

Every pull request gets its own URL. Review changes live before merging. Share with stakeholders. Test on real infrastructure.

Preview Deployments

Preview deployments create a unique URL for every pull request. Review actual changes (not just code) before merging. Invaluable for design review, QA, and stakeholder approval. Most modern platforms offer this.

Review: See changes live before they reach production

05

Environment Variables & Secrets

Keep sensitive data out of code. Configuration that changes between environments.

Bad: Hardcoded in code

const apiKey = "sk_live_abc123"

Good: Environment variable

const apiKey = process.env.API_KEY

Environment variables are values set outside your code that your application reads at runtime. Different values for development, staging, and production.

Configuration Outside Code

Environment variables store configuration outside your code: API keys, database URLs, feature flags. Each environment (dev/staging/prod) has different values. Never commit secrets to your repository.

Principle: Code stays the same. Config changes per environment.

SECRET

API keys, passwords, tokens

CONFIG

Database URLs, service endpoints

FLAGS

Feature toggles, debug modes

ENV

NODE_ENV=production vs development

What to Put in Env Vars

Store in env vars: API keys, database credentials, third-party service URLs, feature flags, environment mode. Don't store: application logic, version numbers that should be in code, anything that needs version control.

Rule: If it changes between environments or is secret, use env vars

# .env (NEVER commit this file!)

DATABASE_URL=postgres://localhost:5432/myapp
API_KEY=sk_test_development_key
NODE_ENV=development

# .env.example (commit this as template)
DATABASE_URL=your_database_url_here
API_KEY=your_api_key_here

Local Development with .env

For local development, use a .env file (loaded by dotenv). Add .env to .gitignore — never commit it. Create .env.example with placeholder values as documentation for other developers.

Security: .env is for local dev. .gitignore it. Always.

Vercel/Netlify Dashboard

Settings → Environment Variables → Add key-value pairs. Can set different values per environment (preview/production).

GitHub Actions Secrets

Repo Settings → Secrets → Actions → New secret. Access via ${{ secrets.MY_SECRET }} in workflows.

Command Line

vercel env add API_KEY production

Setting Env Vars in Production

Each hosting platform has its own way to set environment variables: dashboard UI, CLI commands, or config files. These are encrypted at rest and only available during build/runtime. Keep production secrets separate from development.

Platform: Set production secrets in your hosting platform, not in code

15

Self-Assessment

Test your understanding of Deployment & Hosting. Click each question to reveal the answer.

Q1

What's the difference between static and dynamic hosting?

Click to reveal

Q2

What does CI/CD stand for and what does it do?

Click to reveal

Q3

What are GitHub Actions 'runners' and 'minutes'?

Click to reveal

Q4

Why should you never commit API keys to your repository?

Click to reveal

Q5

What is a preview deployment?

Click to reveal

Q6

What's the benefit of blue-green deployment?

Click to reveal

Deployment & Hosting

Core Concepts

Web Hosting Fundamentals

CI/CD: Automated Deployments

GitHub Actions

Deployment Strategies

Environment Variables & Secrets

Self-Assessment

Self-Assessment

Key Takeaways