Allaman's nvim: a Neovim config split into default specs and an extra folder

A personal config, and the README says so

The repository describes itself as a minimal, blazingly fast, and pure Lua based Neovim configuration for the author's work as a DevOps and cloud engineer, with batteries included for Python, Golang, Terraform and YAML. That phrasing is the honest summary of the whole project. It is a working setup for one person, published so that others can look at it, fork it or use it.

Two signals confirm that. The customization section opens with a warning that this is primarily a personal config, and the README body itself is labelled README WIP. Neither is a criticism so much as a boundary: you are reading someone's dotfiles, and the documentation is incomplete on purpose because the config itself is complete.

The stack is narrow by choice. Neovim 0.10.0 is the stated target, the language is pure Lua with no Vimscript, and the repository root shows the shape of it: init.lua, minimal_init_lazy.lua, vim.toml, a lua directory, a snippets directory, and the tooling files for formatting and linting. The visual side is delegated, with ghostty as the terminal, Comic Code Ligatures as the font and tokyonight.nvim as the colorscheme, which tells you the author wanted the editor to look a particular way and the config to be thin.

For an engineer who wants a batteries included setup in exactly this domain, that is a reasonable starting point. For anyone who wants a maintained, documented configuration, it is not.

The extra folder is the supported extension point

The one part of the README that is properly documented is the mechanism for changing the configuration without fighting it. If you want to use the config, there is a ./lua/vnext/extra/ folder that is loaded by lazy.nvim, and the LazySpecs in that folder are merged with the default LazySpecs in the ./lua/vnext/plugins/ folder.

That merge is the design. The default specs stay as the author wrote them, and your changes sit in a separate folder, so an upstream change to the defaults does not collide with your edits. The result is that the config can keep being restructured without asking every user to resolve conflicts in the same file.

The four documented operations are all variations on the same theme. To disable a plugin:

return {
  {
    "Bekaboo/dropbar.nvim",
    enabled = false,
  },
}

To add options to a plugin that already exists:

return {
  {
    "nvim-mini/mini.surround",
    opts = {
      search_method = 'nearest',
    },
  }
}

To overwrite options, the same shape with a different value, and to change the keys a plugin binds, you add a keys table to the spec, as in the grug-far example, where each entry pairs a leader mapping with a description and a command that opens the plugin with prefills such as the current file path or the word under the cursor.

The README points to a blog post explaining the reasoning behind the change and to the v1 branch, where the previous version of the configuration lives, which is a useful thing to look at if you want to see the before and after.

The Dockerfile turns the config into a container image

There is a Dockerfile in the repository, and it is the most concrete part of the project for anyone who wants to reproduce the environment rather than install it.

The image is built from a prebuilt full Neovim image, with the architecture and base image passed in as build arguments:

ARG ARCH
ARG BASE_IMAGE
# hadolint ignore=DL3007
FROM ${ARCH}allaman/nvim-full:latest

The build then prepares the config directory and the Mason package directory, writes an empty user config file, and appends the Mason tools directory to the PATH in the shell profile:

RUN mkdir -p ~/config/nvim \
  && mkdir -p ~/.local/share/nvim/mason/packages \
  ## Create empty user config file
  && echo "return {}" > ~/.nvim_config.lua \
  ## Add mason tools dir to path
  && echo "PATH=$PATH:~/.local/share/nvim/mason/bin" >> ~/.bashrc

The config is copied into the working directory and the plugins are installed at image build time by running a headless Neovim with a lazy sync, with the container entrypoint opening nvim in bash:

WORKDIR /home/nvim/.config/nvim
COPY --chown=nvim:nvim . .
# Install plugins and tools with Mason and go.nvim
# HACK: Use of sleep is not cool but commands are not blocking (! is not working either)
RUN nvim --headless "+Lazy! sync" +qa
  # && nvim --headless "+Lazy! load mason.nvim +MasonInstall +sleep 45" +qa

ENTRYPOINT ["/bin/bash", "-c", "nvim"]

Two details in that last block are worth noting. The comment above the sync line admits a hack, because the alternative Mason install line is commented out and the author found that a sleep based approach was not blocking correctly. And the image installs plugins at build time rather than at first launch, which means a container start is fast and a container build is slow, and the plugin state is baked into the image.

Formatting, linting and CI files in the root

The repository carries the tooling that keeps a Lua configuration honest: a.stylua.toml for formatting, a selene.toml for the Lua linter, a.markdownlint.yaml for the README, and a.neoconf.json for the neoconf tool. There is also a.emmyrc.json for the Emmy language server, an.editorconfig style set of ignore and Docker related files, and a.github directory.

The CI badge in the README points at a workflow file at.github/workflows/ci.yml, so the configuration is checked on every push rather than only when the author remembers to run it. For a config repository that matters more than it would for an application, because a Lua file with a typo in a plugin spec fails at startup with a message that is often cryptic.

The stylua configuration is also referenced from the README itself, in the key remapping example, where stylua ignore markers wrap a block of long key mapping lines so the formatter does not reflow them. That is a small but telling detail: the author has already hit the formatter disagreeing with a wall of keymaps, and solved it in the file rather than by turning formatting off.

The.neoconf.json entry is worth a mention too, because generating a readable reference of your own keymaps and options from a config is what turns a dotfiles repository into something a colleague can actually read.

No releases, a moving main branch and an MIT licence

The repository publishes no GitHub releases, and the last push was on 2026-10-18, so the main branch is the primary artifact, and beyond cloning it, the repository's Dockerfile lets you consume the configuration as a container image.

The licence is MIT, which is the easiest possible answer for a dotfiles repository: you can take the config, change it, and ship it inside your own setup without the copyleft obligations that come with a GPL licence. For a configuration whose purpose is to be copied, that is the right choice, and the licence file sits at the root next to the README.

The maintenance picture is one of an active personal project rather than a supported distribution. There is a CI workflow and a recent commit, so the author is still working in it, but there is no version history to speak of, and the README being marked work in progress means the documentation may lag behind the config.

That last point has a practical consequence for anyone planning to use this at work. You will be reading Lua files to find out what a key does, not a manual, and when the next restructure lands, the mapping from what you learned to what is in the tree changes without a changelog to explain it. The v1 branch is the one historical anchor the README gives you, and the blog post about debloating the configuration is the other.

Editorial conclusion

Adopt Allaman's nvim if you work in Python, Golang, Terraform or YAML on a daily basis and want a working Neovim setup that you then take over, since the extra folder gives you a supported way to change plugin options without editing the defaults. Do not adopt it as a starting point for a team that needs documented, supported configuration, because the README states it is primarily a personal config and marks itself as work in progress, and do not expect the plugin set to be a curated minimal one. Verify first that the configuration matches Neovim 0.10.0, that the plugins you depend on are loaded through lazy.nvim rather than assumed, and that the build and lint tooling in the repository, selene, stylua and the CI workflow, passes on your own machine before you start editing it.

Frequently asked questions

Official sources

1. Allaman/nvim on GitHub
2. Issues
3. License: MIT
4. README