If you are a VSCode hater (like me), you can achieve the same thing using the open-source, Microsoft-built, official devcontainer CLI [0], which is exactly what VSCode uses under the hood. You don't get automatic port forwarding with this tool, which includes SSH Agent forwarding, so you'll likely want to pair this with installing SSH into your devcontainers, or using some other tool that does the job. I built a tool [1] to do the port forwarding part, which I'd like to be more magic like VSCode's but haven't put the effort into doing, since it works for my purposes.
Using these, I can SSH into my devserver, use the devcontainer CLI to open a tmux session with iTerm2 Tmux integration, and it feels just like a local window. Combine that with Neovide and remote Neovim over the same channel, and I have a native-feeling dev environment running on a remote devcontainer in a nearby data center.
Not loving that the devcontainers CLI is node. The appeal of devcontainers is to limit the amount of code I have to trust on my host. Give me a small static binary I can deploy to new systems.
I ssh into my server, then use the devcontainer cli tool to open a shell in the dev container. Found that easier than installing ssh in every container, especially when there's lots of them. I made a simple command line tool for helping the process, so I don't have to type out any long commands. If I run it it will list the running dev containers and I give them each a number to I don't have to use the full ID.
Yeah, this works. Two drawbacks: you have to rebuild the container when the port forwarding configuration changes, and the port forwards have to be unique on the entire machine.
I like the CLI for commands, but would rather work with an agent chat interface for vibing, which unfortunately I’m becoming increasingly reliant on, even though it’s gotten me into trouble with larger projects.
I have many environments locally, some dependent on others, and some require local databases. I use containers in production, but not always locally.
It’s almost a hellscape situation for trying to setup a fully isolated dev environment. I might be able have have some future generation of Claude convert my existing dev setup to something isolated with k8s. But, I don’t have the power to run such an environment locally, with all of the apps and services. I’d need to set my dev environments up in the cloud, but I don’t have enough money to pay for that, and it wouldn’t even work in some circumstances, because some things must run locally.
So, instead I run Cursor AI with various MCP servers, I approve tool calls, I don’t have things isolated, and I know this will eventually bite me.
> which unfortunately I’m becoming increasingly reliant on, even though it’s gotten me into trouble with larger projects
You could… not do this. You know it causes you problems, you consider it unfortunate that you’re becoming more reliant on it, and yet for some reason you’re choosing to continue anyway. Why are you doing that?
In a similar situation here: it's "unfortunate" in one sense but "extremely fortunate" in another sense.
It's unfortunate if you consider your primary craft to be writing code, as those skills can atrophy. It's obviously important to review and understand all material produced by these tools.
It's fortunate if your primary organizational role is "fix problems, communicate technically, and make new things" because of the sheer power of these tools when applied properly.
I've sunk many hours into attempting to "claude-ify" a complex set of applications and services and (IMO) that's a very useful activity.
Why? So that I can use ai-tooling more effectively? Yes.
Why also? So that services are more decoupled, more testable, more aligned with good development principles.
It's difficult to inject these workflows in a useful way across multiple levels (code/devops/org) but when it works it's worth it.
My key takeaway was something along the lines of: "if an agent can't understand and work with your codebase, you've got an onboarding problem" (we do).
Disclaimer: mostly standard web tech across Java/Scala/React - aggressively complex k8s layer
Just tried it... and it says it's client-only, but when I try to run the SSH provider using my Rapberry Pi it says it needs `docker` to be installed on it :/. So it's not just client-only, is it?
No, client-only means Devpod is contrasting itself to Coder, which requires a central server to orchestrate the containers it creates. Devpod does not. It does still have dependencies, though, among them Docker.
Mate, if you need to install something on a server how the hell can it be called client-only??? eMacs is an example of client-only perhaps, with TRAMP as it works purely on top of SSH , though you could argue it still isn’t client-only as it requires the SSH server to be enabled… so I thought the SSH connector for this would also work the same way but it also requires a full freaking Docker install not just SSH. This is totally misleading.
It's proprietary software masquerading as open-source, for one, and intentionally fosters dependence on its vendor for the plugins that support the most popular languages as well as key features (remote editing, WSL support, integration with the mainline plugin repos), for one.
They do indeed use a different implementation of these features than the one that ships with VSCode, though they're not the original authors of it. They used to host their version separately here: https://github.com/anysphere/open-remote-ssh
But I guess they've just rolled it into the Cursor repo? Idk, because Cursor itself is proprietary.
There's a similar extension for WSL integration, though I'm not 100% sure if Cursor's implementation of this feature is based on it: https://github.com/jeanp413/open-remote-wsl
You can sideload proprietary VSCode extensions to add them to VSCodium or some downstream fork, but you may also have to patch the extensions themselves because some of them refuse to run if they aren't being used with Microsoft's VSCode: https://github.com/OliverKeefe/vscode-extensions-in-vscodium
Microsoft injects proprietary spyware into the official builds that you can't see from the source code. You can get unofficial builds of just the source code from the VsCodium project, but Microsoft blocks your ability to install a lot of extensions if you don't use the official build.
It’s clumsy as hell. It’s neither a good editor, which focus on being fast when doing things with text, nor a good IDE, which is more about the tooling and getting a project done. It’s trying to be both at the same time. And the result is bad at both.
I don’t know, others might be better out of the box. But once you start adding features they all become a mess. I rather just deal with a known mess and not waste time with tools.
For small files and quick edits i use neovim with no customisation at all. Back when I first started using vim I had a pretty long config and some plugins installed and so on. But now that I no longer try to use it as an IDE, neovim is perfect for small edits.
For development work I use JetBrains suite of tools. Very minimal amount of customisation there also, only a couple of extra plugins installed by me and a couple of changes in the settings. It works well enough that I don’t have any desire to spend time customising it a whole bunch.
Don’t get me wrong, I loved neovim and other tools but tbh I just nano for simple edits now. AI tab complete is just too good. Basically it’s barebones or VSCode (or its variants). I could probably use vanilla neovim instead of nano but I've not used vim all that much recently to be in that "flow".
Your point is good, I don't mean to undermine it, but because I work in this area I feel compelled to point out that depending on the type of Swift you're writing using NeoVim to write Swift is actually quite pleasant: https://www.swift.org/documentation/articles/zero-to-swift-n...
I'd waste time with tools. I have my vim config, my git config, my emacs config, my bash config,... that I copy over to any development environment I have. And every now and then, I go into the manual or other people config to check if there's any new trick I can apply.
Comfort is something invaluable when doing a task. I can accept discomfort when I'm in an unfamiliar environment, but not when it's going to be something I will be in for days.
Ultimately, they're about as trite as reasons to hate Vim or Emacs. It boils down to preference, and I'm outlining a path to using another editor and getting access to some of the same features.
Each time I try to use it, I find myself distracted by the impulse to fix the bugs that I notice. There's always this moment when I find a comment from myself, several years earlier, in an issue that's still open because it's unclear whether it's a VSCode problem or a plugin problem, and it's like: "oh, here I am again, doing this instead of working".
That's not to say it's especially buggy, it's just so large, there are a lot of places for bugs to hide.
I get distracted by the impulse to contribute to other editors also, but those are contributions that I'm happy about. They don't always result in bugs fixed or features added, sometimes somebody says "no" but at least it resolves in some way. With VSCode it feels like I'm going in circles.
I personally feel some inner sense of dissonance when I use software written in Electron when alternatives are available. Software targeted to the technical audience has no valid reason not to aim higher in terms of performance and fundamentals.
I do not hate it when others are using it (none of my business). But I do not like to use bloatware. Text editor that eats RAM (even excluding LSP) like 3d editing software.
Oh the gitlab link is really really really cool. I can't express in words how happy I am since I know about iroh and I always wanted to create such a tool myself too but never could figure out iroh.
Now the way I did port forwarding was really wild and really complicated and I think that it might demand a blog post if I am being honest, but yes this project is absolutely godsend. Thanks!!
Just so you know, the devcontainer VSCode extensions are considered proprietary by Microsoft and therefore not allowed to be installed in VSCodium. There are some open-source container plugins, but they are all a bit janky for the container use-case in my experience.
Using these, I can SSH into my devserver, use the devcontainer CLI to open a tmux session with iTerm2 Tmux integration, and it feels just like a local window. Combine that with Neovide and remote Neovim over the same channel, and I have a native-feeling dev environment running on a remote devcontainer in a nearby data center.
[0] https://github.com/devcontainers/cli
[1] https://gitlab.com/CGamesPlay/qtm