DEV Community: Alexey Cherednichenko

Vim for DevOps: Practical Editing Techniques for Remote Operations

Alexey Cherednichenko — Fri, 23 Jan 2026 20:35:15 +0000

1. Introduction: Why Vim matters for remote ops

A lot of junior engineers take one look at Vim and think, “Why on earth would I bother with this?” It’s old, clunky, and, let’s be honest, it feels about as fresh as a rotary phone. You’ve got VS Code, remote everything, and you just click your way through. So what’s the point of learning Vim?

But then, you land in incident response or DevOps environments. Suddenly, the fancy GUI is gone. You’re dropped into a terminal—no mouse, no bells and whistles—and you’ve got to move fast.

At that point, Vim becomes a practical tool rather than a legacy editor. Here’s why it matters in infrastructure work:

High Latency is Brutal

Imagine: you SSH into a server on the other side of the planet, or maybe the machine’s just crawling. Every time you touch your mouse in VS Code, the lag just slaps you in the face. It’s painful.

Vim is terminal-native and lightweight. It transfers minimal data and avoids heavy UI redraws. There’s barely any data flying back and forth. You can keep working, even on the slowest connection, while other editors just freeze up. Editing a config file doesn’t have to be torture.

If you've ever tried to delete a single line over a 300ms satellite link or a jittery VPN, you know the pain of watching your cursor 'rubber-banding' across the screen. While VS Code is busy sending telemetry and waiting for a UI redraw, Vim is already done with the edit. Vim remains responsive over high latency because it’s terminal-native and avoids heavy UI redraws.

Vim is Everywhere

Let’s say you jump into a brand new Docker container running Alpine, poking around to fix something. Or maybe you’re dealing with some ancient server that hasn’t seen love in years.

Your customized VS Code? Nowhere to be found. Heck, even nano might be missing to save a couple kilobytes.

But vi or vim? Always there. If you know Vim, you can work anywhere—on a smart lightbulb, a massive EC2 server, you name it. You’re always ready.

Maintaining Control During Critical Outages

When downtime triggers a flood of alerts and every configuration mistake carries a high price.

In a regular editor, it’s easy to hit the wrong key or nudge the mouse and mess something up without even noticing.

Vim breaks things up—Normal Mode for moving and reading, Insert Mode for typing. It’s like it forces you to slow down, think, and avoid stupid mistakes. When the pressure’s on, that focus matters.

For incident and operations work, Vim is a reliable fallback when GUI tools are unavailable. Sure, most days you’ll use your IDE. But when the GUI is no longer an option, you’re the one who maintains control.

Editing as Text Operations

A lot of newbies treat Vim like Notepad. They jump into Insert Mode and poke around with the arrow keys. That’s missing the point.

Vim isn’t just another text editor. It’s more like a language.

In Normal Mode, you’re not just pecking at keys - you perform structured text operations rather than character-by-character edits. You’re not backspacing through mistakes, you’re making precise moves. Vim commands always follow a pattern: Verb plus Noun, or Action plus Object. That’s how you get fast.

Learning path overview

Honestly, most people give up on Vim because it feels like getting tossed into a pitch-black room and someone’s hidden the door. You get stuck, panic a little, and run back to whatever editor feels safe.

But if you’re an operations engineer, you don’t need to write your own Vim plugins or become some command-line wizard. Normal Mode is optimized for navigation and editing commands. Use it as the default state; switch to Insert Mode only when typing text. So here’s the plan: in the next ten minutes, we’ll close that gap. Here’s how it breaks down:

The Foundation: Set up Vim so it actually feels modern, not like you’re typing on some relic from the ‘70s.
The Navigation: Figure out how to jump around a giant log file in seconds—no endless scrolling.
The Surgery: Get really good at the handful of commands that save your skin when you have to edit important configs like nginx.conf or docker-compose.yaml, and the clock’s ticking.
The Automation: Unlock some of Vim’s hidden tricks to blast through repetitive edits—stuff that takes forever in a GUI but only seconds here.

By the end of this, you won’t just know the infamous exit command (:q!—there you go). You’ll be able to jump onto any server, anywhere, and fix critical bugs faster than your teammates can even launch their IDE.

2. Understanding the Logic: The Three Pillars of Vim

If you want to get good at Vim, you have to wrap your head around one core idea: Vim isn’t like most editors. Most editors just let you type and that’s it. But Vim works in modes. It assumes you spend way more time bouncing around, editing, and fine-tuning code than cranking out long paragraphs.

Normal Mode: Command mode

In other editors, “Normal” just means you’re typing. In Vim, Normal Mode is command central. It’s not a pause. Imagine you’re flying a plane. You’re not always gripping the stick—sometimes you’re flipping switches or checking gauges, steering without ever “writing.” When you’re in Normal Mode, every key is a shortcut. No more Ctrl+Shift+Whatever. Want to delete? Just tap ‘d’. Need to find something? Hit ‘f’. It feels like flight mode—smooth, fast, a little dangerous. You should be in Normal Mode almost all the time. If you’re not actively typing, just hit Esc and you’re back in the cockpit.

Insert Mode: The Workstation

Insert Mode is the only part that feels like a regular editor. Press ‘i’ and you can type. Simple. But here’s the catch: beginners get stuck here and start using arrow keys to move around. Don’t fall for it. Avoid navigating in Insert Mode; return to Normal Mode for movement. Just drop in, type what you need, and hit Esc to pop back out.

Visual Mode: The Highlighter

You get here with ‘v’ (for characters), ‘V’ (for lines), or Ctrl+v (for blocks). Visual Block mode is a lifesaver, especially for DevOps folks. For tasks like mass-commenting YAML or re-indenting code blocks, Visual Block mode provides the ability to edit across multiple lines simultaneously. This vertical precision is far more efficient than handling lines one by one.

The Grammar of Vim: Thinking in Sentences

If you try to memorize every Vim command as a unique shortcut, you will fail. Instead, you need to understand the Vim Grammar. Vim operates on a simple syntax: [Number] + [Verb] + [Noun].

It is literally a language where you tell the editor what to do, how many times, and to what object.

1. The Verbs (What to do)

These are your primary actions. Once you learn a verb, you can apply it to any object.

d — Delete: Removes text (and saves it to the clipboard).
c — Change: Deletes text and puts you in Insert Mode immediately (perfect for fixing mistakes).
y — Yank: Copies text.
> — Indent: Shifts text to the right (crucial for YAML).
v — Visual: Starts selection.

2. The Nouns (Where to do it)

In Vim, these are called Motions or Text Objects. They define the target of your action.

w — Word: From the cursor to the end of the word.
s — Sentence: A full sentence.
p — Paragraph: A block of code/text separated by empty lines.
i — Inside: A modifier that ignores the surrounding characters (brackets, quotes).
a — Around: A modifier that includes the surrounding characters.
t — Tag: For HTML/XML tags.

3. Building "Sentences" (The Magic)

When you combine them, you realize you don't need "shortcuts" anymore. You just speak the language:

di" → Delete Inside Quotes: Perfect for clearing an environment variable value like DB_PASSWORD="secret".
cap → Change Around Paragraph: Deletes an entire block of code and lets you rewrite it from scratch.
y3w → Yank 3 Words: Copies the next three words.
ci{ → Change Inside Brackets: Instantly clears a dictionary or a code block in Python/JSON.
2yy → 2 Lines: Copy two lines.

Why this is a Game Changer for DevOps

Imagine you are editing a docker-compose.yml. You need to change the image name.

Non-Vim way: Move mouse, click, hold backspace, type new image.
Vim way: Place cursor anywhere on the image line and type ci". Done. You are already typing the new name.

The "Verb + Noun" logic reduces cognitive overhead by turning edits into predictable patterns. Instead of memorizing obscure shortcuts, you are applying a consistent syntax to the file.

3. Minimal production-safe Vim configuration (`.vimrc`)

When you are on a production server, you rarely have the luxury of installing heavy plugins or custom themes. You need a configuration that is lightweight, portable, and powerful. Create a .vimrc file in your home directory and add these lines. The logic behind this setup:

" --- Minimal Vim setup ---
syntax on                   " Enable syntax highlighting
set number                  " Show absolute line number
set relativenumber          " Show relative line numbers
set tabstop=4               " Number of visual spaces per TAB
set softtabstop=4           " Number of spaces in tab when editing
set expandtab               " Tabs are spaces (crucial for Python/YAML)
set ignorecase              " Case insensitive searching
set smartcase               " Case sensitive if search contains uppercase
set undofile                " Maintain undo history between sessions
set cursorline              " Highlight the current line

Why these specific lines?

set relativenumber (The Jump Master): This one completely changes how you move around. With number, you just see your current line. But with relativenumber, every line gets a number showing how far it is from where you are.

Picture this: you spot an error 12 lines above. No more guesswork or holding the up arrow forever. You see “12” next to that line, type 12k, and boom—you’re there.

set undofile (The Time Machine): Normally, Vim wipes out your undo history as soon as you close a file.

Real life: You tweak a config, save, restart the service, and suddenly nothing works. Five minutes later, you realize you messed up. With undofile, you just reopen the file and start hitting u—it’ll undo changes from your last session. Absolute lifesaver when you’re scrambling to fix things.

set expandtab & set tabstop=4 (The YAML Guard): Anyone who’s fought with Docker, Kubernetes, or Ansible knows the pain—a single Tab character where spaces should be, and your whole setup falls apart. These settings make Vim insert four spaces every time you hit Tab, so your YAML and Python files stay squeaky clean.
set ignorecase & set smartcase (Efficient Hunting): Digging through a giant log? You don’t want to think about “Error” vs “error.”

Here’s how it works: ignorecase makes all searches lowercase by default, but if you type a capital letter, smartcase kicks in and matches exactly. You find stuff faster, no fuss.

set cursorline (The Visual Anchor): Ever lose track of your cursor in a wall of white-on-black text? This draws a subtle highlight under your current line, so your eyes don’t get lost when you’re picking through big config files.

The Plugin Trap: Why "Vanilla" is Your Best Friend

Scroll through Vim tutorials on YouTube and you’ll spot all kinds of flashy setups—glowing status bars, file trees like NERDTree, AI-powered autocompletion. Looks cool on your laptop. But honestly, for DevOps and operations engineers, that stuff can set you up for trouble.

The Reality of Remote Work: In your daily job, you will often find yourself inside a restricted environment:

A locked-down production server where you cannot download external plugins from GitHub.
A temporary Docker container that will be destroyed in 10 minutes.
A machine with no internet access (Air-gapped environment).

Why Minimal is Better:

Zero Setup Time: If your productivity depends on 20 plugins, you are useless the moment you SSH into a clean server. An experienced engineer is just as fast on a "bare-bones" Vim as they are on their local machine.
Compatibility: Plugins can break between different Vim versions (or if you encounter the older vi). Native commands work exactly the same way they did 30 years ago.
The professional proficiency: There is a specific kind of respect you earn when your colleagues see you perform complex refactoring on a "naked" terminal without any fancy visual aids.

The Strategy: Learn the native ways to do what plugins do.

Don't need a file tree? Use :Ex (the built-in Netrw file explorer).
Don't need a fancy status bar? Use Ctrl + g to see your location.
Don't need a search plugin? Use / and :grep.

Master the tool, not the plugins. You want to be the engineer who brings the skills to the server, not the one who needs to bring their whole "toolbox" just to fix a single line of code.

There is nothing more soul-crushing than SSH-ing into a jump host to fix a SEV-1 issue, only to find that your fancy Neovim config is throwing Lua errors because the server is running an ancient version of GLIBC. In restricted production environments, tooling is minimal. Travel light or get stuck.

4. Efficient Navigation: Don't Walk, Jump

The arrow keys are the enemy of speed. In a standard editor, to move to a specific character at the end of a line, you hold the right arrow or use the mouse. In Vim, you jump.

In-line movement: The "Find" and "Till" commands

As an operations engineer, you often edit long lines—think of an ENTRYPOINT in a Dockerfile or a long list of arguments in a bash script.

Vim gives you two surgical tools for horizontal movement: f and t.

f (Find): Moves the cursor forward to the next occurrence of a character.
Example: You are at the start of a line: IMAGE="python:3.11-slim". You want to change the version. Type f: and your cursor jumps directly to the colon.
t (Till): Moves the cursor forward to the character just before the one you specify.
Example: On that same line, type t" to jump right to the end of the version number, but before the closing quote.
The "Backwards" version: Use capital F or T to perform the same jumps in the opposite direction (to the left).

Advanced tip: You can combine these with your verbs.

df_: Delete everything from the cursor forward until (and including) the underscore.
ct.: Change everything up to the dot (perfect for fixing IP addresses or domain names). #### Search as Navigation

Most people use search (/) to find a word. A pro uses it to move.

Instead of hitting j (down) twenty times to get to the volumes: section in a docker-compose.yml, just type /vol and hit Enter.
n: Jump to the next match.
N: Jump to the previous match.

By combining f, }, and /, you stop "walking" through your files and start "zipping" across them. Your eyes stay on the code, and your hands stay on the home row.**

File Movement: Mastering the Structure with `%`

In the world of on-call support, you aren't just looking at plain text; you are looking at structured data. Whether it's a massive JSON response from an API, a complex Kubernetes manifest, or a nested Nginx configuration, losing track of where a block starts and ends is a common headache.

The % (The Bracket Matcher): This is your "breadcrumb" tool. Place your cursor on any brace {, bracket [, or parenthesis ( and hit %. Vim will instantly teleport your cursor to the matching closing character. Hit % again to jump back to the start.

The Operations use-case: You are debugging a docker-compose.yml (converted to JSON) or a massive HCL file in Terraform. Instead of scrolling and squinting at indentation, you hit % and you’re at the bottom.

Combining with Verbs (The Power Move): Remember the Verb + Noun logic? You can use % as a noun.

d%: Delete everything from the current bracket to its match. This is the fastest way to wipe out an entire misconfigured JSON object.

v%: Visually select the entire block. Useful if you need to copy a specific section of a config.

Moving by Line Numbers: If a colleague tells you, "Check the error on line 452," don't scroll.

Type 452G (or :452) to jump directly to that line.

Type gg to go to the very first line.

Type G to go to the very last line (perfect for checking the latest entries in a log file).

Search as Navigation: Teleporting to the Target

When you are dealing with a 2000-line syslog or a sprawling Terraform state file, scrolling is a waste of time. A professional operations engineer uses the search function as a teleportation device.

The Forward Search (/): Hit /, type your search term (e.g., /database), and hit Enter. You are now at the first match.

n: Jump to the next occurrence.

N: Jump to the previous occurrence.

The Backward Search (?): This is often overlooked but critical for log analysis. If you just opened a log file and jumped to the bottom (G), you want to search upwards for the latest errors.

Type ?ERROR to find the most recent incident.

The "Star" Trick (*): This is perhaps the most powerful "hidden" navigation tool. Place your cursor on any word (for example, a variable name like POSTGRES_USER) and hit *.

Vim will instantly jump to the next time that exact word appears in the file.

Use # to jump to the previous one.

Operations use-case: You see a weird variable in a script. Hit * repeatedly to trace every place that variable is used or modified without typing a single character.

The Pro Strategy: Searching to Edit Combined with the Verb + Noun logic, you can perform actions across the file.

d/warning: Delete everything from your current position until the first occurrence of the word "warning".

By mastering /, ?, and *, you stop looking for things and start arriving at them.

5. Heavy Lifting: Search, Replace, and Macros

In most editors, "Find and Replace All" feels like playing with fire. One wrong move and you’ve made a mess. In Vim, it’s a different story — you get the kind of control that lets you zero in on exactly what you want to change, no more, no less.

Global Search & Replace: Command-Line Precision

Here’s the classic Vim way to search and replace: :%s/search_term/replace_term/gc

Let’s walk through what each part does:

: drops you into command-line mode.
% tells Vim to run the command across the whole file, not just the line you’re on.
s stands for substitute.
/search/replace/ is your before-and-after.
g means change every match on each line, not just the first.
c asks for confirmation each time it finds a match.

Why the `c` Flag Matters

When you’re editing a production config, “Replace All” is just asking for trouble. Maybe your search term pops up somewhere unexpected, like inside another word. The c flag makes Vim pause at each match and ask you what to do: replace with new_term? (y/n/a/q/l)

y: Yes, go ahead and change this one.
n: Nope, leave it.
a: All — just do the rest, stop asking.
q: Quit — stop right here.

Real-World Example: You have to change every port 80 to 8080, but you don’t want to touch a stray comment or the wrong IP address. The c flag lets you check each change as you go. In a few seconds, you can avoid a huge mistake.

Advanced Tip: Ditch the Leaning Toothpicks

If you’re always editing file paths, you know the pain of escaping slashes: :%s/\/var\/lib\/docker/\/data\/docker/g. Total eyesore. Vim lets you pick another delimiter, so you can write: :%s#/var/lib/docker#/data/docker#gc — way cleaner, way less typing, and you won’t lose track of slashes.

Macros: Work Smarter, Not Harder

Let’s say you get a dump of 50 IP addresses. You need to turn them into a YAML list for Ansible or Kubernetes. Sure, you could go line by line, adding a dash and a comment over and over. That’s tedious and slow. Or you can just record a macro in Vim, run it once, and let Vim do the grunt work for you.

The Macro Logic: `q` + [register] + [actions] + `q`

q: Start recording.
a: Choose a "register" (a letter like 'a' where the macro will be stored).
Perform your edits: (Vim records every keystroke).
q: Stop recording.
@a: Play back the macro once.
50@a: Play back the macro 50 times.

Real-World Case: Formatting an IP List for YAML

You have a file that looks like this:

192.168.1.10
10.0.0.5
172.16.0.22
...

You need it to look like this:

- ip: "192.168.1.10"
  - ip: "10.0.0.5"
...

Step-by-step Macro:

Put your cursor at the start of the first line.
Press qa (Start recording into register 'a').
Press I (Capital I to insert at the very beginning of the line).
Type - ip: " then hit Esc.
Press A (Capital A to append at the end of the line).
Type " then hit Esc.
Press j0 (Move down one line and go to the beginning). This is crucial so the next playback starts in the right spot.
Press q (Stop recording).

Now, just type 50@a. Watch as Vim transforms the next 50 lines in a split second.

Why this is a "Superpower"

Consistency: Unlike manual typing, a macro never makes a typo. If it works on the first line, it works on the next thousand.
Complex Refactoring: You can use macros to delete specific columns in a CSV, wrap text in tags, or even run terminal commands on specific lines.
Brain Power: It shifts your job from "data entry clerk" to "automation architect."

6. Multi-tasking inside the Terminal

Don’t close Vim just to check another file. Seriously, that’s extra work you don’t need. One of the best things about Vim is how easily it lets you juggle multiple files without ever leaving the editor.

Splits: The Side-by-Side View

Splits change everything. If you haven’t played with them yet, give it a shot. They’re a lifesaver when you need to compare config files, glance at some reference code, or just keep two things open so you don’t lose your place.

Want to see files side by side? Type :vsplit filename and boom—they’re both there. If you’re working on a wide monitor, this is gold. Maybe you keep your Dockerfile on one side and your docker-compose.yml on the other. Suddenly, matching up ports and volumes gets a whole lot easier.

If you’d rather stack files on top of each other, go with :split filename for a horizontal split. That’s perfect if you want a small window up top for reference and your main file below.

Moving between these windows is a breeze. Just hit Ctrl+w plus a direction key (h, j, k, l). Or use the arrow keys if that feels more comfortable. To hop to the next window, hit Ctrl+w, w. Need to swap their spots? Ctrl+w, r flips them instantly. It’s all pretty straightforward.

Tabs: Organized Workspaces

While splits are for looking at files simultaneously, Tabs are for organizing different tasks.

:tabnew filename: Opens a file in a completely new "page".
gt: Go to the next tab.
gT: Go to the previous tab.
Practical strategy: Use Tab 1 for your main configuration and Tab 2 for browsing logs in the same Vim session.

The Power of Diffing

If you need to find why a service works on Server A but fails on Server B, use Vimdiff.

From the terminal: vimdiff file1.conf file2.conf
Vim will open both files and highlight the exact differences in red. It’s the fastest way to spot a missing semicolon or an incorrect IP address between environments. #### The Secret Command: Integrating the Shell

Vim isn't just a text editor; it’s a shell-aware power tool. The :r ! command (read from bang) allows you to execute any Linux command and dump its output directly into your current buffer at the cursor's position.

The Syntax: :r !<command>

Real-World Operations Use Cases

Documenting an Incident: If you are writing a post-mortem or a log entry and need the exact timestamp:

Type: :r !date

Result: Mon Jan 19 12:45:22 UTC 2026 appears instantly on the line below.

Populating Configs with File Lists: You are editing an Nginx config and need to include a list of all .conf files in a directory:

Type: :r !ls /etc/nginx/conf.d/

Result: All filenames are inserted directly into your config. No more manual typing or typos.

Grabbing Network Info: Need to put the server's public IP into a script?

Type: :r !curl -s ifconfig.me

Result: Your external IP is fetched and pasted automatically.

Advanced: Filtering Text through Shell

You can also send text from Vim to a command and get it back.

Example: You have a messy list of unsorted IDs.
Action: Highlight them in Visual Mode and type :!sort.
Result: Vim sends those lines to the Linux sort utility and replaces them with the sorted output.

With tricks like these, Vim isn’t just a text editor—it’s pretty much an extension of your terminal. You’re not just editing files; you’re wielding the full power of your OS, right inside Vim.

7. Real-world Scenarios (The Practical Meat)

In the quiet of a local dev environment, speed is a luxury. In the middle of an incident, speed is a metric. Here is how you apply "The Vim Way" to incident-response scenarios.

Scenario A: Fixing Nginx Under High Pressure

The Situation: You just pushed a config change. Nginx fails to reload. You run nginx -t and it screams: syntax error in /etc/nginx/sites-enabled/starcom.org:25.

The Amateur Way: 1. Open the file: /etc/nginx/sites-enabled/starcom.org. 2. Hold the down arrow to reach line 25. 3. Realize you scrolled too fast, move back up. 4. Squint at the screen to find the typo.

Efficient approach:

Precision Entry: Open the file exactly where the error is: vim +/proxy_pass /etc/nginx/sites-enabled/starcom.org (Vim opens, and your cursor is already blinking on the broken line).
Visual Anchor: Thanks to set cursorline in your .vimrc, the problematic line is highlighted. You don't need to look for it; it’s looking at you.
The Sniper Fix: You see proxy_passs. You need to kill that last 's'. You don't enter Insert mode. You just type: $x ($ jumps to the end of the line, x deletes the character under the cursor).
The Ghost Exit: Hit Esc then ZZ.

Total time: 2 seconds. You’ve fixed the bug, saved the file, and triggered the reload before the "Amateur" even found the right line.

P.S. The domain and config files in this example are for demonstration purposes only and do not belong to me.

Scenario B: Working with large log files

The Situation: A critical service crashed, and the only evidence is buried somewhere in a 500MB .log file. You try to open it with a standard editor, and the UI freezes. You try cat, and your terminal is flooded with millions of lines you don't need.

Why Vim Wins: Unlike modern "heavy" editors, Vim doesn't try to load the entire 500MB file into the GUI memory. It uses a swap file and only loads the portion of the file you are currently viewing into RAM. It is built to be "memory-efficient" by design.

Efficient approach:

Search to Start: Don't wait for the file to "load." Open the file and immediately jump to the end where the most recent errors are: G.
The "Needle in the Haystack" Hunt: You know the crash happened around 02:15 AM. Use backward search: ?02:15.
The Surgical Extract: You found the 50 lines of the stack trace. You need to send them to a developer.

Mark the start of the block with ma (sets a local "mark" named 'a').

Move to the end of the trace.

Type :'a,.w crash_dump.txt.

Result: Vim just took the text from mark 'a' to the current line (.) and wrote it (w) into a brand new small file.

Total time: Under 30 seconds. You’ve extracted the critical data without ever needing to download the 500MB monster to your local machine or causing an Out-Of-Memory (OOM) error on the server.

Scenario C: Mass Commenting in `docker-compose.yaml`

The Situation: You are troubleshooting a stack. You need to temporarily disable three sidecar containers and their volumes in a docker-compose.yml file—about 25 lines of YAML.

Manual approach: 1. Enter Insert mode. 2. Type #. 3. Arrow key down. 4. Type #. 5. Repeat 25 times. (And probably mess up the indentation).

The Engineer’s Approach (Visual Block Mode): Vim allows you to edit vertically. This is the secret to mass-editing structured files.

Instead of wasting time in Insert mode, use Visual Block to edit vertically. It’s a three-second operation:

Select: Drop your cursor at the start of the block and hit Ctrl+v.
Expand: Tap j to highlight the vertical sliver across all lines.
Execute: Hit Shift+i, type #, and then Esc.

Vim will automatically replicate that # across the entire selection once you hit Escape. To uncomment, just repeat the selection with Ctrl+v and hit d to delete the column of # characters instantly.

The Result: Vim instantly replicates that # on every single line you selected.

Pro-Tip: Vertical Surgery & The "Silent Exit"

In high-pressure ops, every second counts toward your MTTR. Speed comes from staying in Normal Mode and avoiding the command line (:) whenever possible.

Mass Uncommenting: To quickly strip comments from a block, use Ctrl+v to select the vertical column of # characters and hit d. They all vanish at once. To mass-comment, use Ctrl+v, select the lines, hit Shift+i, type #, and hit Esc.
The Silent Exit (ZZ & ZQ): Stop wasting keystrokes on : and searching for q or w. You can vanish directly from Normal Mode:
- ZZ: Save changes and exit. It’s the equivalent of :wq, but faster because it doesn't require command-line mode.
- ZQ: Quit without saving. The equivalent of :q!, essential when you've opened a production config just to "look" and want to ensure zero accidental edits.

8. Conclusion: The Path to Muscle Memory

Learning Vim feels a lot like picking up a guitar for the first time. It’s clumsy, kind of frustrating, and honestly, you might wonder why you’re even bothering. Your fingers go wild, nothing feels natural, and quitting starts to sound pretty good. But if you push through, things shift. Suddenly, the keys start meaning something. Your hands just know where to go. One day you realize you’re not thinking about how to type anymore—you’re just getting things done.

How to Survive Past Day Two

People always talk about this magical “Vim Peak,” but The reality is—most folks never get there. They drop out in what I call the “Vim Valley,” stuck during those rough early days where everything’s confusing and slow. Want to make it across? Here’s what actually helps:

The One Window Rule: Don’t toss your favorite IDE yet. Just use Vim for quick terminal edits—editing a crontab, tweaking .bashrc, that kind of thing. Stack up those small wins. They count.
Unbind Your Arrow Keys: Want to get better, faster? Put this in your .vimrc:

noremap <Up> <Nop>
noremap <Down> <Nop>
noremap <Left> <Nop>
noremap <Right> <Nop>

It’s rough, but it forces you to use h, j, k, and l. That’s where real muscle memory starts.

The vimtutor Ritual: Every Linux box has vimtutor. Run it once a day for a week. It takes fifteen minutes, tops. After a week, you’ll be faster than most of your friends.

Operational ROI

If you're on-call, or in operations, or working in DevOps, you’re not just learning another editor. You’re buying peace of mind.

When production’s on fire, you don’t have time to fumble through key commands. You want to focus on what matters - hunting down that nasty bug hiding in your config. With Vim, the editor melts away. You just think, “delete that part” and it happens.

The terminal is your home base. Vim is your power tool. Learn it, and you’ll never panic when you’re dropped onto a blank server at 3 AM.

Practice Challenge

Want to stop Googling “how do I quit Vim” for good? Here’s how you level up:

Make vimtutor your morning warmup. Fire it up every day for five days. That’s it—fifteen minutes each time. By the end, your fingers will start reaching for dw or y before your brain even catches up.
Extreme Mode: Go cold turkey—ditch VS Code for a full week. It’s rough in the beginning, no question. But without the crutch of a GUI, you adapt fast. After a few days, you won’t even miss your mouse when moving a line.

Mastering the syntax moves the complexity into muscle memory. During high-priority outages, you can't afford the cognitive load of remembering commands—you need to focus entirely on the recovery.

Vim provides a consistent editing environment across servers, containers, and recovery systems. A small set of core motions and operators is enough to perform safe and fast edits during incident response and production maintenance.

Summary

If you work in Site Reliability or Support, you know the number that matters—MTTR. Mean Time To Recovery. Every minute counts. Every outage costs money, hurts your team, and wrecks your night. Getting fast in the terminal isn’t about showing off. It’s about saving those precious minutes and getting things running again.

That’s the difference. An amateur gets lost in logs, clicking around for five minutes. An experienced Vim user can locate the error, apply a precise edit, and restart the service quickly.

Master Vim and you’re not just adding another tool. You’re giving yourself an edge for the moments when everything’s on the line. Vim is a practical tool for fast, low-risk edits in production and incident workflows. Learn a small set of core motions and operators first, then expand gradually.

Stop Shipping Fat Python Docker Images: Multi-Stage Builds Explained

Alexey Cherednichenko — Sat, 17 Jan 2026 19:35:49 +0000

Hey folks! Let’s be honest — if you’ve ever dockerized a basic Python app, you’ve probably run into this: you build a tiny Flask “Hello World” project, and somehow the Docker image balloons to almost a gigabyte. Feels a bit like shipping a single pizza in a cargo freighter.

So, what’s happening? Why do these Python images blow up in size?

Overview

The "Fat" Image Problem

1) Invisible Bloat: pip install pulls in all sorts of stuff behind the scenes. If your app uses pandas or psycopg2, for example, you’ll need build tools like gcc just to get them installed. Once pip’s done, those tools stick around, eating up space for no good reason.
2) The Base Image Trap: If you start with something like FROM python:3.11, you’re basically dragging along a full-blown Debian OS — utilities, tools, and a bunch of extras that your app will never touch in production.
3) Hidden Leftovers: Pip caches, temporary files, and build artifacts. They just pile up, taking up room and serving no purpose once the image is built.

Why It Matters (The L3 Perspective)

I deal with this stuff every day as an L3 Support Engineer. And it’s not just about storage. Every unnecessary megabyte is another opportunity for attackers. If someone breaks into your container, all those extra tools (like gcc, curl, or git) give them a head start to compile exploits or move laterally through your network.

The Plan

We want images that are lean, locked down, and fast. Here’s what we are going to achieve:

1) Shrink your image size by as much as 80%.
2) Strip out build tools before production for tighter security.
3) Speed up your CI/CD pipeline.

The trick? Multi-Stage Builds. Let’s get into it.

Step 0: The Project Setup

Before we even touch Docker, let’s get our bearings with a simple Python app. The setup looks like what you’d see in most real-world projects.

Project Structure:

my-python-app/ 
├── templates/ 
│   └── index.html
├── app.py 
├── requirements.txt 
└── Dockerfile

templates/index.html:

<!DOCTYPE html>
<html>
<head>
    <title>Docker Slim App</title>
</head>
<body>
    <h1>Docker Multi-stage is working!</h1>
    <p>This image is slim, secure, and production-ready.</p>
</body>
</html>

app.py (A simple Flask app):

from flask import Flask, render_template

app = Flask(__name__)

@app.route('/')
def hello():
    return render_template("index.html")

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

requirements.txt:

flask==3.0.0

Step 1: Use a Specific Base Image

Let’s talk about the FROM instruction. This line sets the foundation for your whole Dockerfile. Most folks just slap in FROM python:3.11 and call it a day. The problem? That image is a monster.

You actually have two lighter choices: Alpine and Slim.

Now, Alpine gets a lot of hype because it’s tiny—the base is only about 5MB. Sounds great, right? But if you’re working with Python, Alpine often causes additional complexity for Python workloads because most wheels expect glibc.

Here’s the deal: Alpine uses musl libc, but almost all pre-built Python packages (wheels) expect glibc (which you’ll find on Debian or Ubuntu). With Alpine, pip can’t use those wheels. Instead, it tries to build everything from scratch. That quick 30-second install? Suddenly, it drags out for 20 minutes and usually dies with some confusing error.

The Pro Move: Go with Python-Slim. It’s basically Debian, but trimmed down. You get glibc compatibility, so your packages install fast, and the base image is still only about 120MB. No headaches, no drama.

# Start with the slim version for stability and speed
FROM python:3.11-slim

Step 2: The "Builder" Stage (Compiling Dependencies)

# Stage 1: The Builder
FROM python:3.11-slim as builder

# Install system dependencies needed for building packages
# Since we are on a Debian-based image (like Ubuntu), we use apt
RUN apt-get update && apt-get install -y --no-install-recommends \
    build-essential \
    gcc \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app

# Create the virtual environment
RUN python -m venv /opt/venv
# Ensure subsequent commands use the venv
ENV PATH="/opt/venv/bin:$PATH"

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt \
    && pip install --no-cache-dir gunicorn

Why bother with a virtual environment inside Docker?

Yeah, Docker containers are already isolated. But when we use /opt/venv, we keep all our installed libraries tucked away in one spot. Later, instead of chasing files all over the place, we just grab that one folder and we’re good to go.

Step 3: The "Final" Stage (The Lean Runner)

Now for the fun part. We start fresh with a slim image—no compilers, no build tools, nothing extra.

# Stage 2: The Production Image
FROM python:3.11-slim

WORKDIR /app

# Copy the virtual environment from the builder
COPY --from=builder /opt/venv /opt/venv

# Bring in the app code and templates
COPY . .

# Set some environment variables
ENV PATH="/opt/venv/bin:$PATH" \
    PYTHONDONTWRITEBYTECODE=1 \
    PYTHONUNBUFFERED=1

EXPOSE 5000

CMD ["gunicorn", "-b", "0.0.0.0:5000", "app:app"]

So, what’s actually going on here?

1) COPY --from=builder: This is what makes multi-stage builds awesome. We tell Docker, “Hey, grab only the /opt/venv folder from our heavy builder image and drop it in here.”

2) PYTHONDONTWRITEBYTECODE=1: Stops Python from scattering .pyc files everywhere. Keeps things tidy.

3) PYTHONUNBUFFERED=1: Super important for Docker. It makes sure all your logs and print statements show up right away in the terminal, not stuck waiting somewhere.

Step 4: Security Hardening (Non-Root User)

Never run your app as root in production. If someone finds a bug in your code and breaks in, you don’t want them running wild as the most powerful user in the system.

To lock things down, you need a dedicated user with limited access.

Updated Final Stage:

# Stage 2: The Production Image
FROM python:3.11-slim

# Add a new group and user just for your app
RUN groupadd -r appuser && useradd -r -g appuser appuser

WORKDIR /app

# Bring in the virtual environment from the builder stage
COPY --from=builder /opt/venv /opt/venv

# Copy your code and hand it over to the new user
COPY --chown=appuser:appuser . .

# Set up environment variables
ENV PATH="/opt/venv/bin:$PATH" \
    PYTHONDONTWRITEBYTECODE=1 \
    PYTHONUNBUFFERED=1

# Make sure everything below runs as the non-root user
USER appuser

EXPOSE 5000

CMD ["gunicorn", "-b", "0.0.0.0:5000", "app:app"]

Why bother with all this?

1) groupadd & useradd: You’re making a user called appuser. No password, no home directory, nothing fancy. It’s just there to run your app and nothing else.
2) --chown=appuser:appuser: As soon as your code lands in the image, it belongs to appuser. No root access, no extra powers.
3) USER appuser: This one’s huge. Now, everything after this — including your app itself — only runs with the limited permissions of appuser.

Step 5: Don't Forget the .dockerignore

Think of .dockerignore as Docker’s version of .gitignore. It tells Docker, “Hey, when I copy everything over, skip these files.”

If you miss this, you could end up copying your whole local venv into the image and mess up the clean one you built earlier.

Just drop a .dockerignore file in your project’s root directory:

.git
.gitignore
__pycache__/
*.pyc
venv/
.env
.vscode/

Why does this matter so much?

Stops needless rebuilds: If you change a random local file (like a README or git log), Docker won’t waste time rebuilding your image layers from scratch.
Protects sensitive stuff: You don’t want .git history or .env files — especially with secrets or passwords — ending up in your production image.
Speeds things up: Your build context shrinks. Less junk to copy means your build kicks off almost immediately.

Conclusion

Let’s see what we started with and where we ended up. These changes took a clunky, insecure container and turned it into something you’d actually want running in production.

Feature	Standard FROM python:3.11	Our Multi-Stage Image
Final Size	~467 MB	~154 MB
Security	Runs as `root` (Dangerous)	Non-root user (Secure)
Compilers	`gcc`, `build-essential` present	Removed
Cleanliness	Contains pip cache & junk	Only necessary files

Shrinking the image by almost 85% isn’t just good for bragging rights. Now deployments go faster, you save on storage, and your security gets a serious upgrade. Take it from me—when your image is lean, you have fewer weird issues, and way fewer middle-of-the-night emergencies.

Before you send your next Python image to the registry, double-check these:

Before you push your next Python image to the registry, run through this quick checklist:

Use a -slim base image. Don’t pull in the whole kitchen sink unless you have to.
Build in stages. Compilers and headers stay in the builder; keep your final image tidy.
Bundle dependencies with venv. Keep everything in a single, portable folder.
Never run as root. Spin up a dedicated appuser instead.
Check your .dockerignore. Don’t ship .git, secrets, or __pycache__ by accident.

6. Set PYTHONUNBUFFERED=1. That way, your logs actually show up in real time.

Honestly, good DevOps isn’t just about getting things to work. It’s about doing it efficiently and securely. Multi-stage builds are an easy win if you want to step up your Docker game.

Clean Up!

One last thing—multi-stage builds sometimes leave behind a <none> image (that’s just the builder stage hanging around). Tidy up your system with:

docker image prune

Happy hacking!

SSH Hardening on Linux: A Practical Step-by-Step Guide

Alexey Cherednichenko — Fri, 16 Jan 2026 19:23:02 +0000

Overview

Hey folks! Let’s talk about SSH—the go-to tool for managing remote Linux servers. It’s super useful, but honestly, out-of-the-box, it’s like a magnet for automated attacks. Here’s what I’ve learned as an L3 Support Engineer about locking down SSH:
1) Ditch passwords. Go with Key-Based Authentication. It’s way stronger.
2) Don’t make it easy for attackers. Change the default port to reduce automated bot noise (not a real security boundary) and turn off root login.
3) Set up Fail2Ban. It automatically blocks brute-force attempts, so you don’t have to keep an eye on logs all day.
4) Double-check your setup. Audit your config so you don’t accidentally lock yourself out. That’s it—these steps make SSH a lot tougher for attackers to mess with.

Step 1: Ditch Passwords for SSH Keys

Passwords just don’t cut it when it comes to keeping your server safe. Automated bots hammer away, guessing thousands of passwords every minute. But if you switch to SSH keys, brute-force attacks basically stop being a problem.

Making a Secure Key Pair

Open up your local machine and make yourself a strong, modern key with the Ed25519 algorithm. It’s not only faster than old-school RSA, it’s a lot more secure.

ssh-keygen -t ed25519 -C "admin@example.com"

Step 2: Change the default port and turn off root login

Once you’ve set up your keys, it’s time to lock the door for real and ditch passwords altogether. We're going to tweak the /etc/ssh/sshd_config file so only key-based logins work.

Heads up—leave one SSH session running while you’re editing. If you mess something up and restart the service, you don’t want to lock yourself out.

Go ahead and open up the config file:

sudo vi /etc/ssh/sshd_config

Essential Security Tweaks

Update the following directives in the file:

# 1. Change the default port to dodge automated bots
Port 2222 

# 2. Disable root login. Always use a sudo user instead.
PermitRootLogin no

# 3. Disable password authentication entirely
PasswordAuthentication no

# 4. Limit the number of failed attempts before disconnection
MaxAuthTries 3

# 5. Only allow specific users to log in (Whitelist)
AllowUsers your_username

After saving the file, check the configuration for syntax errors:

sudo sshd -t

If there is no output, restart the service:

sudo systemctl restart ssh

Step 3: Set up Fail2Ban.

Even after you move SSH to a different port and turn off password access, bots still sniff around. Your logs will fill up with failed attempts. That’s where Fail2Ban comes in. It watches for trouble and blocks shady IPs automatically, so you don’t have to babysit your server.

Installation

First, install the service on your server:

sudo apt update && sudo apt install fail2ban -y

Configuration

Instead of editing the main config, we create a .local file to override the defaults. This ensures your settings stay intact during updates.

sudo vi /etc/fail2ban/jail.local

Add the following configuration for your hardened SSH service:

[sshd]
enabled = true
port    = 2222
filter  = sshd
logpath = /var/log/auth.log
maxretry = 3
findtime = 10m
bantime = 1h

1) maxretry: Number of failures before a ban.
2) bantime: How long the offender is blocked (1 hour in this case).

Step 4: Restart the service to turn on protection

sudo systemctl restart fail2ban

Want to see which IPs Fail2Ban has blocked or check your jail’s status? Run:

sudo fail2ban-client status sshd

Conclusion

Locking down your servers isn’t something you set and forget. Ditching password logins, switching up default ports, and letting Fail2Ban handle brute force attacks—these moves shut the door on most lazy hackers.

Honestly, this is just the baseline for any serious server. If you’re ready to bump things up, try adding Two-Factor Authentication or set up a VPN or jump host for extra protection.

Got a favorite SSH security tip? Or maybe you’ve run into a bizarre lockout? Drop your stories in the comments—I’d love to hear them.

DEV Community: Alexey Cherednichenko

Vim for DevOps: Practical Editing Techniques for Remote Operations

1. Introduction: Why Vim matters for remote ops

Learning path overview

2. Understanding the Logic: The Three Pillars of Vim

Normal Mode: Command mode

The Grammar of Vim: Thinking in Sentences

1. The Verbs (What to do)

2. The Nouns (Where to do it)

3. Building "Sentences" (The Magic)

Why this is a Game Changer for DevOps

3. Minimal production-safe Vim configuration (.vimrc)

Why these specific lines?

The Plugin Trap: Why "Vanilla" is Your Best Friend

4. Efficient Navigation: Don't Walk, Jump

In-line movement: The "Find" and "Till" commands

File Movement: Mastering the Structure with %

Search as Navigation: Teleporting to the Target

5. Heavy Lifting: Search, Replace, and Macros

Global Search & Replace: Command-Line Precision

Why the c Flag Matters

Advanced Tip: Ditch the Leaning Toothpicks

Macros: Work Smarter, Not Harder

The Macro Logic: q + [register] + [actions] + q

Real-World Case: Formatting an IP List for YAML

Why this is a "Superpower"

6. Multi-tasking inside the Terminal

Splits: The Side-by-Side View

Tabs: Organized Workspaces

The Power of Diffing

Real-World Operations Use Cases

Advanced: Filtering Text through Shell

7. Real-world Scenarios (The Practical Meat)

Scenario A: Fixing Nginx Under High Pressure

Scenario B: Working with large log files

Efficient approach:

Scenario C: Mass Commenting in docker-compose.yaml

Pro-Tip: Vertical Surgery & The "Silent Exit"

8. Conclusion: The Path to Muscle Memory

How to Survive Past Day Two

Operational ROI

Practice Challenge

Summary

Stop Shipping Fat Python Docker Images: Multi-Stage Builds Explained

Overview

The "Fat" Image Problem

Why It Matters (The L3 Perspective)

The Plan

Step 0: The Project Setup

Step 1: Use a Specific Base Image

Step 2: The "Builder" Stage (Compiling Dependencies)

Why bother with a virtual environment inside Docker?

Step 3: The "Final" Stage (The Lean Runner)

So, what’s actually going on here?

Step 4: Security Hardening (Non-Root User)

Updated Final Stage:

Why bother with all this?

Step 5: Don't Forget the .dockerignore

Why does this matter so much?

Conclusion

Before you send your next Python image to the registry, double-check these:

6. Set PYTHONUNBUFFERED=1. That way, your logs actually show up in real time.

Clean Up!

SSH Hardening on Linux: A Practical Step-by-Step Guide

Overview

Step 1: Ditch Passwords for SSH Keys

Step 2: Change the default port and turn off root login

Essential Security Tweaks

Step 3: Set up Fail2Ban.

Installation

Configuration

Step 4: Restart the service to turn on protection

Conclusion

3. Minimal production-safe Vim configuration (`.vimrc`)

File Movement: Mastering the Structure with `%`

Why the `c` Flag Matters

The Macro Logic: `q` + [register] + [actions] + `q`

Scenario C: Mass Commenting in `docker-compose.yaml`