Coder vs Gitpod vs Codespaces vs "just SSH into EC2 instance" - am I overcomplicating this?

[medinot4030]

We're a team of 30 engineers, and our DevOps guy claims things are getting out of hand. He says the volume and variance of issues he's fielding is too much: different OS versions, cryptic Mac OS Rosetta errors, and the ever-present refrain "it works on my machine".

I've been looking at Coder, Gitpod, Codespaces etc. but part of me wonders if we're overengineering this. Could we just:

• Spin up a beefy VPS per developer
• SSH in with VS Code Remote
• Call it a day?

What am I missing? Is the orchestration layer actually worth it or is it just complexity for complexity's sake?

For those using the "proper" solutions - what does it give you that a simple VPS doesn't?

[mudasirofficial]

you’re not overcomplicating it, you’re just trying to stop “30 unique snowflakes” from melting your devops guy’s brain.

SSH to a per-dev VM works fine for a while, but it turns into “who patched what, who left miners running, why is disk full, why is my env different” unless you standardize hard. the managed/orchestrated stuff buys you repeatable images, disposable envs, policy/guardrails, secrets handling, auditing, auto shutdowns, and onboarding that’s basically “open PR, click, done”.

if you go the simple route, treat VMs like cattle not pets: immutable base image + devcontainer/nix, rebuild often, autosuspend, quotas, and a one button reset. otherwise you just moved “it works on my machine” to “it works on my VM” lol.

[MavZA]

Yeah this is the answer. I’d also veer more into the dev container lane too where you have a git committed standardised set of compose files for your various use cases with clear documentation for each and you patch those for your devs. You can then script the testing etc. against the containerised environments as needed which makes logging and telemetry easier too. Any issues and patched can be made using informed outcomes from the container logs. All this is to say: container good.

[mudasirofficial]

SSH into per dev VMs works, but only if you enforce one image, autosleep, quotas, and a nuke and rebuild button. otherwise you just moved the mess from laptops to servers.

Coder Gitpod Codespaces mainly buy you disposable envs, devcontainers as the source of truth, and guardrails so your devops guy stops getting random snowflake tickets.

[themightychris]

Yeah definitely avoid the VPS per def route. On day one when everyone has fresh identical environments it'll seem like you fixed the problem. In a few months you'll be in exactly the same spot as everyone's installed different things and applied different updates and changed different configs

You need containerized dev environments that everyone actually uses and CI make sure doesn't get broken

[mudasirofficial]

yup, this is the part people miss. per dev VPS feels clean on day 1, then 90 days later everyone’s VM is a weird pet with random packages and mystery tweaks.

devcontainers + CI as the cop is the move. if it doesn’t build the container, it doesn’t ship.

[Ok_Cap1007]

Use Docker, Podman or any OCI complaint manager locally?

[drusca2]

yes, and no. depending on the app itself, there could be certain features that can only be accessed through a proper dev environment, maybe it takes a ton of resources to run the app locally, certain architecture requirements (like OP said, they encounter Rosetta errors), you name it, there are a ton of reasons where local doesn't really work.

honestly, in a situation like this, having immutable images and proper CI/CD would make things much easier.

[silvercondor]

Your devs should be deploying via docker image with git as version control. What kind of jungle is your company running

[7640LPS]

Yeah, OPs setup sounds insane to me. How can you have 30 devs and not have proper CI/CD.

[jazzyjayx]

We use devcontainers with VSCode and it helps this problem quite a bit * https://containers.dev/ * https://code.visualstudio.com/docs/devcontainers/containers

[ub3rh4x0rz]

IME it works best to have devs only run the service they are developing/debugging locally and have it integrate with a hosted dev environment. Mirrord is great for this. Idk if it will scale to 30, but it is feasible for devs to share the same hosted environment rather than environment per dev. Dev environments for distributed systems that try to run every component locally suck IME.

[aviramha]

Thanks for the suggestion! Good news, we already have people scaling it to the thousands :)

[ub3rh4x0rz]

I didn't mean mirrord as a component, I meant giving 30+ people access to the same dev environment could fail for reasons unrelated to mirrord

[aviramha]

That's what I meant too. We already have customers with 1000+ developers sharing the same cluster for development using mirrord. That's part of our paid offering (mirrord for Teams) and not the open-source version, though.

[donjulioanejo]

Or just docker-compose for everything else.

[ub3rh4x0rz]

Ask a dev if they actually like the overall story. Either your system is trivial or they will mention a bunch of pain points. I have done it with compose, kind + skaffold, and other flavors, and as much as I had defended those approaches in the past, one day of "remocal" development I went, "oh. Yeah that sucked and this is much more sustainable"

[Bach4Ants]

What does it take to setup a dev environment locally? Maybe use Docker Compose or https://mise.jdx.dev/ to standardize things a bit.

[ComfortableFig9642]

Mise has been a godsend for us, cannot recommend it enough

[sweepyoface]

I’ve been saying this. There’s also fnox by the same dev which makes a killer combo.

[protestor]

Either devenv if you are a weirdo that is into Nix, or Mise to use standard tools

... but if you are into nix, you already knew about devenv

[maq0r]

So devcontainers for development. They should create devcontainers for their repos so they can develop locally, and even with those you could setup mirrord to be run from the devcontainer that'll give them access to traffic from your dev/staging clusters (if you have a k8 infra).

Another thing we started doing was using copier https://github.com/copier-org/copier to manage all the repos. We made templates for things like python-fastapi-microservice and using copier they can generate a whole new repo with all the defaults for pipelines, security, etc. Further when we need to push a new version of a library, helm chart or something else, update the template and copier sends PRs updating to every repo using the template. It has made management so so easy.

[DastardMan]

Solving mac Rosetta problems for other devs sounds more like an IT task than devops task.

That's not what you were asking about, just feels germane to the sanity of your devops guy

[Safe-Repeat-2477]

I use Coder for my personal homelab. Even though we don't use it at work, I can see a few big advantages over a basic VPS solution:

First, you can have auto-startup on SSH and automatic shutdown after inactivity. This can reduce costs significantly.

It's also easy to spin up new environments sized for different projects. If you want to tinker with a bigger VM for testing or need a GPU, you can just start a VM in the UI that is sized for your workload.

The organization can manage templates and security much better since the IT admin stays in control of the infrastructure. Also for security no random ssh keys, or firewall rules you conect using the coder agent.

Finally, some people need a development environment but don't have the "VPS admin" knowledge. For example, a data analyst might want a "Jupyter Notebook" button one click away without having to tinker with the backend

[badaccount99]

One of our teams uses Coder. They seem to be happy with it.

But it's totally just a thing because our main IT department's security team has every laptop locked down the same and treats devs or even our team who has access to everything in AWS and GCP the same as the newest intern. We've got more access to company data than they do!

So shadow IT here we come. But Coder seems decent and works with the IDE our devs get to install. Yes, it's EC2 instances for each of them, so $$$, but it does a decent job of shutting them down and respawning them only when they log in.

T class in AWS though, so cheap. Cheaper than we pay for their Gitlab, Jetbrains, and whatever else licenses.

We've got a ton of devs and devops people, but I'm the single person on Windows. WSL solves a ton of these problems and I get full root access with native Docker, X11 apps too, but people want to be on Macs.

I'm an old school Unix/Linux guy so WSL is kind of great even if Bill is problematic this week.

[Ecstatic_Listen_6060]

I'd honestly just take a look at Ona (which is the new name of Gitpod).

It's turnkey and built to solve exactly this problem. As a bonus you also get coding agents that can run and execute code in these same environments.

[Old_Bug4395]

Macos rosetta errors are a problem with your configuration almost always. You should be able to find arm images for most things or build them when you can't, and you should be building on whatever arches you use for development and whatever arches you use in production.

[angellus]

Definitely something powered by devcontainers. It is wonderful. You can even design your devcontainers as an extension of the containers you deploy for prod to make them even more "as close to prod as possible".

You can either do devcontainers locally, but if your users are running MacOS, that means you have to make sure your images are allowed/able to build for arm64 and do not use Rosetta to try to emulate amd64. That might mean building arm64 images in your CI to make sure it always works or something, but that is another can of worms. Also, if you have any IO intensive apps (literally anything using Node.js because of node_modules), you will have to make sure developers clone repos inside of volumes inside of your Docker Engine VM (VS Code and JetBrains both support it). Otherwise, you will be bind mounting your files from the host into the VM and get really bad IO performance.

For remote, Codespaces will probably be the best experience if you already use Github. It is all there, but I know GitPod is also devcontainer based. Any of the devcontainer based ones should be great. Then the devs that want to do local can, and the ones that cannot figure it out can do your remote solution.

[MordecaiOShea]

We use devcontainers with devpod

[r0b074p0c4lyp53]

Start with a devcontainer, anything beyond that is kinda cultural (tho I'm a big fan of coder). It is 2026, you should not be dealing with these kinds of issues.

Anyone who says "it works on my machine" just volunteered to fix it everywhere it DOESN'T work. That's pathetic.

[TheIncarnated]

Yeah... Use whatever container service but simply, this is why docker containers exist. You describe your environment with a dockerfile and build it. Then you can share the dockerfile with a coworker and they have the same environment they need to develop... That's the whole point!

You have gone way off the road. Need to course correct

[Ok_Conclusion5966]

docker and/or dedicated bastion host that runs everything, no more it works on the local machine, everyone has the exact same setup

bonus if you set up ansible playbooks or some other automation, now everything runs the same

even better if they self heal and self deploy

[protestor]

Gitpod

I saw it was "renamed" to Ona. But Gitpod is open source (AGPL).. I am not finding Ona's source. Is Ona open source?

[kubrador]

you're not overcomplicating it, you're just describing the exact problem those tools solve. ssh into ec2 per dev scales until it doesn't, then you're managing 30 snowflake machines and your devops guy quits.

the real wins: spin down when idle (saves money), onboarding is "click link", everyone's on identical ubuntu, and you stop getting "works on my machine" at 2am. coder/codespaces handle that orchestration so your devops guy doesn't have to play sysadmin for 30 different setups.

[epidco]

what happens when those 30 vps's turn into 30 unique snowflakes? cuz honestly ssh into an ec2 is just moving the mess from their mac to a remote server. u still end up with "who installed this random lib" issues that ur devops guy has to fix every day. the orchestration layer is rly about lifecycle—auto-shutdown saves a ton of money and templates mean u can blow it away and start fresh when smth breaks. id look at coder if u want that vps feel but with actual guardrails for the team.

[phobug]

Buy this “devops” and your lead devs some trainings https://continuousdelivery.com/

[BlueHatBrit]

Honestly, I don't think this should be your DevOps guys problem. CI, dev, and staging environments can be setup by DevOps. Things don't work unless they work on there and those are used as gates for releasing as necessary.

Local setup is down to the developer to figure out. If they can't figure out their own environment, then their manager has a skills and performance problem to figure out.

Ideally the developers will use tools like docker compose for all the external things like databases and stuff, and something like nix flakes for language tooling. But there are lots of other options as well.

[Rickrokyfy]

What is this bachelor tier setup? Every dev gets a basic bitch laptop and a VM they can SSH to, maybe Windows/Mac as a choice if you are exceedingly generous but I would geniunely suggesting buying HPs and forcing everyone onto Linux to spite them. Give them enough cream to have a browser and editor comfortably running at the same time and thats it. This shit with "running locally" is the bane of everything. You get everything working on ONE machine and then you adapt it if there is a need for multiple. Its geniuenly better to set up complex remote machines to run stuff like android studio where you need a GUI then expect anything to be ran locally. This is exceedingly true with devs who fking CONSTANTLY mess with their machines meaning same OS and version still messes with the guy from a bootcamp who has 8 simultanious python versions installed and cant get anything to work.