Add support for "remote development"

[imron]

Visual Studio Code has a killer feature, "Remote Development", which allows you to remote in to another machine or a docker container, and develop on the remote machine/container as if the entire directory structure and dev environment (including terminal shell) was local.

It would be great to eventually see this feature in Zed, and even if Zed doesn't support this in version 1, it's a compelling enough feature that it would be worth laying to groundwork early on to support it, especially while you're still figuring out the internal api for the editor and how pieces fit together.

For some anecdotal feedback on the usefulness of this feature, in my current role (C++ dev at a large enterprise), for various business reasons our choice of IDEs is more or less limited to VSCode or CLion.

Since I joined and started showing people how the Remote Dev feature of VSCode works, I have seen about a dozen diehard CLion fans switch to VSCode (despite CLion being a better IDE for C++ development) simply because the Remote Development feature works so well and our development process involves a lot of remote development - we have company issued windows laptops, but the software we develop is linux-based and development happens in a mix of docker containers, virtual machines, wsl2 and remote linux instances.

VSCode with the Remote Development extension makes this really easy to deal with and devs will put up with reduced capability on the C++ IDE side of things, for the superior remote development support.

This feature is so useful that Jetbrains recently revamped their entire approach to remote development with Jetbrains Gateway to have something similar.

Anyway, just wanted to put this out there as something to consider, because I guess it will be easier to make architectural changes needed to support something like this earlier rather than later.

[JosephTLyons]

This is a feature I'd love to see built into Zed. It even think it would be be neat if you could remote into some server and do the same collaborative editing there as well, although I don't know how often that would be used - maybe in the context of "fighting fires."

This feature is so useful that Jetbrains recently revamped their entire approach to remote development with Jetbrains Gateway to have something similar.

OT, but I wonder if this has improved significantly since I tried it last - it was super clunky and heavy handed when I first tried it. I much prefer how VS Code's works, it is a lot more simple.

[imron]

OT

I don't think it's off-topic - in fact having this work smoothly and seamlessly is a major part of this feature.

I haven't used Gateway, but their previous remote development solution (which involved rsyncing files between machines) was also super clunky (especially when the host was Windows and symbolic links were involved).

VSCode really knocked it out of the park with the remote developer extension and it should be the standard to aim for and improve upon.

[imron]

It even think it would be be neat if you could remote into some server and do the same collaborative editing there as well, although I don't know how often that would be used - maybe in the context of "fighting fires."

I imagine good collaboration tools would be really useful in this space (I've previously had to collaboratively fight fires over a mix of slack and zoom and other tools), however there are also potential security concerns as anyone connecting to Zed for collaboration would have the same access to the host as the user that ran the Zed process (which may not be themselves).

You don't want people connecting to Zed 'server' that is running as sudo (to fight fires on a file that requires admin priv to edit), and then have connecting users be able to open a shell in the remote terminal as root and do things.

[fdionisi]

I was holding back on this feature, but now that it is out here, I'll also jump in. 😅

At the time of the Xray experiment, one mind-blowing feature was the ability to spin up the editor in headless mode. If I recall correctly, this mechanism was the backbone of the editor's web version. Reading through Discord, using the editor from the browser (i.e. the web version) is on the roadmap, so I hope to see this capability resurface. 😀

But I also agree with @imron; such a feature should be paired with (granular) users' permission management. Not sure if this goes outside of Zed scope's, though.
Xray allowed access only to files loaded in the workspace, but this becomes more complex when the terminal is integrated within Zed. But then again, the permissions story could be somehow managed via user and user groups provided at the OS level? I'm not an expert, so I'll leave it to the team.

[voltrevo]

I'd also love to see this.

Btw this format in the CLI would be fantastic:

zed user@host:path/to/project

vs code's format is very strange by comparison:

code --remote ssh-remote+workspace

I can understanding adding a flag though, esp if e.g. you don't specify user@ (which btw vs code somehow forgot to support specifying a user (in any format)):

zed host # yeah not enough context
zed user@host # probably ok if you don't mind the inconsistency of conditionally allowing --ssh to be omitted
zed --ssh host # 💪
zed --ssh host:path/to/project # 💪
zed --ssh user@host:path/to/project # 💪 (totally understandable to require the --ssh flag)

[thiagomajesk]

+1 to this, it's definitely a must for me because of WSL2 - which is currently the only way to have a decent development environment on Windows for non-MS stuff.

[etep]

The discussion seems focused on launching zed from the local machine to edit a remote file. As a user of rmate, then rsub, then ratom (well, maybe I renamed it ratom), I have the following:

Would like to suggest adding a feature that is equivalent to rmate/rsub for zed, i.e. the ability to trigger a local zed from a remote machine to edit a remote file.

[hronro]

I believe "remote development" is not only about editing files of a remote machine but also connecting to an LSP server running on the remote machine. As far as I know, very few LSP servers allow clients to connect to them via TCP, so maybe an additional forwarder program is required to be installed in the remote machine.

As a person who comes from the NeoVim world, there are already something like distant and distant.nvim. Since distant is a general library and is written in Rust, I guess it might be easy for Zed to integrate with.

[andreujuanc]

Most important for me would be to remote into a container from a local Dockerfile or docker-compose. Same functionality as with vscode's dev containers. IMHO this is much better than simple SSH.

[derekparker]

Adding a +1 vote to this but with a little context.

I have a workstation that I do most of my actual programming on, which I access from various different machines as a "frontend" to that workstation. I've always really enjoyed VSCodes support for this exact scenario and how seamless and easy to setup it is. Would love to see this implemented in this editor. One thing to note however is that the workstation is Linux based and most of the machines I use as "frontends" to that workstation are macOS based, so this might involve making the editor work on Linux as well.

[halink0803]

I use this feature everyday with VSCode as I am having my source in a remote computer, then when I tried Zed and it lack of this feature, I cannot experiment any further. Please adding this feature as it is very useful.

[xpader]

I love this feature in vscode, because it is a pain to unify your own development environment on different computers, by remote development, I can start development on any new machine by install a vscode, even on some computers with extremely low configuration.

[msdrigg]

This is a blocker to me regularly using zed. I almost always use vscode remote developing from my laptop to my desktop at home, so it would be disruptive to change this workflow to use zed.

If this feature was supported, then I would definitely switch to use zed as a primary editor when using my low end MacBook Air.

[JesseFarebro]

I'll also chime in with some additional context around this feature.

For my use case (and others who work with HPC) almost none of our development is done locally. VSCode is the de facto standard due to the remote development tools. I know that JetBrains also has some remote development tools although I'm not too familiar with them.

It would be great to see another editor that could support this use case and it seems Zed might be uniquely positioned to pull off an amazing user experience given the infrastructure built around collaborative editing. Excited to see what can come from this!

[zlpkhr]

+1 for remote lsp connection, I really like docker dev environments for keeping host machine clean

[loujr]

Remote connection is also a big blocker for me using zed. Keep up the great work!

[alexghirelli]

+1, I use remote env everyday. It could be amazing to have this feature in Zed.

[ossfellow]

Supporting devcontainers will open up a lot of possibilities, including easy integration with developer tools, like newly launched DevPod, which supports launching development environments locally or on the cloud platform of your choice.

[jansol]

Launching a whole headless zed on the remote sounds like a good solution - it would trivially allow for remote language servers without them having to support TCP. And remote language servers etc integrations in the correct target environment would make life way, way easier than trying to approximate something similar locally with SSHFS. I occasionally write code where some dependencies are simply not available on mac, so every file that uses those upsets the language server.

[pbiggar]

Sadly can't use zed in its current state because our entire development is done via VSCode devcontainer.

[iamvoidcoder]

+1. Please please please make the remote development feature happen.

[0xGodson]

+1 for remote connection

[tk103331]

lapce support SSH and WSL remote development
https://docs.lapce.dev/get-started/remote-development

[iamvoidcoder]

The remote dev in Lapce looking interesting but the editor itself is really in its early days. Even the basic core editing features aren't there (find & replace, bookmarks etc), no way to use as a daily driver.

Though Zed is not far ahead in this department either :( Wish the devs first implemented basic editing before taking on the fancy complex colab features.

[ncri]

Awesome, works nicely already. Although I cannot get the ruby syntax highlighting extension installed. Any idea?

[clarkezone]

Holy Crap that was quick! Nice job Zed contributors and team!

[sandhawalia]

FWIW — I've been using it for the last 4+ weeks. Works like a charm. Multiple hosts / over ssh / as quick ask local editing. Much appreciated Zed team + contributors.

[lucianoratamero]

this is looking great! did anyone test this with docker? I think this would solve most of my issues if integrated effectively with docker for development, inspired on how vscode does it :]

…

On Friday, July 19th, 2024 at 7:42 AM, Harsimrat Sandhawalia ***@***.***> wrote: FWIW — I've been using it for the last 4+ weeks. Works like a charm. Multiple hosts / over ssh / as quick ask local editing. Much appreciated Zed team + contributors. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[khantseithu]

how does port forwarding works here which vscode does it by default?

[mzhang28]

Opens a reverse shell to Microsoft servers using non-open-source code so they can tunnel all requests (and maybe make some of their own...)

[samchouse]

I'm not sure with regard to the sign in but VSCode does also download a copy of itself on remote machines for SSH, it just doesn't have as much attention drawn to it. It's located at ~/.vscode-server(-insiders) for Linux remotes.

[jansol]

Why am i forced to sign in to use this feature?

Because it is built on top of the collaboration functionality which for the time being goes through zed.dev servers.

[mosenturm]

I'm not sure with regard to the sign in but VSCode does also download a copy of itself on remote machines for SSH, it just doesn't have as much attention drawn to it. It's located at ~/.vscode-server(-insiders) for Linux remotes.

vscode simply (simply) puts all required files in the users home directory. Zed installs crap everywhere [...]

Zed puts all required file in the user home directory too. No crap everywhere.

[iamnbutler]

@tinyaustralia Disagreeing or providing critical feedback are both fine, but the way you are saying things is not. This is your one formal warning of being in breach of our Code of Conduct.

[abhibeckert]

@tinyaustralia Disagreeing or providing critical feedback are both fine, but the way you are saying things is not.

Sure, but he makes an important point. This feature has nothing to do with collaboration. In VSCode I almost exclusively use it to connect to localhost (in a container or virtual machine).

Also - when I do want actual remotes shared, I’ll use 1Password or KeePass for that. Something with E2E encryption and robust security.

[mathroc]

sure, and no one has issues with that part, if you read the release notes, it links to https://zed.dev/docs/remote-development and there it says:

Currently the two instances connect via Zed's servers, but we intend to build peer to peer communication before the feature is fully released.

So it's likely a shortcut they took to get the feature working, and they are planning to make it work without going through Zed servers

[psychedelicious]

@tinyaustralia

The feature itself is in beta and, as described on the docs page, the intention is to have no sign-in requirement for the full release. It's very clear. You don't have to use it before this is implemented.

The words you used (which, btw, are not removed - you can click your comment to show it) are not kind, empathetic or respectful. Whether or not you directed them at the product or project or individuals is immaterial. The simple fact is that humans are building zed, and that kind of language makes its way back to those humans.

Nobody is threatening you and nobody is going to hold it against you if you apologize and move on.

Anyways, I agree with your point. I cannot use zed for anything real until the remote dev feature uses direct peer-to-peer communication.

I'm pleasantly surprised at how fast the zed team has gotten linux and remote dev up and running, great work!

[maan2003]

zed user@host:path/to/project

zed ssh://user@host:1234/path/to/project is clearer and extensible :)

[codegod100]

What still needs to be done before this is closed? Is there a kanban somewhere?

[rome-user]

I have used the remote development feature for a week. I'll start with the positive feedback, since I like this feature as-is.

• Never crashed

• Internet connection was lost due to laptop sleeping, but Zed was able to reconnect and not lose data

• It works well in a mid-sized TypeScript project

As for negative feedback,

• LSP feels slower than VS Code's remote

• Each terminal tab requires authentication

• Inline assist works, but Assistant Panel doesn't

Overall, I agree with the other comments. The feature request seems satisfied. I haven't felt the need to use VS Code this week.

[kevin-leptons]

I look forward to using a peer-to-peer connection between the editor and remote machines 👍 .

[MrCroxx]

I look forward to using a peer-to-peer connection between the editor and remote machines 👍 .

+1 Is p2p remote mode under development? 🥰

[brunoscota]

I look forward to using a peer-to-peer connection between the editor and remote machines 👍 .

+1 Is p2p remote mode under development? 🥰

Sorry my understanding but what is peer to peer remote mode?

[nrclark]

I look forward to using a peer-to-peer connection between the editor and remote machines 👍 .

+1 Is p2p remote mode under development? 🥰

Sorry my understanding but what is peer to peer remote mode?

The current implementation relies on connections to Zed's servers, meaning that it can't be used on remote machines that don't have access to the internet.

[lattice0]

SSH could solve that, as I do for VSCode web, but UDP hole punching with the initial 'handshake' only over zed servers would be awesome and fast Enviado via Proton Mail para Android

…

-------- Mensagem original -------- Em 26/08/2024 14:16, nrclark escreveu:

>>> I look forward to using a peer-to-peer connection between the editor and remote machines 👍 . >> >> +1 Is p2p remote mode under development? 🥰 > > Sorry my understanding but what is peer to peer remote mode? The current implementation relies on connections to Zed's servers, meaning that it can't be used on remote machines that don't have access to the internet. — Reply to this email directly, [view it on GitHub](#5347 (comment)), or [unsubscribe](https:/notifications/unsubscribe-auth/ABSTHAIT2XTDS4ON4HEPR2TZTNPG5AVCNFSM6AAAAABCJF5UZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJQGY4DKNRWHA). You are receiving this because you commented.Message ID: ***@***.***>

[gintsmurans]

+1 for working inside docker containers. We use Dev containers extension to work inside docker machines, this way we are having the same environment on every dev instance and very much the same in prod. This also speeds up file change observers quite a lot.

[nicolalandro]

I have a question, why the remote development need the login on linux?