micro: a terminal text editor that installs as one static binary

What micro solves for people editing over SSH

The README frames the project as "somewhat of a successor to the nano editor", aimed at people who prefer working in a terminal or regularly edit files over SSH. That is a narrower audience than it first appears. The problem is not that Vim or Emacs are bad; it is that they carry a learning curve and a configuration cost that a sysadmin on a jump host does not want to pay at 2am. nano solves that, but it has no multiple cursors, no plugin system, no splits, and no persistent undo.

micro's answer is to keep nano's install model and add the features a full-time terminal user expects. The README lists multiple cursors, splits and tabs, a nano-like menu that shows the keybindings, mouse selection by drag, double click for word and triple click for line, a diff gutter, simple autocompletion, persistent undo, and syntax highlighting for over 130 languages. Default keybindings are the familiar Ctrl-s, Ctrl-c, Ctrl-v, Ctrl-z set, and the README states they can be rebound.

The intended user is therefore specific: someone who lives in a terminal, edits config files and code on remote machines, and wants a single binary they can drop onto a machine without a package manager. The README states micro comes as a "single, batteries-included, static binary with no dependencies". That property matters more than any individual feature when the machine you are editing on is not yours.

The architecture: Go core, Lua plugins, tcell terminal layer

The repository layout is conventional Go: cmd/ holds the entry point, internal/ holds the implementation, pkg/ holds reusable pieces, and runtime/ holds the data the editor loads at startup. The Makefile builds ./cmd/micro, so the binary is a single main package rather than a set of cooperating executables.

The dependency list in go.mod tells you what the editor actually is. Terminal handling comes from a fork, github.com/micro-editor/tcell/v2, rather than upstream tcell. Plugin execution uses github.com/yuin/gopher-lua, a Lua interpreter written in Go, with layeh.com/gopher-luar to bridge Go values into Lua. That combination is why plugins are Lua rather than Go: the editor embeds an interpreter instead of compiling plugins into the binary. Syntax highlighting, color schemes and other runtime data live in runtime/ and are generated into the binary by the generate target, which is why the Makefile has a generate step before build.

The build is deliberately dependency-light at runtime. CGO_ENABLED defaults to 0, so the produced binary is statically linked and does not need a C library on the target machine. The one exception the Makefile documents is macOS: on darwin it sets CGO_ENABLED = 1 and adds linker flags from tools/info-plist.go, because native macOS builds need external and dynamic linking. That is a real asymmetry worth knowing if you build from source on a Mac and expect the same output as a Linux build.

Configuration lives in ~/.config/micro, which the README names as the directory to remove when uninstalling. The README does not document a rollback path for a bad configuration, so the practical recovery is deleting or editing files in that directory.

Installing micro and opening your first file

The README gives several install routes. The fastest is the third-party quick-install script, which places the binary in the current directory rather than on your PATH. The README documents this explicitly, so you still need to move it yourself.

curl https://getmic.ro | bash
sudo mv micro /usr/bin

After the script runs you should see a file named micro in the working directory. The move command puts it on the path; adjust the destination if /usr/bin is not where you keep local binaries.

If you already have Eget installed, the README gives this as the equivalent one-liner, and it can install straight to a directory on your path:

eget --to /usr/local/bin micro-editor/micro

The --tag flag pins a version, which the README shows for both the nightly build and a numbered release:

eget --tag v2.0.8 micro-editor/micro

On macOS, Homebrew is the documented route, and the README notes that only prebuilt binaries, Homebrew and Snap are guaranteed to give you the most recent stable version:

brew install micro

On Linux, the Snap package is the other guaranteed-current route, and it needs the classic confinement flag:

snap install micro --classic

Once installed, confirm what you have before relying on it. The README states micro -version prints the version information:

micro -version

Then open a file the way you would with nano. Passing a filename is the ordinary usage the README implies throughout:

micro README.md

Inside the editor, Ctrl-s saves and Ctrl-q quits, and the nano-like menu at the bottom shows the rest of the bindings. On macOS the README warns that all keybindings use control or alt, never the command key, and that macOS terminals do not forward alt key events by default; the README points to a macOS terminal section for the fix rather than describing it in the install section.

Where micro is the wrong tool

The plugin system is the clearest limitation. Plugins are Lua, and the README describes a built-in plugin manager that installs, removes and updates them. What the README does not describe is a large ecosystem. If your workflow depends on a mature plugin for a specific language or tool, the honest position is that micro may not have it, and the README gives no compatibility guarantee for plugins across versions.

The second constraint is packaging freshness. The README states plainly that packages other than prebuilt binaries, Homebrew and Snap are "not guaranteed to be up-to-date". A commented-out line in the README records that the Debian and Ubuntu apt package was at version 2.0.1-1 with debug mode enabled, which is the kind of gap that turns into a confusing bug report. On distributions where you install through dnf, pacman, emerge, zypper, eopkg or pacstall, check micro -version against the release list before assuming a behaviour is a bug.

The third is Windows. The README says Windows is supported but Mingw/Cygwin is not, and it points to a section further down for the details. If your environment is a Cygwin or Mingw shell rather than native Windows, that exclusion applies to you.

Finally, micro is not a project for someone who wants an IDE. There is no language server protocol client described in the README, and autocompletion is described as "simple". If you need refactoring, go-to-definition across a project, or a debugger, this is not the tool the README is selling.

micro against nano, and against modal editors

The README positions micro against nano directly, calling it a successor in spirit and emphasizing the same easy install and use. The difference in approach is that nano stays minimal by design, while micro adds the features a daily terminal user wants on top of the same interaction model. Multiple cursors, splits, tabs, a diff gutter, persistent undo and mouse selection are all in the README's feature list; none of them are nano features. If you have ever wanted nano to do one more thing without learning a modal editor, micro is the direct answer.

Against modal editors, the difference is not features but the interaction model. micro keeps Ctrl-s, Ctrl-c, Ctrl-v and Ctrl-z, and the README describes rebinding as available but not required. A modal editor asks you to learn a grammar of modes and commands before it becomes fast. micro asks you to learn almost nothing and gives you a menu that displays the bindings. The cost is that micro's editing model is less composable: there is no equivalent of a modal editor's ability to combine an operator with a motion, and the README does not claim one.

The third comparison is the one the README makes implicitly: a single static binary against an editor that needs a runtime. Because CGO is off by default and the runtime data is generated into the binary, micro can be copied to a machine with no package manager and run. For jump hosts and containers, that is the whole argument.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-20, one day before this writing. The release list shows v2.0.15 tagged on 2025-12-31, with a release candidate v2.0.15-rc1 on 2025-12-13, plus a nightly tag dated 2020-07-05. The nightly tag is old, but the README describes nightly as a build compiled every day at midnight UTC, so the tag date and the build cadence are two different things.

Upgrade cost is low by design. Because the binary is static and self-contained, replacing it is the upgrade. If you installed via the quick-install script, re-running the curl command and moving the new binary is the whole procedure. If you installed via a package manager, you are subject to that package manager's cadence, which the README explicitly does not guarantee for most Linux distributions. The configuration directory at ~/.config/micro is separate from the binary, so upgrading does not touch your settings; that also means a configuration written for an older version is not rewritten for you.

micro is MIT licensed, and the repository carries a separate LICENSE-THIRD-PARTY file alongside LICENSE, which is where the terms for the bundled dependencies and runtime data would live. The practical implication for most users is that embedding micro in a product or shipping it inside a container image is permitted under MIT terms, but the third-party file is the one to read before redistributing, since the runtime directory contains syntax definitions and color schemes that may originate elsewhere. This is not legal advice; read both files if redistribution matters to you.

Editorial conclusion

Adopt micro if you edit files over SSH, want Ctrl-s and Ctrl-v to behave normally, and are willing to accept a small Lua plugin ecosystem. Do not adopt it if you need an editor with a large, mature plugin library or a language server protocol client built in, because the README does not claim either. Before committing, run micro -version after installing to confirm which build you got, and check whether your package manager's copy is current, since the README states only prebuilt binaries, Homebrew and Snap are guaranteed to be the most recent stable version.

Frequently asked questions

Official sources

1. License: MIT
2. micro-editor/micro on GitHub
3. Project website
4. README
5. Releases