Kickstart.nvim: vim.pack instead of a plugin manager, and a lock file the template ignores

NOT a distribution, and that single sentence is the design

The introduction is three words long and then one negation. Kickstart is a starting point for Neovim that is small, single-file and completely documented, and it is NOT a Neovim distribution but instead a starting point for your configuration. Everything else follows from that. There is no installer, no setup command and no opinion you are meant to keep. You take the repository and it becomes yours to edit. The FAQ explains why init.lua is one file rather than many, and the answer is the whole point of the project: the main purpose of kickstart is to serve as a teaching tool and a reference configuration that someone can easily use to git clone as a basis for their own. As you progress in learning Neovim and Lua you might consider splitting it into smaller parts, and a fork that does exactly that while maintaining the same functionality exists as kickstart-modular.nvim. The argument is carried on in issue 218 and pull request 473.

vim.pack installs the plugins, so no plugin spec file sits at the root

Plugin management is the part that changed shape, and the root directory explains it. The top level holds .github/, .gitignore, .stylua.toml, LICENSE.md, README.md, doc/, init.lua and lua/, and there is no plugin specification file and no lock file committed. Plugins are declared inside the configuration and installed by Neovim itself. The sequence after you run nvim for the first time is worth knowing precisely, because it is not the usual apply-on-save behaviour. vim.pack will install all the plugins from your config. To inspect plugin state you run the command with an offline flag, and to fetch updates you run the plain update command. Updates are then staged rather than applied: :write applies them and :quit cancels them. So you get a review step where you can look at what changed before it lands, and :StyLua is what the .stylua.toml at the root is there to enforce on the Lua.

The clone target is the config directory, and that path is spelled differently on Windows

Installation is a git clone into the directory Neovim already reads its configuration from, and the destination path is the only thing that varies by platform. On Linux and macOS the configuration lives at $XDG_CONFIG_HOME/nvim or ~/.config/nvim, and the clone command is written so that the first of those wins when the variable is set.

git clone https://github.com/nvim-lua/kickstart.nvim.git "${XDG_CONFIG_HOME:-$HOME/.config}"/nvim

On Windows there are two forms rather than one, because the shell matters. For cmd.exe the destination is %localappdata%\nvim, and for powershell.exe it is ${env:LOCALAPPDATA}\nvim, which is why the table in the README lists Windows twice. That is a small thing that costs people an afternoon if they copy the wrong line, so pick the command that matches the shell you actually launch. The prerequisites are separate from this and are not installed by the clone, and the project asks you to back up any previous configuration before you overwrite the directory.

Use this template or fork, and issue 1740 is where the tradeoffs are argued

There are two supported ways to get your own copy, and the project does not pretend one is right. The recommended step is to use GitHub's Use this template button so you have your own copy that you can modify, then clone that new repository. The alternative is to fork, and the reason given is an easy upstream sync path, for example keeping your config on a separate branch and fast-forwarding master from upstream. The tradeoffs between the two are argued in discussion 1740. The shape of the difference is straightforward once you see it. A template gives you a repository with no upstream to pull from, so nothing arrives unasked and nothing breaks without your action. A fork gives you upstream, so improvements to the reference configuration reach you, along with any change to init.lua that the reference configuration makes, which after the first few months of editing is a merge you did not ask for.

The template ignores nvim-pack-lock.json, and you are told to undo that

Here is a concrete piece of evidence that this repository is a starting point rather than a finished product, and it is in the recommended installation step rather than buried. After you create your own copy, the project says you likely want to remove nvim-pack-lock.json from your repo's .gitignore file too. The reason it is ignored in the kickstart repository is to make maintenance easier, but it is recommended to track it in version control, with a pointer to :help vim.pack-lockfile for the details. So the configuration you are handed ships with an ignore rule that is correct for the maintainer and wrong for you, and a lock file is the thing that makes a plugin set reproducible. Leave the ignore rule in place and your lock file is invisible to review, which means a colleague and you can end up with different plugin versions from the same configuration file with nothing in the history to show for it.

NVIM_APPNAME is how you keep a second configuration beside the first

The FAQ is more useful than most, and one answer in it settles the question everyone asks: can I keep my existing configuration in parallel to kickstart. Yes. You use NVIM_APPNAME set to nvim-NAME to maintain multiple configurations, and the concrete recipe is to install the kickstart configuration in ~/.config/nvim-kickstart and create an alias.

alias nvim-kickstart='NVIM_APPNAME="nvim-kickstart" nvim'

Run through that alias, Neovim uses the alternative config directory and the matching local directory at ~/.local/share/nvim-kickstart, so the two installations never collide. The project notes you can apply this approach to any Neovim distribution you would like to try out, which makes it the general answer rather than a kickstart trick. The same FAQ covers the two ends of the lifecycle. To clear an old configuration you back it up, then delete all associated files including your existing init.lua, and the local data goes with rm -rf on the share directory. To uninstall kickstart you remove the config directory and the local data directory.

git, gcc, ripgrep, fd and a clipboard tool are all hard prerequisites

The dependency list is longer than a config template usually admits to, and every item on it is something you install yourself. Basic utilities come first: git, make, unzip and a C compiler in the form of gcc. Then two search tools, ripgrep and fd-find, and the tree-sitter CLI. A clipboard tool is required, and which one depends on the platform, with xclip, xsel and win32yank named as the options. Fonts are optional but change the rendering: a Nerd Font provides the various icons, and if you have one you set vim.g.have_nerd_font in init.lua to true, which is a configuration change rather than an automatic detection. Emoji fonts are Ubuntu only and only if you want emoji, installed with apt. Language tooling is on you as well, with npm needed for Typescript and go for Golang. Then there is the Neovim version itself, which the project targets only at the latest stable and the latest nightly, and you check with nvim --version.

No GitHub releases, so a clone is a fork tracking master by definition

Maintenance is not in doubt. The repository is not archived and the last push landed on 2026-09-14, so Kickstart is actively maintained. What the release history shows is the absence of releases entirely, there are none, and that is the structural fact that shapes everything else in this article. A configuration you install by cloning or templating has no version to pin, so it is a branch that moves. Combined with the fork option and its fast-forward workflow, that means the reference configuration is something you merge rather than something you consume at a fixed point, and the README gives you no release notes to read when a change arrives because there is no release to read them from. The upside is real and simple, since you get the current version of the reference configuration the moment you pull. The cost is that the only signal you get about a change is the diff in init.lua, so a team sharing a fork needs to decide for itself who reads that diff.

Editorial conclusion

Kickstart suits someone who wants to own their editor configuration line by line and is prepared to read one Lua file before changing anything, and it suits you especially well if you have a parallel configuration already, because NVIM_APPNAME gives you a clean way to run both. It does not suit someone who wants a plugin manager with a declarative spec file and a lock file they never have to think about, and it does not suit a machine where the Neovim version is whatever the distribution happened to ship. Verify three things first: that you are on at least the latest stable Neovim, which the project targets exclusively, that the hard prerequisites including git, gcc, ripgrep, fd and a clipboard tool are present, and that you have removed nvim-pack-lock.json from your .gitignore, because the template's setting is the one thing in the repository that is deliberately wrong for your copy.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nvim-lua/kickstart.nvim on GitHub
4. README