Zed: a Rust code editor built for collaboration, and what it costs you to adopt

The problem Zed targets: editing that assumes one person at one machine

Most editors treat a shared session as an add-on. You install a plugin, open a tunnel, and hope the buffer stays in sync. Zed was written by people who built Atom and Tree-sitter, and the repository reflects that history: collaboration is not a plugin directory, it is a set of workspace crates. The Cargo.toml member list includes crates/collab, crates/collab_ui, crates/call, crates/channel, crates/client and crates/livekit, alongside the editor core. That layout is the argument. If you want a second cursor in your buffer to be a first-class object rather than a socket bolted onto a text widget, the project is built for you.

The audience is narrower than the download page suggests. Zed suits engineers who work in Rust, TypeScript, Go or Python on macOS, Linux or Windows and who want a native binary rather than an Electron shell. It also suits small teams that pair constantly and would rather pay for a hosted session than configure a screen-share. It is a poor fit for anyone whose workflow depends on a browser tab, because the README states plainly that web is not yet available and links a tracking discussion. It is also a poor fit for people who want their editor to be a thin, unopinionated shell. Zed ships AI crates, agent crates and edit-prediction crates in the same workspace as the text buffer, so the surface area is large by design.

How the Rust workspace is arranged, from buffer to session

The workspace is the architecture. Cargo.toml lists members such as crates/editor, crates/buffer_diff, crates/rope (the truncated listing continues well past the excerpt), crates/language, crates/project and crates/gpui. Tree-sitter parsing lives in the language layer, which is why syntax support is a build-time concern rather than a runtime download in the core. Buffer changes are diffed through buffer_diff, which is the same mechanism that feeds collaborative edits and, in a single-user session, undo history.

Above the editor sit the session crates. crates/collab holds the server-side and shared protocol types, crates/call and crates/channel cover voice and channels, and crates/client talks to the hosted service. The compose.yml file shows what a local development stack looks like: a MinIO container named blob_store on port 9000 for object storage, and a LiveKit server on ports 7880, 7881 and 7882/udp for real-time media, both mounted from local config files. That is the concrete answer to how multiplayer works. Edits flow through the collaboration protocol, media flows through LiveKit, and blobs land in S3-compatible storage.

The AI and agent surface is equally explicit. The member list includes crates/agent, crates/agent_servers, crates/agent_ui, crates/anthropic, crates/bedrock, crates/codestral, crates/deepseek, crates/copilot, crates/copilot_chat, crates/context_server and crates/edit_prediction. Provider-specific crates sit next to a generic cloud_llm_client, which suggests the intent is to keep each vendor's quirks contained. Whether that abstraction holds is not something the repository files reveal.

Installing Zed and opening a real project

The README does not give a command-line install line. It says that on macOS, Linux and Windows you can download Zed directly from zed.dev/download, or install it via your local package manager, with per-platform links to the docs for macOS, Linux and Windows. So the first step is a browser, not a terminal, unless you already know your package manager's name for the package. One of the related search phrases people use is "winget zed industries.zed", which is the Windows package manager route, but the README itself does not spell the identifier out, so check your package manager's own listing rather than trusting a search result.

If you would rather build from source, the README points at three documents: docs/src/development/macos.md, docs/src/development/linux.md and docs/src/development/windows.md. The repository also carries rust-toolchain.toml, so the compiler version is pinned by the project rather than chosen by you. A build looks like this:

git clone https://github.com/zed-industries/zed
cd zed
cargo build --release

That last command is the standard Cargo invocation for a workspace; the platform-specific docs are the authority on any extra steps, and on Linux you should expect them to mention system libraries. Do not treat the three lines above as a substitute for those documents.

For a first real use, open a repository you already know and check two things that are specific to Zed. First, whether your language's tree-sitter grammar is present, since parsing is compiled in. Second, whether the collaboration panel connects, because that path depends on the service configuration shown in compose.yml. If you are running the stack yourself, the two services to bring up are the blob store on port 9000 and LiveKit on 7880, 7881 and 7882/udp:

docker compose up blob_store livekit_server

The compose file mounts ./livekit.yaml into the container and expects ./.blob_store as the data volume, so both must exist before the command does anything useful.

The GPL-3.0-or-later licence is the constraint most teams miss

The README states that Zed source code is licensed primarily under GPL-3.0-or-later, with Apache-2.0 components where marked. The repository confirms this with two files at the top level: LICENSE-GPL and LICENSE-APACHE. The description field for the repository reports no licence, which is a metadata gap rather than an accurate summary; the README and the licence files are the reliable source.

For individual users this changes nothing. For companies that embed an editor into a product, it changes a lot, and the project enforces it in CI. The README explains that third-party dependency licence information must be correctly provided for CI to pass, and that cargo-about is used to automate compliance. It then walks through three failure modes: a crate you created showing "no license specified", which is fixed by adding publish = false under [package] in that crate's Cargo.toml; a "failed to satisfy license requirements" error for a dependency, which is fixed by adding the dependency's SPDX identifier to the accepted array in script/licenses/zed-licenses.toml after verifying the licence is acceptable; and a missing licence, which is fixed with a clarification field in the same file. The README explicitly says to ask a lawyer if you are unsure. That instruction is the project telling you the compliance file is a legal artifact, not a build detail.

There is also a commercial dimension. The README says Zed is developed by Zed Industries, Inc., a for-profit company, and that GitHub Sponsors contributions go directly to the company as general revenue with no perks or entitlements. Anyone asking how the project is funded has the answer in the README itself, and it is not a foundation model.

Where Zed is the wrong tool

The clearest limitation is stated by the project: web is not yet available, with a tracking discussion linked from the README. If your workflow depends on opening the editor in a browser, on a locked-down machine, or inside a cloud development environment you do not control, Zed does not solve that today. There is no partial answer in the repository.

The second limitation is the release cadence. The most recent releases are v1.18.0-pre and v1.17.2, both dated 2026-08-26, with v1.17.2-pre the day before. Pre-release builds are published alongside stable ones, and the repository's last push is the same day as the v1.18.0-pre tag. A project that tags pre-releases this frequently is telling you the stable line moves quickly. If your team pins editor versions and validates upgrades on a schedule, budget for that.

The third is scope. The workspace includes agent, agent_ui, agent_servers, agent_settings, agent_skills, copilot, copilot_chat, anthropic, bedrock, codestral, deepseek and edit_prediction crates. That is a large amount of code dedicated to features some engineers actively do not want in an editor. There is no documented way to build a stripped-down Zed without those crates, so if minimalism is your reason for leaving another editor, Zed may not be the destination.

Finally, the collaboration path has an operational cost that solo users never see. Running the stack yourself means MinIO on port 9000, LiveKit on 7880, 7881 and 7882/udp, a livekit.yaml, and a .blob_store volume. That is a real service to operate, not a checkbox.

How Zed differs from VS Code in approach

The comparison people search for is Zed versus VS Code, and the difference is structural rather than a feature list. VS Code is an Electron application whose extension host is a separate process, and whose collaboration story has historically been a separate service or a third-party extension. Zed is a native Rust binary, and its collaboration code lives in the same workspace as its editor code: crates/collab, crates/collab_ui, crates/call, crates/channel and crates/client are siblings of crates/editor, not plugins. The practical consequence is that a shared session is a core concept with its own protocol crates, which is why the project can also describe itself as multiplayer in its own one-line description.

The second difference is parsing. Tree-sitter is not a dependency Zed adopted; the README describes Zed as coming from the creators of Tree-sitter. Syntax support is compiled into the language layer rather than fetched at runtime, which trades flexibility for predictability. VS Code's extension marketplace model lets you add language support without rebuilding the editor. Zed's model means the set of grammars you have is the set that was built.

The third difference is licensing posture. VS Code ships under an MIT-licensed source with a separately licensed product build. Zed's source is primarily GPL-3.0-or-later with Apache-2.0 components where marked, and the project runs cargo-about in CI to enforce dependency licence compliance. If you are choosing between them for a commercial product that embeds an editor, that distinction belongs in the decision, not in an appendix.

Maintenance, upgrades and what to check before you standardise

The repository is not archived, and the last push was on 2026-08-26. Releases in the same window include v1.17.2 and v1.18.0-pre. That is a project shipping continuously, and the presence of crates/auto_update, crates/auto_update_helper and crates/auto_update_ui in the workspace shows that updating is an in-product feature rather than a manual reinstall.

Upgrade cost is where a workspace this size matters. Cargo.lock is committed, rust-toolchain.toml pins the compiler, and the licence file at script/licenses/zed-licenses.toml must be updated whenever a new dependency arrives with a licence not yet in the accepted array. If you build from source, every dependency bump is a potential CI failure with a licence error attached. If you install from a package manager or the download page, that work is the maintainers' problem, not yours.

The licence question deserves a straight answer rather than a hedge. GPL-3.0-or-later means that if you distribute a modified Zed, the terms of that licence apply to your distribution. The Apache-2.0 components marked in the source are the exception. The README directs contributors to ask a lawyer when a dependency's licence is unclear, and that is the correct posture for anyone planning to redistribute rather than use. Reading LICENSE-GPL and script/licenses/zed-licenses.toml before you build a product around the editor is cheaper than discovering the constraint after.

Editorial conclusion

Adopt Zed if you want a native editor whose collaboration model is part of the core rather than a plugin, and if you are comfortable with a GPL-3.0-or-later codebase that ships pre-release builds alongside stable ones. Do not adopt it if you need a browser-based editor, since the README lists web as unavailable, or if you need to vendor the editor into a proprietary product without reviewing the Apache-2.0 exceptions marked in the source. Before committing a team, verify three things: that your platform appears on the download page or in your package manager, that the collaboration service you intend to run matches the ports in compose.yml, and that your dependency policy can accommodate what script/licenses/zed-licenses.toml accepts.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes