LinuxmacOS

Where Does Doom Emacs Store Config and Packages?

Where Doom Emacs keeps config.el, the init system, and how each data directory behaves on upgrades.

Last updated

Doom Emacs splits its files three ways: your config in ~/.doom.d (config.el, init.el, packages.el), the framework in ~/.emacs.d, and generated state in ~/.emacs.d/.local. The doom sync command renders the first two into the third.

That pipeline decides what to back up and what to delete. Version the doom.d folder; treat emacs.d as disposable output. Most broken Doom installs come from editing generated files or skipping sync, both fixed by re syncing from a clean doom.d. The envvar DOOMDIR relocates doom.d.

Where Doom Emacs stores this, by platform

Linux
~/.doom.d

config.el, init.el, packages.el here; newer installs prefer ~/.config/doom. The doom CLI lives in ~/.emacs.d/bin and must sit on PATH. Private modules go in modules/private/ inside this tree.

macOS
~/.doom.d

Same doom.d layout via Homebrew or manual installs. The emacs.d tree behaves identically across Unixes. Native compilation cache in .local/nativecomp can grow large and is safe to clear.

Frequently asked questions

where is the doom emacs config file

Edit ~/.doom.d/config.el (recent builds use ~/.config/doom/config.el) for settings, then run doom sync. Never edit files inside ~/.emacs.d directly; doom sync regenerates them and your changes vanish. Keep the doom.d folder in git, not the emacs.d tree.

where does doom emacs cache packages

In ~/.emacs.d/.local/ (straight mirrors, caches,eln bytecode) plus ~/.cache/doom. Delete .local to force a clean rebuild after branch switches; it regenerates on next sync. Config in doom.d survives the wipe untouched.

why is my doom emacs change not applying

Run doom sync after every config change or package operation, then restart Emacs. Skipped syncs cause half applied states where commands exist but keybinds do not. The doom doctor command diagnoses the usual suspects first.

Notice an outdated path? Let us know.