Who owns the hardware, and what that decides

This is the root of every other difference here. A local environment runs on hardware you own and control; a cloud environment runs on hardware someone else owns and rents to you. GPU access, cost model, offline behavior and data residency all follow from that one fact rather than being separate decisions. Vendor comparisons tend to list each consequence as its own feature or limitation, when they're one decision showing up in several places.

GPU access: a hardware question, not a pricing tier

A local environment has whatever is in the machine. On a modern Mac the GPU is simply there, available to anything on the host, with nothing to provision. A cloud environment offers only what the provider sells as a machine type, and GPU machines have recently become scarcer in this category, not more common. That isn't a permanent rule, but it's a current fact to check. If local-model inference or anything else that wants a GPU is part of your work, confirm a provider's current offering before assuming it's there.

Offline isn't an edge case

A local environment keeps working with no network: on a flight, on a bad connection, during a provider's outage. A cloud environment needs a working connection to be reachable at all; lose it and the environment isn't slow, it's gone. That bites more often than air travel suggests: a home internet outage, a provider's regional incident, a café's flaky Wi-Fi. Treat it as a real reliability property.

Where your code and data live

A local environment's data is on the machine in front of you, under the security you already have. A cloud environment's data is on the provider's infrastructure, under their security, their terms and their jurisdiction, which matters for regulated industries, client work under NDA, or anything where "where does this data live?" carries compliance weight. That's not a criticism of any provider; it's a difference in who's accountable for the boundary, and on what terms.

The cost model rewards some habits and punishes others

This is easy to underweight until it adds up. Metered billing, compute-hours plus storage and nearly universal for cloud dev environments, charges more, with no ceiling, the more environments you create and destroy. That's a direct problem if disposable, create-and-discard workflows are how you want to work, because that's exactly the pattern metering penalizes most. A flat or one-time local cost doesn't care how many environments you make in a day. Neither model is wrong; they reward different habits, and choosing one that fights yours is where the cost surprises come from.

What cloud does better

Stated plainly: it's reachable from any device, including ones that can't run a local environment at all, like a Chromebook, a tablet or a thin client. Nobody is limited by the machine they own. Handing a teammate a running environment, or spinning up many at once for a class or a hackathon, is easy. And it doesn't use the CPU, memory or battery of the machine in front of you. These are structural advantages, not caveats.

A framework, not a verdict

  • GPU-dependent work, or a create-and-discard habit: local's advantages here are hard to match with metered cloud.
  • Regulated data, an NDA or strict data residency: local keeps the decision in your hands rather than a provider's terms.
  • A team on varied or underpowered hardware, or onboarding that matters more than raw speed: cloud's reachability is real and often decisive.
  • Occasional, bursty compute you don't want to own hardware for: cloud's pay-for-use model fits better than most local setups.

Related reading: Velo Workspaces vs. GitHub Codespaces vs. Ona for the product-level version with current prices, and the disposable VM workflow that makes the cost trade-off concrete. Or download Velo Workspaces and try it yourself.