Comment by nzoschke

1 day ago

Congrats!

My daily driver is Zed developing on SSH remote servers on exe.dev.

It's crazy to think of all the dev tools I've churned through over the last 18 months but these two feel sticky.

Zed has everything I need in a unified pane. File editor, terminal, agents, SSH remotes. And it's fast and intuitive

exe.dev is the first "dev container" I've ever *loved*. The remote sandbox means `dangerously-skip-permissions` is safe. Being on the internet with good private / shared / public access saves so much time.

I also use https://conductor.build/ and GitHub but this is starting to feel clunky compared hacking directly against online live reloading apps.

20 comments

nzoschke

Reply
tikotus  1 day ago

I'm glad to hear the SSH remote editing is working well.

A lot of the time I'm developing on a remote server using VSCode Remote-SSH. I mostly love it. But! It consumes a lot of memory. And not only that. At times it gets stuck in some infinite loop or such, and ends up consuming all memory on the machine, preventing all traffic. Takes a few minutes for the OS to finally kill it, so I can get back in. I'm pretty this is happening due to large collections of symlinks (the subprocess eating up the memory is rg). But also just JavaScript editing at times launches up a bunch of ts-servers consuming everything and more.

This is super scary, if I'm poking around on the prod server.

Looking for alternatives. Zed is on my list.

  • tikotus  8 hours ago

    Actually, inspired by this, I went ahead and installed Zed to try it out. After a couple of hours of working remotely using Zed, I'm impressed. It actually works, and the experience feels great. Only little issue was that when I first opened the remote folder, I was greeted with a blank window. I thought it was stuck loading and was about to give up, but turns out I had to open the project panel myself to see the files. Otherwise, working fine so far! Memory-wise it's practically free.

    EDIT: Scrap that. After a while it starts running at 100% CPU on my macbook. I'm editing a small, simple PHP remotely over SSH. I haven't yet tested if it only happens with remote editing. Too bad... Well, at least it didn't trash the server like VSCode.

    EDIT: Logs showed it was trying to do some auto suggestions every few seconds, but failed due to missing credentials. Didn't seem like something that would eat up 100%, but after disabling all AI features (I'm glad there was an option for this), the problem disappeared, and I'm happy with Zed again.

  • eknkc  1 day ago

    I've been using the SSH remote editing on Zed too and it works great. No issues whatsoever.

  • whalesalad  20 hours ago

    The only reason I remained on vscode for so long was the remote ssh editing as I also use a dev box (M2 air + dev box = multi-day battery life) but recently got sick and tired of the vscode instability and frequent need to blow away state / reinstall plugins after updates. When I saw Zed had an ssh dev equivalent I jumped ship and haven't looked back. Here is my theme if anyone is interested, https://github.com/whalesalad/dotfiles/blob/master/zed/whale...

huijzer  1 day ago

How does exe.dev differ from VPS + Caddy + some subdomain on a domain you already own?

For auth one can use Caddy and basic auth. Yes it takes a bit of work but it isn’t that bad. Plus zero subscription costs if your VPS is a Raspberry

  • mrklol  9 hours ago

    Personally the main advantage is to simply spin up new ones with the same setup. You can also do that by yourself but imo it includes way more managing and time compared to exe

  • nzoschke  12 hours ago

    I have a Hetzner box with Caddy too.

    The difference with exe.dev is multiple VMs. I have over 20 now with isolated apps, branches of the same app, etc.

  • fowlie  19 hours ago

    > Yes it takes a bit of work but it isn’t that bad.

    Agreed, it takes a few hours to set up everything. But just did it with Claude the other day, and I was up and running in no time! :-)

c-hendricks  1 day ago

I'll have to check it out again. Last time I tried, the got integration didn't work when connecting to a remote SSH server, and ports couldn't be mapped at runtime.

Had to shut everything down, list the port, and then reconnect. A big pain when other tools just automatically figure out what needs to be forwarded, or just let you specify arbitrary ports at runtime.

nate  1 day ago

"online live reloading apps" => trying to get my head around this workflow. so the disk is shared across these? so do you still have the problem of say running a "main" version of an app, and it's weird experimental version of that same app? because they still have to live in different folders/worktrees? that's where I get stuck a little trying to enable things like this for others. right now, I've got people a system we can spin up N "vms". but it's not persistent storage if the vm goes away. it's whatever version exists in their GitHub branch. hopefully if they hack the vm app they commit and push back to the repo.

  • nzoschke  1 day ago

    Yes I’m trusting exe.dev disks and persistence.

    For many apps the weird experimental version is all there is. Call it vibe coding or experiments or non-critical tools. These may not even have a GitHub repo. I trust local git and the exe.dev disks.

    Then for serious apps the above is the same shape for development branches. Spin up a VM in a few seconds with the code checked out and running online and editable over an SSH mount is the magic.

    Then that turns into a PR on GitHub and a normal review then CI/CD to staging and prod takes over.

chrisweekly  1 day ago

Thank you for this comment! exe.dev is what I've been seeking without quite knowing it. excited to dig into it.

user3939382  12 hours ago

What you really want is to build a Docker container and wait for ECS deployments between iterations.

  • vaishnavsm  12 hours ago

    ECS really isn't scalable. imo a multi-account EKS cluster is a bare minimum. It's what I use for my todo list app, and it works great!