Neovim Setup for DevOps Engineers

By Kokil Thapa | Last reviewed: September 2026

You edit configs on servers dozens of times a week. A solid Neovim setup for DevOps engineers turns that scattered work into one fast, repeatable environment. You get LSP for YAML and Terraform, fuzzy search across /etc, and safe remote editing over SSH. This guide builds that stack on Ubuntu 22/24—the same base I use for Linux system administration and Deployer releases on production EC2 hosts.

What should a Neovim setup for DevOps engineers include?

DevOps work is not application coding. You touch nginx configs, systemd units, GitLab CI YAML, Terraform HCL, Dockerfiles, Helm charts, and shell glue scripts. Your editor must handle all of them without opening VS Code on a 512 MB jump box.

A practical stack has five layers. Each layer solves a real production pain point I hit during deployments and incident response.

• Core editor: Neovim 0.10 or newer with sensible defaults and leader key mapped to space.
• Plugin manager: lazy.nvim—fast, lazy-loaded, easy to version in Git.
• Language support: Treesitter plus LSP for YAML, Bash, Terraform, Docker, and optional Go or Python.
• Navigation: Telescope or fzf-lua for ripgrep-backed search across /etc/nginx and project trees.
• Remote workflow: SSH config, optional neovim-remote, and a dotfiles repo you can bootstrap in one command.

If you already run GitLab CI and Deployer on Ubuntu, Neovim fits naturally beside those tools. It starts in milliseconds. It runs over SSH. It does not need a GUI on headless servers. That matters when you are fixing a broken pipeline from a phone tether in Kathmandu at midnight.

For broader context on the role, see the DevOps engineer skills roadmap for 2026. Server foundations belong in your Ubuntu server setup guide workflow first.

How do you install Neovim on Ubuntu Server for DevOps work?

Ubuntu 22.04 and 24.04 ship an old Neovim in apt. DevOps configs need 0.10+ for better defaults and Lua API stability. Install from the official PPA or build from source on locked-down hosts.

Install from the Neovim PPA

1. Add the stable PPA and update indexes.
2. Install Neovim and ripgrep, fd, and git—the search toolchain Telescope expects.
3. Verify version output shows 0.10 or newer.
4. Clone your dotfiles into ~/.config/nvim.

sudo add-apt-repository ppa:neovim-ppa/unstable -y
sudo apt update
sudo apt install -y neovim ripgrep fd-find git curl unzip
nvim --version

git clone https://github.com/YOUR_USER/nvim-devops.git ~/.config/nvim
nvim

On minimal cloud images, also install build-essential and nodejs if you use Mason to pull LSP binaries. Node.js 26 LTS is fine for language servers. PHP 8.5 on the server is unrelated to Neovim, but many DevOps engineers still maintain Laravel apps—keep editor and runtime versions separate in your notes.

Set baseline options in init.lua

Start with a small init.lua before adding plugins. These options match what I want on every production jump host.

-- ~/.config/nvim/init.lua
vim.g.mapleader = " "
vim.opt.number = true
vim.opt.relativenumber = true
vim.opt.expandtab = true
vim.opt.shiftwidth = 2
vim.opt.tabstop = 2
vim.opt.ignorecase = true
vim.opt.smartcase = true
vim.opt.swapfile = false
vim.opt.backup = false
vim.opt.undofile = true
vim.opt.signcolumn = "yes"
vim.opt.updatetime = 250
vim.opt.scrolloff = 8

Disable swap files on servers. You do not want .swp littering /etc/nginx after a rushed hotfix. Use persistent undo in your home directory instead.

How do you configure lazy.nvim for a DevOps-focused Neovim setup?

lazy.nvim is the plugin manager most Neovim users pick in 2026. It loads plugins on demand, which keeps startup fast on small VPS instances—common on Nepal hosting tiers around Rs 800–2,000/month (~USD 6–15).

Bootstrap lazy.nvim

Add the bootstrap block at the top of init.lua. The official lazy.nvim readme documents this pattern. Copy it once, then never touch it again.

local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git", "clone", "--filter=blob:none",
    "https://github.com/folke/lazy.nvim.git",
    "--branch=stable", lazypath,
  })
end
vim.opt.rtp:prepend(lazypath)

require("lazy").setup("plugins")

Store plugin specs in ~/.config/nvim/lua/plugins/init.lua. Split by concern: editor UX, LSP, DevOps file types, Git, and terminal integration.

Core plugin bundle for DevOps

-- ~/.config/nvim/lua/plugins/init.lua
return {
  { "folke/tokyonight.nvim", lazy = false, priority = 1000 },
  { "nvim-lua/plenary.nvim" },
  {
    "nvim-telescope/telescope.nvim",
    dependencies = { "nvim-telescope/telescope-fzf-native.nvim" },
    cmd = "Telescope",
  },
  { "nvim-treesitter/nvim-treesitter", build = ":TSUpdate" },
  { "williamboman/mason.nvim", cmd = "Mason" },
  { "williamboman/mason-lspconfig.nvim" },
  { "neovim/nvim-lspconfig" },
  { "tpope/vim-fugitive" },
  { "tpope/vim-rhubarb" },
  { "windwp/nvim-autopairs", event = "InsertEnter" },
  { "numToStr/Comment.nvim", event = "ModeChanged" },
  { "akinsho/toggleterm.nvim", version = "*", cmd = "ToggleTerm" },
}

Run :Lazy sync on first launch. Mason installs yaml-language-server, bash-language-server, terraform-ls, and dockerfile-language-server without apt packages scattered across hosts.

Wire LSP in lua/config/lsp.lua. Enable servers that match your stack. Skip language servers you never touch—it saves RAM on t3.small instances.

local mason = require("mason")
local mason_lsp = require("mason-lspconfig")
local lspconfig = require("lspconfig")

mason.setup()
mason_lsp.setup({
  ensure_installed = {
    "lua_ls", "yamlls", "bashls", "terraformls",
    "dockerls", "templ", "jsonls",
  },
})

local on_attach = function(_, bufnr)
  local map = function(mode, lhs, rhs)
    vim.keymap.set(mode, lhs, rhs, { buffer = bufnr })
  end
  map("n", "gd", vim.lsp.buf.definition)
  map("n", "K", vim.lsp.buf.hover)
  map("n", "<leader>rn", vim.lsp.buf.rename)
end

lspconfig.yamlls.setup({ on_attach = on_attach })
lspconfig.bashls.setup({ on_attach = on_attach })
lspconfig.terraformls.setup({ on_attach = on_attach })
lspconfig.dockerls.setup({ on_attach = on_attach })

Pair this with the Terraform with Azure DevOps pipelines guide when you edit HCL and pipeline YAML in the same session. Test regex in pipeline guards with the regex tester before you commit.

Which Neovim plugins matter most for YAML, Terraform, Docker, and shell scripts?

Not every plugin earns disk space on a production bastion. The table below ranks what DevOps engineers actually use weekly versus what looks cool in dotfiles repos.

Treesitter parsers must be installed per language. Run :TSInstall yaml terraform bash dockerfile hcl once. YAML schema validation for Kubernetes or GitLab CI comes from yamlls settings—not a separate plugin.

-- yamlls settings for GitLab CI and K8s
lspconfig.yamlls.setup({
  settings = {
    yaml = {
      schemas = {
        ["https://json.schemastore.org/gitlab-ci"] = ".gitlab-ci.yml",
        ["https://json.schemastore.org/helmfile"] = "helmfile.yaml",
      },
      validate = true,
      format = { enable = true },
    },
  },
})

For shell scripts that wrap backups and cron jobs, Bash LSP catches quoting errors before you deploy. That pairs well with an automated server backups setup where one typo breaks nightly dumps.

Telescope keymaps for incident response

When logs explode during an outage, you need ripgrep—not manual less scrolling. Bind these once:

local builtin = require("telescope.builtin")
vim.keymap.set("n", "<leader>ff", builtin.find_files)
vim.keymap.set("n", "<leader>fg", builtin.live_grep)
vim.keymap.set("n", "<leader>fb", builtin.buffers)
vim.keymap.set("n", "<leader>fh", builtin.help_tags)

Run <leader>fg with cwd set to /var/log/nginx and pattern upstream timed out. You get the same workflow on laptop and server. No GUI required.

I still use VS Code locally for large Laravel refactors. On servers, Neovim is the better default. The Go for DevOps guide and Python for DevOps automation articles benefit from the same LSP stack when you edit small automation scripts.

How do you edit remote servers safely with Neovim over SSH?

Remote editing is where a Neovim setup for DevOps engineers pays off daily. You have three sane patterns. Pick one and document it for your team.

Pattern 1: SSH in and run nvim on the host

Sync dotfiles to every managed host with Ansible or a simple bootstrap script. Edit files in place. This is what I use on Deployer target servers.

#!/bin/bash
# bootstrap-nvim.sh — run once on new Ubuntu 24.04 hosts
sudo apt install -y neovim ripgrep git
git clone https://github.com/YOUR_USER/nvim-devops.git ~/.config/nvim
nvim +Lazy sync +qa

Always edit configs under /etc with sudoedit or sudo nvim. Never run Neovim as root by default. Keep audit trails clean.

Pattern 2: neovim-remote from your laptop

Install neovim-remote (nvim-remote or nvr) locally. It pushes files into a remote Neovim session over SSH socket forwarding. Useful when one persistent session stays open on a bastion.

ssh -R /tmp/nvim.sock:/tmp/nvim.sock deploy@bastion.example.com
nvr --remote-wait ssh://deploy@bastion//etc/nginx/sites-available/app.conf

Pattern 3: Direct scp edit workflow

For one-off fixes, copy down, edit locally, copy up. Boring and safe. Script it so you do not forget checksum verification.

scp deploy@server:/etc/systemd/system/app.service /tmp/app.service
nvim /tmp/app.service
scp /tmp/app.service deploy@server:/etc/systemd/system/app.service
ssh deploy@server 'sudo systemctl daemon-reload && sudo systemctl restart app'

Document your pattern in the team wiki. New hires should not guess whether to edit live. Tie changes to Git where possible—even for ops repos. The Prometheus and Grafana setup guide is easier to maintain when alert YAML lives in version control and you edit it with schema-aware LSP.

What security and performance habits keep Neovim safe on production servers?

A misconfigured editor on a prod box is a footgun. These habits come from real incidents and near-misses on client infrastructure.

• Version your config: Store ~/.config/nvim in a private Git repo. Tag releases. Roll back bad plugin updates.
• Pin plugin commits: lazy.nvim supports lockfiles via :Lazy lock. Reproducible setups beat "works on my laptop".
• Limit Mason downloads: Only install LSP servers you need. Fewer binaries mean smaller attack surface.
• Avoid root sessions: Use sudoedit. Keep undo files in ~/.local/state/nvim/undo, not world-readable paths.
• Disable unused providers: Turn off Node/Ruby providers if unused—less clutter, faster startup.

Performance on a 1 GB RAM VPS is fine if you lazy-load. Do not set every plugin to lazy = false. Telescope, Mason, and LSP attach on first use. Startup should stay under 80 ms on warm cache.

Security scanning belongs in CI, not the editor—but Neovim helps you read findings. Cross-check dependency reports with the dependency vulnerability scanning setup article. For interview prep on the same toolchain, see Linux interview questions for DevOps.

Official references worth bookmarking: the Neovim documentation for Lua API details, and the lazy.nvim repository for plugin spec syntax. Mozilla’s SSH hardening guides complement your bastion setup—disable password auth before you spread dotfiles company-wide.

On projects with full GitLab CI pipelines—like the sister legal-tech sites I deploy with Deployer 7—you edit pipeline YAML, PHP-FPM pool configs, and nginx snippets in one evening. A unified Neovim config beats switching between nano on the server and a GUI IDE locally. See the Notary Kathmandu portfolio for the kind of multi-site ops footprint where that consistency matters.

Key Takeaways

• Install Neovim 0.10+ from the official PPA on Ubuntu 22/24; pair it with ripgrep and fd for Telescope.
• Use lazy.nvim plus Mason to install yamlls, terraformls, bashls, and dockerls—covering most DevOps file types.
• Bind Telescope live grep for log triage; disable swap files on servers and enable persistent undo in your home dir.
• Pick one remote workflow—on-host nvim, neovim-remote, or scp—and document it for the team.
• Version dotfiles in Git with lazy lockfiles so jump hosts and laptops stay identical.
• Keep VS Code for heavy app refactors; use Neovim on SSH and low-RAM VPS instances where speed wins.

People Also Ask

Is Neovim better than VS Code for DevOps engineers?

On headless Linux servers and jump hosts, yes—Neovim starts instantly and needs minimal RAM. VS Code Remote SSH is stronger for large monorepos and GUI debugging locally. Most engineers use both: Neovim on servers, VS Code on the workstation.

Do I need to learn Vim motions for a DevOps Neovim setup?

You need basic motions—hjkl, dd, yy, / search, and file saves—to edit configs efficiently. You do not need advanced macros on day one. Enable relativenumber and practice for a week on non-production hosts first.

Can Neovim replace IntelliJ or PyCharm for infrastructure code?

For Terraform, YAML, Docker, and Bash, Neovim with LSP is enough. For deep Java or .NET app debugging, keep a full IDE. DevOps work skews toward configs and scripts where Neovim excels.

How do I sync Neovim config across multiple servers?

Store config in a Git repo and run a bootstrap script on each host. Ansible copy tasks work too. Pin plugin versions with lazy.nvim lockfiles so every server gets the same plugin set.

Ship a Neovim setup your team can reuse

A repeatable Neovim setup for DevOps engineers saves hours across pipelines, nginx hotfixes, and 2 a.m. incident edits. Start with Ubuntu, lazy.nvim, and four LSP servers. Add Telescope keymaps. Sync dotfiles to bastions. Keep improving the config in Git—the same way you treat infrastructure code.

If you want help hardening Ubuntu hosts, CI pipelines, or deployment workflows around the tools you edit daily, review our support and maintenance services or contact us for a practical ops review. Explore more on the eBPF for DevOps and DevOps roadmap for 2026 guides when you expand beyond the editor.