I grew up on emacs. One of my first jobs I sat down at a terminal and was editing some files with pico, it’s what I knew since I used that fantastic email client pine. I was quickly told by the lead developer that I needed to use a real text editor if I’m going to progress in my career. He told me I need to try emacs, and after suffering through a few weeks of memorizing multi command-char sequences and training the muscle memory in my pinky to perform bizarre contortions of my left hand just to save my file, I became a convert. I found out a few months later that the developer who convinced me to use emacs was a vi user all along. I think I was a victim of a cruel joke or hazing ritual, but I learned to love emacs, and when I am not coding in a desktop IDE (IntelliJ) then I am using emacs.
§2026 Update
This is the companion to “Don’t Install cqlsh”, and the same verdict applies: the container-as-command trick still works and has quietly become normal practice. A few things have moved since 2018, and they make the case stronger, not weaker.
Modern Emacs got heavier and better. Emacs is at 30.x now, with native compilation on by default, tree-sitter for real syntax parsing, and Eglot (Language Server Protocol) baked into the editor. That is a genuinely nicer Emacs than the 2018 build. It is also more of a chore to compile, exactly the kind of “download and build a pile of dependencies” job the original post was trying to avoid. Letting an image carry that build is more worthwhile now than it was then. As a bonus aimed squarely at the rest of this blog, Emacs 30 added TRAMP support for editing files inside Kubernetes pods.
Mind the architecture on Apple Silicon. When I wrote this I was on an Intel Mac. If a utility image is built for amd64 only, it will run under emulation on an M-series Mac, which is slow and occasionally flaky. Prefer a multi-architecture image, or build your own for arm64. The same goes for any container-as-command image you adopt.
Take the security warning below seriously, more so than I did. Mounting your whole $HOME into a container running as root is convenient and a real risk. The safer pattern today is to run the container as your own user with --user "$(id -u):$(id -g)" and mount only the directory you are actually editing, plus a small named volume for your Emacs config. Options 2 and 3 below already point this way.
The original write-up follows.
Original article below. Everything from here down is the post as originally written. The 2026 Update above covers what’s changed since.
However most base server installs don’t come with emacs, and emacs installs a ton of extra libraries and dependencies. Emacs often takes a considerable bit of time to install as packages are downloaded and compiled depending on the platform.
As the world, and my company has been rapidly moving to containerization, I find Docker installed on more servers. Docker lets me leverage something I have been doing a lot of lately: container-as-command. Like monolithic or microservices, websites, databases, and on and on, containers give us dependency isolation. So with the only requirement being Docker, I can run any utility that I can slide into a little Alpine Linux container.
§Running emacs
Since I don’t want to type out a long docker run command every time I want emacs I give my .bashrc an alias command.
alias emacs='docker run --rm -it -v "$PWD":/src -v "$HOME":/root cjimti/emacs'
Now I source my .bashrc with source ~/.bashrc and I instantly have emacs on any Docker installed server or workstation. I use this on my local workstation as well as servers.
WARNING: Mounting a home directory with an unknown container can be a big security problem, and you would need a lot of trust in the container you are letting mount this directory.
- You can use the cjimti/emacs container as-is and trust me.
- You can use the cjimti/emacs container as-is and adjust the alias not to mount your home directory. Use a persistent volume for .emacs and related files.
- You can make your own container.