Who controls the hardware, and what that actually determines

This is the root of every other difference on this list, not just one item among several: a local environment runs on hardware you own and control directly; a cloud environment runs on hardware someone else owns, that you're renting access to. Everything else — GPU access, cost model, offline behavior, data residency — follows from that one structural fact rather than being an independent, separately-decided tradeoff. It's worth naming explicitly because vendor comparisons tend to present each consequence as its own feature or limitation, when they're really one decision showing up in several places.

GPU access: not a pricing tier, a hardware question

Local hardware includes whatever's physically in the machine — on a modern Mac, that means the GPU is simply there, available to anything running on the host, no provisioning step required. Cloud environments only offer what the provider has chosen to make available as a billable machine type, and GPU-backed instances specifically have gotten more scarce in this category recently, not less — not a permanent industry rule, but a real, current data point worth checking directly rather than assuming availability. If local-model inference or anything else that wants a GPU is part of the workflow, this is worth verifying against a specific provider's current offering before assuming it's there, rather than treating "cloud dev environment" as a single, GPU-agnostic category.

Offline behavior isn't a niche edge case

A local environment keeps working with no network at all — a flight, a bad connection, a provider outage. A cloud environment, by definition, needs a working connection to the provider to be reachable at all; lose that connection and the environment isn't slow, it's unreachable. This shows up as a real cost more often than "I was on a plane" — a home internet outage, a provider's regional incident, a coffee shop's flaky wifi — and it's worth weighing as a genuine reliability property, not just a hypothetical.

Where your code and data actually sit

A local environment's data resides on the machine in front of you, under whatever security posture you already have there. A cloud environment's data resides on the provider's infrastructure, under their security posture, their data-handling terms, and whatever jurisdiction their infrastructure sits in — details that matter a great deal for regulated industries, client work under an NDA, or anything where "where does this data actually live" is a question with real compliance weight, not just a preference. This isn't a knock on any specific provider's security practices; it's a structural difference in who's accountable for that boundary and under what terms.

The cost model shapes the habits it rewards

This is the tradeoff that's easiest to underweight until it compounds: metered cloud billing — compute-hours plus storage, the near-universal model for cloud dev environments — charges more, without a ceiling, the more environments you spin up and tear down. That's a direct problem if disposable, create-and-discard workflows are actually how you want to work, since that exact pattern is what metered billing penalizes hardest. A flat-rate or one-time local cost, by contrast, doesn't care how many times you create and destroy an environment in a day — the cost model doesn't fight the workflow. Neither model is wrong in the abstract; they reward genuinely different usage patterns, and picking one that fights your actual habits is where the real cost surprises come from.

What cloud genuinely does better

Worth stating plainly rather than building toward a foregone conclusion: reachability from any device, including ones that can't run a full local dev environment at all — a Chromebook, a tablet, a thin client. Zero local hardware requirement, so contributors aren't gated by what machine they happen to own. Easier handoff — sending a teammate a running environment, or spinning up many at once for a class or a hackathon, without provisioning individual laptops. And it doesn't consume the CPU, memory, or battery of the machine in front of you while it runs, since the compute lives elsewhere entirely. These are real, structural advantages of cloud environments, not caveats.

A framework, not a verdict

  • GPU-dependent workflow, or a disposable/create-and-discard habit → local's structural advantages here are hard to match with a metered cloud model.
  • Regulated data, an NDA, or strict data-residency requirements → local keeps that decision entirely in your own hands rather than a provider's terms.
  • Team members on varied or underpowered hardware, or frictionless onboarding matters more than raw performance → cloud's reachability advantage is real and often decisive.
  • Occasional, bursty compute needs where you don't want to own or maintain hardware for it → cloud's pay-for-what-you-use model fits that pattern better than most local setups.

Related reading: Velo Workspaces vs. GitHub Codespaces vs. Ona for the specific-product version of this comparison, with real current pricing, and the disposable VM workflow that makes the cost-model tradeoff above concrete. Or download Velo Workspaces and try it yourself.