Phase 6: Cloud & Deployment Concepts · ~45 minutes · Render · Docker · deployment

Actually Deploying Something

A deploy can show green in the dashboard while the app itself is completely broken underneath — the platform only confirms the container started, never that it's actually working. Reading the real deploy logs is the only way to know for certain.

Hiring signal: Reads deploy logs before trusting a dashboard's green checkmark, and knows exactly why a hardcoded port silently breaks a deployment

What you will learn

Explain what a deploy actually does: build, package, and run code somewhere with a public address
Deploy a real containerized application to a real, currently-free cloud platform
Read deploy logs to diagnose a deploy that 'succeeds' per the dashboard but crashes on boot
Diagnose the platform-provided PORT binding requirement as a real, common deployment failure

Introduction

Type: Learn Languages: Docker, deployment Prerequisites: Lesson 02 (Environment Variables and Config, for Real) Time: ~45 minutes

Objective

Learning objectives

Explain what a deploy actually does: build, package, and run code somewhere with a public address
Deploy a real containerized application to a real, currently-free cloud platform
Read deploy logs to diagnose a deploy that "succeeds" per the dashboard but crashes on boot
Diagnose the platform-provided PORT binding requirement as a real, common deployment failure

What you're building

Take the containerized script from Course 02's Phase 02 lab (or a small new one, if needed)
Push it to a real GitHub repository
Deploy it to Render (or a currently-equivalent free, no-card-required platform — verify current options before starting) as a real web service, ensuring it correctly binds to the platform's PORT environment variable
Confirm it's genuinely reachable at a real public URL, from a different network if possible (not just assuming it works)
Deliberately introduce this lesson's hardcoded-port bug, redeploy, and read the real resulting logs to confirm what a PORT mismatch actually looks like in the platform's own log output — then fix it and redeploy successfully
Write deploy_notes.txt with the real public URL, what the PORT bug's real log output showed, and how you diagnosed it

A deploy log shows: Error: listen EADDRINUSE: address already in use 0.0.0.0:8000 followed by the process exiting. The platform's PORT environment variable for this deploy is 10000. What's the most likely cause?

This is this lesson's exact hardcoded-port trap, now showing a real, specific downstream symptom of it: the app tried to bind to 8000 (its hardcoded value) instead of 10000 (what the platform actually provided via PORT), and something about the platform's own environment already had 8000 occupied, producing a real bind conflict on top of the underlying mismatch. Even without that specific conflict, a hardcoded port would still fail health checks since the platform is checking 10000, not 8000 — the fix is the same either way: read PORT from the environment, as this lesson's corrected version does.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The Problem, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.