Atom has been frozen since GitHub sunset it in December 2022, and nothing has patched it since. If you are still opening it out of habit in September 2026, you are running an editor with no security updates, no plugin registry maintenance from its original owner, and no path forward. This tutorial walks through migrating your workflow to Zed, the native, Rust-based editor built by several of Atom’s original creators, currently shipping stable builds at version 1.20.2 (released September 17, 2026). We will cover installation, settings and keybinding ports, extension mapping, Git and project search workflows, and the AI agent panel that Zed ships out of the box.
This is not the Atom-to-Pulsar path. Pulsar keeps Atom’s Electron shell and package format alive for people who want a drop-in continuation. Zed takes a different route entirely: a rebuilt-from-scratch native application, GPU-accelerated rendering, and a collaboration layer that its founders describe as an eventual replacement for pull requests. If your priority is raw speed and you are willing to rebuild your package list rather than reuse it wholesale, this guide is for you.
Why Atom users are moving to Zed in 2026
GitHub announced Atom’s retirement in mid-2022 and shut down new releases that December. By 2026, the editor is effectively archived: no security patches, no listing on GitHub’s own product pages, and an ecosystem that has largely scattered to VS Code, Pulsar, and native alternatives. Running Atom as a daily driver on a machine connected to the internet is a real exposure, since any dependency vulnerability discovered in its bundled Electron or Node.js runtime will never be fixed upstream.
Two migration paths have emerged. Pulsar, the community fork, keeps Atom’s package format and UI paradigm, trading some performance for familiarity. Zed goes the opposite direction. It was built from the ground up in Rust by Nathan Sobo and other engineers who worked on Atom and GitHub’s editor tooling, and it markets itself bluntly as “your last next editor.” Where Pulsar’s goal is continuity, Zed’s goal is a clean break: sub-second startup, GPU-accelerated text rendering, and built-in real-time collaboration instead of bolted-on extensions.
The timing also matters. Zed’s release cadence has been aggressive through 2026. The stable channel moved from 1.18.0 in early September to 1.20.2 by September 17, shipping call hierarchy support, multi-select in the Git panel, automatic language detection for untitled buffers, inline C/C++ debugging through CodeLLDB and GDB, and an expanded roster of AI model integrations. The team also opened a public beta for Delta, a code-review tool it positions as a long-term alternative to GitHub pull requests. None of that exists in Atom’s frozen codebase, and none of it is coming to Pulsar’s Electron-based fork in the same form.
There is also a practical cost argument that rarely gets mentioned in migration write-ups. Teams still standardized on Atom are quietly absorbing risk every time a contractor or new hire opens an unpatched Electron shell on a corporate network. Security teams that have already flagged Atom internally tend to treat this migration less as a developer-experience upgrade and more as a compliance item, especially at companies that run SOC 2 or ISO 27001 audits where “actively maintained tooling” is a checklist line item. Framing the move that way tends to get budget approval faster than pitching it purely on startup speed.
Prerequisites and versions
Before starting, confirm you have the following. Version numbers below reflect what shipped as of September 19, 2026.
- An existing Atom or Pulsar installation with your
.atomconfiguration folder intact (used for exporting settings and keymaps) - Zed 1.20.2 (stable channel) or later – macOS 12+, a recent 64-bit Linux distribution, or Windows 10/11 64-bit
- Git 2.30 or newer, already configured with your name, email, and credential helper
- Node.js 18 LTS or newer, only if you use JavaScript/TypeScript language servers
- Roughly 400 MB of free disk space for the Zed binary and its bundled language servers
- A GitHub or GitLab account, plus a SuperGrok, OpenAI, or Anthropic account if you plan to use Zed’s built-in AI agent panel
- 15 to 45 minutes, depending on how many custom packages and keybindings you are porting over
You do not need admin rights on most systems; Zed installs to a user-level directory by default on macOS and Linux. On Windows, the installer requests standard user permissions unless you choose a system-wide install.
Step 1: Back up your Atom configuration before touching anything
Atom stores everything in a single hidden folder. Copy it somewhere safe before you install anything new, since this is the source material for every later step in this guide.
# macOS / Linux
cp -r ~/.atom ~/.atom-backup-2026-09-19
# Windows (PowerShell)
Copy-Item -Recurse "$env:USERPROFILE.atom" "$env:USERPROFILE.atom-backup-2026-09-19"Inside that folder, the three files you actually need are config.cson (settings), keymap.cson (custom keybindings), and your installed package list. Everything else, cached indexes, compiled packages, state databases, can be discarded.
# Export your installed package list for reference
apm list --installed --bare > ~/atom-packages-list.txt
cat ~/atom-packages-list.txtStep 2: Install Zed
Zed publishes native installers for macOS, Linux, and Windows from its official download page. On macOS and Linux, the fastest path is the shell installer.
# macOS / Linux - installs the current stable release (1.20.2 as of Sept 17, 2026)
curl -f https://zed.dev/install.sh | sh
# Verify the install and version
zed --versionOn Windows, download the .exe installer directly from the Zed download page and run it. There is no separate CLI shim step needed; the installer registers zed in your PATH automatically on all three platforms.
If you want to test bleeding-edge features before they hit stable, Zed also maintains a preview channel that updates on a near-daily cadence, the mid-September 2026 preview builds (1.21.0) already include faster syntax-highlighted rendering and a language server command picker that has not reached stable yet. For a daily-driver replacement of Atom, stick to the stable channel; switch to preview only once you are comfortable with Zed’s basics.
Step 3: Open your first project and understand Zed’s layout
Launch Zed and open the same project folder you had open in Atom.
zed ~/projects/my-appThe layout will feel familiar if you came from Atom: a file tree on the left, tabs across the top, and a status bar at the bottom. The differences show up in the details. Zed’s command palette (Cmd+Shift+P on macOS, Ctrl+Shift+P on Windows/Linux) mirrors Atom’s, and most muscle memory for opening files, switching panes, and running commands transfers directly. What is new is the AI panel on the right edge and a collaboration icon in the top bar for joining or starting a live session with another developer.
Step 4: Port your settings from config.cson to settings.json
Atom used CSON (CoffeeScript Object Notation); Zed uses plain JSON. Open Zed’s settings file with the command palette (search “Open Settings”) or directly:
# Zed settings file locations
# macOS/Linux: ~/.config/zed/settings.json
# Windows: %APPDATA%Zedsettings.json
zed ~/.config/zed/settings.jsonBelow is a mapping of the Atom settings developers port most often, translated into Zed’s JSON schema.
| Atom setting (config.cson) | Zed equivalent (settings.json) | Notes |
|---|---|---|
| editor.fontSize | “buffer_font_size” | Same numeric value, no unit needed |
| editor.fontFamily | “buffer_font_family” | Zed ships its own default font, Zed Mono |
| editor.tabLength | “tab_size” | Can be set per-language in a “languages” block |
| editor.softWrap | “soft_wrap”: “editor_width” | Also accepts “none” or “preferred_line_length” |
| core.themes | “theme” | Zed bundles its own theme set; most Atom themes need manual recreation |
| editor.showInvisibles | “show_whitespaces”: “all” | Accepts “selection”, “all”, or “none” |
| core.autoSave | “autosave”: “on_focus_change” | Also supports “after_delay” with a millisecond value |
A minimal starter settings.json that covers the settings most Atom refugees ask for looks like this:
{
"buffer_font_size": 14,
"buffer_font_family": "JetBrains Mono",
"tab_size": 2,
"soft_wrap": "editor_width",
"theme": "One Dark",
"show_whitespaces": "selection",
"autosave": "on_focus_change",
"format_on_save": "on",
"git": {
"inline_blame": { "enabled": true }
}
}Step 5: Recreate your keybindings
Open your old ~/.atom-backup-2026-09-19/keymap.cson alongside Zed’s keymap file (accessible via the command palette: “Open Keymap”). Zed uses a JSON array of context/bindings objects instead of Atom’s CSON selector blocks, but the concept, a CSS-like selector scoping a key combination to a context, is the same.
// Zed keymap.json - example porting a common Atom custom binding
[
{
"context": "Editor",
"bindings": {
"cmd-k cmd-d": "editor::DuplicateLineDown",
"cmd-shift-l": "editor::SelectLine",
"ctrl-g": "editor::ToggleGitBlame"
}
},
{
"context": "Workspace",
"bindings": {
"cmd-shift-e": "project_panel::ToggleFocus"
}
}
]Zed’s default keymap already covers the vast majority of what most Atom users had rebound manually, multi-cursor editing, line duplication, and word-jump navigation are all native. Expect to port fewer than a dozen custom bindings for a typical setup rather than replicate an entire file.
Step 6: Map your Atom packages to Zed extensions or built-ins
This is the step that takes the longest, because Zed does not run Atom packages. Its extension model is different, and many features that required a third-party Atom package are simply built into Zed’s core. Check the table below against your atom-packages-list.txt from Step 1 before assuming you need to hunt for a replacement.
| Common Atom package | Zed replacement | Built-in or extension? |
|---|---|---|
| minimap | Not present; Zed’s scrollbar shows a code overview instead | Built-in equivalent |
| atom-beautify | Language server formatters (Prettier, rustfmt, gofmt, etc.) | Built-in via “format_on_save” |
| git-plus / git-control | Native Git panel with multi-select staging | Built-in |
| autocomplete-plus | Language Server Protocol completions | Built-in |
| platformio-ide-terminal | Integrated terminal (Cmd+`) | Built-in |
| language-* packages (syntax highlighting) | Tree-sitter grammars | Built-in for most common languages |
| linter / linter-eslint | ESLint via language server integration | Extension (search “eslint” in extensions panel) |
| docblockr | Language-specific snippet extensions | Extension, varies by language |
| emmet | Native “wrap with abbreviation” support | Built-in as of the 1.20.x cycle |
If your team is running a similar transition on other tools, the same rebuild-vs-carry-over tradeoff shows up in a VS Code to Cursor migration. For anything not covered natively, open the extensions panel with the command palette (“zed: extensions”) and search by name. Zed’s extension registry is smaller than Atom’s package registry ever was, so budget time to find the closest match rather than an exact one. If a package is truly irreplaceable, that is a legitimate reason to keep Pulsar around for that specific project instead of forcing a full switch.
Step 7: Set up language servers for your stack
Zed auto-detects and prompts to install language servers the first time you open a file of a given type. For most languages this is a one-click install. To pre-configure specific servers or pass custom arguments, add an “lsp” block to your settings file.
{
"lsp": {
"rust-analyzer": {
"initialization_options": {
"check": { "command": "clippy" }
}
},
"typescript-language-server": {
"initialization_options": {
"preferences": { "importModuleSpecifierPreference": "relative" }
}
}
}
}C and C++ developers get an added benefit here that Atom never had natively: inline debugger values through CodeLLDB and GDB adapters, shipped in Zed’s 1.18.0 cycle in early September 2026. If you were leaning on a separate Atom debugging package before, this replaces it directly.
Step 8: Configure the Git panel and inline blame
Zed’s Git integration is native rather than package-based. The panel supports multi-select staging (added in the 1.19.x cycle), inline blame annotations, and a diff view without leaving the editor.
{
"git": {
"git_gutter": "tracked_files",
"inline_blame": {
"enabled": true,
"delay_ms": 600
}
}
}Open the panel with Cmd+Shift+G (macOS) or Ctrl+Shift+G (Windows/Linux). If you relied on git-plus for staging hunks in Atom, this replaces essentially all of that functionality without an extension.
Step 9: Set up project-wide search and the file finder
Zed’s project search now runs “search on type” by default as of the 1.19.x release, meaning results populate as you type rather than requiring an Enter press. The file finder (Cmd+P) also persists its history across sessions as of the September 2026 stable builds, a small but noticeable quality-of-life change from Atom’s fuzzy finder, which reset every restart.
# Command palette actions worth binding to muscle memory
Cmd+P - Fuzzy file finder (persists history)
Cmd+Shift+F - Project-wide search
Cmd+Shift+O - Go to symbol in file
Cmd+T - Go to symbol in projectStep 10: Connect the AI agent panel (optional but relevant to 2026 workflows)
Zed ships a native AI agent panel that Atom never had any equivalent for. As of the September 2026 releases, the panel supports multiple providers including GPT-5.6 via Amazon Bedrock with a 1-million-token context window, Gemini 3.5 Flash-Lite, and updated Grok models through direct SuperGrok sign-in, added in the mid-September preview cycle and rolling into stable shortly after. Configuration lives under a dedicated “agent” block in settings.
{
"agent": {
"default_model": {
"provider": "anthropic",
"model": "claude"
},
"prevent_idle_sleep": true
}
}The core editor and its collaboration features remain free regardless of which AI provider you pick; heavier agent usage on some providers ties into a paid Zed Pro tier. If you do not want AI features at all, leave the panel closed, nothing about Zed’s core editing experience depends on it.
Step 11: Try real-time collaboration and Delta
This is the feature with no Atom analog at all. Zed’s collaboration mode lets a second developer join your buffer in real time, see your cursor, and co-edit live, similar in spirit to what Google Docs does for text. In September 2026, Zed also opened public beta access to Delta, a tool the team describes as a first step toward replacing pull request workflows entirely, integrated directly into the editor as a review surface rather than a separate web app.
To start a session, click the collaboration icon in the top bar and choose “Share Project.” Anyone with the generated link and appropriate permissions can join instantly, no separate screen-share tool required.
Step 12: Benchmark your new setup against your old Atom workflow
Before declaring the migration done, do a side-by-side sanity check. Time a cold start and open your largest project file in both editors if you still have Atom installed for comparison.
# Rough cold-start timing on macOS/Linux
time zed ~/projects/my-app
# vs, if Atom is still installed
time atom ~/projects/my-appIndependent 2026 performance comparisons have shown Zed’s native, Rust-based architecture delivering sub-second startup on identical hardware where Electron-based tools, Atom and its forks included, land in a multi-second range. That gap tends to compound across a workday of repeated project switches, and it is the single biggest practical reason developers cite for finishing the migration rather than reverting out of habit.
Common pitfalls when migrating from Atom to Zed
Most migration friction comes from a handful of repeatable mistakes. Here is what trips people up most often.
- Assuming CSON syntax works in Zed. Zed’s config is plain JSON. Pasting a CSON block from Atom directly into settings.json will fail to parse; convert key-value pairs manually or with a CSON-to-JSON converter first.
- Expecting a one-to-one package match. Some Atom packages have no Zed equivalent yet. Check the built-ins table in Step 6 before spending time hunting for an extension that duplicates functionality Zed already has natively.
- Skipping the language server install prompt. If you dismiss Zed’s first-run prompt to install a language server, you lose autocomplete and diagnostics for that language until you manually trigger the install again from the command palette.
- Porting every keybinding instead of learning the defaults first. Many custom Atom bindings existed only because Atom lacked the feature natively. Test Zed’s defaults for a day before re-adding bindings you may no longer need.
- Ignoring the preview channel confusion. Installing both the stable and preview builds side by side without renaming the app can cause settings file conflicts on some Linux distributions. Stick to one channel per machine unless you know the config paths differ.
- Not backing up .atom before uninstalling. Once Atom is removed, recovering a forgotten custom snippet or keybinding becomes far harder. Complete Step 1 before Step 2, not after.
- Assuming themes carry over visually. Zed bundles its own theme set and does not read Atom’s LESS/CSS-based theme packages. A theme with the same name in both editors can look noticeably different.
- Forgetting project-specific .atom settings. If any project had a local override file, check for it separately; Zed’s project-level settings live in a
.zed/settings.jsonfile inside the repo, not a hidden dotfolder at the project root with Atom’s old naming.
Zed vs Pulsar vs staying on Atom: which fits your workflow
Not every Atom user should migrate to Zed. The decision comes down to how much you value raw speed and native AI/collaboration tooling versus how much of your workflow depends on Atom’s specific package ecosystem.
| Factor | Zed 1.20.2 | Pulsar (Atom fork) | Staying on Atom |
|---|---|---|---|
| Security patches | Active, weekly-plus release cadence | Active, community-maintained | None since December 2022 |
| Architecture | Native, Rust, GPU-accelerated | Electron (inherited from Atom) | Electron, frozen version |
| Package/extension compatibility | New extension model, not package-compatible | Source-compatible with most Atom packages | Full compatibility (with itself) |
| Built-in AI agent panel | Yes – multi-provider (GPT, Gemini, Grok, Claude) | No native equivalent | No |
| Real-time collaboration | Built-in, plus Delta beta for code review | Not built-in | Not built-in |
| Startup time (typical) | Sub-second on modern hardware | Multi-second (Electron) | Multi-second (Electron) |
| Best for | Developers prioritizing speed and new tooling over legacy packages | Developers who need specific Atom packages preserved | Nobody, as a daily driver, in 2026 |
If your team leans heavily on a specific Atom package with no Zed equivalent and no time to rebuild that workflow, Pulsar remains the lower-friction choice for now. If you are optimizing for speed, native Git and AI tooling, and you are willing to spend an afternoon rebuilding your extension list, Zed is the stronger long-term bet, and its release velocity through 2026 suggests that gap will only widen.
Rolling out Zed across a whole team
Migrating one developer is a 30-minute task. Migrating a team of ten or more off Atom takes coordination, mostly because you want everyone landing on the same baseline configuration rather than ten slightly different settings.json files drifting apart over time. The cleanest approach is treating your Zed configuration the same way you treat your linter config or your CI pipeline definition: as a versioned file that lives in the repository, not in each developer’s home directory.
Start by picking one senior developer’s already-migrated settings.json and keymap.json as the baseline, then commit a trimmed-down, team-relevant version into a .zed/ folder at the root of your primary repository. Anything that should apply to every contributor, tab size, formatter-on-save behavior, and language server initialization options, belongs there. Anything personal, font size, theme, individual keybinding preferences, stays in each developer’s local settings.json outside the repo.
# Suggested repo structure for a shared Zed config
.zed/
settings.json # team-wide formatting and LSP rules, committed to git
keymap.json # optional, only if the team wants shared bindings
# Onboarding checklist for a new hire replacing Atom
1. curl -f https://zed.dev/install.sh | sh
2. Clone the repo - .zed/settings.json applies automatically
3. Open the project once to trigger language server auto-install
4. Confirm `zed --version` reports 1.20.2 or newer
5. Point the AI agent panel at the team's approved provider accountFor teams that were running a shared Atom package list through a config-sync style package, the equivalent workflow in Zed is simpler because so much of what used to require a package is now a plain JSON setting. That said, expect a short adjustment period. The biggest source of friction during team rollouts is not technical, it is habit: developers who have used Atom’s fuzzy finder and file tree for years reach for the old keyboard shortcuts automatically. Budget a week of parallel availability (keep Atom or Pulsar installed as a fallback) before uninstalling it entirely across a team, rather than forcing a hard cutover on a single day.
Performance in real projects, not just synthetic benchmarks
Startup time is the headline number most comparisons lead with, but it is not the only place the architectural difference between Zed and Atom shows up. Because Zed renders text through the GPU rather than through a Chromium layout engine, the gap widens further on tasks that stress the editor rather than just open it: scrolling through a multi-thousand-line log file, running project-wide search across a large monorepo, or holding multiple split panes open at once while a language server indexes in the background.
Memory behavior differs too. Atom’s Electron shell keeps a full Chromium renderer process resident even for small projects, which is part of why idle memory usage climbs steadily the longer a session stays open with multiple tabs. Zed’s native process model tends to hold memory usage flatter across a session, since it is not carrying a browser engine’s overhead for basic text rendering. None of this means Zed is unconditionally lighter in every scenario, a very large project with many active language servers running simultaneously will still consume meaningful memory, but the baseline cost of simply having the editor open is measurably lower.
The practical takeaway for anyone migrating a large codebase: do not judge Zed purely on the first file you open. Give it a full day with your actual project open, including your normal split-pane layout, your usual number of running language servers, and your typical search patterns, before deciding whether the performance difference matches what the benchmarks promised.
Troubleshooting common migration issues
The following issues come up most often during and immediately after an Atom-to-Zed migration.
- Zed will not launch after install on Linux. Confirm your distribution has a recent enough GPU driver; Zed’s GPU-accelerated rendering requires OpenGL/Vulkan support that older or headless VM configurations sometimes lack. Try launching with
zed --foregroundto see the error output directly. - Settings.json changes are not taking effect. Check for a JSON syntax error; unlike Atom’s more forgiving CSON parser, Zed will silently ignore a settings file with a trailing comma or unescaped character. Use the command palette’s “Open Settings” action, which validates the file on save.
- A language server never finishes installing. Run the command palette action “zed: language server logs” to see the download or initialization error. Corporate proxies and VPNs are the most common cause of a stuck install.
- Git panel shows no changes on a repo that clearly has them. Confirm the folder you opened is the actual Git root, not a subdirectory. Zed’s Git integration, like most editors, expects the
.gitfolder at or above the opened path. - Keybindings behave differently than expected. Check for a conflict between your custom keymap.json entry and a default binding using the same combination. Zed’s keymap file supports a “context” scope specifically to avoid this, but a global binding placed without a context can still override an editor-scoped default.
- AI agent panel shows an authentication error. Provider tokens expire independently of your Zed installation. Re-authenticate through the agent panel’s provider settings rather than editing the settings.json token field directly, since some providers use short-lived OAuth tokens that cannot be pasted manually.
- Fonts render inconsistently between machines. Zed’s default font, Zed Mono, ships bundled, but a custom font specified in “buffer_font_family” must be installed at the OS level on every machine; Zed does not embed custom fonts into its settings sync.
- Extensions panel shows no results for a known package name. Zed’s extension registry uses different naming conventions than Atom’s package registry. Search by the underlying tool name (for example “eslint” rather than “linter-eslint”) rather than the exact Atom package name.
- Project search feels slower on a very large monorepo. Add a .gitignore-aware exclude list to your project’s
.zed/settings.jsonto keep search scoped away from build artifacts and node_modules, which Zed indexes by default unless explicitly excluded.
Advanced tips for power users
Once the basic migration is stable, a few advanced settings are worth exploring specifically because they have no Atom equivalent at all.
- Use per-language settings blocks instead of one global config. Zed lets you nest a “languages” object in settings.json to override tab size, formatter, and font per file type, which is cleaner than Atom’s approach of relying on separate packages per language.
- Enable “format_on_save”: “on” combined with a project-level .zed/settings.json to enforce consistent formatting across a team without relying on a pre-commit hook.
- Pair the inline Git blame feature with the diff view to review your own recent changes before a commit, instead of shelling out to a separate git diff command.
- If you manage multiple client codebases, keep provider-specific AI agent settings scoped to project-level .zed/settings.json rather than global settings, so a client’s preferred model does not leak into unrelated projects.
- Run Zed’s preview channel on a secondary machine only, so you can test upcoming features like the 1.21.0 rendering improvements without risking your primary daily-driver stability.
Zed sits within a broader shift in developer tooling toward native performance and built-in AI, a trend also visible in Python’s tooling stack with uv’s move past Poetry and in linting with Ruff’s replacement of Black and Flake8.
Building a small custom extension for what Zed doesn’t cover
If you were one of the developers who wrote your own internal Atom package, a snippet expander, a custom linter wrapper, an internal API doc lookup, Zed’s extension system is different enough that you cannot port the JavaScript directly. Zed extensions are built in Rust and compiled to WebAssembly, which sounds heavier than Atom’s CoffeeScript-friendly packages but is often less code in practice for anything that wraps an existing command-line tool or language server.
The fastest path to a working extension is scaffolding one from Zed’s official extension template rather than starting from an empty Cargo project. This gets you a working extension.toml manifest and a stub src/lib.rs file that already implements the extension trait Zed expects.
# Clone the official extension template
git clone https://github.com/zed-industries/zed-extension-template my-extension
cd my-extension
# extension.toml - minimal manifest for a language-server-wrapping extension
cat extension.toml# extension.toml
id = "my-internal-tool"
name = "My Internal Tool"
version = "0.1.0"
schema_version = 1
authors = ["you@example.com"]
description = "Wraps our internal CLI as a Zed language server integration"
[language_servers.my-internal-tool]
name = "My Internal Tool LSP"
languages = ["Python"]For most internal tooling, you are not writing a language server from scratch, you are pointing Zed at one that already exists (many internal linters and formatters can be wrapped with the Language Server Protocol relatively quickly using existing libraries in Python, Go, or Rust). Once built, load it locally for testing with zed: install dev extension from the command palette, pointed at your extension’s local directory, before publishing it to Zed’s registry for the rest of the team to install.
This is genuinely more setup than Atom required for a quick internal package, and it is the honest tradeoff of moving to a compiled, sandboxed extension model instead of a CoffeeScript package that could touch anything in the editor’s process. What you get in exchange is an extension that cannot crash or slow down the rest of the editor the way a poorly written Atom package sometimes could.
Complete working project: a portable Zed configuration
Below is a complete, working settings.json and keymap.json pair that consolidates everything covered in this guide into a single starting configuration. Drop these into your Zed config directory to skip most of the manual setup above.
// ~/.config/zed/settings.json - complete starter config
{
"buffer_font_size": 14,
"buffer_font_family": "JetBrains Mono",
"tab_size": 2,
"soft_wrap": "editor_width",
"theme": "One Dark",
"show_whitespaces": "selection",
"autosave": "on_focus_change",
"format_on_save": "on",
"git": {
"git_gutter": "tracked_files",
"inline_blame": {
"enabled": true,
"delay_ms": 600
}
},
"lsp": {
"rust-analyzer": {
"initialization_options": {
"check": { "command": "clippy" }
}
},
"typescript-language-server": {
"initialization_options": {
"preferences": { "importModuleSpecifierPreference": "relative" }
}
}
},
"agent": {
"default_model": {
"provider": "anthropic",
"model": "claude"
},
"prevent_idle_sleep": true
},
"languages": {
"Python": { "tab_size": 4 },
"Go": { "format_on_save": "on" }
}
}// ~/.config/zed/keymap.json - complete starter keymap
[
{
"context": "Editor",
"bindings": {
"cmd-k cmd-d": "editor::DuplicateLineDown",
"cmd-shift-l": "editor::SelectLine",
"ctrl-g": "editor::ToggleGitBlame"
}
},
{
"context": "Workspace",
"bindings": {
"cmd-shift-e": "project_panel::ToggleFocus",
"cmd-shift-g": "git_panel::ToggleFocus"
}
}
]Save your project’s team-shared overrides in a .zed/settings.json file at the repo root and commit it, so every developer migrating off Atom on the same codebase inherits the same formatting and Git behavior without repeating this setup individually.
Expected output when the migration is complete
After finishing all 12 steps, a successful migration looks like this: Zed opens your project in under a second, the Git panel shows accurate tracked changes with inline blame, your language server annotates errors and warnings in real time, your custom keybindings from Step 5 respond correctly, and the AI agent panel authenticates without errors when opened. Running zed --version in a terminal should return 1.20.2 or newer, confirming you are on a current, patched build rather than a stale download.
Frequently asked questions
Is Zed a fork of Atom?
No. Pulsar is the Atom fork. Zed is a separate, ground-up native application written in Rust by some of the same people who worked on Atom and GitHub’s editor tooling, but it shares no codebase with Atom.
Can I run my old Atom packages in Zed?
No, Atom packages are not compatible with Zed’s extension system. Many common package features are built into Zed natively (see the table in Step 6), and the rest need a Zed-specific extension or have no replacement yet.
Is Zed free to use?
The core editor, its collaboration features, and basic usage are free. Some advanced AI agent usage on specific providers ties into a paid Zed Pro tier, but you can use the editor fully without it.
Does Zed support Windows?
Yes. Zed ships native installers for macOS, Linux, and Windows, with the same feature set across all three as of the 2026 stable releases.
What happened to Atom’s official support?
GitHub announced Atom’s sunset in mid-2022 and stopped shipping new releases in December 2022. It has received no security patches since, and GitHub no longer promotes it through its own product pages.
Should I migrate to Zed or Pulsar?
If you depend heavily on specific Atom packages with no Zed equivalent, Pulsar offers a lower-friction path since it keeps Atom’s package format. If you prioritize speed, native AI tooling, and built-in collaboration, Zed is the stronger long-term option, at the cost of rebuilding your extension list.
Is my Atom configuration lost forever after switching?
Not if you back it up first. Following Step 1 preserves your .atom folder so you can reference old settings, keymaps, and package lists at any point, even after uninstalling Atom entirely.
Can Zed sync settings across multiple machines?
Zed does not currently offer a built-in settings sync service comparable to some competitors. The practical workaround is keeping your settings.json and keymap.json in a personal dotfiles repository and symlinking them on each machine.
Will my custom Atom package work in Zed at all?
Not directly. Atom packages are written in CoffeeScript/JavaScript against Atom’s own API; Zed extensions are compiled Rust targeting WebAssembly. If your package wraps an existing command-line tool or language server, rebuilding it as a thin Zed extension is usually faster than porting the original code line by line.
How long does a full team migration typically take?
An individual developer can be productive in Zed within 30 to 45 minutes using this guide. A full team rollout, including a shared .zed/settings.json, onboarding documentation, and a parallel-availability period where Atom or Pulsar stays installed as a fallback, typically takes one to two weeks from kickoff to full cutover.