Why this is in the vault
Part 4 of Technically's "Software Eng for Vibe Coders" series — the deployment installment, teaching non-engineers what a coding agent's one-click deploy is actually doing (PaaS vs IaaS, build vs runtime, rollbacks, environment variables) — keeping alongside Parts 1-3 as the same plain-language reference set for the same audience.
The core argument
David Krevitt (continuing from Parts 2-3) walks the moment an app leaves localhost and becomes reachable by real users. The core framing: a PaaS like Railway is "renting an unfurnished apartment" (foundation poured, plumbing works, you move your stuff in) versus IaaS like raw EC2, which is "renting an empty plot of land" (everything, including nginx, is your problem) — the tradeoff is setup effort versus control, not one being strictly better. A deploy runs in two distinct phases: build (install dependencies, compile, bundle — a broken build never goes live) and runtime (the live app; runtime errors are the painful ones because the app built fine but something in the running code is wrong). The load-bearing operational advice: every deploy is a snapshot, so a broken production release is fixed with a one-click rollback to the prior working snapshot, not a panicked forward-fix; environment variables (API keys, DB connection strings) never travel with the code and must be set separately per environment (.env locally, the platform's Variables tab in production) — Krevitt calls a first broken deploy from a missing env var a "rite of passage." For apps that ship fast via coding agents, two guardrails matter more than usual: additive-only schema migrations (add the new column, ship the code that uses it, drop the old column later — never rename in one shot on a live app) because code and schema don't land in the same instant during a deploy, and CI plus a staging environment to catch agent-generated regressions before they hit real users.
Mapping against Ray Data Co
Direct pre-flight checklist for any RDCO-provisioned deploy (MAC, Squarely backends, Scribble Works' Pages/Workers stack, any client-facing surface a coding agent touched): does a rollback path actually exist and has anyone exercised it, or is "revert" a theory nobody has tested since the last agent-driven schema change? The additive-migration rule directly reinforces the feedback_verify_static_asset_diffs_not_just_tests lesson — both are instances of "an agent's fast, confident change can silently break something a test suite doesn't cover," here specifically old-code-against-new-schema during the deploy window itself. It also sharpens the Scribble Works Pages/R2 binding failure (feedback_pages_r2_binding_breaks_function_publish): that was exactly a deploy-time environment/binding mismatch between what worked locally and what the platform enforced in production, the same category of "stuff that can't come with you" Krevitt flags for env vars.
Related
- [[2026-09-08-technically-auth-security-vibe-coders]] — same series, Part 3, same sponsor
- [[2026-08-25-technically-vibe-coders-databases-storage]] — same series, Part 2, same sponsor
- [[feedback_pages_r2_binding_breaks_function_publish]]
- [[feedback_verify_static_asset_diffs_not_just_tests]]
⚠️ Sponsorship
Railway sponsors this issue via an explicit "Thanks to our friends at Railway... for sponsoring this series" block plus in-narrative product placement (Art's Postgres instance and deploy target both live on Railway). This is the fourth consecutive confirmed recurrence of the series-level Railway sponsorship the README tracks (Part 1 Aug 11, Part 2 Aug 25, Part 3 Sep 8, now Part 4 Sep 22) — pattern holds, no break. Reader should treat the PaaS-vs-IaaS framing and the specific "Railway is a more modern PaaS" line as commercially motivated, not neutral technical comparison, even though the underlying technical content (build/runtime split, rollback mechanics, env-var discipline) is accurate and general.