Railway's own domain covered web services, workers, and cron jobs as distinct shapes without necessarily naming every single one as its own explicit category. Render makes this taxonomy fully explicit, with a named service type for each — and that explicitness is itself the actual point of this lesson.
2 min read
Static Site — pre-built HTML/CSS/JS, served directly from a CDN,
no server process at all
Web Service — a long-running process serving HTTP requests
Background Worker — a long-running process with NO public HTTP endpoint
Cron Job — runs on a schedule, then exits
Private Service — like a Web Service, but reachable ONLY internally
Railway's own domain covered web services, workers, and cron jobs as real, distinct shapes (its own lessons 1, 2, and 7) — Render names a near-identical set explicitly in its own dashboard and documentation, plus two Render adds as their own first-class category: Static Site (genuinely no server process running at all — just files served from a CDN, the cheapest and simplest possible option for anything that's truly static) and Private Service (a web-service-shaped process, but deliberately never exposed publicly, Render's own explicit version of the same default-private posture Railway's private networking establishes implicitly).
A Web Service running a Node process just to serve pre-built static files pays for a running container the entire time, for work a CDN alone can do for free — Cloud Computing's own CDN lesson covered exactly why serving static content directly from edge caching, with no origin server involved at all for the common case, is both cheaper and faster than routing it through a server process. Render's Static Site type is the explicit acknowledgment of this: genuinely static content (a built React SPA with no server-rendering needs, a documentation site) should never be deployed as a Web Service at all.
Railway's own domain achieved the equivalent of a Private Service by simply not generating a public domain for a service (its own lesson 4's default-private posture) — Render instead makes this an explicit, separately-named service type at creation time, which has a real, practical benefit: a team reading a list of services immediately sees which ones are meant to be internal-only, without needing to separately check whether each one happens to have a public domain configured or not.
Choosing the wrong service type for a given workload carries the same real cost this curriculum's other infrastructure domains have already established for analogous mismatches: a genuinely static site deployed as a Web Service wastes compute cost for nothing; a backend API that should never be public-facing deployed as a plain Web Service (rather than Private Service) carries unnecessary public attack surface, exactly the same concern Application Security's own defense-in-depth lesson named directly.
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. What are Render's five named service types?
2. Why does a genuinely static site benefit from the Static Site type instead of being deployed as a Web Service?
3. What practical benefit does Render's explicit Private Service type provide over Railway's implicit equivalent?
Render