render.yaml: Render's entire infrastructure, declared in one file

A Blueprint (render.yaml, checked into the repository root) declares every service, database, and their configuration in one file — pushing this file to Render creates or updates the entire described infrastructure in one deliberate action, rather than a team manually clicking through a dashboard to recreate the same setup service by service.

Cloud Computing's own IaC lesson named the real reasons infrastructure-as-code matters generally: the actual infrastructure configuration is reviewable in a pull request (the same code-review discipline Web Security's own secure-code-review lesson applied to application code, now applied to infrastructure changes too), reproducible (spinning up an identical staging environment means running the same file, not trying to remember and manually repeat every dashboard click that built production), and version-controlled (a bad infrastructure change can be traced to a specific commit and reverted, the same way application code can).

Railway's own domain described configuring services, reference variables, and environments primarily through its dashboard — real, usable, but living in Railway's own system of record, not in a file a team's own version control tracks directly. Render's Blueprint model makes the infrastructure definition itself a first-class part of the repository, reviewable and diffable exactly like application code — a real, deliberate trade-off: more upfront structure (writing and maintaining a YAML file) for more of the reproducibility and audit-trail benefits IaC generally provides.

A Blueprint defines the shape of the infrastructure — what services exist, how they're configured — but day-to-day operations (viewing logs, manually triggering a one-off deploy, inspecting current resource usage) still happen through Render's dashboard, the same way Terraform defining AWS infrastructure doesn't replace the AWS console for day-to-day observation once that infrastructure is actually running.