Last week, we revealed the Free Tmux course. I am also working on creating roadmaps so that members can follow a dedicated learning path with all the resources we have created in the last 8 years.

Next week, we should have the GitOps course, focusing on ArgoCD. This will build upon the foundation of the Git basics course.

Essential Linux concept: diff

All that Git talk actually rests on a very old, very simple Linux idea. You compare two versions of something, and then you act on the difference.

That's exactly what the diff command does. You give it two files, and it tells you what you'd need to change in one to make it match the other. It's the same mental model your version control uses under the hood.

The output looks cryptic the first time you meet it, with things like 2c2, 3a4 and 5d5. Once you learn to read it, it makes complete sense. We explain the output line by line in this guide.

Here's the part most of us forget: diff isn't limited to single files. With diff -r you can compare two entire directories and spot exactly how two config folders drifted apart. And if you find yourself creating temporary files just to compare two command outputs, process substitution lets you do it in one line: diff <(command1) <(command2).

💡Quick terminal tip

Using history expansions like !$ (last argument) or !! (entire previous command) can feel like a gamble when running destructive operations. You only see what it resolved to after you have pressed the Enter key.

Bind Readline's magic-space to expand history references instantly as soon as you press the Spacebar:

Open the ~/.inputrc file and add the following line at the end.

Space: magic-space

Restart the terminal session.

When you type sudo !! or rm -rf !$ and hit Space, the shell immediately replaces the tokens with the full command string right in front of your eyes. You can review, edit, or back out before executing, eliminating both keystrokes and blind execution risk.

🛠️ Tool discovery

Let's see if you find your next favorite tool.

Monoscope: Open-Source Observability and Trace Aggregator for Distributed Microservices

Monoscope is an open-source observability engine tailored for developers needing unified log, metric, and distributed trace visibility across local containers and multi-service staging environments.

GitHub - monoscope-tech/monoscope: Monoscope lets you ingest and explore your logs, traces and metrics. We store these in S3 compatible buckets. Query in natural language via LLMs.

Monoscope lets you ingest and explore your logs, traces and metrics. We store these in S3 compatible buckets. Query in natural language via LLMs. - monoscope-tech/monoscope

GitHubmonoscope-tech

Colanode: Open-Source, Local-First Collaboration Workspace

Colanode is an open-source, local-first collaboration platform designed to unify documents, structured databases, real-time chat, and file management under a self-hosted architecture.

GitHub - colanode/colanode: Open-source and local-first Slack and Notion alternative that puts you in control of your data

Open-source and local-first Slack and Notion alternative that puts you in control of your data - colanode/colanode

GitHubcolanode

📣 Event alert

AGNTCon + MCPCon Europe is happening in Amsterdam on 17–18 September, and if you're building anything in the agentic AI or MCP space, this is the event to attend.

The event is full of open source maintainers, enterprise engineers, infra and tooling folks, and researchers.

You'll bump into the people building MCP itself, alongside teams from AWS, Google, Hugging Face, Microsoft, Anthropic, Solo.io, and a long list of startups exploring Agentic AI.

You can knock off your ticket prices with code ITSFOSS_50.

🗓 17–18 September
📍 RAI Amsterdam

📰 Linux news that matters

• Broadcom has quietly removed all public download pages for the VMware Virtual Disk Development Kit (VDDK), restricting future access exclusively to authorized Technology Alliance partners.
• Threat actors are actively breaching F5 BIG-IP APM appliances to deploy "PoisonedRefresh," a stealthy Linux rootkit that persists across firmware upgrades and modifies SELinux policies.
• CERN is migrating over 2,200 accelerator control computers to Debian 13 to bypass restrictive enterprise CPU requirements and modernize hardware lifecycle management. In a parallel push toward digital sovereignty, the Swiss government has launched a CHF 9 million pilot deploying openDesk to replace Microsoft 365 across 3,000 federal workstations.
• Intel's Dynamic PAMT support has been queued in the x86/tdx tree for Linux 7.4, reducing the ~0.4% baseline memory overhead required by Trust Domain Extensions by allocating the Physical Address Metadata Table dynamically rather than upfront.
• Google has open-sourced Mantis under Apache 2.0, providing a modular framework of slash-command skills that enables AI coding agents to manage end-to-end vulnerability triage.

😂 Geek humor

💌 Keep on loving Linux Handbook

GitOps course is nearly ready. It should arrive next week.

Perfect time to become a Pro member and enjoy unlimited access to our eBooks, courses and in-depth tutorials.

Missed the previous editions? You can access the newsletter archives.

You may also contribute to Linux Handbook and share your experience and expertise with the community.

I like reading your messages, so just hit the reply button and share your thoughts 😄

We have a new course, Tmux Fundamentals. As evident from the name itself, the course teaches you the fundamentals of Tmux.

A terminal multiplexer like Tmux is a lifesaver if you connect to remote servers via SSH. No more session drops because your laptop went in sleep mode or if you forgot to stay connected in the terminal.

Tmux has a little learning curve, and that's the reason we created this new course. It is available to everyone for free. Enjoy 😄

Tmux Fundamentals: Free Course on Terminal Multiplexing

Never lose a terminal session again! Learn tmux sessions, panes, and windows in this free, beginner-friendly course. No signup required.

Linux HandbookYash Kiran Patil

Essential Linux concept: Named pipe redirection

Most linux users are familiar with the concept of redirection. One of the redirections is pipe. The vertical line | in the commands gives Linux an incredible power for combining commands.

But did you know that there is also named pipes that exist like a file in the system. Well, everything is file in Linux so that's not surprising. Named pipes can store output in memory buffer. It's an interesting concept that most of us Linux users don't come across every day.

Pipe redirection in Linux: Named and Unnamed Pipes

There are two kinds of pipes in Linux: named and unnamed. Here’s a detailed look at pipe redirection.

Linux HandbookDebdut Chakraborty

Interested in Linux kernel developments?

Linux Foundation's instructor led training program on Linux Kernel Internals and Developments is for you. The course is designed to provide experienced programmers with a solid understanding of the Linux kernel.

It is an instructor-led virtual session that will run from 9 to 5 for 4 days. Which means that it is like attending a training class but live on your computer. The next session runs on 28th September.

If you are working in a company, you can ask your boss or company to pay for this training. Tell them that you are getting a 50% discount with ILTGTRITSFOSS coupon code that saves $1750 on this specialized course.

💡Quick terminal tip

In a pipeline like commandA | commandB | commandC, the shell only records the exit code of the final command (commandC), quietly masking crashes or errors produced upstream.

Bash solves this with the built-in ${PIPESTATUS[@]} array, which captures the discrete exit codes of every stage in your pipeline.

For example, in the below command:

cat app.log | grep "FATAL" | awk '{print $2}'
echo "${PIPESTATUS[@]}"

The ${PIPESTATUS[@]} array preserves the discrete exit code of every process in the pipeline, not just the awk command.

🛠️ Tool discovery

Let's see if you find your next favorite tool.

Listmonk: Self-hosted, newsletter and mailing list manager

Listmonk is an open-source, AGPL-licensed newsletter and mailing list manager packed into a single Go binary backed by a PostgreSQL database. It features a modern web dashboard with multi-threaded SMTP queues, dynamic templating, SQL-based subscriber segmentation, and an HTTP webhook interface for transactional messaging.

GitHub - knadh/listmonk: High performance, self-hosted, newsletter and mailing list manager with a modern dashboard. Single binary app.

High performance, self-hosted, newsletter and mailing list manager with a modern dashboard. Single binary app. - knadh/listmonk

GitHubknadh

Updo: Real-Time Uptime Monitoring Tool

Updo is an open-source Go CLI tool that monitors website uptime, response latency breakdowns (DNS, TCP, TTFB), and SSL certificate expiration in real time via an interactive TUI or plain-text mode.

GitHub - Owloops/updo: Uptime monitoring CLI tool with alerting and advanced settings

Uptime monitoring CLI tool with alerting and advanced settings - Owloops/updo

GitHubOwloops

📰 Linux news that matters

• The Linux kernel is approaching 2,000 fixed CVEs per release as automated LLM analysis floods maintainers with low-priority bug reports and hallucinated fixes across obscure code paths.
• Multikernel Technologies has launched mklinux v7.0-mk2, an open-source kernel fork that allows physical servers to run multiple independent Linux kernels side by side without a hypervisor.
• Automated AI web scrapers are consuming roughly 20% of git.kernel.org's total compute capacity by requesting individual HTML commit views instead of cloning repositories directly.
• Debian has officially voted to allow generative AI tools for development, maintenance, and documentation, placing full legal and technical accountability directly on the human contributor to review and test all submissions.
• California lawmakers have passed Assembly Bill 1856, amending the upcoming Digital Age Assurance Act to formally exempt software and operating systems distributed under permissive licenses allowing copying, modification, and redistribution.

😂 Geek humor

💌 Keep on loving Linux Handbook

GitOps course is nearly ready. It should arrive next week.

Perfect time to become a Pro member and enjoy unlimited access to our eBooks, courses and in-depth tutorials.

Missed the previous editions? You can access the newsletter archives.

You may also contribute to Linux Handbook and share your experience and expertise with the community.

I like reading your messages, so just hit the reply button and share your thoughts 😄

Your SSH connection drops mid-deploy. Your laptop goes to sleep. You accidentally close the wrong tab. And just like that, the build log you were watching, the SSH session you had open on three servers, the half-finished debugging session...all gone.

Tmux fixes this.

Tmux (terminal multiplexer) lets you run multiple terminal sessions inside a single window, keep them alive even after you disconnect, and pick up exactly where you left off, on the same machine or a different one entirely.

It's one of those tools that, once you learn it, you wonder how you worked without it.

Why learn tmux?

• Sessions that survive disconnects: Close your laptop, lose your SSH connection, or walk away entirely. Your session keeps running and you reattach right where you left off.
• Split panes, no extra windows: View logs, edit a file, and run a build, all in one terminal window, side by side.
• Multiple windows, one session: Organize your work like browser tabs, but built into your terminal.
• Works everywhere: No GUI required. If you can SSH into it, you can run tmux on it.
• Build repeatable workflows: Script your entire dev environment to open exactly the way you like it, every time.

If you spend any real time in a terminal like SSHing into servers, running long processes, working across multiple projects at once, tmux isn't optional for you. You will save a lot of frustration and productive hours.

Tmux has a little learning curve, but it pays off in the long run. Ask any senior engineer.

What you'll learn

By the end of this free Tmux course, you'll be able to:

• Keep a terminal session running even after your SSH connection drops or your laptop sleeps
• Split your terminal into multiple panes and jump between them without touching your mouse
• Organize different tasks across windows, all inside a single tmux session
• Scroll back through terminal output and copy text using only the keyboard
• Set up a real, repeatable workflow instead of retyping the same commands every time
• Write your own tmux configuration so it starts up exactly the way you want, every time

No prior tmux experience needed, just basic comfort with a terminal.

Who this course is for

• Developers and sysadmins who SSH into remote servers regularly
• Anyone who's lost work to a dropped connection or an accidentally closed terminal
• Self-hosters and homelab enthusiasts managing multiple long-running processes
• Command-line users who are tired of juggling a dozen terminal windows
• Complete tmux beginners

Why learn tmux with us?

Most tmux guides stop at a keybinding cheat sheet. This course doesn't.

It's built around actually using tmux, not memorizing commands in isolation. It also includes a dedicated chapter on building a real, practical workflow, and another on writing your own tmux configuration so it feels like your terminal, not a default install.

Every chapter is short, hands-on, and something you can follow along with in your own terminal as you read.

And it's completely free. No signup, no paywall, no catch.

Ready to start?

Jump into Chapter 1: Why Tmux? Understanding Terminal Multiplexing and get your first session running in the next few minutes.

Even after all these years, some people still have a strong dislike for systemd. My colleague, Umair, stopped hating systemd after realizing its automation capabilities.

He has created two courses on systemd:

• Systemd playbook: A hands-on, text-based course to turn you into a confident systemd user.
• Systemd automation: Learn to schedule, monitor, sandbox, and optimize automated workflows.

The best way to learn anything on Linux is by getting your hands on the system. That's the approach we take on Linux Handbook.

Other than us, here are several other platforms you can use to learn DevOps with practical, hands-on labs.

Basic but essential Linux concept: <, << and <<<

You'll often see <, << and <<< in various Linux command examples. It is important to know what they mean.

• < : It is known as Input Redirection and is used to take input from a file rather than typing instructions manually.
• <<: It is known as Here Document which is used to provide multiple lines of input directly to the command.
• <<<: It is known as Here String and used to provide a single line of input to the command.

I know it sounds super complex but this article explains it in details.

What do <, << and <<< mean in Linux?

The <, << and <<< look similar to redirection indicators but they have a different purpose. Learn about them.

Linux HandbookSagar Sharma

🎫 Event alert: AGNTCon+MCPCon Japan

Whether you're building AI agents, adopting the Model Context Protocol (MCP), developing MCP servers and clients, or exploring the future of agentic AI, this is the event where the community comes together to share ideas, solve challenges, and shape what's next for the AI ecosystem.

Happening in Tokyo, Japan, on 10-11th September. If you want to attend, use coupon code ITSFOSS30 to get 30% discount on the event ticket pricing.

💡Quick terminal tip

In Bash (and other Readline-based shells), navigating complex directories often means dealing with annoying typos or mixed case sensitivity. You can make Tab auto-complete paths regardless of capitalization while cleanly expanding common file prefixes before cycling through options.

Add these lines to your ~/.inputrc file:

# Ignore uppercase/lowercase differences during Tab completion
set completion-ignore-case on

# Treat hyphens (-) and underscores (_) as equivalent
set completion-map-case on

# Complete shared prefixes before cycling through individual choices
set menu-complete-display-prefix on

Now, if you have files named Project-Alpha.txt and Project-Beta.txt, typing cd pro and pressing Tab will first safely expand your prompt to the longest shared prefix (cd Project-). Pressing Tab a second time begins stepping smoothly through each matching file, completely ignoring letter case.

🛠️ Tool discovery

Check out these hidden gems.

tuicr: Terminal Native Code Review

tuicr is an open-source Rust TUI utility designed to streamline code review workflows across multiple version control systems using modal, Vim-style navigation. The application aggregates multi-file diffs into a unified stream, allowing users to leave granular, line-level comments and submit them directly as live reviews to major code hosting platforms.

• ⚡ Terminal-native, Vim-centric diffs with seamless modal navigation
• 🔄 Multi-VCS compatibility for unified reviews across git, jj, and hg
• 💬 Inline line-level commenting submitted directly to GitHub, GitLab, and Bitbucket
• 🤖 Structured markdown export to clipboard/stdout tailored for AI agent workflows
• 🦀 Ultra-fast Rust binary delivering zero-dependency CLI execution

GitHub - agavra/tuicr: a code review TUI with vim keybindings

a code review TUI with vim keybindings. Contribute to agavra/tuicr development by creating an account on GitHub.

GitHubagavra

forgit: Interactive Git usage with fzf

Forgit is a shell utility that leverages fzf to provide interactive, terminal-native interfaces for routine version control operations. The tool integrates directly with CLI syntax highlighters while remaining lightweight and shell-agnostic across common terminal environments.

• ⚡ Fuzzy-search Git selectors with interactive diff and log previews
• 🌿 Interactive branch and worktree management for seamless switching
• 🛠️ Automated .gitignore generator to fetch templates straight from your terminal
• ⏪ Interactive rebase and fixup tools to easily squash and reorder commits
• 🎨 Extensible preview integration using external tools like delta for diffs and bat for syntax highlighting

GitHub - wfxr/forgit: :zzz: A utility tool powered by fzf for using git interactively.

:zzz: A utility tool powered by fzf for using git interactively. - wfxr/forgit

GitHubwfxr

📰 Linux news that matters

• Qualcomm has started a Linux kernel discussion about upstreaming Synx, a vendor-agnostic global synchronization framework for coordinating fences across different processors, firmware, and Linux-hosted clients.
• Linux wireless maintainer Johannes Berg has announced that AI/LLM-generated patches will generally be ignored unless a quick review makes the fix “obviously right,” following a similar move in the kernel staging area.
• Cloudflare has open-sourced Cloudflare OS (VibeSDK), an internal platform enabling non-technical personnel to build and deploy applications via natural language prompts.
• Microsoft has open-sourced code-testing-generator, an MIT-licensed polyglot unit test creation agent hosted within the dotnet/skills repository.
• Senior Linux kernel maintainer Greg Kroah-Hartman has established a explicit policy rejecting LLM-generated patch submissions targeting the drivers/staging tree.
• Sonatype researchers have identified an automated supply-chain campaign dubbed "Flooding Dropper" that has published nearly 850 malicious npm packages distributed across hundreds of disposable accounts.
• Modular has released the complete source code for the Mojo language compiler, runtime, and development tooling under the Apache 2.0 license with LLVM exceptions following its 1.0 release.

😂 Geek humor

💌 Keep on loving Linux Handbook

GitOps course is nearly ready. It should arrive next week.

Perfect time to become a Pro member and enjoy unlimited access to our eBooks, courses and in-depth tutorials.

Missed the previous editions? You can access the newsletter archives.

You may also contribute to Linux Handbook and share your experience and expertise with the community.

I like reading your messages, so just hit the reply button and share your thoughts 😄

Watching DevOps tutorials is easy. Actually knowing what to do when a server is broken at in production is not.

The gap between the two is hands-on practice and if you have been searching for structured, interactive DevOps labs, you have probably run into the same problem: most good platforms cost money, and the free ones are scattered across a dozen different sites with no clear path connecting them.

I went through the platforms the DevOps community actually recommends on Reddit, in Discord servers, in job prep threads and pulled together the 12 best ones where you can practice for free. These are not passive reading resources. Every platform here puts you in front of a terminal and makes you figure something out.

This list is not for you if you are looking for video courses or reading material that is a different category. This guide is about interactive labs, broken-server challenges, browser-based environments, and hands-on projects where you learn by doing.

Short on time? Jump to the comparison table below, or use the headers to find platforms that match your current skill level.

At a Glance: All 12 Platforms Compared

SadServers - The LeetCode of DevOps Troubleshooting

SadServers is the closest thing DevOps has to LeetCode. You are given a broken Linux or DevOps environment, a problem statement, and a timer. Your job is to fix it. No hints, no hand-holding, just a terminal and a server that is doing something wrong.

Who it's best for: Anyone who wants to practice the skill that actually matters most in DevOps: diagnosing and fixing production problems under pressure. Especially useful if you are preparing for DevOps interviews, where live troubleshooting scenarios are increasingly common.

The scenarios cover real DevOps situations: a web server that refuses to start, a disk that is mysteriously full, a process that keeps dying, a misconfigured database. Each one is an actual production-style failure.

Verdict: The single best platform for practicing the skill that defines a working DevOps engineer, fixing things that are broken. Bookmark this and do one scenario a week.

OverTheWire - Bandit: Learn Linux by Breaking In

OverTheWire Bandit is a wargame where you SSH into a live server and solve challenges to discover the password for the next level. Level 0 to Level 34, each one teaching a specific Linux skill through a concrete puzzle rather than a lecture.

Who it's best for: Complete beginners who need real Linux terminal practice and people who are comfortable with commands but want to understand file permissions, process management, and shell scripting by actually using them under pressure.

The early levels cover navigation, file reading, and hidden files. By the time you reach the middle levels, you are working with SSH keys, port forwarding, shell scripting, and basic cryptography. Every concept sticks because you needed it to progress.

Verdict: The best free tool to build Linux command-line confidence from scratch. There is a reason DevOps engineers still recommend it to juniors in 2026; it works.

Learn Git Branching - Master Git Visually

Learn Git Branching is a browser-based, interactive Git tutorial that teaches branching, rebasing, merging, and cherry-picking through visual puzzles. You type real Git commands and watch the commit graph update in real time.

Who it's best for: Anyone who uses Git daily but secretly does not understand what rebase, cherry-pick, or HEAD~2 actually does, which is most engineers at some point.

The platform covers two tracks: Main (local Git operations) and Remote (push, pull, fetch, tracking branches). Each level sets a goal state for the commit graph and you have to figure out which commands produce it.

Verdict: The fastest way to actually understand what your Git commands are doing. Run through both tracks once and Git will never feel mysterious again.

Killercoda - The DevOps Lab That Is Always Open

Killercoda gives you a real Linux environment in your browser, no install, no account required for the free tier. Choose a scenario, and within seconds, you have a terminal connected to a real server. The scenario library covers Linux, Docker, Kubernetes, Ansible, ArgoCD, Terraform, and more.

Who it's best for: Anyone who wants a quick, no-friction DevOps practice, especially useful for learning a new tool without setting up a local environment first, or for keeping skills sharp between projects.

The free library includes hundreds of official and community-created scenarios. Many are contributed by tool vendors themselves, Grafana, Cilium and others publish their official getting-started tutorials directly on Killercoda.

Verdict: The best free option for hands-on practice with any specific DevOps tool right now. Anytime you encounter something new, ArgoCD, Cilium, Flux, check if there is a Killercoda scenario before setting up a local environment.

Play with Docker - A Real Docker Daemon in Your Browser

Play with Docker gives you a free, 4-hour Linux instance with a real Docker daemon running, directly in your browser. Run containers, build images, write Compose files, and experiment with Docker networking without touching your local machine.

Who it's best for: Beginners who want to learn Docker without installing it locally, and people who need a quick sandbox to test a Docker command or Compose configuration without affecting their machine.

You can create multiple instances and connect them, useful for practicing Docker Swarm or multi-container networking scenarios. The official Docker documentation uses Play with Docker for many of its interactive examples.

Verdict: The zero-friction way to start with Docker. No installation, no configuration, just a terminal and a Docker daemon. Use this before committing to a local Docker Desktop setup.

Play with Kubernetes - A Multi-Node Cluster in Minutes

Play with Kubernetes provides a free, browser-based Kubernetes playground where you can bootstrap a real multi-node cluster and run workloads, without any local Kubernetes installation or cloud account.

Who it's best for: People learning Kubernetes fundamentals who want to practice kubectlcommands, deploy real workloads, and understand cluster architecture without the complexity of setting up minikube or a cloud cluster.

Sessions give you a 4-hour window with enough compute to bootstrap a control plane and add worker nodes. Every standard kubectl operation works: deployments, services, configmaps, namespaces and RBAC.

Verdict: The most accessible way to get a real Kubernetes cluster for practice without a cloud bill. Pair it with Kubernetes The Hard Way for a deeper understanding of what that bootstrap process is actually doing.

pwn.college - Deep Linux Internals Through Structured Challenges

pwn.college is a university-backed (Arizona State University) platform that teaches Linux internals through a structured series of challenges. Unlike typical beginner Linux tutorials, it covers how the shell works, process interactions, file descriptors, environment variables, and privilege escalation, concepts that are foundational to DevOps but rarely taught explicitly.

Who it's best for: Engineers who use Linux daily but want to deeply understand what is actually happening beneath the commands, process spawning, shell internals and permissions at the kernel level. Especially valuable if you work with Docker, because containers are Linux primitives underneath.

The platform is organized into modules (Linux Luminarium is the entry point for DevOps practitioners) and every challenge is a real binary running on a real Linux system that you interact with directly.

Verdict: The best free resource for understanding why Linux behaves the way it does, not just memorizing commands. If you use containers daily and want to understand what namespaces and cgroups actually are, start here.

Grafana Play - Live Observability Practice With Zero Setup

Grafana Play is a fully functional, live Grafana instance that anyone can open in a browser right now, pre-loaded with dashboards, Loki log data, Prometheus metrics, alerting rules, and Tempo traces. No installation, no Docker Compose stack, no Prometheus setup.

Who it's best for: Engineers who want to get comfortable with Grafana dashboards, PromQL queries, Loki log queries, and alert configuration before setting up a full observability stack locally or in production.

Verdict: If your Linux skills feel shaky and you want to fix that with a structured, real-world approach, the Linux Upskill Challenge is the most complete free answer. Twenty focused days produce a genuine foundation.

Linux Upskill Challenge - 20 Days to Real Linux Sysadmin Skills

The Linux Upskill Challenge is a free, community-run 20-day course where you rent a cheap VPS (or use a free cloud trial) and learn to manage it as a real system administrator would. Each day introduces new concepts with clear instructions, exercises, and a community forum for questions.

Who it's best for: Beginners who want a structured, day-by-day Linux learning path that produces a real skill foundation, not just knowledge of commands, but actual comfort managing a remote server. The VPS-based approach means everything you do is real.

The course covers everything a working sysadmin needs: SSH key management, file permissions, package management, process management, system services with systemd, firewalls, cron jobs, log analysis, and basic security hardening.

Verdict: If your Linux skills feel shaky and you want to fix that with a structured, real-world approach, the Linux Upskill Challenge is the most complete free answer. Twenty focused days produces a genuine foundation.

Kubernetes The Hard Way - Build a Cluster From Scratch

Kubernetes The Hard Way, created by Kelsey Hightower (Google), guides you through bootstrapping a Kubernetes cluster manually, without kubeadm, without any helper scripts, every component configured by hand. It is not the easiest way to get a cluster, which is exactly the point.

Who it's best for: Engineers who already use Kubernetes daily but feel like they are operating it without truly understanding it. Going through this once answers questions that years of kubectl apply never will.

Verdict: Not something you do every day, but something every serious Kubernetes practitioner should do at least once. The understanding it provides changes how you operate clusters permanently.

iximiuz Labs - Investigate How Containers and K8s Actually Work

iximiuz Labs takes a deliberately different approach to DevOps learning: instead of guided tutorials, it puts you in an environment and asks you to investigate how something works. Labs cover container networking, Linux namespaces, Kubernetes control plane behavior, and distributed systems concepts through exploration rather than instruction.

Who it's best for: Intermediate to advanced practitioners who want to understand why containers and Kubernetes behave the way they do, the Linux primitives underneath Docker, why pod networking works the way it does and what the scheduler actually considers.

The free tier includes a solid selection of foundational labs on container runtimes, networking, and Kubernetes basics. The platform is built by Ivan Velichko, widely respected in the cloud-native community for the depth of his writing on container internals.

Verdict: The best platform for going from "I can use Kubernetes" to "I understand Kubernetes." If you have been using containers for a year and still feel uncertain about the internals, this fills that gap.

Terraform Tutorials - Official Interactive IaC Practice

HashiCorp's official Terraform tutorials on the Developer portal are interactive, browser-based labs that teach Infrastructure as Code without requiring a cloud account for most foundational content. They cover AWS, Azure, GCP, and local Terraform workflows with a consistent, practical structure.

Who it's best for: Engineers who know containers and Kubernetes but have not yet learned Infrastructure as Code and anyone preparing for the Terraform Associate certification who wants practice alongside the theory.

The tutorials build progressively: start with a local Docker provider (no cloud account needed), move to cloud providers once you understand the workflow. Each tutorial includes working code, an explanation of what each block does, and a real-world step.

Verdict: The most reliable starting point for Terraform. If IaC is the gap in your DevOps skillset and for many practitioners it is, start here before looking anywhere else.

How to Use These Platforms Together

These platforms are not competing alternatives; they cover different skills and different learning modes. A practical sequence:

• Start with Linux fundamentals : Linux Upskill Challenge (structured) + OverTheWire Bandit (challenges)
• Add Git mastery early : Learn Git Branching (spend one afternoon, do both tracks)
• Learn containers hands-on : Play with Docker, then Killercoda Docker scenarios
• Move to Kubernetes : Play with Kubernetes for basics → Killercoda K8s scenarios → Kubernetes The Hard Way for deep understanding → iximiuz Labs for internals
• Add IaC : Terraform Tutorials (start with local Docker provider, no cloud account needed)
• Add observability : Grafana Play (explore before setting up your own stack)
• Keep troubleshooting sharp : SadServers (one scenario per week) + pwn.college Linux modules

None of these require paid subscriptions to start; all have free tiers that cover the core learning value.

FAQ

Do I need a powerful computer to use these platforms?
No. Every platform on this list is either browser-based or requires only a basic setup. Your local machine is just a browser or SSH client.

Which platform should a complete beginner start with?
Start with Linux Upskill Challenge for structured foundations, then add OverTheWire Bandit for command-line confidence, then Learn Git Branching for Git. After those three, Killercoda opens up most of the rest of the DevOps toolchain at a reasonable pace.

Are these platforms useful for certification preparation (CKA, CKAD, Terraform Associate)?
Yes. Play with Kubernetes and Killercoda are both consistently recommended for CKA/CKAD practice. Terraform Tutorials covers the Terraform Associate curriculum directly. SadServers builds the troubleshooting speed that the CKA exam requires.

Is Kubernetes The Hard Way still relevant with modern tools like k3s and minikube?
Yes, and for the same reason, reading a car manual is still useful even if you use a GPS. K3s and minikube are better for daily use. The Hard Way is for understanding what they are abstracting. Do it once, then use the convenient tools with actual understanding.

Conclusion

The best DevOps skill is not knowing which tool to use; it is knowing what to do when something breaks. Every platform on this list gets you closer to that, whether you are starting from zero with the Linux Upskill Challenge, building Git intuition with Learn Git Branching, diagnosing broken servers on SadServers, or finally understanding what Kubernetes is actually doing under the hood with Kubernetes The Hard Way and iximiuz Labs.

You do not need to work through all twelve at once; pick the one that matches your current gap, spend a few hours a week, and let the practice compound. The engineers who stand out in DevOps are the ones who have broken things, fixed things, and done it enough times that the instinct becomes automatic. These platforms give you the reps. If you know of such a platform, do drop it in the comments!

Don't we learn something new everyday? Something that might be obvious to others but feels like discovery to you?

I had that feeling when I learned about the concept of compose override in Docker. In my self-hosted Ghost CMS deployment, I made modifications in the compose file to introduce log rotation. But now the compose file was modified and any upstream change would complain about modified file. Git stash comes to rescue, but it's an additional pain.

And that pain went away with the override compose file. It's an excellent way of separating local and upstream changes, local and production compose files. I wrote about it here.

Git Pull Kept Failing on My Ghost Server. Docker Compose Override Fixed It

Modifying your docker-compose.yml directly and now git pull throws a “local changes would be overwritten” error? Use a compose.override.yml file to keep your changes separate from the file Ghost’s repo manages.

Linux HandbookAbhishek Prakash

Claude (or other mainstream AI tools) can be an excellent help in troubleshooting your infrastructure issues. But if you just ask it "find me for this error message", you'll get generic answers. Yash who has recently started working as a DevOps engineer shares some of the Claude skills he uses. You can take inspiration and modify these skills as needed or use them as it is.

8 Claude Skills I Use Everyday as a DevOps Engineer

Sharing the skills I use for troubleshooting and other purposes as a devops engineer. They are primarily for Claude but should work with other AI tools, too.

Linux HandbookYash Kiran Patil

💡Quick terminal tip

In bash (and other readline-based shells), press Alt+Shift+3 (or Alt+#) while typing a command. It prefixes the line with #, submits it, and since # starts a comment, the command won't execute.

It stays in your shell history for later. Handy for jotting down a command you're not ready to run yet.

Now that you know this one, here are a few more shortcuts worth adding to your muscle memory.

🛠️ Tool discovery

Let's find your next favorite software in this section.

Buzz: Self-Hostable Workspace for Humans and AI Agents

Buzz is an open-source collaboration platform from Block that brings team chat, Git repositories, and AI agents into a single workspace. Built on the Nostr protocol, it lets organizations self-host their collaboration platform while allowing AI agents to participate as authenticated team members with their own identities and permissions.

• 💬 Integrated Team Collaboration – Channels, threads, DMs, media sharing, and search in one workspace (voice huddles in progress).
• 🤖 AI Agents as Teammates – Agents hold cryptographic identities and can review code, submit patches, and collaborate alongside humans.
• 🌐 Self-Hostable & Open Source – Apache 2.0 licensed; deploy on your own infrastructure with full data control.
• 🛠️ Built-in Git Collaboration – Host repos, submit patches, and manage code review without external Git hosting.
• 🔐 Nostr-Based Architecture – Every event is signed via Nostr, giving verifiable identity and a full audit trail.

GitHub - block/buzz: A hive mind communication platform

A hive mind communication platform. Contribute to block/buzz development by creating an account on GitHub.

GitHubblock

Solidtime: Modern Open-Source Time Tracking for Teams

Solidtime is an open-source time tracking platform built for freelancers, agencies, and teams that need an easy way to track work, manage projects, and generate invoices. It offers a polished web and desktop experience, supports self-hosting, and keeps activity tracking privacy-friendly by processing desktop activity locally before converting it into time entries.

• ⏱️ Time Tracking – Simple, modern interface to track work time.
• 📁 Projects & Tasks – Create projects and tasks, and assign them to team members.
• 👥 Clients – Manage clients and link them to projects.
• 💰 Billable Rates – Set rates per project, member, or organization.
• 🏢 Multiple Organizations – Manage several organizations from one account.
• 🔑 Roles & Permissions – Control access within organizations.
• 📥 Data Import – Import from Toggl, Clockify, or CSV.

GitHub - solidtime-io/solidtime: Modern open-source time-tracking app

Modern open-source time-tracking app. Contribute to solidtime-io/solidtime development by creating an account on GitHub.

GitHubsolidtime-io

📰 Linux news that matters

• The Linux kernel CVE team published 432 CVEs over just two days, prompting concerns from security engineers about the practicality of reviewing and prioritizing individual kernel vulnerabilities. The surge reflects the kernel project's policy of assigning CVEs to virtually every qualifying security-related bug fix in stable releases, with AI-assisted bug discovery also contributing to the growing number of reports reaching maintainers.
• NetworkManager 1.58 adds support for IPv6-only deployments through RFC 8925 IPv6-only-preferred signaling and 464XLAT (CLAT), enabling legacy IPv4 applications to continue working on IPv6-only networks. The release also introduces GENEVE tunnel management for virtualized environments, 6 GHz Wi-Fi enhancements, persistent managed state across reboots for automation, and fixes multiple DHCP-related security issues, including CVE-2026-10805.
• Cisco has released Antares-350M and Antares-1B, two open-weight small language models purpose-built to locate known vulnerabilities within large source code repositories. Unlike general-purpose coding models, Antares focuses on repository-level vulnerability localization. Can run locally without uploading proprietary code to the cloud, and Cisco claims it achieves comparable accuracy at up to 172× lower cost than leading frontier AI models while also releasing a benchmark to measure this task.
• The Model Context Protocol (MCP) is preparing its 2026-07-28 specification, replacing its stateful architecture with a stateless protocol core by removing session IDs and the initialization handshake while introducing a new extensions framework and stronger authorization mechanisms. The redesign allows MCP servers to run behind standard HTTP load balancers without sticky sessions or shared session stores, making large-scale deployments significantly easier, although existing implementations will require migration because of breaking protocol changes.
• GitHub has made its redesigned Pull Requests Dashboard generally available, introducing an Inbox that surfaces review requests, CI failures, merge-ready pull requests, saved views, advanced search, and support for identifying AI agent-created pull requests. The update reflects a broader industry shift where AI coding assistants generate code faster than humans can review it, prompting GitHub to focus on review triage rather than code generation alone.

😂 Geek humor

💌 Keep on loving Linux Handbook

GitOps course is nearly ready. It should arrive next week.

Perfect time to become a Pro member and enjoy unlimited access to our eBooks, courses and in-depth tutorials.

Missed the previous editions? You can access the newsletter archives.

You may also contribute to Linux Handbook and share your experience and expertise with the community.

I like reading your messages, so just hit the reply button and share your thoughts 😄

I was skeptical about AI tools in a DevOps workflow for a long time. Every demo I saw showed someone asking AI Agent to write a Hello World Dockerfile. That's not a DevOps use case, that's a simple chat.

What changed my mind was using Claude for things that actually slow me down at work. Not boilerplate code generation, but the genuinely tedious parts of the job: interpreting a cryptic error from a stack trace buried inside a Kubernetes pod, converting a Bash script someone wrote in 2017 into something readable, or asking "what does this flag do again" without having to leave the terminal context I'm already in.

But here's the thing: generic Claude and skilled Claude are two very different tools.

Out of the box, Claude gives you general-purpose answers. When you add a SKILL.md, a structured instruction file that tells Claude exactly how to approach a specific task, you get a focused, deterministic workflow instead of a guess. The difference matters in DevOps, where a half-correct answer about a Kubernetes misconfiguration or a Terraform plan can cause real problems.

This article covers both sides: the skills themselves, and the concrete difference between using Claude with and without them. I'm running this on VS Code with Claude Sonnet 4.6.

What Are Claude Skills?

Claude Code supports a feature called skills: markdown files named SKILL.md that live inside a .claude/skills/ directory in your project. When you ask Claude something that matches a skill's trigger phrases, it automatically uses the structured workflow defined in that file instead of its default behavior.

Think of it like the difference between asking a new colleague a question and asking someone who's already written the runbook for it. Same knowledge, completely different depth and reliability.

I've written 8 of my own, one for each workflow I find myself using regularly.

Why Skills Actually Matter

Let me show the difference concretely before going through each skill.

I'll use the error-decoder skill as the example, with a Docker container that keeps exiting. This is something you can reproduce on any machine with Docker installed.

The prompt: "My Docker container keeps exiting immediately. Here's the output." (with docker logs and docker inspect output pasted in)

Here's what I actually pasted in:

$ docker run --name my-app myrepo/my-app:2.1.0
Error: DATABASE_URL environment variable is not set.
Exiting.

$ docker inspect my-app --format='{{.State.ExitCode}} {{.State.OOMKilled}}'
1 false

$ docker ps -a | grep my-app
my-app   myrepo/my-app:2.1.0   Exited (1) 3 seconds ago

The response is accurate but completely generic. It lists common causes without engaging with the actual output that was pasted. The real answer is sitting right there in the logs (DATABASE_URL environment variable is not set) but Claude, without the skill, doesn't structure its analysis to find it.

The response now follows the skill's output format. It pulls the specific root cause directly from the logs, gives the exact fix command, tells you what a successful run looks like, and gives the next diagnostic step if it still fails.

The skill didn't add knowledge Claude didn't have. It added structure and focus, it forces Claude to identify the root cause separately from the proximate cause, and to give a verification step instead of stopping at "here's the fix."

The 8 Claude Skills in My Toolbox

Below are the 8 skills you will have in your project, which will give you a focused and structured workflow for your projects. I will also show you the results I get after the prompt I give to the agent with the skills enforced. You are free to download them and modify them as per your requirements.

The skills folder structure will look like this:

.claude/
└── skills/
├── error-decoder/
│ └── SKILL.md ← Diagnose Kubernetes, Terraform, Helm errors
├── bash-auditor/
│ └── SKILL.md ← Write and audit Bash scripts
├── k8s-manifest-reviewer/
│ └── SKILL.md ← Explain and audit Kubernetes YAML
├── format-converter/
│ └── SKILL.md ← Convert between DevOps formats and tools
├── runbook-drafter/
│ └── SKILL.md ← Draft runbooks, postmortems, SOPs
├── terraform-explainer/
│ └── SKILL.md ← Explain and audit Terraform code and plans
├── api-tester/
│ └── SKILL.md ← Generate cURL and API test commands
└── cicd-auditor/
└── SKILL.md ← Audit GitHub Actions, GitLab CI, Jenkins

error-decoder - Diagnosing Cryptic Errors

This is the one I use most often. DevOps tools are notoriously bad at error messages. Docker exits a container with code 137 and you're left guessing whether it's OOM or a signal. Terraform throws a provider error with a reference ID you have to track down. Helm fails on a templating issue with a line number that doesn't match your file. Kubernetes gives you a pod in CrashLoopBackOff with no explanation of why. In all of these cases, the raw error is pointing at a symptom, not at the cause.

My workflow: paste the full error, not a summary, the full thing and add two sentences of context:

Here is the error from my Kubernetes pod. This pod was working yesterday.
The only change was updating the image tag from 1.3.2 to 1.4.0.

[full kubectl describe pod output]

The single biggest thing that improved my results: treating Claude like a knowledgeable colleague who needs to be briefed, not a search engine. The skill enforces this by requiring full context before proceeding.

bash-auditor - Writing and Reviewing Bash Scripts

Bash is the lingua franca of DevOps and also one of the most footgun-prone languages in existence. A script that looks fine will silently fail because someone forgot set -e. A loop will do something destructive because the variable expansion wasn't quoted. A condition will always evaluate to true because of the way [[ ]] handles empty strings.

I use this skill for three things: Writing scripts from a plain-English description, reviewing scripts I didn't write, explaining what a script does, etc.

# My Prompt

Review this Bash script as if you're performing a production code review.

Identify:
- Bugs
- Security issues
- Reliability problems
- Quoting mistakes
- Error handling issues
- Race conditions
- Portability concerns
- Performance improvements

Explain why each issue matters and then provide a corrected production-ready version with comments.

A note on trust: I always read through generated Bash before running it, especially anything that touches the filesystem or makes external requests. The skill produces a first draft with proper structure, not production-certified code.

k8s-manifest-reviewer - Understanding Kubernetes YAML

Kubernetes YAML is verbose by design. A single Deployment manifest can be 80 lines long and most of it is boilerplate. The meaningful parts, resource limits, liveness probes, affinity rules and security contexts are buried in the middle.

I use this skill in two ways:

Explaining what a manifest does: Paste in a Deployment or StatefulSet YAML I haven't seen before and the skill walks through it section by section, calling out anything non-obvious. Particularly useful when you inherit infrastructure and need to quickly understand what's running and why.

Spotting misconfigurations: The skill audits against a production-readiness checklist

# My prompt
Review this Kubernetes Deployment as if you're the platform engineer responsible for approving it for production.

Please:
1. Explain what each section of the manifest does.
2. Point out any security, reliability, scalability, or performance issues.
3. Identify Kubernetes best-practice violations.
4. Rank the issues by severity (Critical, High, Medium, Low).
5. Explain why each issue matters.
6. Suggest concrete fixes.
7. Provide a corrected production-ready manifest.

Context:
- This is running in a production EKS cluster.
- It was migrated from a development environment.
- Traffic is expected to reach 800-1000 requests per second.
- High availability is required.
- Zero-downtime deployments are expected.

Here's the manifest provided:

Things the skill catches that are easy to miss: Memory limit lower than memory request, missing readinessProbe, hostNetwork: true left in from a debugging session, :latest image tag in a production manifest, no podAntiAffinity rules, etc.

format-converter - Converting Between DevOps Formats

DevOps involves a lot of format conversion work that nobody talks about because it's unglamorous. Docker Compose files that need to become Helm charts. Bash scripts that need to become Ansible playbooks. cURL commands from API docs that need to become Python scripts. JSON that needs to become YAML.

All of this is mechanical but error-prone when you do it by hand.

The skill enforces that constraints are explicit before generating output. The more specific your constraints, the less cleanup you do afterwards.

runbook-drafter - Writing Operational Documentation

A runbook is only useful if it's actually written. Most teams have "runbooks" that are either a Confluence page last updated in 2021 or just "the person who knows how to restart the thing."

My process: do the thing first, then write a quick stream-of-consciousness description of what I did and why:

# My prompt

I just fixed a production database connectivity issue. Here's what happened:
the app pods were getting connection refused on port 5432, which turned out to
be a NetworkPolicy that was blocking traffic from the app namespace to the db
namespace after a recent namespace label change. I fixed it by updating the
namespaceSelector in the NetworkPolicy. Write a runbook section for this.

The skill turns that stream-of-consciousness into a structured runbook section in about 30 seconds. I edit it, add the actual commands I ran, and it becomes something a teammate could actually follow at 2am.

The same approach works for postmortems. Dump the timeline, dump the actions, ask the skill to organize it into a postmortem structure. You still write the "lessons learned" section yourself; that's the part that requires judgment.

terraform-explainer - Understanding Infrastructure as Code

Terraform's HCL is readable enough on its own, but complex module structures - especially third-party modules with 40 variables, can be hard to parse quickly. I use this skill to understand infrastructure I didn't write.

Reading a module:

Explain what this Terraform module does. I specifically want to understand:
- What resources it creates
- What the required vs. optional variables are
- Whether anything here creates a public-facing resource
- Anything that might be surprising in a production AWS account

Provider APIs go stale. Terraform and cloud provider APIs evolve constantly. For anything version-sensitive, verify against the official registry before trusting the output.

api-tester - Generating cURL and API Test Commands

Every time I'm integrating a new service or debugging a webhook, I end up constructing cURL commands from API documentation. JWT auth headers, JSON body formatting, the right Content-Type; this is tedious and the skill is fast at it.

The prompt I put:

Give me a cURL command to call the GitHub REST API to list all open pull
requests for the repo "myorg/myrepo", authenticated with a personal access
token stored in $GITHUB_TOKEN, with output formatted as JSON and piped to jq
to show only the PR title and number.

The skill knows the auth patterns for common APIs (GitHub, Slack, Prometheus, Alertmanager, PagerDuty) without needing to be told. It also enforces that credentials are always environment variables and generated commands never contain a literal token.

I use this for any API I haven't touched before: Prometheus remote write, Alertmanager webhooks, AWS API Gateway, Slack, PagerDuty, wherever I need a quick working example to start from.

cicd-auditor - Reviewing CI/CD Pipeline Configs

CI/CD pipelines written in YAML accumulate complexity over time. Stages that nobody remembers the purpose of. Jobs that run sequentially because nobody added needs: correctly. Secrets being printed to logs somewhere. Docker layers not being cached.

My review prompt:

Review this GitHub Actions workflow for common issues:
- Steps that could be parallelized but aren't
- Secrets being exposed in logs
- Missing caching for dependencies or Docker layers
- Jobs that will always run even when they should be conditional
- Third-party actions not pinned to a SHA

The skill specifically checks for something that most miss: third-party GitHub Actions pinned to mutable tags. uses: some-action/tool@v3 looks fine, but it can be hijacked; the tag can be moved to point at different code. The safe version is pinning to a commit SHA.

Wrapping Up

The value I get from Claude in a DevOps context is concentrated in specific places: decoding errors faster, auditing configs I didn't write, handling format conversion that's mechanical but annoying, and getting documentation drafted while the context is fresh. You can refer the official documentation for Claude skills.

The skills are what make this reliable instead of hit-or-miss. Without them, Claude gives you general advice. With them, it follows a deterministic workflow - asks for the right inputs, applies a consistent checklist, and formats the output in a way you can actually act on.

If you have more such skill.md that you use, share them in the comments and tell how these skills enhance your workflow!

Have you ever deployed an app to Kubernetes and later realized you don't really know what changed, who changed it, or how to roll it back safely? Maybe dev looked fine, staging looked stable, and production still broke at midnight, right when nobody wanted to touch it.

This is exactly the problem GitOps exists to solve.

GitOps isn't just another DevOps trend. It's a deployment model where Git becomes the single source of truth for your infrastructure and applications. Your cluster continuously pulls the desired state from Git, so every change is auditable, reversible, and predictable.

Tools like ArgoCD make this possible on Kubernetes, and that's exactly what this course teaches you, starting from the core concepts and working all the way to real production deployments.

What you'll learn

This course is split into four modules, taking you from concepts to implementation to production-grade, safe deployments.

Module 1: GitOps Foundations

• What GitOps really is, and how it compares to traditional DevOps
• Why GitOps is not just CI/CD, and why it's trending right now
• Push vs pull deployments, explained with real-world examples

Module 2: Getting Started with ArgoCD

• Installing ArgoCD and understanding its architecture
• Deploying your first application the GitOps way
• Setting up RBAC and managing user access

Module 3: Working with ArgoCD

• Secret management in GitOps
• Helm vs Kustomize deployments
• Multi-environment GitOps strategy across dev, staging, and production

Module 4: Progressive Delivery with Argo Rollouts

• Blue-green and canary deployments
• Automated rollbacks
• Metrics based decision and safe production releases

Who this course is for

This course is for you if you deploy applications to Kubernetes and want a safer, more predictable way to do it. It works well whether you're a DevOps engineer tired of manual deployments, a platform engineer building GitOps workflows for your team, or a developer and student who just wants to understand what ArgoCD and Argo Rollouts are actually doing under the hood.

You don't need any prior experience with ArgoCD to start. A basic understanding of Kubernetes will help you get more out of the course, but the first module builds up the concepts from scratch anyway.

Start the course

Start with Module 1 and go through the four modules in order. Each one builds on the last, so you move from GitOps concepts, to your first ArgoCD deployment, to running progressive, production-grade rollouts by the end.

By the time you finish the final project in Module 5, you'll have hands-on experience with the same GitOps setup used to run real production systems.

If editing your docker-compose.yml directly is breaking git pull from upstream, here's the fix: move your customizations into a separate compose.override.yml file instead of editing the original.

The fix: use a compose override file

Create a compose.override.yml in the same folder as your compose.yml, and use the exact service names from your original file (ghost and caddy, in my case).

services:
  ghost:
    logging:
      driver: json-file
      options:
        max-size: "100m"
        max-file: "5"
  caddy:
    logging:
      driver: json-file
      options:
        max-size: "100m"
        max-file: "5"

Docker Compose picks up compose.override.yml automatically and merges it into compose.yml at runtime, so you don't need to pass any extra flags.

So, when you run:

docker compose up

It is equivalent to running:

docker compose -f compose.yml -f compose.override.yml up

Your original compose.yml never gets touched, so there's nothing left for git pull to conflict with and so no complaints from git.

How I ran into this

I run my Ghost sites using Ghost's official Docker Compose self-hosting method. Eventually, I noticed that Ghost's default setup generates a lot of log output, so I added log rotate option in the docker compose file for the ghost and caddy services directly inside compose.yml.

This solved the logs eating up disk space problem, but updating the Ghost version became inconvenient.

Updating to a newer Ghost version after that is meant to be a simple three-step routine:

• git pull
• docker compose pull
• docker compose up -d.

That routine broke because I modified compose.yml. Every git pull started failing with the same error:

root@ghost-learnubuntu:/opt/ghost# git pull
remote: Enumerating objects: 89, done.
remote: Counting objects: 100% (68/68), done.
remote: Compressing objects: 100% (46/46), done.
remote: Total 89 (delta 52), reused 29 (delta 20), pack-reused 21 (from 2)
Unpacking objects: 100% (89/89), 31.28 KiB | 485.00 KiB/s, done.
From https://github.com/TryGhost/ghost-docker
   14cc722..d3204b2  main                                   -> origin/main
Updating 14cc722..d3204b2
error: Your local changes to the following files would be overwritten by merge:
        compose.yml
Please commit your changes or stash them before you merge.
Aborting

For a while, my workaround was keeping a backup of the untouched compose.yml, or running git stash before every pull. It worked, but it meant remembering an extra step every single time I wanted to update Ghost.

And one day, I came across the concept of compose override file.

What is a compose override file

A compose override file is just a second compose file that sits next to your main one. Anything you define inside it gets layered on top of compose.yml automatically, without you having to pass any extra flags to docker compose.

Since it's a separate file, it's not the one git is tracking against upstream, so pulling new changes from Ghost's repo doesn't touch anything you've customized.

Here's the compose.override.yml file for my Ghost.

This solved the problem for me completely. My compose.yml now stays exactly as it comes from upstream, and git pull, docker compose pull, docker compose up -d goes back to being a clean three-step routine.

Using override files to separate test and production

The same mechanism works for more than just logging. Since an override file just layers extra configuration on top of the base file, you can use a similar setup to separate test and production: keep one compose.override.yml for local tweaks like lighter resource limits or different ports, and a separate file, say compose.prod.yml, for anything specific to production. You pick which one applies at deploy time with the -f flag.

Other ways to use override files

Let's see various ways you can use the overrride compose file.

Run without override

If you ever need to deploy without applying the override, point docker compose at only the base file explicitly:

docker compose -f compose.yml up -d

Passing -f like this skips the automatic override merge entirely.

Use multiple override files

You're also not limited to one override file. Layer as many as you need by repeating -f in order, with later files taking priority over earlier ones:

docker compose -f compose.yml -f compose.override.yml -f compose.prod.yml up -d

See what the final compose file looks like

Whenever you want to double check what's actually being applied after all that layering, run:

docker compose config 

It prints the fully merged result.

💡Add override to gitignore

I have added my compose.override.yml to the .gitignore. It's local to my setup, not something upstream needs to know about, and keeping it out of git means I'll never run into a merge conflict over it either. You can do the same if it fits your scenario.

I'm sure there's more you can do with override files depending on your setup, but this fixed the problem I had: keeping my logging tweaks out of the file Ghost's repo manages.

If you're running Ghost, or anything else, through docker compose and editing the compose file directly, it's worth switching to an override file before you reach for git stash every time.

Short one this week my friend, energy's a bit low on my end, but two kernel vulnerabilities landed that are too important to skip, so let's get into it.

Two old, nasty kernel bugs got public exploits this week. If you're running KVM or any kind of multi-tenant containers, this is a "patch today, not this weekend" situation.

GhostLock (CVE-2026-43499) is a 15-year-old use-after-free bug in the Linux kernel's futex/rtmutex subsystem. It lets an unprivileged local user grab root and escape containers on unpatched systems. This one's been sitting quietly since 2011, affects pretty much every major distro, and researchers have already shown a reliable exploit that gets root in about five seconds. It also breaks container isolation, so if you're self-hosting anything multi-tenant, take this seriously.

Januscape (CVE-2026-53359) is a 16-year-old use-after-free in KVM's shadow MMU implementation. It can let an attacker escape a guest VM and run code on the host, on both Intel and AMD systems. Cloud providers and anyone running untrusted workloads in virtualized environments are the biggest targets, but if you run KVM at home, it's worth checking your patch status too.

Two decade-plus-old bugs surfacing with working exploits in the same week is a good reminder that "old and stable" doesn't mean "safe to ignore."

📚 Worth reading from Linux Handbook

A Postgres instance on a remote server, port 5432 not exposed to the internet (rightly so). How to access it? The fix is SSH tunneling, and this tutorial walks through all three flavors with the actual commands and real use cases behind them.

• Local forwarding (-L) to reach a remote service, like that Postgres box, as if it were running on your own machine
• Remote forwarding (-R) to expose something local, like a webhook receiver on your dev machine, to the outside world through a VPS
• Dynamic forwarding (-D) to turn your SSH connection into a SOCKS proxy for encrypting your traffic on untrusted WiFi

If you've ever wanted to skip standing up a VPN just to reach one service, this is worth ten minutes of your time. Read the full guide.

Also recent, in case you missed them:

• I Like This Fuzzy Search Finder Better Than Find Command in Linux, a quick case for swapping find for fzf in your daily workflow
• These 11 Open Source Tools Completely Improved My Docker Workflow, a practical roundup if you're managing more than a couple of containers

💡Quick terminal tip

Most Linux users know how to extract archives, but tar includes several lesser-known options that can make working with archives safer and more efficient.

Before extracting an archive, inspect its contents:

tar -tf archive.tar.gz

This lists every file and directory inside the archive without extracting anything.

To avoid cluttering your current directory, extract the archive into its own automatically created folder:

tar -xf archive.tar.gz --one-top-level

If you prefer a custom directory name instead, specify it explicitly:

tar -xf archive.tar.gz --one-top-level=archive

Finally, you don't have to extract the entire archive. To restore only specific files or directories, list them after the archive name:

tar -xf archive.tar.gz path/to/file.txt docs/

This is particularly useful when working with large source archives or backups where you only need a handful of files.

🛠️ Tool discovery

Let's find your next favorite software in this section.

DarkMoon: AI-Powered Autonomous Penetration Testing Platform

DarkMoon is an open-source platform that runs full penetration tests using AI agents that plan, execute, and validate real exploits against a target, across web apps, Active Directory, and Kubernetes.

Why use it? Well, manual pentesting takes weeks and a proper consultant costs thousands a day, and Dark-Moon automates that entire loop, from recon to a structured, evidence-backed report, using 50+ integrated tools like Nuclei, sqlmap, and BloodHound under the hood.

It also runs a local privacy gateway that keeps your real IPs, hosts, and credentials from ever reaching the LLM provider. Good fit for DevSecOps pipelines, bug bounty workflows, or just testing your own homelab exposure before someone else does.

You can self-host it or purchase a plan from their website.

GitHub - ASCIT31/Dark-Moon: Autonomous AI pentesting engine, continuous offensive security across web, cloud, AD & Kubernetes. Agentic reasoning + real exploit execution deliver proof-based vulnerabilities. Privacy gateway: the LLM never sees your real IPs, hosts, creds or paths (deterministic placeholders rehydrated locally), nothing leaves your perimeter.

Autonomous AI pentesting engine, continuous offensive security across web, cloud, AD &amp; Kubernetes. Agentic reasoning + real exploit execution deliver proof-based vulnerabilities. Privacy gatewa…

GitHubASCIT31

Dashy: Self-Hosted Dashboard for Homelab and Infrastructure Services

Dashy is an open-source, self-hosted dashboard that provides a unified homepage for accessing infrastructure services, applications, and development tools. It combines link management with service health monitoring, widgets, authentication, and extensive customization, making it a practical landing page for homelabs, self-hosted environments, and DevOps teams managing numerous services.

• 🚦 Service Health Monitoring: Displays real-time availability and status checks for configured applications and services.
• 📊 Rich Widget Ecosystem: Integrates dynamic widgets for self-hosted services, system information, and external APIs to create an operational dashboard.
• 🎨 Highly Customizable UI: Supports multiple themes, icon packs, custom CSS, configurable layouts, and a built-in visual configuration editor.
• 🔍 Fast Navigation: Includes instant search, keyboard shortcuts, multiple pages, and flexible launch options for quickly accessing services.
• 🐳 Easy Deployment: Runs via Docker, Docker Compose, or directly from source, with support for multi-architecture container images.

GitHub - lissy93/dashy: 🚀 A self-hostable personal dashboard built for you. Includes status-checking, widgets, themes, icon packs, a UI editor and tons more!

🚀 A self-hostable personal dashboard built for you. Includes status-checking, widgets, themes, icon packs, a UI editor and tons more! - lissy93/dashy

GitHublissy93

📰 Linux news that matters

• Apple has released version 1.0 of its open-source Container project, a Swift-based tool that runs OCI-compatible Linux containers inside lightweight virtual machines on Apple silicon Macs. The stable release introduces persistent Linux environments through the new container machine command, adopts TOML-based configuration, and adds capabilities such as host-to-container file copying while establishing a stable baseline for future development.
• The German state of Mecklenburg-Vorpommern is expanding its open-source strategy by rolling out a self-hosted Nextcloud platform across state and municipal administration, with a long-term target of more than 50,000 public-sector employees. The initiative replaces Microsoft SharePoint for collaboration, is operated on state-controlled infrastructure, and forms part of a broader digital sovereignty strategy that also includes OpenProject and a locally controlled AI assistant based on OpenWebUI while emphasizing open standards and European technologies.
• AWS has expanded its DevOps Agent with release management capabilities that automatically review code changes, validate dependency impacts and access controls, and execute functional verification in managed environments before software is deployed. The enhancement moves the agent beyond troubleshooting and operations into pre-production quality assurance, positioning it as an AI-assisted release engineer integrated into the software delivery lifecycle.
• Researchers at Noma Security disclosed GitLost, a prompt-injection technique that tricks GitHub Agentic Workflows into reading data from private repositories and publishing it in a public repository comment. The attack requires only a crafted GitHub Issue in a public repository when the organization's AI workflow has read access to private repositories, illustrating how natural-language instructions embedded in untrusted content can override the agent's intended behavior.

😂 Geek humor

💌 Keep on loving Linux Handbook

GitOps course is nearly ready. It should arrive next week.

Perfect time to become a Pro member and enjoy unlimited access to our eBooks, courses and in-depth tutorials.

Missed the previous editions? You can access the newsletter archives.

You may also contribute to Linux Handbook and share your experience and expertise with the community.

I like reading your messages, so just hit the reply button and share your thoughts 😄

There's a moment every Linux user eventually hits, you need to access something on a remote machine, but it's not exposed to the internet. Maybe it's a database running on port 5432, a local web app on port 3000, or a service hidden behind a firewall. The "obvious" solution is to punch a hole in the firewall and expose it. The *right* solution is SSH tunneling.

I started using SSH tunnels out of necessity. I had a PostgreSQL database running on a remote server, and the sysadmin (correctly) refused to open port 5432 to the internet. Someone in the team mentioned that I could just "tunnel through SSH" to access it. I had no idea what that meant. Twenty minutes of reading later, I had it working and I've been using SSH tunnels regularly ever since for everything from accessing remote services to getting around restrictive networks.

I'll walk through what SSH tunneling actually is, how each type works, how I set them up, and importantly, what the risks are and how to stay on the right side of them.

What is SSH Tunneling?

SSH (Secure Shell) is usually thought of as a way to get a remote terminal. But SSH also has the ability to forward ports; it can take network traffic on one port and route it through the encrypted SSH connection to emerge somewhere else entirely.

That's SSH tunneling in a sentence: using an SSH connection as a secure pipe to route other traffic.

The traffic inside that pipe is encrypted by SSH, which means it gets the same protection as your terminal session. A service that has no encryption of its own, an old database, a plain HTTP admin panel, a Redis instance, suddenly gets full TLS-grade protection just because you're reaching it through SSH.

There are three types of SSH tunnels. Understanding which one solves your problem is most of the battle:

Local forwarding: -L tunnel forwards a port on your machine to somewhere the remote server can reach.
Remote forwarding: -R tunnel forwards a port on the remote server to something on your machine.
Dynamic forwarding: SOCKS proxy, -D tunnel turns the SSH connection into a proxy that routes any traffic through the remote.

Let's go through each one the way I actually use them.

Local Port Forwarding: Accessing Remote Services Locally

This is the one I use most. Local forwarding lets me open a port on my laptop and have traffic on that port come out on the remote server, as if I'm connecting from the server itself.

My exact use case: I needed to connect my local database client (DBeaver) to a PostgreSQL instance running on a remote server. Port 5432 was not open to the internet. SSH port 22 was.

ssh -L 5433:localhost:5432 username@remote-server.example.com

Breaking this down: -L tells SSH we're doing local forwarding, 5433 is the port I'm opening on my machine, localhost:5432 is where the traffic should go from the remote server's perspective, lhb@remote-server.example.com is the SSH server I'm tunneling through.

After running this, I opened DBeaver, pointed it at localhost:5433, and it connected to the PostgreSQL instance on the remote server, over an encrypted channel, as if the database were running locally.

The tunnel is active for as long as the SSH session stays open. When you exit, the tunnel closes. If you don't need an interactive shell, just the tunnel - add -N to suppress it:

ssh -N -L 5433:localhost:5432 username@remote-server.example.com

And if you want it to run in the background:

ssh -N -f -L 5433:localhost:5432 username@remote-server.example.com

-f sends the process to the background after authenticating. The tunnel stays open without occupying your terminal.

Here, I have used a Docker PostgreSQL container to show the SSH connection to the remote server.

Remote Port Forwarding: Exposing Your Local Machine to the World

Remote forwarding is local forwarding in reverse. Instead of bringing a remote service to me, I'm pushing something on my machine out to a remote server.

My use case for this: I was developing a webhook receiver locally. The service I needed to receive webhooks from (a payment processor) needed a public URL to send to. My development machine is behind NAT, with no public IP. I had a cheap VPS with a public IP. Remote forwarding solved it.

ssh -R 8080:localhost:3000 username@my-vps.example.com

Here, -R for remote forwarding, 8080 is the port that opens on the remote server, localhost:3000 is where traffic on that remote port gets forwarded, back to my machine, port 3000.

After running this, anyone hitting my-vps.example.com:8080 would have their request tunneled back to port 3000 on my laptop. My local dev server was now reachable from the internet, through an encrypted SSH connection. For the example I have setup the container for the vps as:

The VPS container is running for reverse tunneling for the requests that are coming.

curl from inside the container simulates the external request to the vps:8080 endpoint.

Python server verifying and logging the connected request from the internet that comes to the VPS and then to the localhost:3000

When to use this: Remote forwarding is incredibly useful for quick webhook testing, sharing a local demo with a client, or giving someone remote access to something on your internal network without setting up a VPN.

Dynamic Port Forwarding: SSH as a SOCKS Proxy

Dynamic forwarding is the most flexible of the three. Instead of forwarding a specific port to a specific destination, it creates a SOCKS proxy on your machine. Any application that supports SOCKS proxies can route all its traffic through your SSH connection and it will appear as if that traffic is coming from the remote server.

Command that can be used:

ssh -D 1080 -N yash@remote-server.example.com

This opens a SOCKS5 proxy on localhost:1080 on my machine. Any traffic I route through that proxy goes through the SSH tunnel and exits from remote-server.example.com.

I have used it as:

ssh -f -D 1080 -N \
  -i ~/ITSFOSS/REVIEW/SSH\ Tunneling/docker-demo/demo_key \
  -p 2223 -o StrictHostKeyChecking=no \
  vpsuser@localhost
ss -tlnp | grep 1080

Then I can setup the network proxy through the network settings as:

Then, you need to set up the SOCKS proxy through the network settings.

When to use this: When you are in a coffee shop with WiFi and want to encrypt all your browsing, you need to access something that's only reachable from a specific server (e.g., an internal admin panel that only allows connections from the VPS's IP), or you want to test how your website looks from the perspective of another geographic location.

Making Tunnels Persistent

Running long ssh -L ... commands every time is annoying. I put my common tunnels in ~/.ssh/config so I can activate them with a short alias:

Host db-tunnel
    HostName remote-server.example.com
    User yash
    LocalForward 5433 localhost:5432
    ServerAliveInterval 60
    ServerAliveCountMax 3

Host socks-proxy
    HostName my-vps.example.com
    User yash
    DynamicForward 1080
    ServerAliveInterval 60
    ServerAliveCountMax 3

Now activating the database tunnel is just:

ssh -N db-tunnel

And the SOCKS proxy:

ssh -N socks-proxy

The Risks And How to Handle Them

SSH tunneling is powerful, and like most powerful tools, it can cause problems if misused or misconfigured. This is the part most tutorials skip.

Risk 1: Unauthorized Tunnel Creation

The flip side of remote forwarding (-R) is that if someone has SSH access to your server, they can open tunnels out of it, potentially bypassing your network security controls. An attacker with a compromised SSH key could use your server as a relay to reach systems inside your network.

Mitigation: Restrict what SSH users can do. In /etc/ssh/sshd_config:

# Disable port forwarding for all users by default
AllowTcpForwarding no
GatewayPorts no

# Then allow it only for specific trusted users:
Match User deploy-user
    AllowTcpForwarding local

Use SSH keys (not passwords), enforce key-based auth only, and audit your ~/.ssh/authorized_keys files regularly.

Risk 2: Tunnel Misuse on Corporate/Managed Networks

Dynamic SSH tunneling (-D) is a common technique for bypassing network monitoring and content filters. On a corporate or university network, using a SOCKS proxy to route traffic through an external server may violate acceptable use policies, even if you have a legitimate reason.

I use it when I'm on untrusted public WiFi to protect my own traffic, which is reasonable. Using it to bypass your employer's security controls on company equipment is a different matter; read your acceptable use policy, and don't be surprised if your IT team can see that you're making an encrypted SSH connection to an external server even if they can't see inside it.

Risk 3: Exposing Tunnels Beyond Localhost

When you run -L 5433:localhost:5432, by default the tunnel binds to 127.0.0.1 on your machine, only you can use it. But if you bind it to 0.0.0.0, anyone on your local network (or beyond) can use that forwarded port to reach the remote service.

# DANGEROUS — binds to all interfaces
ssh -L 0.0.0.0:5433:localhost:5432 user@remote-server.example.com

Unless you specifically need to share a tunnel with other people on your network, always let the tunnel bind to 127.0.0.1 (the default). You can explicitly enforce this:

# Safe — explicitly binds to loopback only
ssh -L 127.0.0.1:5433:localhost:5432 user@remote-server.example.com

Risk 4: Keeping SSH Keys Secure

All of this relies on the security of your SSH keys. If your private key is stolen, your tunnels and everything behind them are compromised.

My key hygiene: Use ssh-keygen -t ed25519 for new keys, as Ed25519 keys are smaller, faster, and considered stronger than RSA-4096 for most use cases, always set a passphrase on private keys, use ssh-agent to avoid retyping the passphrase constantly while keeping the key protected at rest, never share private keys or put them in version control.

# Generate a new Ed25519 key with a passphrase
ssh-keygen -t ed25519 -C "yash@workstation" -f ~/.ssh/id_ed25519_tunnel

# Add it to ssh-agent so you don't retype the passphrase every session
ssh-add ~/.ssh/id_ed25519_tunnel
```

A Quick Reference: When to Use Which Tunnel

Wrapping Up

What I like about SSH tunneling is that it solves real problems without adding infrastructure. No VPN server to configure, no WireGuard keypairs to exchange, no nginx proxy rules to write. The SSH connection you already use for server access can also carry your database traffic, your webhook traffic, or your browsing traffic, all encrypted, all without opening extra firewall ports.

Local forwarding (-L) is the one I reach for most often, any time I need to access a service on a remote machine from a local client. Remote forwarding (-R) is what I use when I need to do the reverse: expose something local to the internet temporarily. Dynamic forwarding (-D) is the occasional privacy tool for when I'm not on a network I trust.

The risks are real but manageable: keep port forwarding locked down on your SSH servers, bind tunnels to localhost unless you have a specific reason not to, and treat your SSH keys with the same care you'd give a password.

The setup is one command. The maintenance is minimal. The usefulness compounds the more remote infrastructure you work with.

A good Linux user takes notes all the time. A better Linux user organizes them in a proper knowledge base.

From Obsidian to Tolaria, there are plenty of choices. You could explore some self-hosted knowledge base tools that may even help your team.

If your knowledge base grows bigger, you can plugin an AI and get answers from your personal notes.

Lately, we have been exploring AI... local AI mostly with open source models running on your machine and keeping the data private on your system.

For example, take this AI powered file sorter app. To a seasoned sysadmin, this could be a shell script but it could still fit someone's need I think.

Then there is agent based automation. So we took ZeroClaw and plugged it with Fizzy CLI to manage Kanban task board. Interesting times we live in.

I still find it amsuing that many new age developers are not familiar with even the basics of Linux command line. Our intro course is free so feel free to use it and share it with others.

Quick Introduction to Linux Command Line

Learn the basics of Linux commands in this short introductory course. Also contains videos.

Linux HandbookTed LeRoy

And for advanced Linux users, the systemd Playbook is a good way to make more out of systemd.

The systemd Playbook: Learn by Doing

Master systemd the practical way—one lab at a time.

Linux HandbookBhuwan Mishra

💡Quick terminal tip

Ever need to document a complex deployment, or share the exact errors a script threw with a teammate? Instead of manually copying and pasting from your terminal, you can record the entire session, both the commands you typed and their visual outputs to a single text file.

Launch a dedicated logging session using the built-in script command:

script sample.txt -T sample_time

Here, the sample_time file saves the timing information, needed to replay the content later.

From this moment on, your terminal behaves normally, but every keystroke, command, and output is quietly recorded in the background.

When your task is finished, simply exit the recording session:

exit

Now you have a perfect, chronologically ordered transcript (sample.txt) ready for documentation or debugging.

To replay the commands, use:

scriptreplay -B sample.txt -T sample_time

🛠️ Tool discovery

Let's find your next favorite software in this section.

WTF: Build a Personal DevOps Dashboard Inside Your Terminal

WTF (wtfutil) is an open-source terminal dashboard that aggregates operational data, development workflows, and personal productivity information into a single TUI interface. Instead of constantly switching between GitHub, Jira, Kubernetes dashboards, calendars, monitoring tools, and terminal windows, WTF presents everything through configurable modules arranged in a customizable grid layout.

GitHub - wtfutil/wtf: The personal information dashboard for your terminal

The personal information dashboard for your terminal - wtfutil/wtf

GitHubwtfutil

GoAccess: Real-Time Web Log Analytics Without Tracking Scripts

GoAccess is an open-source web log analyzer that provides real-time traffic analytics directly from web server logs. Unlike Google Analytics and similar services, it requires no JavaScript trackers, cookies, databases, or external services, making it a privacy-friendly choice for self-hosted environments. It runs in the terminal or generates live HTML dashboards, allowing administrators to monitor traffic, bandwidth usage, response times, errors, and suspicious activity directly from Apache, Nginx, Caddy, CloudFront, and other log sources.

GitHub - allinurl/goaccess: GoAccess is a real-time web log analyzer and interactive viewer that runs in a terminal in *nix systems or through your browser.

GoAccess is a real-time web log analyzer and interactive viewer that runs in a terminal in *nix systems or through your browser. - allinurl/goaccess

GitHuballinurl

📰 Linux news that matters

• Podman 6.0 is here with some breaking and some interesting features. In cleaning, cgroups v1, iptables, CNI networking, slirp4netns, Intel Mac, and Windows 10 support are all dropped. BoltDB is gone and Podman auto-migrates to SQLite. Network isolation now defaults to enabled. New additions: AMD GPU support via --gpus, a podman machine os update command, and a patch for CVE-2026-57231 (host env var leakage via malformed image metadata)
• Microsoft's long-planned Secure Boot certificate rollover has reached its final stage as legacy certificates issued in 2011 begin expiring in June 2026, requiring systems to transition to newer 2023 certificate chains. The change is intended to maintain UEFI trust integrity and enable future security updates that protect against firmware attacks, bootkits, and supply-chain compromises.
• The Linux Foundation announced its intent to launch the Agent Name Service (ANS), an open standard that extends DNS to provide identity, verification, and discovery mechanisms for AI agents operating across organizations and platforms. ANS aims to create a federated trust layer that allows operators to verify who an agent represents, what permissions it has, and whether its software remains authentic, without relying on proprietary registries or centralized control.
• Linux 7.2 removes the final uses of the strncpy() function from the kernel after roughly six years of work and more than 360 patches spread across numerous subsystems. The API has long been discouraged because its semantics frequently lead to truncation bugs, non-terminated strings, and other memory-handling mistakes, prompting kernel developers to replace it with safer alternatives.
• AWS has released AWS Blocks in public preview, an open-source TypeScript framework that packages application code, local development environments, and AWS infrastructure definitions into reusable modules called "Blocks." The framework provides local Postgres, authentication, messaging, storage, and other backend services without requiring an AWS account, while generating production AWS infrastructure automatically during deployment.
• Vercel has released eve, an open-source framework that defines AI agents as directories containing Markdown instructions, skills, and TypeScript tools, allowing agents to be developed using a filesystem-first workflow. The framework ships with production-oriented capabilities such as durable execution, sandboxed compute, subagents, approvals, and workflow orchestration already integrated rather than requiring developers to assemble multiple infrastructure components.
• GitHub has started retiring GitHub Models, the free AI playground and API layer introduced in 2024, with new customers already blocked from accessing the service as of June 16, 2026. Existing users can continue using the playground, APIs, and hosted models for now, but GitHub has confirmed that the service is heading toward full retirement and is directing new projects toward Azure AI Foundry.

😂 Geek humor

💌 Keep on loving Linux Handbook

We are working on a few new courses. GitOps is the next in publishing queue followed by GNS3.

And if you like the LHB Linux digest, you can encourage others to subscribe to this newsletter. (From here)

Become a Pro member and enjoy unlimited access to our eBooks, courses and in-depth tutorials.

Missed the previous editions? You can access the newsletter archives.

You may also contribute to Linux Handbook and share your experience and expertise with the community.

I like reading your messages, so just hit the reply button and share your thoughts 😄

My Downloads folder is a crime scene. My home directo

Thousands of files with names like IMG_2048.jpg, Copy_of_final_FINAL_v3.pdf, and untitled(2).docx accumulated over years of telling myself I'd sort it out later. I never did.

I tried manual sorting. I tried renaming scripts. Nothing stuck because the real problem isn't laziness, it's that I don't know what half the files actually are without opening them first.

AI File Sorter takes a different approach. Instead of applying fixed rules, it reads your files, actually looks at images using a visual LLM, extracts text from documents, reads audio/video metadata and then suggests what each file is and where it should go. You review the suggestions before anything moves. Nothing happens without your approval.

With over 1,000 stars on GitHub and 16 releases since launch, this isn't an abandoned proof-of-concept. It's a cross-platform desktop app actively being developed, and version 1.8.0 just shipped with meaningful improvements to the visual model and local learning.

What AI File Sorter Actually Does

Let me be precise about this, because "AI file organizer" can mean very different things.
AI File Sorter does three related but distinct things:

Categorization - It analyzes each file (by name, extension, content, and folder context) and assigns it a category and optional subcategory. "Photography", "Work Documents", "Music", "Screenshots" - then creates the folders and moves files into them. You pick the categories or let the model suggest them freely.

Rename suggestions - For images, it uses a visual LLM to actually look at the picture and suggest a descriptive filename. IMG_2048.jpg might become sunset_over_lake.jpg. For documents, it reads the text content and proposes a cleaner name. For audio/video, it reads the embedded metadata tags and turns them into a consistent library-style name like 2024_artist_album_title.mp3.

Review before action - This one matters. None of the above actually happens until you see the suggestions in a review table, approve what you want, edit anything you don't like, and click confirm. Nothing is irreversible without your sign-off.

Getting It Running on Linux

I tested this on Ubuntu 24.04. The prebuilt .deb package from https://filesorter.app/
First, install the runtime prerequisites:

sudo apt update && sudo apt install -y \
  libqt6widgets6 libcurl4 libjsoncpp25 libfmt9 libopenblas0-pthread \
  libvulkan1 mesa-vulkan-drivers patchelf

Then download the latest released version deb file form https://filesorter.app/download/ and then install it:

After that install the package:

sudo apt install ./aifilesorter_*.deb

Once installed, launch it from your application menu or run:

aifilesorter

Choosing Your LLM Backend

This is the first real decision you make, and it shapes the whole experience. AI File Sorter supports several options:

Local models (no internet required): Gemma 3 4B IT, the new default for both text and visual analysis. Downloads once via the in-app Select LLM dialog. Gemma 1.1 7B, a solid local text-only choice for categorization. Mistral 7B, another built-in option with broader category language support. Your own GGUF, any compatible model you already have can be registered

Remote models (API key required): - ChatGPT, your own OpenAI API key, any model (gpt-4o-mini, gpt-4.1, etc.). Gemini, your own Google AI Studio key (gemini-2.5-flash, gemini-2.5-pro, etc.). Custom OpenAI-compatible endpoint, LM Studio, Ollama, or any local server you're already running

After that there is option to analyse the folder which starts the analysis and one by one parses the files from that folder and categorises it as follows:

A few things I noticed in the review: An old screenshot was correctly categorized as "Screenshots/Desktop UI" rather than as a generic "Image" and the images are structured under the folder as per the content and not just by name of the files.

It asks for your permission to proceed and turn the given randomly stuffed files into categorised, well-structured files. Now, after accepting the changes, you will be able to see the structured files in your Downloads folder:

In the Downloads, there are multiple folders created, like Images: which contains different folders like General, Logos and Photographs which are created with the help of categorization of aifilesorter.

Documents: which contain different documents categorized after the analysis by aifilesorter. The rename suggestions aren't always perfect. Some generic outdoor shots got overly generic names

Document Analysis: Reading the File, Not Just the Name

Document analysis uses the same LLM (text mode, no mmproj needed) to extract text from supported file types and generate a summary and filename suggestion. Supported formats include:

Plain text: .txt, .md, .rtf, .csv, .json, .yaml, .log, .html
PDF: built-in PDFium extractor (no pdftotext dependency needed)
Office formats: .docx, .xlsx, .pptx, .odt, .ods, .odp

For my test files, a .pdf result certificate got the Academic_record.pdf based on its opening paragraph. A .odt export from a bank statement was categorized as "Finance" correctly. An old HTML file from a downloaded web page got correctly identified as a web capture rather than a document.

GPU Acceleration: Vulkan, CUDA, and CPU Fallback

The app supports GPU acceleration via CUDA (NVIDIA) and Vulkan (AMD, Intel, NVIDIA). On Linux, the launcher script auto-detects available backends and prefers CUDA over Vulkan, falling back to CPU if neither is detected.

You can check and force backends with flags:

# Force CPU only
aifilesorter --cuda=off --vulkan=off

# Force Vulkan
aifilesorter --vulkan=on --cuda=off

Category Whitelists and Consistency Controls

One thing I appreciated after my first run: you can constrain what categories the model can pick. Under Settings → Manage category whitelists…, you create named lists of allowed categories.

On a re-run of my Downloads folder with a whitelist set to ["Work", "Personal", "Finance", "Software", "Media", "Archive"], the suggestions became noticeably more consistent. Files weren't spread across thirty micro-categories; they clustered into the buckets I actually wanted.

The docs recommend keeping whitelists to 15–20 entries so they don't overflow smaller local model context windows. For a tightly defined use case (organizing a project folder, sorting a media library), whitelists are the right tool.

Pair whitelists with "More Consistent" categorization mode for the strongest uniformity across a batch.

What Works Well

The review-first workflow is the right design. Nothing moves until you approve it. This sounds obvious, but a lot of "automatic" organizers just move your files and hope for the best. The review table with inline editing gives you real control.

Visual analysis on images is genuinely useful. Calling a local 4B model to look at actual pixel content and suggest a descriptive name is the thing that separates this app from any rename-by-rules script. It won't always be perfect, but it's directionally right far more often than filename heuristics.

It runs entirely offline. No data leaves your machine when using local models. Images, filenames, document text, all processed locally. For people sorting sensitive files, this matters.

The 1.8.0 screenshot-awareness is a real improvement. UI screenshots no longer get misclassified as generic photos. The app adds specific prompt guidance for dashboards, forms, mockups, and terminal captures.

The undo feature works. Edit → Undo last run reverses the moves on a best-effort basis. Combined with dry-run mode, the safety net is solid for cautious users.

What to Be Aware Of

Analysis time scales with folder size and model. Processing a 500-file folder with visual analysis on every image takes meaningful time on CPU. Plan for it, don't run this right before you need your machine for something else.

Legacy Office formats (.doc, .xls, .ppt) are not supported. Only the modern Office XML formats (.docx, .xlsx, .pptx) and OpenDocument equivalents are handled. Old binary formats need converting first.

The visual model needs two GGUF files. The main model and the mmproj projector. If you download one and forget the other, image analysis is silently disabled. The app will prompt you to open the Select LLM dialog, but it's easy to miss if you're not looking.

Rename suggestions on images aren't always specific. A generic outdoor photo might get a generic descriptive name. The model does its best with what it can see, but "mountain_landscape.jpg" is only marginally better than "IMG_2048.jpg" if you have fifty of them. The categorization accuracy is stronger than the rename precision.

Conclusion

AI File Sorter is doing something meaningfully different from rename scripts and rules-based organizers. Reading actual image content with a visual LLM, extracting document text, reading audio metadata and then letting you review everything before a single file moves, is the right design for a tool that touches your files.

The local-first approach is a genuine differentiator. My images, documents, and filenames stayed on my machine throughout. No API key, no cloud, no data leaving my hard drive.

The 1.8.0 improvements to the visual model (Gemma 3 4B IT as default, better screenshot detection, local learning from your approved reviews) make this a noticeably better version than what shipped a few months ago. It's not a finished, polished SaaS product; it's an actively developed open-source desktop app with rough edges, but for the specific problem of "I need to make sense of this chaotic folder of files," it works.

I am loving to use local AI. It started with using AI for knowledgebase and now for file sorting. I got to keep exploring 😄

I spent time evaluating these across personal homelab setups, team documentation workflows, and AI-augmented note-taking, filtering down to 11 tools that solve real problems that cloud-only solutions like Notion and Confluence leave unaddressed.

There's a reason self-hosted knowledge bases are surging in interest right now: local AI integration. Tools like Claude (via MCP), Ollama-backed local LLMs, and RAG pipelines mean you can now ask your own knowledge base questions in natural language, without sending your private notes to a third-party server. The difference between a knowledge base that supports Markdown on disk and one that locks you into a proprietary format is now the difference between AI-queryable and AI-blind.

Short on time? Jump to the comparison table below, or use the headers to find your fit.

At a Glance: All 11 Tools Compared

Here's a quick overview before the full breakdowns.

Now let's go through each one.

Outline - Best Team Knowledge Base with Native Claude/MCP Integration

Outline is a fast, Markdown-based team wiki and knowledge base that has quietly become the go-to self-hosted alternative to Notion/Confluence for small-to-medium teams - and its Model Context Protocol (MCP) support now lets you connect Claude directly to your Outline wiki to search, read, and write documents through natural language.

Who it's best for: Engineering teams and small companies who want a clean, fast, team-accessible wiki that doesn't require a Confluence subscription - especially teams that want Claude or other AI assistants to be able to query the wiki directly.

Quick Setup:

git clone https://github.com/vicalloy/outline-docker-compose.git
cd outline-docker-compose
cp scripts/config.sh.sample scripts/config.sh
# update config file: vim scripts/config.sh
make install  # Create a docker-compose config file and start it. Initializing the oidc-server(add oidc client for outline and create a superuser).

You will be asked to set up the username and the password for the authentication. Once you set all the things, you will see the outline running on localhost:8888 as below:

The Claude/MCP integration is the headline feature here. With the Outline MCP server, Claude can search your wiki, fetch document contents, and even create or update documents.

Verdict: The most AI-forward self-hosted team wiki available today. If your team uses Claude and wants the AI to actually know what's in your internal docs, Outline's MCP integration makes that real.

BookStack - Best Self-Hosted Wiki for Simple, Structured Team Documentation

BookStack is a self-hosted documentation platform organized around a physical book metaphor: Books → Chapters → Pages. It's opinionated in the best way, the structure makes sense immediately, and there's virtually no setup overhead for the end user.

Who it's best for: Small teams, IT departments, and homlab operators who need a clean, no-frills internal wiki for SOPs, runbooks, and project docs and don't want to spend time configuring the tool itself before using it.

Quick Setup:

#docker compose file
services:
  bookstack:
    image: lscr.io/linuxserver/bookstack:latest
    container_name: my_bookstack
    environment:
      - PUID=1000
      - PGID=1000
      - APP_URL=http://localhost:6875
      - APP_KEY=[key]
      - DB_HOST=my_bookstack_db
      - DB_USER=bookstack
      - DB_PASS=yourpassword
      - DB_DATABASE=bookstackapp
    volumes:
      - ./bookstack_app_data:/config
    ports:
      - 6875:80
    restart: unless-stopped
    depends_on:
      - bookstack_db

  bookstack_db:
    image: lscr.io/linuxserver/mariadb:latest
    container_name: my_bookstack_db
    environment:
      - PUID=1000
      - PGID=1000
      - MYSQL_ROOT_PASSWORD=yourpassword
      - TZ=Etc/UTC
      - MYSQL_DATABASE=bookstackapp
      - MYSQL_USER=bookstack
      - MYSQL_PASSWORD=yourpassword
    volumes:
      - ./bookstack_db_data:/config
    restart: unless-stopped

You need to set the parameters as per your requirements, then after docker compose up you will see the application running on localhost:6875. You just need to generate one APP_KEY then you can replace the same and run the compose file.

You will see a simple minimalist view which represents the books, chapters and pages. Export formats: Markdown, HTML, PDF, Plain Text, ZIP (portable backup of an entire Book or shelf).

Verdict: The most production-ready, plug-and-play wiki on this entire list. If your team has been putting off setting up internal documentation because every option felt complex, BookStack removes that excuse.

Wiki.js - Best Self-Hosted Wiki for Developer Teams

Wiki.js is a modern, Node.js-based wiki platform with multiple storage backends, including Git sync - meaning your documentation can live as Markdown files in a Git repository, automatically synced both ways. This makes it trivially easy to point AI tools at your docs.

Who it's best for: Developer teams who want their documentation to live in Git alongside their code and want a clean web UI on top without giving up version history, PRs, or `git blame` for docs.

Quick Setup:

services:
  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_DB: wiki
      POSTGRES_PASSWORD: wikijsrocks
      POSTGRES_USER: wikijs
    volumes:
      - db-data:/var/lib/postgresql/data
    restart: unless-stopped

  wiki:
    image: ghcr.io/requarks/wiki:2
    depends_on:
      - db
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: wikijs
      DB_PASS: wikijsrocks
      DB_NAME: wiki
    ports:
      - "3000:3000"
    restart: unless-stopped

volumes:
  db-data:

After running the compose, you will be able to see the application running:

After the initial setup of the email and password, you will get to see different features like search engines, API access, authentication, storage, analytics and many more.

Verdict: The best choice for engineering teams who want their wiki to behave like their code, in Git, reviewable, version-controlled, and introspectable by any AI tool that can read a repo.

Obsidian - Best Personal Knowledge Base with AI Plugin Ecosystem

Obsidian stores your notes as plain Markdown files on disk, which sounds simple, but it means you have the most AI-friendly knowledge base possible. Every local LLM (via Ollama), every AI agent (including Claude via MCP), and every search tool can work directly with your notes without any export step.

Who it's best for: Researchers, writers, developers, and knowledge workers who want a powerful personal knowledge base with bidirectional links, a graph view, and access to the richest AI plugin ecosystem of any PKM tool available.

Quick Setup:

services:
  obsidian:
    image: lscr.io/linuxserver/obsidian:latest
    container_name: obsidian
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
    volumes:
      - obsidian-config:/config
    ports:
      - 3000:3000
      - 3001:3001
    restart: unless-stopped
    shm_size: "1gb"

volumes:
  obsidian-config:

After setting up your obsidian will be running on localhost:3000

It supports many open source and community plugins and the graph view is one of the most promising features. Through these plugins, like obsidian-mcp you can expose your Obsidian vault to Claude desktop.

Verdict: The most AI-ready knowledge base because it's the most file-system-friendly. Your notes are just Markdown. Claude can read them via MCP. Ollama can embed them for RAG. If AI augmentation of your personal knowledge base matters, start here.

AFFiNE - Best All-in-One Knowledge Base with Built-In AI Copilot

AFFiNE is an open-source, self-hostable Notion alternative that combines documents, databases, and an infinite whiteboard canvas - with a built-in AI Copilot that supports Claude, OpenAI, and Gemini models, configurable from the admin console of your self-hosted instance.

Who it's best for: Teams and individuals who want the Notion all-in-one experience (notes + projects + databases + visual thinking) but want to self-host their data and plug in their own AI provider, including Claude.

Quick Setup:

name: affine
services:
  affine:
    image: ghcr.io/toeverything/affine:${AFFINE_REVISION:-stable}
    container_name: affine_server
    ports:
      - '${PORT:-3010}:3010'
    depends_on:
      redis:
        condition: service_healthy
      postgres:
        condition: service_healthy
      affine_migration:
        condition: service_completed_successfully
    volumes:
      # custom configurations
      - ${UPLOAD_LOCATION}:/root/.affine/storage
      - ${CONFIG_LOCATION}:/root/.affine/config
    env_file:
      - .env
    environment:
      - REDIS_SERVER_HOST=redis
      - DATABASE_URL=postgresql://${DB_USERNAME}:${DB_PASSWORD}@postgres:5432/${DB_DATABASE:-affine}
      - AFFINE_INDEXER_ENABLED=false
    restart: unless-stopped

  affine_migration:
    image: ghcr.io/toeverything/affine:${AFFINE_REVISION:-stable}
    container_name: affine_migration_job
    volumes:
      # custom configurations
      - ${UPLOAD_LOCATION}:/root/.affine/storage
      - ${CONFIG_LOCATION}:/root/.affine/config
    command: ['sh', '-c', 'node ./scripts/self-host-predeploy.js']
    env_file:
      - .env
    environment:
      - REDIS_SERVER_HOST=redis
      - DATABASE_URL=postgresql://${DB_USERNAME}:${DB_PASSWORD}@postgres:5432/${DB_DATABASE:-affine}
      - AFFINE_INDEXER_ENABLED=false
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy

  redis:
    image: redis
    container_name: affine_redis
    healthcheck:
      test: ['CMD', 'redis-cli', '--raw', 'incr', 'ping']
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped

  postgres:
    image: pgvector/pgvector:pg16
    container_name: affine_postgres
    volumes:
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    environment:
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: ${DB_DATABASE:-affine}
      POSTGRES_INITDB_ARGS: '--data-checksums'
      # you better set a password for you database
      # or you may add 'POSTGRES_HOST_AUTH_METHOD=trust' to ignore postgres security policy
      POSTGRES_HOST_AUTH_METHOD: trust
    healthcheck:
      test:
        ['CMD', 'pg_isready', '-U', "${DB_USERNAME}", '-d', "${DB_DATABASE:-affine}"]
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped

After setting up, your application will be running on localhost:3010

You can also manage AI integration through the settings by providing API_KEY and necessary URLs.

Verdict: The most feature-complete open-source Notion alternative, and the only one with a genuinely integrated AI Copilot you can point at Claude. For teams migrating from Notion who want to keep their AI features, this is the path.

SiYuan Notes - Best Privacy-First Knowledge Base with Local-First Architecture

SiYuan is a block-based, local-first personal knowledge management system with a built-in SQLite index, which means you get powerful block-level cross-referencing and database-like queries entirely on your own machine, with no mandatory cloud connection.

Who it's best for: Privacy-conscious individuals and power users who want deep block-level relational linking, a clean self-contained app, and the option to self-host their own sync server without any third-party cloud involvement.

Quick Setup:

version: "3.9"
services:
  siyuan:
    image: b3log/siyuan
    command: ["--workspace=/siyuan/workspace/", "--accessAuthCode=siyuanrocks"]
    ports:
      - 6806:6806
    volumes:
      - siyuan-data:/siyuan/workspace
    restart: unless-stopped

volumes:
  siyuan-data:

After running the setup you need to enter the authcode that you have set in the configuration in this case: siyuanrocks

You can also get the AI features through the API_KEY of ChatGPT, Claude, DeepSeek, and other models that support the OpenAI interface.

Verdict: The most technically sophisticated privacy-first PKM on the list. The SQL-queryable block database is genuinely unique; no other tool on this list lets you run relational queries across your notes like this.

Logseq - Best Knowledge Base for Networked Thought and Graph-Based Thinking

Logseq is a local-first, outline-based knowledge tool built around the concept of networked thought, every bullet point is a block that can be referenced from anywhere, and a graph view visualizes the connections between all your notes. Like Obsidian, it stores everything as plain Markdown (or Org-mode) files on disk.

Who it's best for: Researchers, academics, writers, and deep thinkers who work with connecting ideas across many notes, anyone who has found flat note apps limiting and wants to see how their knowledge relates to itself.

Quick Setup:

services:
  logseq:
    image: ghcr.io/logseq/logseq-webapp:latest
    ports:
      - "3001:80"
    restart: unless-stopped

After deploying the setup, the Logseq will be available at localhost:3001

Whiteboard and flashcards are one of the promising features from Logseq.

Verdict: The best choice for people who think in connections rather than linear documents. If you've ever wanted to see how all your research relates to itself, the graph view will immediately make sense. Pair it with Ollama and the Smart Search plugin for local AI querying.

AppFlowy - Best Open-Source Notion Alternative with Growing AI Features

AppFlowy is an open-source, local-first Notion replacement built in Flutter, with a modular architecture designed from the ground up for customization and self-hosting. Its AI integration is under active development, with integrations for local models (Ollama) and cloud providers being added in 2024-2025.

Who it's best for: Teams and individuals who want a Notion-like interface (documents, databases, kanban boards, calendars) with full local ownership and the ability to deploy their own sync server and are willing to accept that AI features are still maturing.

Quick Setup:

# clone repo
git clone https://github.com/AppFlowy-IO/AppFlowy-Cloud.git
cd AppFLowy-Cloud

# copy .env file
cp deploy.env .env

# change ports
NGINX_PORT=80
NGINX_TLS_PORT=443

docker compose up -d

docker compose ps

After the setup, if there is an error of a port already in use, try changing the ports and running the application again.

Verdict: The most Notion-like experience in the open-source world, with local-first data ownership. The AI integrations are genuinely there, just earlier-stage. If you want to own your Notion replacement and watch it grow, AppFlowy is the right bet.

Trilium Notes - Best Self-Hosted Tool for Deep Hierarchical Personal Knowledge

Trilium Notes is a hierarchical personal knowledge base with an unusual superpower: scripted automation via built-in JavaScript note scripts. Notes can contain runnable JS that queries and manipulates other notes, making it a programmable knowledge system, not just a static wiki.

Who it's best for: Power users and developers who want maximum flexibility in how their knowledge is organized and automated, including those who want to build custom AI integrations directly into their notes via JavaScript.

Quick Setup:

services:
  trilium:
    image: zadam/trilium:latest
    container_name: trilium-notes
    restart: unless-stopped
    ports:
      - "50081:8080" # Mapping to an alternative port to avoid conflicts with other apps
    volumes:
      - trilium_data:/home/node/trilium-data
    environment:
      - TRILIUM_PORT=8080

volumes:
  trilium_data:

After the setup the Trilium will be running on localhost:50081

It has a hierarchical structure of notes and also has the feature of canvas notes where you can add shapes, arrows and colors to your notes.

Verdict: The most programmable personal knowledge base on the list. If you've ever wanted your notes to run code and call an AI API on their own, Trilium (via TriliumNext) is the only tool on this list that does that natively.

Anytype - Best Local-First Knowledge Base with Offline-First Architecture

Anytype is a privacy-focused, object-based personal knowledge tool built on a peer-to-peer protocol (Any-Sync). Everything is stored locally first and synced peer-to-peer; there's no central server that holds your data. Even when using Anytype's network for sync, data is end-to-end encrypted before leaving your device.

Who it's best for: Privacy-focused individuals who want a Notion-like structured knowledge system with the strongest possible data sovereignty guarantees and are comfortable with a younger, still-maturing product.

Quick Setup:

Unlike the other projects this one needs you to download the Desktop app through their website: https://anytype.io/

Any experience gallery is one of the features they provide to experience different configurations created by some users for easy workflow management.

Verdict: The strongest privacy guarantee of any tool on this list, peer-to-peer, E2EE, and self-hostable right down to the sync layer. For users who treat data sovereignty as a non-negotiable, Anytype is the pick, even if it means waiting for AI features to land.

Joplin - Best Open-Source Notes App with Portable Encryption and Sync

Joplin is a mature, battle-tested open-source note-taking app that strikes the best balance between data portability, privacy, and accessibility across platforms. It syncs to virtually anything: Nextcloud, WebDAV, Dropbox, OneDrive, S3 and has Joplin AI and AI plugin support for LLM integration.

Who it's best for: Users switching from Evernote or OneNote who want an open-source, self-hostable replacement with broad platform support, end-to-end encryption, and enough extensibility to add AI features via the plugin system.

Quick Setup:

services:
  postgres:
    image: postgres:16
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    restart: unless-stopped
    environment:
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_DB=${POSTGRES_DATABASE}
    networks:
      - joplin_network

  joplinsync:
    image: joplin/server:latest
    depends_on:
      - postgres
    ports:
      - "22300:22300"
    restart: unless-stopped
    environment:
      - APP_PORT=22300
      - APP_BASE_URL=${APP_BASE_URL}
      - DB_CLIENT=pg
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_DATABASE=${POSTGRES_DATABASE}
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PORT=5432
      - POSTGRES_HOST=postgres
    networks:
      - joplin_network

networks:
  joplin_network:

After giving the necessary parameters in your .env or values in specific parameters, the Joplin server will run at localhost:22300.

It has a plugin named Jarvis (Joplin Assistant Running a Very Intelligent System), which is an AI note-taking assistant for Joplin, powered by online and offline LLMs (such as OpenAI's ChatGPT or GPT-4, Hugging Face, Gemini, Universal Sentence Encoder). For the Desktop application, you can download it from the official link.

Verdict: The safest choice for Evernote/OneNote migrants who value data portability above all else. The plugin ecosystem and AI integration make it more capable than it looks, and the sync flexibility means it fits into virtually any existing self-hosted stack.

Final Recommendation

If you need a team knowledge base with AI today, use Outline. Its MCP integration for Claude is production-ready, its Markdown export keeps you unlockedin, and the managed cloud tier means you can start without infrastructure. After that, pick based on your primary use case:

• Team documentation: Outline (AI-first, MCP/Claude) or BookStack (simple, structured)
• Developer teams wanting Git-backed docs → Wiki.js (Markdown in Git, then any AI agent can query it)
• Personal knowledge + AI plugins: Obsidian (plain files + Ollama/Claude MCP) or Logseq (graph-first with local AI)
• Notion replacement with built-in AI Copilot: AFFiNE (Claude/OpenAI/Gemini configured in admin)
• Privacy-first with maximum data sovereignty: SiYuan (local-first, SQL-queryable) or Anytype (E2EE P2P sync)
• Programmable personal knowledge base: TriliumNext (JavaScript scripting in notes, call AI APIs directly)
• Evernote migrators: Joplin (ENEX import, E2EE sync, AI plugin available)

If you have any of the self-hosted knowledge base tools not listed here, feel free to drop them in the comments!

I manage my project boards in Fizzy, Basecamp's clean, opinionated kanban tool, and I got tired of the same ritual: open the browser, navigate to the board, drag a card, close the tab, back to work, repeat. The board lives in one app, my actual work lives somewhere else, and that context switching chips away at focus more than I'd like to admit. So I decided to fix it. Here's what I did.

What I built

Before going through this, I need you to know what Fizzy CLI and ZeroClaw is:

Fizzy CLI fixes half of that problem. It's an official command-line tool that lets you create cards, post comments, search your board, and manage attachments entirely from the terminal, no browser required. The other half of the problem gets solved by ZeroClaw.

ZeroClaw is an open-source agent runtime written in Rust, a single binary you install and configure. It connects to 30+ channels (Telegram, Discord, Matrix, email, or just your CLI), and is genuinely provider-agnostic: it talks to Anthropic, OpenAI, Gemini, Ollama, Groq, and about twenty other LLM backends, all from the same TOML config file. Everything runs on your machine, with your keys. This guide walks you through installing Fizzy CLI, authenticating it, and wiring it up to a running NanoClaw agent so you have end-to-end control of your boards from the terminal and from any messaging app.

Once you wire Fizzy into ZeroClaw as a shell tool, you can message your agent "add a card titled fix the auth bug to my backlog" and it just does it - from your phone, from Telegram, from wherever you happen to be.

I ended up installing Fizzy CLI, authenticating it, and wiring it to a ZeroClaw agent, and in this post I'm walking through exactly what I did, including the parts that didn't go smoothly.

What I used

• A Linux machine - I ran this on Ubuntu 22.04 LTS; Arch and Fedora should work fine too
• An active Fizzy account with at least one board created
• A Fizzy personal access token - get it from Profile → API Tokens in the Fizzy web UI
• One of: a free Gemini API key from Google AI Studio, or Ollama running locally with a model pulled (e.g., ollama pull qwen2.5:7b)

Installing Fizzy CLI

The fastest path on Linux is the official install script - it detected my architecture, pulled the right binary, and verified checksums automatically. I just ran:

curl -fsSL https://raw.githubusercontent.com/basecamp/fizzy-cli/master/scripts/install.sh | bash

Complete the installation process, it will prompt for the PAT, generate it from your personal fizzy profile and enter it when prompted.

If you're on Arch Linux or Omarchy, it's available in the AUR:

yay -S fizzy-cli

Once the installer finishes, confirm the binary is on your PATH:

fizzy --version

You should see the version string printed cleanly. If your shell says command not found, the binary likely landed in ~/.local/bin - make sure that's in your PATH.

export PATH="/home/USERNAME/.local/bin:$PATH"

Exploring the Basic Commands

First I ran this to confirm my identity and grab my account slug:

fizzy identity show

It will show all the identity information along with your slug id , use that id and run the following command:

fizzy board list --account "slug id"

Here is a list of boards with their names. As I have more accounts, I need to mention the account ID for commands.

Try more commands like:

# List cards on your default board
fizzy card list

# View details of a specific card
fizzy card show 2

# Search across your board
fizzy search "authentication bug"

# Add a comment to a card
fizzy comment create --card 42 --body "Reproduced on staging."

It will display the cards, a specific card, searching across the board, etc.

Also, if you use jq the output will be in formatted so that you can clearly make sense of the results.

fizzy card list --account "id" | jq

Installing ZeroClaw

ZeroClaw ships as a single Rust binary. When the install script asked me whether I wanted a prebuilt binary or a source build, I went with prebuilt - it was done in seconds:

curl -fsSL https://raw.githubusercontent.com/zeroclaw-labs/zeroclaw/master/install.sh | bash

When it finishes, confirm it's available:

When it finishes, confirm it's available:

zeroclaw --version

ZeroClaw has no runtime dependencies. No Docker, no Node.js, no Python. The binary is self-contained.

Running the Onboarding Wizard

ZeroClaw's config lives at ~/.zeroclaw/config.toml. Running the onboarding wizard creates it for you:

zeroclaw onboard

The wizard walked me through four things:

• LLM provider - which model backend to use
• API key or endpoint - your credentials for that provider
• At least one channel - the built-in cli channel works for now; you can add Telegram or Discord later
• Agent alias - a name for your agent entry in the config

For the LLM provider step, enter gemini and paste your Google AI Studio API key when prompted. If you're using Ollama locally, choose ollama instead, the wizard will ask for your model name (e.g., qwen2.5:7b) and leave the endpoint at the default http://localhost:11434.

There is vast support for various channels:

Then there will be an option to select a memory backend, select the appropriate one as per your need:

the model_provider field on your agent is the only place you specify which LLM to use in your ~/.zeroclaw/config.toml . Swapping from Gemini to Ollama to Groq is a one-line change.

Registering Fizzy as a Shell Tool

ZeroClaw's shell tool lets the agent run any command on your machine. To give it access to fizzy, add a tool entry to your config and give the agent permission to use it:

Add "fizzy" at commands in config, it will look like this:

allowed_commands = [
    "git",
    "npm",
    "cargo",
    "ls",
    "cat",
    "grep",
    "find",
    "echo",
    "pwd",
    "wc",
    "head",
    "tail",
    "date",
    "df",
    "du",
    "uname",
    "uptime",
    "hostname",
    "python",
    "python3",
    "pip",
    "node",
    "free",
    "fizzy"
]

One thing that caught me off guard: Fizzy has to be explicitly listed in allowed_commands or ZeroClaw's security layer blocks it, even if you've defined the tool entry. I learned this the hard way after getting a "Command not allowed by security policy" error.

Then add the new entry in the config:

[tools.shell.fizzy]
description = "Manage Fizzy kanban boards via the Fizzy CLI"
command     = "fizzy"
allowed_args = ["board", "card", "comment", "search", "commands"]

[agents.assistant]
model_provider = "gemini-cli"
risk_profile   = "supervised"
tools          = ["shell.fizzy"]

Follow the similar steps for ollama setup too.

Check once the parameters as per your model are selected. Whichever path you followed, the wizard ends with a quick live chat to confirm your agent is working. You'll see a prompt like:

Confirming the Agent Responds

Whichever path you followed, Gemini or Ollama, start the agent to confirm everything is working:

zeroclaw agent

You should get a CLI chat prompt. Type a test message:

Hello, are you there?

If it responds, you're done. If you are using a local LLM and see an error like model requires more system memory than is available, your chosen model is too large for the free RAM currently available. Fix it by pulling the 1B model instead and updating your config:

ollama pull llama3.2:1b
# Then edit ~/.zeroclaw/config.toml and set: model = "llama3.2:1b"

If it responds, your LLM backend is wired up correctly. Total setup time is about five minutes. Once the agent responds, you're ready to wire in Fizzy.

Verifying the Fizzy Integration

I asked the agent something simple to confirm the wiring:

Use the fizzy shell tool to run: fizzy card list

ZeroClaw called fizzy card list, parsed the JSON output, and summarized my cards in natural language. In supervised mode it asked for approval first - I pressed Y, and it worked.

One tip I'd pass on: be explicit in your prompt. "List the cards on my board" can confuse the agent into doing a web search instead. Saying "use the fizzy shell tool to run..." removes the ambiguity entirely.

From there, you can do things like:

Create a card titled "Review auth middleware" on my board.
Add a comment to first card saying I'll look at this after the release.
Search for anything related to "database migration".

What to Explore Next

We have covered how to setup and get started with Fizzy CLI with ZeroClaw agent, but you can explore more things like:

Per-repo board context: Create a .fizzy.yaml in any project directory with a board field. When you're inside that directory, fizzy card list will default to that project's board automatically, no flags needed.

Swap the model: If Gemini starts hitting rate limits or you want to try something faster, add a second provider entry and change the model_provider alias on your agent.

Add a second agent: ZeroClaw supports multiple [agents.*] entries pointing at different providers. You could run a lightweight Ollama model for quick card operations and route heavier reasoning tasks to Gemini, all from the same ZeroClaw instance.

Wrapping Up

What I like most about this setup is the flexibility. ZeroClaw doesn't care which LLM I use. I started with Ollama locally, hit tool-calling limitations with smaller models, and switched to Gemini's free tier without touching anything except two lines in the config.

The context switching problem is what motivated all of this, and I think this setup genuinely solves it. Having Fizzy in the terminal is one improvement. It took me an afternoon to get everything right. The time it saves should compound from here.

Do visit the repos and try it yourself!

I have thousands of notes. Obsidian vaults, random Markdown files, half-finished research documents, meeting notes from three years ago. And for the longest time, they just sat there, searchable by filename, searchable by keyword, but never actually understood.

Then one evening I thought, What if I could just ask my notes a question?

You might be thinking the ChatGPT already does that, but it does not have access to your local workspace. You need to upload all the files you want to discover, not a cloud service that makes me wonder what happens to my data.

Instead, I thought of using just a small AI model, completely running on my own machine. I thought that it could handle these situations, which could read my notes and answer questions about them.

I tried it. It worked. And I have not stopped using it since. No GPU required, no monthly subscription, no data leaving my machine.

The problem with the huge pile notes (and how AI fixes it)

Here is the honest truth: most knowledge management systems fail not at storing information, but at retrieving it. You spend time writing the note. You tag it. You organize it. And then, three weeks later, you cannot find it because you cannot remember what you called it or which folder you put it in.

Traditional search is keyword-based. It finds notes that contain the word "containerization", but it cannot answer "how do I deploy a container in a restricted environment?" by synthesizing your notes on Docker, your notes on firewalls, and that one Markdown file you wrote during a workshop.

That synthesis is exactly what a local AI model can do.

The technique is called RAG (Retrieval-Augmented Generation). The AI does not memorize your notes. Instead, it reads them at query time, pulls the most relevant chunks, and uses them as context to generate an answer.

Think of it as giving the AI your notes as a reference book every time you ask a question.

What I used in this setup

A fully local setup with three components:

• Ollama: Runs LLM models locally on your CPU (or GPU if you have one)
• A lightweight embedding model: Converts notes into searchable vectors
• AnythingLLM (or Open WebUI): UI that connects your notes to the model

Everything runs on the local machine. The notes never leave the computer. The model does not even need an internet connection once it is downloaded.

Choosing the right model

This is the part most guides get wrong. They recommend a 7B parameter model. You try to run it on your laptop, and it takes 90 seconds to answer a simple question.

For a knowledge base assistant that runs comfortably on a CPU, even a mid-range one, the sweet spot is Phi-3 Mini (3.8B parameters from Microsoft) or Gemma 2B (from Google). Both are surprisingly capable for question-answering tasks, and they run well with 8 GB of RAM.

You can also refer to this article for information about models running on CPU.

My recommendation: phi3:mini, it is fast, accurate, and was specifically fine-tuned for instruction-following tasks like Q&A. It is the model I use for my own notes.

Part 1: Setting up Ollama

Ollama is the engine that lets you run LLMs locally. It is a single binary, and the installation is one command.

Step 1: Install Ollama

curl -fsSL https://ollama.com/install.sh | sh

Once installed, verify it is running:

ollama --version

Ollama starts a background service automatically. You can check its status:

systemctl status ollama

Step 2: Pull the model

Now download the model. For the CPU-friendly, low-resource setup I recommend:

ollama pull phi3:mini

This will download about 2.3 GB. Grab a coffee. If you have more RAM available (16 GB+) and want slightly better answers, you can also try:

ollama pull gemma2:2b

To verify the model is installed and working, test it immediately:

ollama run phi3:mini "Explain what the ITIM subject is all about."

If you see a coherent response, the model is working. We can move on.

Part 2: Setting up AnythingLLM as the notes interface

AnythingLLM is a self-hosted, open-source application that lets you upload documents, point it at a folder, and query them through a clean chat interface. It handles the chunking, embedding, and retrieval pipeline so you do not have to set up a vector database yourself.

Step 1: Install AnythingLLM via Docker

docker pull mintplexlabs/anythingllm

Create a directory to store AnythingLLM's data (your note indexes will live here):

mkdir -p ~/.anythingllm

Now run it:

docker run -d \
  --network=host \
  --cap-add SYS_ADMIN \
  -v $HOME/.anythingllm:/app/server/storage \
  -e STORAGE_DIR="/app/server/storage" \
  --name anythingllm \
  mintplexlabs/anythingllm

Verify the container is running:

docker ps | grep anythingllm

Now open your browser and navigate to: http://localhost:3001

You will see the AnythingLLM setup wizard.

Step 2: Connecting AnythingLLM to the local Ollama model

During setup, AnythingLLM will ask you to choose an LLM provider. Select Ollama from the list.

• Ollama Base URL: http://localhost:11434
• Model: Select phi3:mini from the dropdown (it will auto-detect your installed models)

For the embedding model, which converts your notes into searchable vectors, stay within Ollama and choose:

ollama pull nomic-embed-text

nomic-embed-text is tiny (274 MB), fast, and produces excellent embeddings for English-language text. It is purpose-built for document retrieval, exactly what we need.

Part 3: Importing the notes

Let's move to connect knowledgebase with AI.

In AnythingLLM, a workspace is a scoped knowledge base. Think of it like a project folder; you can have one workspace for your work notes, one for personal research, one for a specific book you are reading.

1. Click New Workspace and give it a name (e.g., "My Notes")
2. Click the Upload Documents button
3. Drag and drop your Markdown files, PDFs, or text files into the upload area

AnythingLLM will split your notes into chunks (typically 500–1000 tokens each) then generate an embedding vector for each chunk using nomic-embed-text and then store everything in a local vector database (LanceDB, stored in ~/.anythingllm).

This process takes a minute or two, depending on how many notes you have.

Part 4: Querying the notes

Now is the time to make the most of the notes by using AI to question it.

Now the satisfying part. Click on your workspace, type a question in the chat box, and press Enter. To truly see the power of local AI, ask something that ChatGPT could never possibly know. For example, if you uploaded your home server notes:

According to my server migration notes, why did I decide to switch from Nginx Proxy Manager to Traefik, and what IP address is my Pi-hole running on?

Notice that AnythingLLM shows you which notes it used to generate the answer. This is the RAG process in action; ChatGPT can tell you what Traefik is, but only your local AI knows that you switched to it because you were tired of managing SSL certificates manually, and that your Pi-hole is at 192.168.1.100.

Try a few more highly personalized queries:

What is the Wi-Fi password for the guest network at my parents' house, and where is the router hidden?

When are my parents' birthdays this year, and what exactly did I decide to buy for my brother to fix his noisy keyboard?

Each answer is grounded in your notes. The model is not making things up from its training data; it is synthesizing from what you wrote, which means the answers are accurate to your actual knowledge and context.

💡 Keeping things running (optional)

If you want AnythingLLM to start automatically with your system:

docker update --restart unless-stopped anythingllm

And Ollama is already managed as a systemd service, so it will start on boot automatically.
To update the model later if a newer version is released:

ollama pull phi3:mini

Ollama handles versioning for you.

My experience (so far)

I have been using this setup for a few months now. Here is what changed for me:

Before: I would search my notes, find five partial answers in different files, open each one, manually cross-reference them, and then write a synthesis myself.
After: I ask a question. In 5–8 seconds, I get a synthesized answer with the source notes cited. I open the sources to verify. Done.

The model is not perfect - Phi3:mini will occasionally miss nuance or misread a technical term from a note. But for a free, offline, CPU-only setup, it is genuinely impressive.

What it is excellent at:

• Summarizing notes on a topic
• Finding connections between notes you forgot existed
• Drafting a starting point for new writing based on your existing research
• Answering "what did I write about X" questions instantly

What to watch out for:

• Very long PDFs (>50 pages) may need to be split before uploading
• Code blocks in Markdown sometimes confuse the chunking
• Plain prose notes work best
• The model will occasionally "hallucinate" if your notes are thin on a topic; always verify

The entire stack is free, open-source, and runs completely offline. Once set up, it requires zero maintenance and adds nothing to your monthly cloud bill.

Conclusion

The popular mental model of AI is "Cloud service that reads your data". This does not have to be the case and for personal notes, it arguably should not be.

A small, open model running locally on your laptop is good enough for synthesizing your own knowledge base. It will not beat GPT-4 at coding challenges or creative writing. But for the task of "help me navigate and synthesize the notes I already wrote", it does the job well.

Your notes are already doing half the work. A local AI just helps you finish the other half.

Our 20th course is now available 🍾

This one is about log management with ELK stack.

Actually, it's not ELK. Instead of Elastic Search, we used OpenSearch. The course gives you the basics along with sample labs to follow.

This is available for Pro members only. Not a Pro member yet? Upgrade to Pro membership and access all 20 courses, 6 eBooks and every other premium content.

Log Management Course (ELK Stack with OpenSearch)

Stop SSH-ing into servers at 2 AM. Learn to centralize, search, and visualize logs across your entire infrastructure using fully open-source tools.

Linux HandbookYash Kiran Patil

The next course in our pipeline is GitOps video course. After that, we are also thinking of creating a course around using AI assistance in typical DevOps scenarios. I'll keep you posted.