A Neovim environment for infrastructure work.
🚀 fast · 🧩 modular · 🔧 easy to extend · 📦 maintained plugins only · 📝 documented · 🎨 Catppuccin Mocha
Chroma Neovim is a ready-to-use Neovim configuration for people who work with infrastructure from a terminal. It brings the language servers, formatters, linters, parsers and plugins for:
Terraform / OpenTofu · Kubernetes · Helm · Ansible · Ansible Vault · AWS · Docker · GitHub Actions · YAML
It is modular. Each of those is a component you can switch on or off, and the
editor loads only what you chose — a configuration with Kubernetes off installs
no kubectl.nvim, enables no helm_ls, and compiles no Helm parsers. See
:help chroma-nvim-components.
| Dependency | Version |
|---|---|
| Neovim | ≥ 0.12 |
| git | ≥ 2.19 |
| tree-sitter CLI | ≥ 0.26.1, from your package manager rather than npm |
| fzf | ≥ 0.36 |
| ripgrep, fd, bat | any |
| curl, tar, unzip, gzip | any |
| A C compiler | any |
A Nerd Font is recommended. That table is the whole list, and the versions in it are floors rather than pins — each one is a requirement stated by something Chroma depends on: lazy.nvim needs partial clones, nvim-treesitter names its CLI version, fzf-lua names its fzf. Anything newer works.
Terraform, OpenTofu, kubectl, Helm, Ansible, the AWS CLI and Docker are not
installed or managed by Chroma, and enabling a component does not ask for
them. Choosing Kubernetes asks for Chroma's Kubernetes features — the plugin,
the language server, the schemas, the parser. The kubectl those features shell
out to is yours to provide, and Chroma will not install, upgrade or shadow it.
So a missing one never blocks an installation. chroma install says at the end
which are not on PATH, :checkhealth chroma and chroma doctor say it again
whenever you ask, and the feature that needs one tells you when you use it —
which is the moment it matters. If you run OpenTofu rather than Terraform, that
is simply what the Terraform component uses.
What Chroma does pin is its own runtime — plugins, language servers, formatters, linters and parsers, installed through lazy.nvim and Mason — so that one release installs the same editor twice. You never have to think about that half.
Download chroma for your machine from the
latest release,
check it against the published SHA256SUMS, and run it:
curl -fsSLO https://github.com/ultherego/chroma-nvim/releases/latest/download/chroma-linux-amd64
curl -fsSLO https://github.com/ultherego/chroma-nvim/releases/latest/download/SHA256SUMS
sha256sum --ignore-missing -c SHA256SUMS
chmod +x chroma-linux-amd64 && sudo mv chroma-linux-amd64 /usr/local/bin/chroma
chroma installIt asks where to put the configuration and which components you want, shows the whole plan, and writes nothing until you agree. By default it installs beside whatever Neovim configuration you already have:
NVIM_APPNAME=chroma-nvim nvimChoosing the other placement takes over ~/.config/nvim and keeps what was
there, to be given back if you ever uninstall.
Everything the installer fetches is verified before it is unpacked: the archive is checked against the checksum published with the release, and unpacking refuses anything that is not a plain file or directory under the release's own prefix. Every operation is a transaction — if a step fails, what you had is put back and the record still describes it.
A component is one technology's support: its language servers, linters, formatters, parsers, plugins and schemas. What you did not choose is not installed and not loaded.
chroma components # choose, starting from what you have
chroma components --set terraform,helm # or say it outrightChanging components does not change which release you are on, and changing release does not change your components.
chroma doctor # what each component needs, and what this machine has
chroma update # move to another release, keeping your components
chroma rollback # go back to the previous one, keeping your componentsAn update keeps the release it replaced, so rollback is a local operation
rather than a re-download. Rolling back again returns you to where you were.
chroma uninstallIt prints the exact list of paths before it removes anything. What Chroma made
— the configuration, the kept generations, the plugins, the Mason packages, the
parsers, the cache, the state and your component selection — is removed. A
configuration that was in ~/.config/nvim before Chroma took it over is
given back, not deleted. External tools and Neovim itself are never touched.
The repository is itself a Neovim configuration directory, which is how it is
worked on. This is not the installation route: it skips the release
verification, the transaction, the install state and everything update,
rollback and uninstall depend on.
git clone https://github.com/ultherego/chroma-nvim.git ~/.config/chroma-nvim
NVIM_APPNAME=chroma-nvim nvimCONTRACT.md covers the test suite, the linters and how installations are
tested in a container. chroma install --source-tree . installs a checkout
through the real installer, which is how the two are kept honest.
Most of this configuration drives external programs, and when one is missing
the symptom is usually silence rather than an error. :checkhealth chroma
reports what is absent, what stops working without it, and which components are
enabled. chroma doctor answers the same question from a shell. :Lazy and
:Mason cover the plugins and the packages.
If something behaves oddly rather than being absent, :help chroma-nvim-troubleshooting lists the cases that have come up before and what
each one turned out to be.
In the editor: :help chroma-nvim — every keymap, every component, the
safety model of the modules that handle secrets and run infrastructure
commands, and what they do and do not guarantee.
Why it is like this: DECISIONS.md — the reasoning behind
every choice, and what is deliberately absent. CONTRACT.md —
the rules this project is built under. cli/DESIGN.md — the
installer.