Deploy a container to the cloud

1 · The deploy path, end to end essential

Here's the moment every new engineer dreads. Your app runs beautifully on your laptop — docker run, open localhost:8000, everything works. Then your boss says "great, ship it," and you freeze. Because "deploying" sounds like one mysterious button, and nobody ever explained what actually happens between your machine and a URL a customer can type. The good news: it's not mysterious at all. It's four plain steps, and by the end of this section you'll be able to draw them from memory.

Think of it like mailing a parcel. The container image you built is the parcel. It's sitting in your house (your laptop) where no one else can get it. To send it, you first drop it at the post office — a place designed to hold parcels and hand them to whoever's authorized to collect (that's the registry). Then a courier picks it up and delivers it to a destination that will actually open and use it (the managed service that runs your container). Finally the recipient gets a street address others can visit (your public URL). You never hand the parcel directly to the customer; it always goes through storage and a delivery service. Deployment is the same handoff chain.

Why it matters that you see this as a pipeline, not a magic button: every one of the four stages is a place things can go wrong, and knowing the stages tells you exactly where to look. "The image built but the deploy failed" points at the registry (bad tag, no login). "It deployed but the URL 404s" points at the run stage (wrong port, crashed on startup). If you only know "I ran the deploy command and it broke," you're debugging blind. The pipeline is your mental map of the failure space.

The mistake beginners make is skipping the registry entirely — trying to somehow copy the local image straight onto a cloud server, or rebuilding it on the server from source. That's the equivalent of driving the parcel to the customer's door yourself: it works once, badly, and doesn't scale. The registry exists precisely so the image is built once, stored in a neutral place, and pulled by any number of machines identically. Learn the four-box flow below and you've learned the shape of every cloud deploy — AWS, Google, Azure — because they all do these same four things; only the command names change.

2 · Push to a registry essential

Ask yourself a scary question: right now, could you say exactly which version of your app is serving customers — down to the commit? For a lot of teams the honest answer is "no idea, whatever the last person pushed." That single gap is behind a huge share of production incidents, and the registry plus disciplined tagging is how you close it.

A registry is the shared warehouse for images. Picture a library: you don't lend your only copy of a book to every reader — you deposit it, and everyone borrows the same catalogued copy. A registry does that for container images. You push (deposit) your built image once, and every machine that needs it pulls (borrows) the identical bytes. GHCR, ECR, and Docker Hub are all just different libraries offering the same service. The key idea from the section before still holds: this neutral storage is what lets the same image run unchanged on your laptop, in CI, and in prod.

The part that earns its own paragraph is the tag — the label after the colon, like myapp:1.0. A tag is how you name a specific version so you can point at it later. And here's where nearly everyone gets burned exactly once: they tag everything :latest and move on. The problem is that :latest is a sticky note that keeps getting rewritten, not a permanent label. It means "whatever I pushed most recently" — which changes every time anyone pushes. Six weeks later, when prod is on fire, you look at the running service and it says myapp:latest… and you have no way to know whether that's the code from today, last Tuesday, or the intern's experiment. You can't reproduce it and you can't confidently roll back to a known-good state, because there's no name for the previous good build either.

The fix is a one-word discipline: pin. Tag every image with a real, immutable version — a semver like 1.4.2, or better, the git commit SHA (e.g. myapp:9f3c1a2) so the running image ties straight back to the exact source that produced it. A pinned tag is a promise that never changes: myapp:1.0 today is byte-for-byte myapp:1.0 next year. That promise is what makes a deploy reproducible (you can rebuild the exact situation) and roll-back-able (you can repoint traffic to 1.0 the instant 1.1 misbehaves). Use :latest for local scratch work if you like; never let it near production.

push.shdocker build -t myapp .
docker tag myapp ghcr.io/you/myapp:1.0        # registry/name:VERSION
echo "$TOKEN" | docker login ghcr.io -u you --password-stdin
docker push ghcr.io/you/myapp:1.0
# pin every deploy to a specific tag (or the git SHA) -> reproducible + rollback-able

3 · Run on a managed service essential

There's an old way to do this that will eat your weekend. You rent a virtual server, SSH in, install Docker, copy your image over, figure out systemd so it restarts on crash, install nginx for HTTPS, chase a TLS certificate, then set up a second server so one machine dying doesn't take you offline… and you haven't shipped a single feature yet. A managed service exists so you never do any of that. You hand it three things — image, port, config — and it hands you back a running, secure, auto-scaling URL.

The cleanest analogy is renting an apartment versus building a house. Self-managing servers is building a house: you're responsible for the plumbing, the wiring, the roof, and every leak at 3am. A managed service is renting a serviced apartment: you bring your furniture (your image) and the landlord handles utilities, security, and maintenance. You give up some control over the building's internals, but in exchange you get to just live there and focus on your own stuff. For the vast majority of apps, that trade is overwhelmingly worth it.

Why this is worth learning as one universal model rather than one product: Cloud Run, AWS App Runner, AWS ECS, and Azure Container Apps look like four different tools with four different CLIs, and beginners waste weeks thinking they must learn each from scratch. They don't. Every one of them accepts the same request — "here is my image, the port it listens on, and its environment; give me a scaling HTTPS endpoint" — and returns the same thing. Internalize that sentence and the specific product becomes a lookup of flag names, not a new concept. We use Cloud Run below only because it's the shortest to demonstrate.

The one detail that trips people up on their very first deploy is the port. Your container listens on some port inside its own little world — say 8000. The managed service needs to be told that number so it can forward incoming web traffic to the right door. Get it wrong and the deploy "succeeds" but every request hangs or 404s, because the platform is knocking on a door your app isn't behind. So the common failure here isn't dramatic — it's a silent mismatch between the port your app actually binds and the port you told the service about. Watch that they agree, and your first deploy will just work.

deploy.shgcloud run deploy myapp \
  --image ghcr.io/you/myapp:1.0 \
  --region us-central1 --port 8000 \
  --allow-unauthenticated \
  --set-env-vars ENV=prod --memory 512Mi --max-instances 10
# -> Service URL: https://myapp-xxxx.a.run.app  (TLS + autoscaling included)

4 · Config, env & secrets intermediate

A true horror story, and it happens weekly. An engineer hardcodes the production database password into their code to "just get it working," commits it, and pushes to a public GitHub repo. Automated bots scanning for exactly this find it within minutes. By morning the database is ransomed. Nobody in that story was stupid — they just never learned the one rule this section teaches: your image must never contain a secret, and never contain environment-specific settings.

Start with why config and code must live apart at all. Think of your image as a sealed appliance — a coffee machine. The machine's design is fixed and identical for every unit shipped (that's your code). But each kitchen sets its own water hardness and cup size (that's config). You'd never manufacture a separate coffee machine per household just to change a setting; you build one machine and let each owner dial in their preferences. Baking config into the image is exactly that mistake: it forces you to rebuild a whole new image every time a URL or log level changes, and — worse — it means your "test" image and "prod" image are different builds, so testing one never truly tests the other. Injecting config at runtime keeps a single image that behaves differently based on what you feed it when it starts.

There are two flavours of injected config, and the distinction is the whole point. Plain settings — which environment, log level, feature flags — are non-sensitive; you pass them as environment variables and your app reads them from os.environ. Secrets — database passwords, API keys, tokens — are dangerous, and they need a secret manager: a locked vault the cloud provides that stores the value encrypted and hands it to your container only at runtime. It never touches your image layers, never lands in your git history, and never gets printed to logs. To your code, both arrive as ordinary environment variables, so you read a password the same way you read a log level — the app doesn't need to know one came from a vault.

The common mistake beyond hardcoding is subtler: treating a secret manager as optional bureaucracy and stuffing the password into a plain env var in your deploy command or a checked-in .env file. That's better than baking it into the image, but the value still sits in plaintext in your CI logs, your shell history, and your deploy scripts. The rule to burn in: plain settings → env vars; anything you'd be fired for leaking → the secret manager. Getting this split right is precisely what lets the identical image run on your laptop and in prod, with only the injected values differing.

config.shgcloud run deploy myapp --image ghcr.io/you/myapp:1.0 \
  --set-env-vars "ENV=prod,LOG_LEVEL=info" \
  --set-secrets "DATABASE_PASSWORD=db-password:latest"   # from the secret manager
# the app reads os.environ — same code locally and in prod, config differs

5 · Health checks that mean something intermediate

Imagine a smoke detector that only checks whether it has power. The battery's fine, the green light is on, everyone feels safe — and it happily ignores the smoke filling the room, because "am I powered?" was the only question it ever asked. That is the health check most people write on their first try: an endpoint that returns 200 OK as long as the process is running, while the app behind it is completely unable to serve a real request because its database vanished. A health check that only proves the process is alive is a smoke detector that only checks its own battery.

To fix it, you have to understand what the platform is actually doing with the answer. The managed service from the last sections doesn't just deploy your container and walk away — it repeatedly pokes a health check endpoint asking "are you okay to receive traffic?" Your reply is a signal it acts on: a 200 means "keep sending me users," and a 503 (Service Unavailable) means "stop routing to me, I can't cope — restart or replace me." So the endpoint isn't a status page for humans; it's a control input that decides whether broken instances stay in rotation. Answer honestly and the platform routes around your failures automatically. Answer "I'm fine!" while broken and it keeps feeding real users straight into the failure.

That's why a meaningful health check verifies the things your app truly depends on — can it reach the database? the cache? the queue? — and reports 503 the moment any critical dependency is down. This is the difference between a liveness check ("is my process running?") and a readiness check ("can I actually do my job right now?"). The database being unreachable doesn't crash your Python process, so a liveness check stays green and the platform keeps you live — and every user hits an error. A readiness check that actually pings the dependency catches it, returns 503, and the platform pulls you out until you recover.

The mistake to avoid lurks at the other extreme, though: don't turn a health check into a heavyweight test that runs expensive queries or checks everything on every poll. The platform calls this endpoint every few seconds, so a slow check becomes its own load problem, and marking yourself unhealthy over a non-critical dependency causes needless restarts. The sweet spot is a fast, cheap probe of the dependencies you genuinely can't function without — the ones where, if they're down, serving traffic would only produce errors anyway. The tiny function in the lab captures exactly that: healthy only if all the dependencies you list are ok.

healthz.pydef health_check(deps):
    """deps: name -> is_ok. Healthy only if ALL dependencies are ok."""
    healthy = all(deps.values())
    status = 200 if healthy else 503          # 503 -> platform reroutes/restarts
    return status, {"status": "healthy" if healthy else "degraded",
                    "checks": deps}

print(health_check({"db": True,  "cache": True}))
print(health_check({"db": True,  "cache": False}))   # cache down -> 503
print(health_check({"db": False, "cache": True}))    # db down   -> 503

(200, {'status': 'healthy', 'checks': {'db': True, 'cache': True}})
(503, {'status': 'degraded', 'checks': {'db': True, 'cache': False}})
(503, {'status': 'degraded', 'checks': {'db': False, 'cache': True}})

6 · Advanced — rollout strategies advanced

Picture the naive deploy — the one everyone does first. New version's ready, so you kill all the old instances and start all the new ones at once. For thirty seconds there's nothing serving traffic, so every user gets an error. And if the new version is broken, you've just handed the bug to 100% of your customers simultaneously, with the old version already torn down so there's nothing to fall back to. The entire discipline of rollout strategies exists to answer one question: how do you swap old code for new without a moment where everyone's broken at once?

The core insight is that a deploy is a bet, and the smart move is to bound how much you lose if the bet is wrong — your "blast radius." Think of a restaurant putting a new dish on the menu. The reckless kitchen replaces every dish at once and hopes. The careful one offers it as a special to a few tables first, watches whether plates come back untouched, and only then rolls it out to everyone. Same food, wildly different risk. Rollout strategies are just formalized versions of "test it on a few tables first," and the three below sit on a spectrum from fast-and-risky to slow-and-safe.

Read the table as that spectrum. Rolling replaces instances a few at a time, so there's always something serving — simple and zero-downtime, but for a while old and new run side by side, which can bite if they're incompatible. Blue-green stands up the entire new version ("green") next to the old ("blue"), then flips all traffic in one instant — giving you an atomic switch and an equally instant rollback (flip back), at the cost of running two full copies briefly. Canary is the "few tables first" approach taken seriously: send 5% of traffic to the new version, watch your error metrics, then widen to 50% and 100% only if it stays healthy — the safest option, because a bad release hurts a sliver of users before you catch it, but the slowest to fully roll out.

The mistake isn't picking the "wrong" one — it's not picking deliberately, or doing a canary with no eyes on the metrics. A canary that ramps 5% → 100% without actually watching the error rate at each step is just a slow version of the reckless deploy; you've added the ceremony without the safety. The value is entirely in the gate: measure at each stage and abort automatically the moment things look wrong. The lab makes exactly that concrete — a canary that reads the error rate at every step and rolls back itself the instant it crosses a threshold, so the decision is data, not a human squinting at a dashboard at midnight.

canary.pydef canary_rollout(steps, error_rate_at, threshold=0.02):
    """steps: list of traffic %; error_rate_at(pct)->observed error rate.
    Abort (roll back) if any stage exceeds the error threshold."""
    for pct in steps:
        err = error_rate_at(pct)
        print(f"  {pct:3}% traffic -> error rate {err:.1%}", end="")
        if err > threshold:
            print("  ABORT -> roll back"); return False
        print("  ok")
    print("  promoted to 100%"); return True

# a healthy release
print("release A:")
canary_rollout([5, 25, 50, 100], lambda p: 0.005)
# a release that spikes errors at 25%
print("release B:")
canary_rollout([5, 25, 50, 100], lambda p: 0.005 if p < 25 else 0.08)

release A:
    5% traffic -> error rate 0.5%  ok
   25% traffic -> error rate 0.5%  ok
   50% traffic -> error rate 0.5%  ok
  100% traffic -> error rate 0.5%  ok
  promoted to 100%
release B:
    5% traffic -> error rate 0.5%  ok
   25% traffic -> error rate 8.0%  ABORT -> roll back

7 · Professional — readiness gate before promotion professional

"It's probably fine, ship it." Those four words, spoken by a tired engineer at 6pm on a Friday, have caused more outages than any bug. The problem isn't the engineer — it's that "ready to deploy?" was left as a judgment call, and human judgment is exactly what degrades when you're rushed, distracted, or optimistic. A readiness gate replaces that judgment with a checklist a machine runs the same way every single time, whether it's Tuesday morning or Friday night.

The right mental model is a pre-flight checklist. Pilots don't eyeball the plane and go "looks good" — no matter how experienced, they read a fixed list aloud: flaps, fuel, instruments, doors. Not because they're forgetful, but because the checklist doesn't get tired, doesn't get cocky, and doesn't skip the boring item that turns out to matter. A deploy-readiness gate is that checklist for shipping software: an objective, automated set of yes/no conditions that must all pass before a build is allowed near production. It turns "I think we're good" into "the gate says go," which is a very different — and far safer — statement.

What goes on the list is everything this chapter has taught, now enforced rather than hoped for: are the tests green? does the image pass policy (no critical vulnerabilities, small enough, non-root — the CD2 concerns)? does a real health endpoint exist so the platform can tell if you're alive? are there no secrets baked into the image? is the image pinned to a real version rather than :latest? Each is a binary check with no room for interpretation, and crucially the gate reports which checks failed — so a blocked deploy tells you exactly what to fix, not just "no."

The mistake teams make here is building a gate and then adding an override button they reach for constantly — "skip checks just this once." Every skipped gate is a promise to future-you that you'll pay for later, usually during the incident the gate would have prevented. The discipline is that the gate is the decision, not a suggestion: if it says no, you fix the blocker, you don't route around it. The lab models this precisely — a function that collects every blocker into a list and only returns "deploy" when that list is empty, which is exactly how CI systems make an automated, unemotional go/no-go call.

readiness.pydef ready_to_deploy(state):
    blockers = []
    if not state["tests_passed"]:     blockers.append("tests not green")
    if state["image_score"] < 70:     blockers.append(f"image score {state['image_score']} < 70")
    if not state["has_healthcheck"]:  blockers.append("no health endpoint")
    if state["secrets_in_image"]:     blockers.append("secrets baked into image")
    if not state["pinned_tag"]:       blockers.append("image not pinned to a version")
    return (not blockers), blockers

ok, why = ready_to_deploy(dict(tests_passed=True,image_score=95,has_healthcheck=True,secrets_in_image=False,pinned_tag=True))
print("deploy?", ok)
ok2, why2 = ready_to_deploy(dict(tests_passed=True,image_score=50,has_healthcheck=False,secrets_in_image=False,pinned_tag=True))
print("deploy?", ok2, "|", why2)

deploy? True
deploy? False | ['image score 50 < 70', 'no health endpoint']

8 · Professional — observability of a live service professional

The most dangerous state for a production service isn't "down" — it's "down and you don't know yet." A service can be quietly failing 5% of requests for hours while you sip coffee, blissfully unaware, because nothing is telling you. The users know. Twitter knows. Your dashboard, if you built one, knows. But if you didn't, the first you'll hear of it is an angry customer — the worst possible monitoring system. Observability is simply the practice of making your running service tell you how it's doing before anyone else has to.

Think of it as the dashboard in a car. You don't pop the hood at 70mph to check the engine — you glance at a handful of gauges that summarize everything you need: speed, fuel, temperature, warning lights. A well-instrumented service gives you the same at-a-glance health, and the industry has converged on four gauges worth watching, the "golden signals": latency (how slow are responses?), traffic (how much load?), errors (what fraction are failing?), and saturation (how full are CPU/memory/connections?). Master those four and you can spot almost any problem forming; ignore them and you're driving blind, hood down, hoping.

Raw gauges aren't enough on their own, though — you need to know what number counts as "too much," and that's what an SLO (Service Level Objective) gives you. An SLO is a stated promise like "99.9% of requests succeed." Its clever twin is the error budget: if 99.9% must succeed, then 0.1% are allowed to fail — and that 0.1% is a budget you get to spend. This reframes reliability from an impossible "zero errors ever" into an honest, measurable allowance. Over a million requests, a 99.9% SLO buys you a thousand failures; burn through more than that and you've broken your promise. The error budget turns a vague feeling of "are we reliable enough?" into arithmetic.

Why the budget framing matters — and the mistake it prevents — is that it settles the eternal fight between shipping features and keeping things stable. With budget left, you can afford to take risks: ship the ambitious release, run the canary, move fast. With the budget nearly spent, the same math tells you to slow down, freeze risky changes, and shore up reliability first. The mistake teams make without it is treating every alert as equally urgent and every error as a five-alarm fire — burning out on noise. The error budget tells you which failures you can absorb and which mean stop. The lab computes exactly this: given an SLO and the errors you've observed, how much of your budget is gone, and are you still within your promise?

slo.pydef error_budget(slo_pct, window_requests, observed_errors):
    """SLO e.g. 99.9% success -> 0.1% error budget over the window."""
    allowed = window_requests * (1 - slo_pct/100)
    used_pct = 100 * observed_errors / allowed if allowed else 0
    return round(used_pct, 1), observed_errors <= allowed

used, ok = error_budget(slo_pct=99.9, window_requests=1_000_000, observed_errors=600)
print(f"error budget used: {used}% | within SLO: {ok}")   # 600 of 1000 allowed
used2, ok2 = error_budget(99.9, 1_000_000, 1500)
print(f"error budget used: {used2}% | within SLO: {ok2}")  # burned through

error budget used: 60.0% | within SLO: True
error budget used: 150.0% | within SLO: False

9 · Tech-lead — safe rollout & instant rollback tech-lead

Two teams hit the identical production bug at the same minute. Team A spends the next ninety minutes writing a hotfix under pressure, testing it badly because everyone's panicking, and shipping a second bug on top of the first. Team B types one command, is back to the last good version in thirty seconds, and calmly fixes the real bug the next morning over coffee. Same bug, same severity — the only difference is that Team B's lead had made rollback the reflex. That difference is a leadership choice, and it's what this final section is about.

The instinct under fire is to fix forward — to frantically patch the broken thing while it's live. It feels productive, but it's usually the worst option, because you're writing your most consequential code in your least clear-headed state. The professional reflex is the opposite: roll back first, debug later. Get the system healthy by returning to a version you already know works, which removes the time pressure entirely, and then investigate the failure calmly with the fire out. Rolling back isn't admitting defeat; it's buying yourself the safety to think.

What makes that one-command rollback even possible is a property we've been building toward all chapter: immutable, version-tagged revisions. Because each deploy is a distinct, unchangeable image with its own pinned tag (§2), the previous good version still exists exactly as it was — nothing overwrote it. So "roll back" isn't a rebuild or a scramble; it's simply "point traffic at the revision that was live yesterday." Contrast this with the :latest anti-pattern from earlier: if every deploy overwrote the same tag, there'd be no previous version to return to. Immutability is what turns rollback from a project into a one-liner.

The mistake a lead must design out is leaving the rollback decision to a human in the moment. When someone has to notice the failure, decide it's bad enough, and choose to roll back, you've inserted human hesitation into your worst thirty seconds. The mature move is to make the decision automatic: define "healthy," and if a new revision fails the check, the system keeps the last good version live on its own — no page, no panic, no judgment call. That's what a lead really owns: not heroics during the incident, but the boring plumbing beforehand that makes incidents non-events. The lab models exactly this — a deployer that records every revision but only promotes a healthy one, automatically holding the last good version when a deploy goes bad.

rollout.pyclass Deployer:
    def __init__(self): self.revisions=[]; self.live=None
    def deploy(self, tag, healthy):
        self.revisions.append(tag)
        if healthy:
            self.live=tag; return f"deployed {tag} (now live)"
        return f"{tag} UNHEALTHY -> kept {self.live} live (auto-rollback)"

d = Deployer()
print(d.deploy("v1.0", True))
print(d.deploy("v1.1", True))
print(d.deploy("v1.2", False))     # bad deploy -> automatic rollback
print("serving:", d.live, "| history:", d.revisions)

deployed v1.0 (now live)
deployed v1.1 (now live)
v1.2 UNHEALTHY -> kept v1.1 live (auto-rollback)
serving: v1.1 | history: ['v1.0', 'v1.1', 'v1.2']

docker build -t myapp .
docker tag myapp ghcr.io/you/myapp:1.0        # registry/name:VERSION
echo "$TOKEN" | docker login ghcr.io -u you --password-stdin
docker push ghcr.io/you/myapp:1.0

gcloud run deploy myapp \
  --image ghcr.io/you/myapp:1.0 \
  --region us-central1 --port 8000 \
  --allow-unauthenticated \
  --set-env-vars "ENV=prod,LOG_LEVEL=info" \
  --set-secrets "DATABASE_PASSWORD=db-password:latest" \
  --memory 512Mi --max-instances 10
# -> Service URL: https://myapp-xxxx.a.run.app  (TLS + autoscaling included)

def health_check(deps):
    """deps: name -> is_ok. Healthy only if ALL dependencies are ok."""
    healthy = all(deps.values())
    status = 200 if healthy else 503          # 503 -> platform reroutes/restarts
    return status, {"status": "healthy" if healthy else "degraded",
                    "checks": deps}

print(health_check({"db": True,  "cache": True}))    # 200
print(health_check({"db": True,  "cache": False}))   # 503 - cache down
print(health_check({"db": False, "cache": True}))    # 503 - db down

def canary_rollout(steps, error_rate_at, threshold=0.02):
    """steps: traffic %; error_rate_at(pct)->observed error rate. Abort if a stage exceeds threshold."""
    for pct in steps:
        err = error_rate_at(pct)
        print(f"  {pct:3}% traffic -> error rate {err:.1%}", end="")
        if err > threshold:
            print("  ABORT -> roll back")
            return False
        print("  ok")
    print("  promoted to 100%")
    return True

print("release A:")
canary_rollout([5, 25, 50, 100], lambda p: 0.005)
print("release B:")
canary_rollout([5, 25, 50, 100], lambda p: 0.005 if p < 25 else 0.08)

def ready_to_deploy(state):
    blockers = []
    if not state["tests_passed"]:     blockers.append("tests not green")
    if state["image_score"] < 70:     blockers.append(f"image score {state['image_score']} < 70")
    if not state["has_healthcheck"]:  blockers.append("no health endpoint")
    if state["secrets_in_image"]:     blockers.append("secrets baked into image")
    if not state["pinned_tag"]:       blockers.append("image not pinned to a version")
    return (not blockers), blockers

ok, why = ready_to_deploy(dict(tests_passed=True, image_score=95, has_healthcheck=True,
                               secrets_in_image=False, pinned_tag=True))
print("deploy?", ok)
ok2, why2 = ready_to_deploy(dict(tests_passed=True, image_score=50, has_healthcheck=False,
                                 secrets_in_image=False, pinned_tag=True))
print("deploy?", ok2, "|", why2)
# deploy? True   /   deploy? False | ['image score 50 < 70', 'no health endpoint']

class Deployer:
    def __init__(self):
        self.revisions = []
        self.live = None
    def deploy(self, tag, healthy):
        self.revisions.append(tag)
        if healthy:
            self.live = tag
            return f"deployed {tag} (now live)"
        return f"{tag} UNHEALTHY -> kept {self.live} live (auto-rollback)"

d = Deployer()
print(d.deploy("v1.0", True))
print(d.deploy("v1.1", True))
print(d.deploy("v1.2", False))     # bad deploy -> automatic rollback
print("serving:", d.live, "| history:", d.revisions)
# serving: v1.1 | history: ['v1.0', 'v1.1', 'v1.2']

Knowledge check check yourself