Who Owns Your Dev Environment?

There's a difference between using a service and depending on one.

When you use a cloud dev environment, you're usually depending on it. Your configuration is in their format. Your workflow is built around their tools. Your data lives on their infrastructure. This is fine until something changes — pricing goes up, a feature gets deprecated, the company pivots.

Then you discover how much of your setup was actually theirs.

How lock-in happens

Nobody sets out to get locked in. It happens gradually.

You start with a cloud IDE because it's convenient. The onboarding is smooth. You configure your environment using their config format: .devcontainer.json, .gitpod.yml, whatever. You install their CLI. You use their port forwarding. You build your workflow around their abstractions.

Each individual step is reasonable. But after six months, migrating to something else means rebuilding from scratch. Not because the code is locked in; the code is in Git. But the environment is locked in. The configuration, the tooling, the workflow.

This isn't malicious. It's just what happens when platforms build proprietary interfaces. They're optimizing for their product, not your portability.

What ownership looks like

An environment you own is one you can move. Not theoretically — actually.

Can you SSH into it? Can you scp files out? Can you take your configuration and run it on a different machine without modification? Can you read the source code of the thing running your environment?

If the answer to any of these is no, you're renting.

EnvHaven environments are standard Docker containers running standard Linux. The image is public, MIT-licensed, and runs anywhere Docker runs. There's no proprietary format. No vendor-specific abstraction.

# Self-hosted: SSH in directly
ssh [email protected] -p 2222

# Copy files out
scp -P 2222 [email protected]:~/project ./backup

# Or use Haven CLI for bidirectional sync
haven connect . [email protected]:2222

If we shut down tomorrow, you'd still have a Docker image you can pull and run on any Linux machine. Your projects are files on disk, accessible via SSH and SCP.

The "free forever" question

A lot of platforms offer free tiers. Free tiers are marketing. The terms change, features get gated, and usage limits shrink until "free" means "free until we decide it isn't."

EnvHaven's self-hosted version is MIT-licensed. The full Docker image. The CLI. Everything. No features gated behind a paid tier. No "community edition" missing the good parts.

Managed hosting costs $10/mo if you want someone else to deal with servers. But the self-hosted version is complete. This isn't a teaser. It's the same thing.

Why give it away? Partly because most of what's in the image isn't ours. It's built on code-server, linuxserver.io, mise, tmux, Mutagen, and dozens of other open-source projects. We composed them together and made them work in a container. The value of managed hosting is convenience, not features. If you can run Docker, you don't need us. If you'd rather not manage infrastructure, that's what the $10 is for.

Why this matters more with AI agents

AI agents are changing how people use dev environments. They need filesystem access, install packages, run builds, and experiment freely. Experiments sometimes break things.

On a locked-down platform, agents hit walls. Permission errors. Sandboxing restrictions. Rate limits on API calls. You end up debugging the platform instead of building your project.

Sandbox SDKs like Vercel Sandbox and Cloudflare Sandbox give agents isolated execution, but they're APIs, not environments. Ephemeral platforms like E2B and Daytona spin up disposable containers for agents, but nothing persists between sessions. Cloud dev environments like Codespaces give you persistence, but with platform restrictions that limit what agents can do.

In an environment you actually own, with root access and no artificial restrictions, agents just work. If something breaks, you SSH in and fix it. No support tickets. No waiting for a vendor to unblock you.

This is increasingly the bottleneck. The models are getting good. The tooling is getting good. The limiting factor is the environment, and specifically, how much freedom it gives both you and your agents.

The honest tradeoff

Owning your environment means more responsibility. You manage updates. You handle backups. You debug infrastructure issues. Managed platforms handle all of this for you, and there's real value in that.

If you're a student, or someone who codes occasionally, or someone who values zero-config convenience above everything else, a managed platform with a proprietary interface might genuinely be the better choice. The lock-in tradeoff is worth it for the simplicity.

But if you're a professional developer who plans to be doing this for years, the calculus is different. Investing in a portable setup pays off over time. Skills transfer. Configuration transfers. Nothing gets stranded.

That's the argument for ownership. Not that renting is bad. Just that owning is better if you're in it for the long haul.

The source is on GitHub. Try managed hosting or self-host. Either way, it's yours.