For people with large codebases, programming on a laptop can be overwhelming. Your fans are constantly spinning, the language server is continually out of memory, and rebuilds take forever...
Now, in Zed, you can open a project on any machine you can SSH into. The UI runs fully locally to give you 120 frames per second of perfectly configured graphics, but with all the gubbins: language servers, tasks, and terminals run on the remote server where they can take advantage of cloud hardware.
It's simple to use for one-off projects:
zed ssh://my-host/~/code/zed
And you can configure longer-lived connections as you need:
For more information, see the documentation.
Building Remote Development
We've been working on our remote development feature for a while. While Zed is built for remote code editing, changing the infrastructure to support SSH required solving a whole bunch of sub-problems, from SSH connection maintenance, to how we build the remote server, to integrating the feature into everything else we have in Zed.
For the SSH connection, we use the ControlMaster setting to maintain a single connection to each host. This means that you can open new terminals and spawn tasks without having to retype your passphrase or re-authenticate. Once connected, we download the remote server for your operating system and architecture. Unlike our normal Linux builds, the remote server can be compiled with musl, which requires no dynamic linking. This lets it work on older distros (where before we ran into compatibility problems with glibc) and on modern share-nothing distros like Nix that don't have a global set of libraries to dynamically link. Once we've established the connection and installed the remote server, we initialize it as a daemon, so that when connections do drop the remote server continues running and on reconnect your language servers are still fully initialized. We also back up any unsaved changes locally, so you never lose your work.
The final piece of the puzzle was making SSH projects work with collaboration. This has been a real stress test of our collaborative syncing protocol as there can now be at least four different nodes involved in a 2-person collaboration over SSH. We had to rewrite our Project, and split it into logical chunks that could be enabled in remote and local modes depending on whether your client is the collab host, the ssh host, or the collab guest. We also have some new, fun tests that instantiate each of these roles, and our collaboration server, and ensures that the synchronization is done correctly. If you're working on a project with a friend or colleague, it should be completely transparent to them whether the project is on your laptop, or on a machine you can SSH into.
Please try it out today and, as always, leave us feedback in GitHub Issues or Discord.