Imagine building something important in a workshop. At first, everything you need is within arm's reach. Your tools are there, your plans are there, and when you want to change something, you walk over and work on it. That was how much of our system began. The Mac was where we built, tested, administered and initiated changes. For a while, that felt like the system itself because it was the place where we could see the work happening. But there comes a point when a workshop and a public business can no longer be the same room. If people around the world need to reach what you built while your personal computer is asleep, disconnected or being repaired, the system needs a home that stays available even when the builder steps away.
Moving from the Mac to the cloud taught us to see infrastructure less like one powerful computer and more like a city. The road that brings people in is not the building they came to visit. The person keeping the building open is not the archive where the blueprints are stored. The warehouse holding heavy equipment is not the office where decisions are made. In our system, Nginx, PM2, the Node application, GitHub, Backblaze B2, the cloud host and the Mac each have different jobs. That separation matters most when something goes wrong. If the front door will not open, we should not tear down the whole building. We first need to know which layer failed, what the evidence proves, and who has the authority to change it.
The Starting Point. The Mac is the human builder environment: a place to develop, administer and initiate authorized changes. But a builder workstation is not the same thing as a persistent production runtime. Moving to the cloud separates the machine used to build the system from the infrastructure responsible for keeping the system available.
From Mac to Cloud. Mac / Local Builder: Human development, administration and authorized deployment. Cloud Host: Persistent compute environment for the running system. Nginx — Ports 80 & 443: Public HTTP and HTTPS ingress. PM2: Supervises the AudioMatrix video portal application process. Node Application — Port 8787: The application runtime behind the public ingress layer. Backblaze B2: Large media and object-storage authority. GitHub: Repository preservation for code, configuration and lightweight governed artifacts.
Separation Creates Clarity. The cloud is not one machine doing everything. Each layer has a responsibility. Nginx is not the application. PM2 is not the source repository. GitHub is not large-media storage. Backblaze B2 is not the application-code authority. The Mac is not the production runtime.
Failure Is Also Layered. When one layer fails, that does not automatically prove that another layer failed. A public HTTP failure does not by itself prove the Node application is dead. A stopped process does not prove the source code is corrupt. An unavailable builder workstation does not by itself prove that the cloud runtime is offline.
Evidence Before Recovery. Recovery begins by identifying what actually failed. Process state, network state, public reachability, application contracts, hashes and receipts can provide different pieces of evidence. A failure signal is not mutation authority. The sequence is: detect, collect evidence, identify the responsible layer, establish recovery authority, preserve the pre-recovery state, execute the authorized recovery, verify the result, and record the receipt.
A Backup Is Not Automatically the Answer. A historical backup may preserve something real while still not representing current production authority. A GitHub copy is not automatically the current running state. A B2 object is not automatically safe to restore. A restart is not automatically the correct recovery action. Recovery must follow evidence.
What We Do Not Claim. This architecture does not claim capabilities that have not been proven: automatic cloud failover, multi-region redundancy, automatic host replacement, automatic database failover, automatic B2 failover, zero-downtime disaster recovery, or guaranteed recovery times. A resilience capability becomes a system fact only after it has been implemented and directly evidenced.
Human Authority. Moving the system into the cloud changes where it runs. It does not transfer authority over what the system should become. Infrastructure can host execution. Evidence can show state. Recovery systems can support restoration. But governed changes still require human authority.
The Boundary. The cloud is a chain of responsibilities. Reliability begins by knowing where each responsibility starts, where it ends, and what the evidence actually proves.
Evidence Basis
This chapter is based on the governed infrastructure authority map, Mac-to-cloud transition model, resilience responsibility boundaries, and evidence-and-recovery model established for STORY_0008.
Historical migration dates or deployment sequences that have not been independently established remain unknown.