Remote dev environment or local laptop: a security decision guide

Choose a remote dev environment when you want disposable, isolated workspaces and little source code on laptops. Choose local when you need offline work, special hardware or full control of the machine. Either way, the main risks are the same: untrusted repositories, long lived secrets and weak sign-in.

What a remote environment changes

Take GitHub Codespaces as one documented example. According to GitHub, each codespace runs on its own newly built virtual machine, no two share one, and restarting moves it to a fresh VM with the latest security updates. Each has its own virtual network, firewalls block inbound internet connections and block codespaces from reaching each other, and outbound access is allowed. Only the creator can connect, over a TLS encrypted tunnel.

Those are real benefits compared to a laptop that has lived for three years with every tool you ever tried. Here is what they do not change: the code you open can still run commands, and anything you put in the environment can still leave through outbound access.

Quick lean guide

• Lost or stolen laptops worry you: lean remote, since less code sits on the device.
• You need to work offline: lean local.
• You need special hardware or drivers: lean local.
• You want a clean, repeatable setup per task: lean remote.
• Strict data residency or an air gap: lean local, or remote only if the provider and region meet the rule.
• Reviewing untrusted contributions: lean remote with secrets withheld, or a throwaway VM locally.
• Tablet or borrowed device use: lean remote.

Questions to answer before choosing

1. Where can code and secrets live? Some policies forbid source on personal devices. A remote environment can meet that more easily.
2. What can the environment reach? Outbound access is allowed in the documented example, so decide whether to restrict egress if you can.
3. Who can create environments, and from which repositories?
4. How are secrets delivered? Prefer scoped, short lived ones. See why cloud dev secrets are withheld on fork pull requests.
5. What happens on a lost device? With a remote setup, you revoke the account session, not wipe a drive. See the lost phone playbook.

Risks that remain in both

• Untrusted repositories. GitHub advises opening only repositories you know and trust, because devcontainer.json can install extensions and run commands via postCreateCommand. The same applies to a local container setup.
• Extensions. Install only trusted editor extensions and keep them updated, GitHub advises.
• Dependencies. Vet new ones for maintenance activity and timely security fixes, per the same guidance.
• Sign-in. Whoever controls the account controls the remote environment. Use phishing resistant sign-in, see passkeys for developer accounts.

A middle path

Many teams use both. Remote environments for review, onboarding and short tasks, local machines for daily work. Set the same baseline in each: a pinned dev container definition, secrets from a manager, scanning of dependencies in the editor and in CI.

How to run a pilot

Pick one team and one repository. Measure setup time, number of "works on my machine" issues and any security findings caused by the setup. Review after a month. Decide on evidence, not on the sales page.

Quick check

Sources

• GitHub Docs: Security in GitHub Codespaces

Last reviewed: 19 October 2026.