Categories of Hosting

Objectives

By the end of this lesson, you should be able to:

• Distinguish platform-as-a-service, managed container platforms, and raw virtual machines
• Explain the real trade-off each category makes, between control and operational effort
• Choose a reasonable category for a small, containerized API like this track’s Notes API

💡 Why this matters: Module 3 built a container image, Module 4 built a pipeline that publishes it automatically. Neither one runs anywhere on its own, something has to actually host that container, and the options differ enormously in how much they manage for you, and how much control they leave you with.

Platform-as-a-Service (PaaS)

A platform-as-a-service (Railway, Render, Heroku, and similar) takes a container image, or even just a Git repository, and handles almost everything else, provisioning a server, networking, HTTPS, scaling, in exchange for the least control and, usually, the least required setup. For a small API like this track’s Notes API, this is often the right starting point, minutes from a pushed commit to a live URL, with sensible defaults for everything this course has built so far.

Managed Container Platforms

A managed container platform (AWS ECS, Google Cloud Run, Azure Container Apps) sits a level below PaaS, still not managing raw servers directly, but requiring more explicit configuration, how many instances, how much memory, which networking rules apply. This trades some of PaaS’s simplicity for more control, and often, more cost-efficiency at real scale, a reasonable next step once an application outgrows what a simpler PaaS comfortably handles.

Raw Virtual Machines

A raw virtual machine (a plain EC2 instance, a DigitalOcean droplet) gives full control, and full responsibility, no platform installs security patches, manages HTTPS certificates, or restarts a crashed process automatically, all of that becomes the deploying team’s job, exactly what Module 2 (process management) and Module 6 (reverse proxies and HTTPS) build toward handling directly. This is the most control, and by far the most operational effort, usually only worth it once a team has specific needs a managed platform genuinely can’t meet.

The Real Trade-Off

Every category trades control for managed convenience, along the same spectrum, more control always means more operational responsibility, there’s no option that offers both maximum control and zero operational effort. For a small, real API like this track’s capstone, a PaaS is almost always the right choice, this course’s Module 5 walkthrough uses one directly, the concepts (environment variables, custom domains, zero-downtime deploys) apply, with minor differences, across every category.

Try It

1. For each of the three categories above, name one real, current platform that fits it (beyond the examples already given).
2. Explain, in your own words, why a small side project and a large, established company might reasonably choose different categories for the exact same kind of application.
3. Explain, in one or two sentences, what “operational responsibility” actually means in practice, using a concrete example (patching, restarting, certificate renewal).

Recap

• Platform-as-a-service manages the most for you, in exchange for the least control, often the right starting point for a small API.
• Managed container platforms trade some simplicity for more explicit control and cost-efficiency at scale.
• Raw virtual machines offer full control, at the cost of full operational responsibility, patching, process management, HTTPS, all becoming the deploying team’s job.

Next lesson: a real deployment walkthrough, taking a containerized application from a pushed commit to a live, reachable URL.