Check out our contribution guide to learn how you can contribute to Zed.
You can obtain the release build via the download page.
We currently don't offer a convenient way for users to log out of GitHub from within Zed. If you'd like to log out, follow these steps:
Keychain Access applicationlogin keychain, find and delete the https://zed.dev entryWhen you receive an invite to test a feature in private beta, your user record in our database is registered to a particular feature flag.
During the beta period, you must log in via the Sign in button in the upper right corner of Zed, which authenticates you through GitHub.
A network connection is required when opening Zed during private beta testing, as Zed sends a request to our server to verify your access.
If you are not associated with the feature flag, UI elements related to the feature will be hidden.
For features in private beta, we prioritize updates to the preview channel. During a private beta, we accelerate our preview patch release schedule to roughly a minimum of one update per day, including all the latest additions and fixes since the previous preview patch build.
Some users have noticed that, in certain cases, they can access private beta features on the stable channel. This occurs because private betas are not tied to a particular release channel, but rather scoped to specific users. Depending on the duration of the beta testing period, code related to the feature will gradually make its way into stable builds, as our minor update release cycle remains the same. While we recommend testing private beta features on the preview channel to access the most recent updates and improvements, you can use older preview patch builds, or potentially stable builds, if you don't have access to preview—such as when using third-party packages maintained by developers who don't ship Zed preview. However, be aware that you will be working with outdated versions of the feature.
Some deep-divers have found they can enable feature flags by changing a small snippet of code and compiling Zed from source; we'll leave digging up that code as an exercise for the reader.
Yes! Zed currently supports various types of extensions, with support for deeper extension APIs planned.
Yes! Zed (the editor) is free for all to use, with binaries for macOS and popular Linux distributions readily available for download.
Yes! Zed is open source!
Check out the announcement post for more details.
Nightly: Built daily from the main branch with the latest features.
It has not gone through any testing and may have stability issues.
Nightly isn't public.
Preview: Our weekly release with recent features that have undergone initial internal testing.
More stable than Nightly, but potentially less stable than Stable.
Preview may contain experimental functionality and might experience reverts of recently-added features.
You should anticipate experiencing a higher frequency of updates if you are on Preview.
If the frequency of these updates is distracting for you, you can disable automatic update checks via "auto_update": false and run manual update checks via command palette > auto update: check.
Stable: Our most production-ready version that has been tested in Preview for a week.
This release is recommended for those relying on Zed for mission-critical work.
On a typical release Wednesday, we follow these steps:
Promote last week's preview to stable
v0.180.x) is promoted to stable by taking the most recent preview tag and creating a new tag on the latest commit without the -pre suffix (e.g., v0.180.1-pre → v0.180.1)Create a new preview branch
main branch-pre suffix is added to the latest commit (e.g., v0.181.0-pre) to mark the branch as previewPrepare main for the next cycle
main is bumped to the next minor versionDuring the week between minor releases, we may cherry-pick important fixes to the preview or stable branches and release new patches. The frequency of preview patch updates will increase during periods where we are conducting private beta testing of new features.
Fun fact: We like to celebrate release Wednesday by calling it "Zednesday." Don't worry, we don't know how to pronounce it either.
While we are committed to building a stable, professional-grade editor, you'll likely run into bugs and pain points throughout the beta phase. Additionally, Zed may not support all languages you use and may not be available for your preferred operating system. What we can confidently say is that we are working hard to bring you the features, support, and stability you need to make Zed your homebase editor for building great software.
As diligent as we try to be with every line of code we write, human error is inevitable, especially during periods of rapid development. Make sure to properly backup any code you are working on in Zed to protect yourself from potential catastrophic events. While we believe Zed to be safe to use, it is always advisable to err on the side of caution in these early stages.
Zed is a large, complex codebase. While we work to ship a steady stream of bug fixes in our releases each week, periodically, we conduct what we refer to as "Quality Week." During this time, we halt work on feature additions and pivot to working solely on user pain points within Zed. Prior to Quality Week, the community team spends time curating a project board of issues. We focus on finding issues that try to balance a small amount of work with a potentially large impact. We prioritize reducing cases where Zed can panic. The overall goal of Quality Week is to ship a more stable, refined Zed.
Currently, we officially support macOS and popular Linux distributions. Community efforts are gradually enabling Windows support, which can be compiled from source. We will provide binaries when we are confident the user experience there is good.
Subscribe to our platform-tracking issues to receive updates on our progress with other platforms.
Language servers are stored at ~/Library/Application Support/Zed/languages. See language servers for more information.
The settings.json can be found at ~/.config/zed/settings.json. See configuring Zed for more information.
The keymap.json can be found at ~/.config/zed/keymap.json. See key bindings for more information.
The last 1000 lines of Zed's log file can be opened in a Zed buffer by searching for zed: open log within the command palette. If you need to view more history, you can find the full log file at ~/Library/Logs/Zed/Zed.log.
Workspace data is stored in SQLite databases located at ~/Library/Application Support/Zed/db. There is a database for each release channel of Zed installed:
0-nightly0-preview0-stableWe stopped working on Atom and started on the foundations of Zed when we realized that we couldn't shape Atom into our vision for the ultimate editor. While we respect and appreciate the innovations brought by Visual Studio Code, we never found ourselves loving it enough to give up on the dream. Ultimately, we think we're going to add the most value to the world by creating something new. It's also a lot more fun.
We liked the simplicity of the name "Ed", but we didn't want to shadow ed, the editor in which the Unix was originally developed. We liked how adding the letter "Z" formed the word "Zed", which is also the name for the letter "Z" in some dialects of English. As the last letter of the alphabet, it seemed like an appropriate name for the ultimate editor we are building.
This isn't something we're worrying too much about right now, but we anticipate adding enterprise-focused features eventually.
If you have any questions about your Zed Pro subscription, feel free to send us an email at [email protected]. Make sure to write us from the email account associated with your Stripe/Zed Pro subscription.
For information on plans, billing, and models offered through Zed Pro, see the documentation, or visit our pricing page.
When we started on Zed, the Rust UI framework space was much younger. In absence of a mature solution that met our exact needs, the simplest path for us was to build it ourselves. We're too far into things now to change at this point. We also like our framework. It's working well for us.
Yes. All interactions between collaborators are proxied through our servers. This ensures much greater reliability than peer to peer connections. It also allows us to store a small amount of server-side state about each shared project, which makes it faster for new collaborators to join the project.
user identification - When you're not signed in, we don't send anything to our servers. When you do sign in, we establish a WebSocket connection to one of our servers that's associated with your Zed account, but we don't send any other data.
project metadata - When you're in a call and you share one of your projects, we send to our servers the name of that project, and the relative paths of all of the files in that project. We also send the names of any language servers that are running for that project, and their status messages. Note that we only store the relative file paths and the language server statuses of the shared project on our server; all other data stays on the host and is proxied through our servers when requested by a guest.
file contents - When you're sharing a project in a call, your collaborators can open any file in your project, as well as files that are returned by your language servers from requests like 'go to definition' and 'find all references'. When they do open these files, we send them to our servers, which forward them to the collaborator. File contents are never stored on our servers.
Zed collects and sends its own crash reports to our server so that we can quickly get a pulse on what users are experiencing and begin implementing fixes to these issues. We also collect user telemetry to help us understand how Zed is being used. The collection of crash reports and user telemetry can be be disabled via the settings. See Telemetry in Zed.
Our EULA can be found here.
Check our jobs listings.
We generate revenue through optional Zed Pro subscriptions.
Yes. We sold equity in our company to investors to enable ourselves to give Zed the focus it deserves.