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.

I have been learning DevOps for a while now. The problem is not finding DevOps content on YouTube. There is plenty of it. The problem is knowing which channels are actually worth your time.

Some channels drop theory at you for 45 minutes without touching a terminal. Others teach outdated tooling. A few are genuinely excellent - structured, practical, updated, and respected by the community. I went through dozens of channels, cross-checked with what the DevOps community recommends and narrowed it down to 14 that hold up in real learning situations.

These are not ordered by subscriber count or popularity contests. They are ordered by how naturally they build on each other - from foundational to advanced, from broad to specialized.

Short on time? See the quick overview table below, then jump to the channels that match your current level.

At a Glance: All 14 Channels Compared

TechWorld with Nana - Best for a Complete DevOps Learning Path

TechWorld with Nana is the most recommended DevOps channel on communities and it earns that consistently. Nana covers the full DevOps stack - Docker, Kubernetes, CI/CD, Terraform, Ansible and monitoring - in a structured, course-style format that builds concepts before jumping into commands.

She starts with the basic concepts, builds the fundamentals and then moves towards the advanced concepts and practical approach of the concept. Especially Docker and Kubernetes Tutorial for Beginners is one of the most popular and recommended playlists on YouTube.

Who it's best for: Complete beginners who want a single channel that takes them from zero to job-ready on core DevOps tooling, without having to stitch together random videos.

Verdict: Think of this as your DevOps course library. When you need a full course on a specific tool - Terraform, AWS, Kubernetes, this is where you look first.

freeCodeCamp.org - Best for Full-Length Free Courses on Every DevOps Topic

freeCodeCamp's YouTube channel is not a DevOps-specific channel - it is a massive library of full-length, structured courses across every technical domain, and its DevOps coverage is exceptional. You will find complete, multi-hour courses on Docker, Kubernetes, Terraform, AWS, Linux, and more, all free, no sign-up required.

They usually have one-shot videos of multiple hours, which cover the whole topic in depth, like Docker Tutorial for Beginners, Kubernetes course - Full Beginner Tutorial, etc. They cover a wide range of DevOps topics in full-length videos; you name it, and they have it on their channel.

Who it's best for: Anyone who prefers structured, course-style learning, the kind where you sit down, follow along start to finish, and come out the other end having actually learned a tool completely.

Verdict: Think of this as your DevOps course library. When you need a full course on a specific tool - Terraform, AWS, Kubernetes, this is where you look first.

NetworkChuck - Best Entry Point for Absolute Beginners

NetworkChuck makes networking, Linux, Docker, and cloud concepts feel genuinely approachable. His style is upbeat, fast-paced, and deliberately beginner-friendly - built around the philosophy that the first goal is to make you comfortable enough to not quit.

He mainly makes videos related to cybersecurity, home labs, self-hosted tools and Linux, which is essential for building the prerequisites for DevOps. His storytelling abilities make you stick with the concept and follow all along.

Who it's best for: Complete beginners who feel intimidated by technical content and need a first channel that makes them feel like they can actually do this - before moving to more structured learning.

Verdict: The best channel to remove the intimidation factor before starting a structured DevOps path. Watch a few videos here, then move to a sequenced learning track.

KodeKloud - Best Channel for Learning by Doing and Certification Prep

KodeKloud started as a training platform and its YouTube channel reflects that DNA: every video is designed around hands-on exercises with a clear learning objective. It is the most consistently recommended channel on Reddit when someone asks about CKA, CKAD, or CKS Kubernetes certification prep.

The channel focused on certification prep as well as concept videos on topics like Docker, Kubernetes, Nginx, AWS, etc. Kubernetes Crash Course is one of the most popular video which covers the Kubernetes concepts in the best possible way according to the viewers.

Who it's best for: Learners who retain things by doing, not just watching - and anyone preparing for Kubernetes, Docker, or AWS certifications who wants structured prep content that matches the actual exam format.

Verdict: The best structured practice resource on YouTube for DevOps certifications. Watch KodeKloud when you are preparing for CKA, CKAD, or Docker certification - it was built for exactly that.

Fireship - Best for Fast, Accurate Concept Explainers

Fireship is not a DevOps channel - it is a technology explainer channel with a cult following, and its DevOps coverage is some of the best bite-sized technical content on the internet. The famous "X in 100 seconds" format delivers accurate, dense explanations of Docker, Kubernetes, CI/CD pipelines, Git, and cloud concepts faster than any other format.

Who it's best for: Learners at any level who want a fast, accurate reference for a concept they have heard of but do not fully understand - before going deeper elsewhere. Also excellent for keeping up with new DevOps tooling without spending hours on each one.

Verdict: The fastest way to understand what something does before committing to learning it. Use Fireship to decide what to learn next, then use a hands-on channel to actually learn it.

DevOps Directive - Best for Deep, Technically Accurate Tutorials

DevOps Directive is the channel community recommends when someone says, "I want to actually understand Docker and Kubernetes, not just copy commands." Every tutorial is longer than average, technically precise, and built around real use cases rather than simplified toy examples.

He covers the history, installation, demo, practical, deployment, clustering and CI/CD in a complete depth. His Best of DevOps Directive YouTube Videos is popular for in depth knowledge of DevOps.

Who it's best for: Intermediate learners who already have the basics and want to go deep, understanding not just how to use Docker or Terraform, but why the design decisions exist and how things work under the hood.

Verdict: When you are past the basics and want tutorials that respect your technical intelligence, DevOps Directive is where you go. Fewer videos, higher quality per video.

Kunal Kushwaha - Best Free DevOps Bootcamp on YouTube

Kunal Kushwaha's DevOps bootcamp is one of the rare examples of a complete, free, structured DevOps curriculum published entirely on YouTube. The bootcamp covers Linux, Docker, Kubernetes, networking, Git, CI/CD, and cloud from scratch, in a sequence that actually makes sense as a learning path.

DevOps Bootcamp is a popular series in which he has covered the DevOps topics in depth; the teaching style is more of a conversation where you don't feel it as a scripted story.

Who it's best for: Beginners and intermediate learners who want a free, structured bootcamp they can follow from start to finish - without paying for a course platform or stitching together random videos.

Verdict: If you want a free, complete, structured bootcamp that you can follow without paying anyone, Kunal Kushwaha's bootcamp series is the honest answer.

TrainWithShubham - Best for Project-Based Learning and Roadmap Clarity

TrainWithShubham is built around one idea: learning DevOps by building and deploying real projects. Shubham Londhe focuses on projects that you can put on a resume, CI/CD pipelines, containerized deployments and infrastructure automation and explains the roadmap clearly for learners unsure what to learn next.

The creator teaches in the native language Hindi, so it might be a con for other language users, but for users whose native language is Hindi it provides a clear understanding of the topic that he covers fully. Has one of the best one-shot videos, like Linux One Shot, Kubernetes One Shot and many more.

Who it's best for: Beginners and intermediate learners who are actively job-hunting or building a portfolio, and want project-based tutorials that produce something real, not another to-do app deployed locally.

Verdict: If building an actual DevOps portfolio is your goal, TrainWithShubham's project-based approach gives you real output for every hour you invest, especially if you are a Hindi audience.

That DevOps Guy - Best for Honest, Real-World Kubernetes Content

Marcel Dempers does not make content for clout. That DevOps Guy is built around real Kubernetes setups, actual production decisions, and content that tells you what actually happens when things go wrong, not just the happy path. The channel covers Kubernetes, Helm, GitOps, ArgoCD, and service mesh with a refreshing absence of marketing language.

What makes him truly unique is his distinctive teaching style combined with those nostalgic, retro-style animations that make even the most complex concepts feel simple and fun. His real, no-fluff talk in every video delivers deep, practical knowledge that actually sticks - turning technical topics into something you genuinely enjoy learning.

Who it's best for: Intermediate to advanced learners who want Kubernetes content that reflects what real deployments actually look like - including the failure modes, tradeoffs, and operational realities that most tutorials skip.

Verdict: One of the most trusted voices in the Kubernetes space, precisely because Marcel does not oversimplify. When you are ready for production-level content, this channel is a regular stop.

KubeSimplify - Best Channel Focused Entirely on Kubernetes

KubeSimplify does one thing: Kubernetes. Not Docker fundamentals, not cloud basics, Kubernetes concepts, tools, and ecosystem in depth. The channel covers Helm, Kustomize, GitOps, cluster management, networking, and Kubernetes tooling with a focus on making concepts clear through practical demos.

The Kubernetes Course by him is one of the suggested courses for gaining complete knowledge of Kubernetes.

Who it's best for: Learners who have Docker and basic Kubernetes knowledge and want to go deep specifically into the Kubernetes ecosystem - Helm, GitOps, cluster operations, RBAC, networking policies, and more.

Verdict: The go-to channel when you are ready to move beyond kubectl apply and actually understand how Kubernetes production setups are built.

Bret Fisher - Best for Docker and Kubernetes Live Q&A

Bret Fisher has been teaching Docker since before it was cool. His live sessions are a masterclass format that few channels match: real questions from real engineers, answered in real time with actual Docker and Kubernetes context - not scripted scenarios.

Cloud Native DevOps and Docker Talk is a series popular for live shows with Q&A and guests from the cloud native ecosystem.

Who it's best for: Intermediate learners who have hit real-world problems they cannot find answers to in tutorials - Bret's live Q&A sessions are specifically good for the gap between "tutorial worked" and "production is broken."

Verdict: Once you have real Docker and Kubernetes problems, not just tutorial exercises - Bret Fisher's Q&A sessions are one of the most valuable resources available for free.

Anton Putra - Best for Production-Grade AWS, Terraform, and Kubernetes Content

Anton Putra is the channel community calls "underrated gem" on a regular basis, and the description is accurate. The content is production-grade: real AWS architectures, Terraform modules that reflect actual engineering decisions, Kubernetes setups built the way teams actually build them, not simplified for beginners.

AWS EKS Kubernetes Tutorial is one of the recommended playlists for learning production-grade kubernetes learning.

Who it's best for: Advanced learners and working engineers who want content that reflects production reality - AWS infrastructure, Terraform state management, Kubernetes cluster operations, observability, and CI/CD at scale.

Verdict: If there is one underrated channel on this entire list, it is Anton Putra. The quality-to-subscriber-count ratio is remarkable. Subscribe before the rest of the internet catches up.

Abhishek.Veeramalla - Best for DevOps Roadmap, Real Projects, and Interview Preparation

Abhishek Veeramalla has built one of the fastest-growing DevOps channels by doing something most channels avoid: being explicit about what you need to learn, in what order, and why - from the perspective of someone actively placing engineers into DevOps roles. The channel covers projects, roadmaps, and interview preparation with rare practical clarity.

DevOps Engineer in 3 months is the playlist many people follow to learn DevOps. He is also covering topics like AI assisted DevOps, Learning, DevSecOps and many more.

Who it's best for: Beginners and intermediate learners who want a clear learning roadmap, hands-on project walkthroughs, and honest interview preparation content - especially those targeting their first or second DevOps role.

Verdict: If you are building toward a DevOps role and want a channel that connects learning to employment outcomes, Abhishek Veeramalla is one of the most practically useful channels on this list.

Jeff Geerling - Best for Ansible, Homelab Infrastructure and Automation

Special mention for Jeff Geerling, the internet's go-to resource for Ansible, not as a passing topic, but as a deep, ongoing practice. Beyond Ansible, his channel covers Raspberry Pi infrastructure, homelab automation, and systems topics that most DevOps channels do not touch, all with a level of technical depth that reflects decades of hands-on systems work.

Homelab playlist is one of the most popular ones viewers recommend for actual technical depth. Ansible playlist contains all the content about Ansible, your one-stop solution for Ansible concepts.

Who it's best for: Engineers who want to master Ansible for real infrastructure automation, homelab enthusiasts who want to take their setup to a professional engineering level, and anyone who wants content that goes deep on systems topics.

Verdict: For Ansible specifically - Jeff Geerling is the answer, full stop. The channel is what trustworthy, technically serious free content looks like.

FAQ

You will have some questions in mind, so let me answer some of those.
Do I need to watch all these channels?
No. Most people get structured value from 2-3 channels at a time. Start with one beginner-friendly channel (TechWorld with Nana, Kunal Kushwaha, or NetworkChuck), add a hands-on or cert-focused channel (KodeKloud), and a specialized one based on your current tool focus. Add the rest as your skill level grows.

What is the recommended order for a complete beginner?
A practical sequence: NetworkChuck (comfort with Linux and Docker basics) → TechWorld with Nana (structured DevOps roadmap) → KodeKloud (hands-on labs and cert prep) → DevOps Directive or That DevOps Guy (production depth). Use Fireship throughout as a quick reference when you encounter new concepts.

Are these channels still actively updated in 2026?
All channels on this list are actively publishing as of April 2026. Anton Putra and DevOps Directive publish less frequently but maintain consistent quality.

Which channels are best specifically for Kubernetes?
In rough order of depth: KubeSimplify (K8s-focused, breadth of ecosystem), That DevOps Guy (production realism), KodeKloud (cert prep), Anton Putra (cluster operations, Terraform + K8s integration). TechWorld with Nana has solid K8s fundamentals for beginners.

Are these channels useful for someone already working as a DevOps engineer?
Yes - specifically That DevOps Guy, Anton Putra, Jeff Geerling, KubeSimplify, and Bret Fisher. These four channels produce content that reflects real production decisions rather than learner-facing introductions. The others are better suited to foundational or intermediate learning.

Which channels cover cloud platforms (AWS, Azure, GCP) beyond just containers?
Anton Putra (AWS + Terraform depth), TrainWithShubham and Abhishek.Veeramalla (AWS projects), freeCodeCamp (platform-agnostic full courses), TechWorld with Nana (all three major cloud providers covered). KodeKloud has certification prep for AWS, Azure, and GCP certifications.

Final recommendation

If you are just starting out: TechWorld with Nana, trainwithshubham gives you the roadmap, KodeKloud gives you the practice. Those two together cover what most DevOps learners need through the intermediate stage.

If you are preparing for certifications: KodeKloud is the standard recommendation for a reason. The CKA and CKAD prep content is the best free version available.

If you want production-level depth: Anton Putra for infrastructure, That DevOps Guy for Kubernetes operations, Jeff Geerling for Ansible. These three channels give you what textbooks and tutorials usually skip.

If you know of a channel that deserves to be on this list, don't wait and drop it in the comments below!

You're debugging logs the hard way.

A single app on a single server is manageable. Ten servers? Fifty containers? Log files become a nightmare you can't grep your way out of.

Your current workflow at 2 AM:

$ ssh prod-server-01
$ tail -f /var/log/app.log # nothing obvious
$ ssh prod-server-02
$ grep -r "error" /var/log/ | awk '{print $5}'
# 20 minutes later... still piecing it together

The ELK Stack centralizes every log from every service into one searchable, visualizeable system. You go from reacting to incidents to proactively catching them before they happen.

What you'll learn

🏗️ ELK Architecture: How logs flow from your app through Logstash into OpenSearch and out to dashboards.

⚙️ Logstash Pipelines: Parse, filter, and enrich raw logs before they hit your index.

🔍 Query DSL & Indexing:Search across millions of log events in milliseconds.

📊 Kibana Dashboards: Build visualisations that surface patterns raw log files never could.

🔒 Security & Access Control: TLS, users, roles — features Elasticsearch charges for, free on OpenSearch.

🤖 ML-Powered Anomaly Detection: Let OpenSearch flag unusual patterns before your users notice them.

📈 Scaling OpenSearch: From a single node to a cluster that handles production traffic.

Who this course is for?

✅ Linux / DevOps Engineers: You manage servers and containers and want a proper observability stack without Elastic's licensing fees.

✅ Backend Developers: You deploy apps and want to understand what's actually happening in production when things break.

✅ SRE / Platform Engineers: You need centralised logging across microservices and want a self-hosted solution you fully control.

✅ Teams Migrating Off Elastic: You're moving away from paid tiers and want to get up to speed on OpenSearch fast.

Start learning today

Stop reacting. Start observing.

Everything you need to build a production-grade observability stack. Free, open source, and ready to deploy.

Included with Linux Handbook Pro.

For years, my default setup for Linux demos was simple. Spin up a virtual machine, configure the environment, take a snapshot, and hope nothing breaks during the presentation.

In fact, my old demo setup was a collection of virtual machines I'd accumulated over the years. One for Docker demos, another for Kubernetes workshops, and a third one, a Debian box for shell scripting sessions. Each one sat on my SSD, consuming gigabytes of space and demanding occasional updates just to stay usable.

The breaking point came during a Kubernetes workshop I was running remotely. Screen sharing was already choppy because OBS, Chrome, and the VM were all fighting over the same CPU. Then the VM froze mid-demo during a kubectl walkthrough. The audience waited in silence. I got it working again, but the rhythm of the session never recovered.

That evening, I started looking for something better. I found Webtop, and it quietly replaced most of that VM setup.

What Webtop Actually Is

Webtop is a Linux desktop environment packaged inside a Docker container and accessible entirely through a browser. You start the container, open a browser tab pointing to port 3000, and a full Linux desktop appears.

LinuxServer.io maintains this project. The same group provides container images for Jellyfin, Nextcloud, and dozens of other self-hosted tools.

What surprised me when I first launched it was how complete the experience felt. You get a real desktop environment, with the option to choose from XFCE, KDE, MATE, or others, depending on the image, with a terminal, file manager, and the ability to install packages normally through apt, dnf, or whatever the base distro uses. It behaves like a lightweight remote workstation that happens to live in your browser.

Getting It Running

The quickest path is Docker Compose or Podman Compose. Here's the configuration I started with:

services:
  webtop:
    image: lscr.io/linuxserver/webtop:ubuntu-xfce
    container_name: webtop
    security_opt:
      - seccomp:unconfined
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Kolkata
    volumes:
      - ./config:/config
    ports:
      - 3000:3000
    shm_size: "1gb"
    restart: unless-stopped

Running docker compose up -d and then navigating to http://[SERVER-IP]:3000, or http://localhost:3000 genuinely all it takes. The first boot took maybe 10 seconds before the desktop was usable.

Choosing the Right Image

Webtop supports multiple distributions and desktop environments. The available combinations include Ubuntu, Debian, Fedora, Alpine, and Arch, each paired with desktop options like XFCE, KDE, and MATE. You can find all related tags on the project's GitHub page.

From my practical experience, XFCE consistently performs best for demos and workshops. It's lighter on resources, and the responsiveness during screen sharing is noticeably better than KDE. KDE is visually polished and worth running if you have headroom, but when your machine is also running OBS, a browser, and a video call simultaneously, the extra weight shows.

Alpine is worth knowing about if you need something extremely minimal. Its image is tiny and starts almost instantly, but package availability is limited compared to Ubuntu or Debian. For most demo scenarios, ubuntu-xfce hits the right balance of familiarity, package ecosystem, and performance.

Why This Works Better for Demos Than VMs

Recovery feels dramatically simpler. If I break something during a session, and with live demos, this happens. Restoring a VM means hunting for the right snapshot, waiting for it to load, and hoping the snapshot captured the right state. With Webtop, recovery looks like this:

docker rm -f webtop
docker compose up -d

That's it. A fresh environment in seconds.

Resource usage is another area where the difference is noticeable. A traditional Ubuntu VM with 8 GB allocated holds that memory whether it's being used or not. Containers are far more cooperative with the host system. After moving most of my demo environments to Webtop, I noticed the laptop fan spinning less during presentations and screen sharing becoming smoother.

Building Reproducible Demo Environments

One thing I missed initially about VMs was the snapshot workflow. It's the ability to freeze a perfectly configured state and return to it. Webtop doesn't work that way, but the Docker approach is actually cleaner once you adjust your thinking.

Instead of snapshots, I build custom images. Here's an example Dockerfile for a Kubernetes demo environment:

FROM lscr.io/linuxserver/webtop:ubuntu-xfce

RUN apt-get update && apt-get install -y \
    docker.io \
    kubectl \
    helm \
    neovim \
    tmux \
    htop \
    git

Building that with docker build -t demo-webtop . produces an image I can launch anywhere, including on my homelab server, a VPS, a colleague's machine, and get an identical environment every time.

There are no multi-gigabyte VM disk files to transfer. The image is versioned, shareable, and rebuildable from scratch if needed. For a Kubernetes workshop I ran recently, I published the image so participants could run their own copy locally, which would have been considerably more complicated to coordinate with traditional VM images.

Accessing It Remotely

Browser-based access turned out to be more valuable than I expected. I can reach my Webtop environments from any device with a browser. That portability genuinely changed how I work while traveling.

For remote access, I put Webtop behind a reverse proxy with HTTPS and authentication. Running it directly to the internet without any protection is a bad idea. You'd be serving an unauthenticated Linux desktop to the world. Here is an example configuration for Caddy:

webtop.lhb-tut.com {
    basicauth {
        bndev $2a$14$ebc7C6dlwFafmtZmfQ4vKe2ToQsTe6nWbV3k3ky6HAwLQr76u1l8m
    }

    reverse_proxy webtop:3000
}

My current setup uses Tailscale for network-level access control and Caddy for HTTPS termination.

Traefik and Cloudflare Tunnels are both solid alternatives, depending on your existing infrastructure. The key principle is the same regardless of tooling: don't expose port 3000 publicly without something in front of it.

What It Doesn't Handle Well

Webtop isn't a universal replacement for VMs, and overselling it would be dishonest. There are categories of work where I still reach for a traditional hypervisor without hesitation.

Kernel development and anything requiring full systemd Support needs a real VM. Container isolation isn't equivalent to hardware virtualization, and some low-level work simply requires full-stack virtualization and nested virtualization.

Low-level networking labs where you need to demonstrate VLAN behavior, DHCP servers, or raw packet analysis at the hardware interface level are also better suited to VMs, because container networking abstracts away exactly the things you're trying to show. Similarly, malware analysis and security sandboxing, where strong isolation is the whole point, shouldn't be done in a container environment.

GPU-accelerated workloads, video editing, and anything that genuinely needs graphics hardware won't be served well by Webtop. The rendering pipeline is inherently software-based, and the limitations are obvious in GPU-heavy applications. For terminal work, admin demos, and development environments, this is rarely relevant, but it's worth knowing upfront.

Practical Situations Where It Shines

Training sessions where participants need identical environments are where Webtop provides the most obvious value. Instead of distributing VM images and debugging hypervisor incompatibilities across fifteen different laptop configurations, participants open a browser tab. That's a meaningful reduction in setup overhead and the inevitable "it doesn't work on my machine" troubleshooting.

The disposable workstation use case is one I didn't anticipate valuing, but I use it regularly. Sometimes I need a clean Linux environment to test a script, verify a package installation, or try something I don't want running on my main machine. Spinning up a Webtop container, doing the work, and removing it takes a minute. The equivalent with VMs took considerably longer and left behind disk state to clean up.

Final Thoughts

I went into Webtop expecting curiosity. What I found was something that genuinely improved a recurring frustration in my workflow. The demo environment problem, maintaining multiple VMs, managing snapshots, and dealing with hypervisor overhead, completely went away.

The tradeoff with VMs isn't that containers are strictly superior. The point is that for the specific problem of running Linux environments for demos, workshops, and quick testing, the browser-based container approach solves the actual pain points without introducing new ones.

If you're maintaining a collection of demo VMs and spending time managing snapshots and debugging hypervisor issues, it's worth an hour to spin up Webtop and see how it feels. The barrier to trying it is low enough that the experiment costs almost nothing.

If you've ever pasted a Bitly link into your marketing email and then checked your stats at the end of the month, only to find the analytics you actually wanted are locked behind a $10/month or $29/month plan, you've already felt the frustration that Shlink was built to solve.

Shlink is a self-hosted, open-source URL shortener built in PHP. It gives you your own short domain (like yourdomain.com/abc), full visit tracking with geolocation, a REST API, a web dashboard, custom slugs, and more, all running on your own server. No per-link limits, no monthly bills, no vendor lock-in.

With nearly 4.9k stars on GitHub and 151 releases at the time of this writing, Shlink is not an experimental side project. It's a mature, actively maintained tool with real production deployments.

Try it yourself: Shlink on GitHub | Official website

What Is Shlink, Exactly?

Let's start with the basics. Shlink (short for "short link") is a PHP application that you run on your own server. You point a short domain at it, and from that moment on, every link you create under that domain is yours, the data, the tracking, the slugs, everything.

Think of it as the backend engine that powers a URL shortener service. Shlink itself doesn't have a graphical UI built in, but it comes with two ways to control it out of the box:

A command-line interface (CLI) - run shlink short-url:create https://your-long-url.com and get a short link back instantly.
A REST API - every operation available in the CLI is also exposed through a well-documented HTTP API, so you can integrate Shlink into any application or script.

And then, because most people don't want to manage links from a terminal forever, there's a separate web client called Shlink Web Client, a progressive web app that connects to your Shlink API and gives you a proper dashboard to manage everything visually.

You can use the hosted version at app.shlink.io (it talks directly to your own self-hosted server), or you can self-host it too. This separation of concerns - backend API + frontend client is a deliberate architectural choice that makes Shlink incredibly flexible for integrations.

How Does It Compare to Bitly?

Before diving into the features, let's be honest about who Bitly is and what they charge.

Bitly's free tier limits you to 50 links/month. 2 QRs/month (yes, only two). Branded links with your custom domain require the Growth plan at ~$29/month. Detailed analytics and API access push you toward the Premium plan at ~$199/month. And the free tier obviously comes with a lot of ads.

Now here's the thing - Shlink gives you all of the following completely free, running on your own VPS:

The trade-off is real: Bitly is plug-and-play, while Shlink requires a server to run on and some initial setup time. But if you already have a VPS or a home server, the case for Shlink is very strong.

The $10/month savings angle: If you're on even the cheapest Bitly paid plan ($10/month Core) just for the extra links, you're paying $120/year for something you could own outright. The math is obvious.

Getting Shlink Running

The fastest way to get Shlink up is with Docker. The official image is published on both Docker Hub and GitHub Container Registry, and it handles all PHP dependencies internally.

Quick Setup:

services:
  shlink:
    image: shlinkio/shlink:stable
    container_name: shlink_review
    restart: unless-stopped
    ports:
      - "8888:8080"
    environment:
      # The domain Shlink will use to build short URLs
      DEFAULT_DOMAIN: localhost:8888
      # HTTP only for local testing (no SSL cert needed)
      IS_HTTPS_ENABLED: "false"
      # GeoLite2 key for geolocation — get a free one at https://www.maxmind.com/en/geolite2/signup
      # Leave as REPLACE_ME to start without geolocation (everything else works fine)
      GEOLITE_LICENSE_KEY: "REPLACE_ME"
      # Use SQLite — no external DB container needed for local testing
      DB_DRIVER: "sqlite"

You can use this compose and have to replace the placeholder for the Geolite key with you key. After setting up you will be able to see the container running.

There is a full list of commands for the CLI interaction of the shlink at the official documentation.

The Web Client: Your Dashboard for Everything

Once your Shlink backend is running, you connect it to the Shlink Web Client. This is a Progressive Web App (PWA), meaning you can install it on your desktop or phone like a native app, and it works entirely in your browser.

Here's the key thing to understand: the web client never stores your link data. It just communicates with your own Shlink server via the REST API. The hosted version at app.shlink.io is simply a UI; all your data stays on your server.

Let's setup web-client to see how efficient it is to manage your server through a GUI.

On this, you need to set up the name, URL and the API key generated by you through running the container. You can run the command:

docker exec -it shlink_review shlink api-key:generate

after configuring the server will be connected in 30-40 seconds.

In this you can create short URLs by clicking on Create short URL:

After setting up, the short links are activated and you get the analytics like visits, oprhan visits, short URL, tags, etc.

I was simply able to redirect to the main URLs from the short URL generated by shlink, it was consistent and no complex configurations for making a shortened URL.

You get detailed stats according to the days, visits, visualizations, location, context, and exporting options for the stats report.

Don't want to manage a server? Shlink is available on PikaPods, which handles all the hosting for you with a one-click setup. Pricing starts at ~$2.3/ per month, and Shlink gets a portion of the revenue to fund the project.

Core Features Worth Knowing About

Custom Slugs and Multi-Segment Slugs

By default, Shlink auto-generates short codes like s.yourdomain.com/abc123. But you can set your own human-readable slug: s.yourdomain.com/linux-guide or even multi-segment slugs like s.yourdomain.com/articles/linux-guide.

Visit Tracking and Analytics

Every click on a short URL gets tracked. Shlink records: Date and time of the visit, Country, region, and city(via MaxMind GeoLite2 geolocation), Device type (desktop/mobile/tablet), Browser and OS, Referrer(where the visitor came from).
IP addresses are anonymized by default, which is what makes Shlink GDPR-compliant out of the box.

Limited Access and Expiry

This feature alone is worth highlighting. You can set a short URL to: Expire after a certain date - perfect for time-limited promotions or event links, Expire after a maximum number of visits - create a link that only the first 100 people can use, and after that it shows a 404.

Dynamic Redirects (Rule-Based)

Here's where Shlink goes beyond being a "simple" URL shortener. You can set up rules that redirect visitors to different destinations based on: Geolocation, Device type, Language and OS. This turns a short link into a smart redirect engine, which is something you'd normally need a dedicated link management platform to do.

The REST API and CLI: For When You Want to Automate

Shlink's API is well-documented at api-spec.shlink.io, with an interactive sandbox where you can try every endpoint. Every operation you can do from the web client is available via the API and a few things (like API key management) are only available from the CLI or API, not the web client.

Some examples of what you can do with the CLI inside the Docker container:

# Create a short URL with a custom slug
docker exec my_shlink shlink short-url:create https://itsfoss.com/linux-guide --custom-slug linux-guide

# List all short URLs
docker exec my_shlink shlink short-url:list

# View visit stats for a specific short URL
docker exec my_shlink shlink short-url:visits linux-guide

# Generate a new API key with a name
docker exec my_shlink shlink api-key:generate --name "automation-script"

The API makes Shlink a building block for larger systems. If you run a website, you can integrate Shlink to automatically generate short links for every new article you publish. If you send newsletters, you can use it to wrap all your links and get click tracking without any third-party service touching your subscriber data.

Importing From Bitly (and Others)

If you're currently using Bitly and want to migrate, Shlink has a built-in importer. It can import existing short URLs from Bitly, YOURLS, CSV, Shlink, and kutt.

Import is performed from the command line, by running the short-urls:import command.

This command will guide you through the import process, asking you to provide the source from which you want to import, together with all required information for this process to succeed. The import preserves the original short codes where possible, so your existing links don't break after migration.

You can always refer to official documentation for specific importing steps from different platforms.

What Shlink Doesn't Do Yet

There's no built-in multi-user authentication. Shlink uses API keys for access control; there's no "create an account with a username and password" UI. If you want multiple people to manage links, you create separate API keys for them. This works, but it's not the polished team management experience you'd get from a SaaS product.

The setup requires some technical comfort. You need to understand Docker (or PHP server setup), DNS configuration, and reverse proxy configuration to get Shlink running with HTTPS and custom domains. It's not hard if you've done it before, but it's not a one-click install for beginners either.

The GeoLite2 license key requirement is a minor friction point. MaxMind's license key is free, but you have to register and include it manually. Without it, geolocation doesn't work. It's a licensing compliance thing, not a Shlink design flaw, but it adds a step.

Real-time updates need extra infrastructure. Shlink supports real-time visit notifications through Mercure or RabbitMQ, but you have to set those up separately. If you don't, the web client just refreshes on a polling interval, which works fine for most people.

What Works Really Well

The custom domain support is genuinely good. Most self-hosted shorteners make you pick one domain. Shlink's multi-domain support means you can run personal, professional, and team link shorteners all from one installation.

The analytics are far better than Bitly's free tier. Country, device, browser, referrer - you get all of this without paying anything beyond your server cost.

The API is excellent. Every feature is accessible via the API with consistent, well-designed endpoints. If you want to integrate URL shortening into your workflow or build tooling around it, Shlink is designed for this use case.

The Docker image is production-ready. Non-root user execution (since v4.0.0), multi-architecture support (amd64 and arm64), proper versioning with stable and tags, it's thoughtfully packaged.

151 releases and 4.9k stars. This is not a tool that gets abandoned after six months. Shlink has been actively developed since 2016, maintained by Alejandro Celaya, and has a real community around it.

Conclusion

Shlink does one thing and it does it very well: it gives you a professional-grade URL shortener that you actually control. The custom domain support, visit analytics, dynamic redirects, and REST API together make it a legitimate replacement for Bitly across most use cases, without the monthly subscription.

The setup does require some server knowledge, but it's well within reach for anyone who has deployed a Docker application before. The documentation is thorough, the project is actively maintained, and if you don't want to manage a server at all, PikaPods makes it a one-click deployment.

If you're currently paying Bitly $10–$30 a month for features that Shlink provides for free, this is worth a serious look.

In a world where authentication services charge per user and lock you into their ecosystem, Keycloak offers something rare: enterprise-grade identity management that you can run on your own infrastructure, completely free. No vendor lock-in, no monthly bills, no user limits.

After spending several days setting up Keycloak, integrating it with Portainer via OAuth, configuring social login with GitHub, and wrestling with the documentation gaps, here's what you need to know before diving in.

What is Keycloak?

Keycloak is an open-source Identity and Access Management (IAM) solution that handles authentication and authorization for modern applications. Think of it as a self-hosted alternative to Auth0, Okta, or AWS Cognito, but without the per-user pricing or vendor lock-in.

It's a CNCF (Cloud Native Computing Foundation) project under the Apache 2.0 license, which means it's backed by a strong community and actively developed. It includes featuers like Single Sign-On (SSO), Social login (GitHub, Google, Gitlab, etc.), OAuth 2.0 and OpenID Connect (OIDC) and many more.

The selling point isn't just the feature list - it's that you get all of this without paying per user or worrying about what happens if the vendor shuts down.

The Setup Challenge

Yes, I am mentioning it as a challenge because in the official documentation, there is no proper docker-compose file to set up the whole database with Keycloak. You're left piecing together environment variables from different documentation pages. After many trial-and-error attempts, here's my custom docker-compose.yml that actually works:

services:
  postgresql:
    image: postgres:16
    container_name: keycloak_db
    environment:
      POSTGRES_USER: keycloak
      POSTGRES_DB: keycloak
      POSTGRES_PASSWORD: SUPERsecret
    volumes:
      - ./postgres_data:/var/lib/postgresql/data
    networks:
      - keycloak

  keycloak:
    image: quay.io/keycloak/keycloak:26.5.3
    container_name: keycloak
    depends_on:
      - postgresql
    command: start-dev
    environment:
      - KC_BOOTSTRAP_ADMIN_USERNAME=admin
      - KC_BOOTSTRAP_ADMIN_PASSWORD=admin
      - KC_DB=postgres
      - KC_DB_URL=jdbc:postgresql://postgresql:5432/keycloak
      - KC_DB_USERNAME=keycloak
      - KC_DB_PASSWORD=SUPERsecret
    ports:
      - "8081:8080"
    networks:
      - keycloak

networks:
  keycloak:

In this, we have mentioned PostgreSQL container for the database, ./postgres_data ensures your users and configurations survive container restarts and stay persistent using volumes, KC_BOOTSTRAP_ADMIN_USERNAME and KC_BOOTSTRAP_ADMIN_PASSWORD create the initial admin account, port mapping is done as 8081:8080 because port 8080 is often already taken on development machines, a it, custom network keycloak ensures Keycloak and PostgreSQL can communicate by service name.

Save the above file as docker-compose.yml and run the following command:

mkdir -p keycloak && cd keycloak
# Save the compose file above
docker-compose up -d

Within 30-60 seconds, you'll have Keycloak running at http://localhost:8081.

Initial Configuration

When you first access Keycloak, you'll land on the admin console login page. Use the credentials you set in username and password (in this case, admin / admin).

Once logged in, you'll see the master realm. Realms in Keycloak are isolated spaces for managing users, clients, and authentication policies. The master realm is for administrative purposes only - you can create a separate realm for different applications.

You can add Users, Groups, Events, etc., for your specific realm. You can add an email and verify it, which can be used later to add users and authenticate them.

Real-World Test: Portainer OAuth Integration

The best way to understand Keycloak is to integrate it with a real application. Portainer (a Docker management UI) supports OAuth authentication, making it a perfect test case.

For this purpose, I have my Portainer running on port 9000, which shows me all the containers, images, networks, services, etc., running on my host machine.

You can run Portainer on your own by using the following command:

docker run -d -p 9000:9000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:lts

You will see the Portainer running on localhost:9000 and showing all the results of your Docker stuff.

Creating an OAuth Client: For this, navigate to your realm, then open Clients and click on create client, here you need to paste the following so that it successfully connects to the portainer running on the system.

Client ID: portainer
Client authentication: ON (this generates a client secret)
Valid redirect URIs: http://localhost:9000/*
Valid post logout redirect URIs: http://localhost:9000/*
Web origins: http://localhost:9000

Save the client, then go to the Credentials tab and copy the Client Secret. You'll need this for Portainer.

Configuring Portainer: In Portainer, go to Settings, then Authentication,, navigate to  OAuth, where you need to configure some things inorder to connect to the client created at keycloak and the portainer Oauth.

Client ID: portainer
Client secret: (paste the secret from Keycloak)
Authorization URL: http://localhost:8081/realms/myrealm/protocol/openid-connect/auth
Access token URL: http://localhost:8081/realms/myrealm/protocol/openid-connect/token
Resource URL: http://localhost:8081/realms/myrealm/protocol/openid-connect/userinfo
Redirect URL: http://localhost:9000/
User identifier: email
Scopes: email openid profile

Then save the configurations and you are ready to test your Keycloak authentication.

Testing the flow: The actual test is to see if we can log out from the Portainer and see the login with OAuth, and as expected, after logging out from the portainer the login with OAuth button is visible in the Portainer.

which redirects to the Keycloak sign-in page and if you have added the same user in the Keycloak with an active login session, then you will be able to log in to Portainer and be redirected to the homescreen with that user; the entire process happens seamlessly.

To be honest, as it is seamless in execution, I found it very complex and time consuming to configure the proper urls, as for the self hosted websites and architechture you need to configure the urls correctly handling the routes perfectly, otherwise there are many errors, like not redirecting to the correct destination, OAuth failed, url does not contains needed parameter, etc. that I faced during the configuration.

Social Login Integration

One of Keycloak's standout features is built-in support for social login providers. Adding GitHub authentication takes about 5 minutes. I tested with GitHub Identity Provider.

Setting Up: In Keycloak, you can have options to add an Identity Provider; I have taken GitHub for example. There is a list of options for the Identity provider, you can choose any as per your need.

For GitHub, you need to go to your GitHub Profile → Settings → Developer settings → OAuth Apps → New OAuth App and set the Auth callback URL as http://localhost:8081/realms/master/broker/github/endpoint

Copy the Client ID and Client Secret from GitHub into Keycloak and save the identity provider configuration.

When a user logs in via GitHub for the first time, Keycloak automatically creates a user account and links it to their GitHub identity. You can see linked accounts in the user's account console.

After doing this, I was able to get the expected GitHub Identity Provider in the login window.

This same process works for Google, Facebook, Twitter, Microsoft, and 20+ other providers. You can even enable multiple social logins simultaneously, giving users the choice.

What Works Really Well In Keycloak

Multi-factor authentication, social login, user federation with LDAP/Active Directory and fine-grained authorization policies - features that cost hundreds of dollars per month on SaaS platforms are all included. No per-user pricing, no feature gates. Which gives Enterprise Features for free.

Keycloak implements OAuth 2.0, OpenID Connect, and SAML 2.0 correctly. This means it works with virtually any modern application that supports these protocols. You're not locked into proprietary APIs.

You can customize login themes to match your brand, create custom authentication flows (e.g., require email verification before MFA), and even write custom extensions in Java. The level of control is unmatched, giving Flexibility and customization.

As a CNCF project with backing from Red Hat, Keycloak receives regular updates, security patches, and new features. The community is active, and GitHub issues get responses signifying active development.

The experience of testing the Keycloak was seamless in terms of performance.

Where Keycloak Falls Short

No tool is perfect, and Keycloak has some significant limitations you should know about upfront.

Documentation gaps. The official docs are comprehensive but scattered. The biggest pain point: there's no official docker-compose example that includes a production database. You're left piecing together environment variables from different pages. This is why the custom docker-compose file above took trial and error to get right.

Steep learning curve. Keycloak has a lot of concepts: realms, clients, client scopes, protocol mappers, identity providers, user federation, and authentication flows. For someone new to IAM, the admin console can be overwhelming. Expect to spend a few days just understanding the terminology.

Scalability and Multi-Tenancy. Keycloak can struggle with a high number of realms (multi-tenant environments), experiencing performance degradation in the Admin Console and realm management. While newer versions are improving,, earlier and default configurations have limitations.

Resource hungry. Keycloak is a Java application that needs a PostgreSQL database. It's not lightweight like some self-hosted tools. Expect at least 512MB of RAM for Keycloak alone, plus database overhead. Startup time is 30-60 seconds, not instant.

Default Security Configuration. The default password hashing iterations are low, which requires administrators to manually tune security to prevent brute-force attacks. Keycloak can struggle with a high number of realms (multi-tenant environments), experiencing performance degradation. While newer versions are improving, earlier and default configurations have limitations.

Conclusion

Keycloak delivers enterprise-grade identity and access management without the enterprise price tag. The setup complexity is real - the lack of official Docker Compose examples and the steep learning curve are genuine barriers - but the features you get in return make it worthwhile.

Is it overkill for a simple single-app project? Absolutely. If you just need basic username/password authentication, Keycloak is too much. But if you're building a multi-app ecosystem, need SSO across services, want social login without vendor lock-in, or require features like MFA and user federation, Keycloak is one of the best self-hosted options available.

The docker-compose file above solves the biggest setup hurdle. Once you're past the initial configuration, Keycloak is remarkably powerful and flexible.

True learning begins when you actively work on something. That’s why a balance of theory and hands-on practice is essential.

To address this, we are creating labs. These are small, guided projects designed to help you practice on your Linux system. When you work through them yourself, you naturally encounter challenges you didn’t anticipate. In this way, these labs help prepare you for real-world scenarios.

You can test it out with this lab where you have to build an automated image optimization system.

Building an Automated Image Optimization Pipeline

In this lab, you’ll build an automated process that watches a folder for new images and automatically optimizes them.

Linux HandbookRoland Taylor

I'll be making a collection of such labs for your learning pleasure. Stay tuned.

That's not the only change. We have a blog section now. As I am reorganizing the content on Linux Handbook, it makes sense to write blogs around tools and tips we discover as a Linux user.

Optimizing images for the web is a common step in website design and development, but it can also be one of the most tedious. With all the steps like resizing, compressing, stripping metadata, and exporting multiple formats, it can eat chunks of time that rack up quickly when you’re just trying to work your blog, portfolio, or even a small business website.

This lab exercises will show you how to not only make that process easier, but automate it in a way that can be replicated on your own system or even a Linux server.

🎯 The goal

For this Linux Lab project, we'll be building a simple, fully automated image processing pipeline that does the following:

• Watches a specific folder for new images
• Automatically optimizes them using ImageMagick
• (Optionally) Generates web-friendly WebP copies
• (Optionally) Moves images into section-specific folders like optimized/blog/img/ for rapid reference and deployment
• (Preferably) Runs the automation as a systemd user service

By the time we're finished, you’ll have a reusable automation that you can implement on your desktop or server, with minimal overhead, no need for configuration, and no need for Docker or any external services.

Prerequisites

Before you dive in, there are a few dependencies that should be taken care of first. The details may differ slightly for your distro, so please be aware that you may need to consult your distro's documentation where necessary to install the correct packages. Once this stage is done, however, you should be able to follow everything just the same on most distributions.

You'll need to install:

• ImageMagick: for resizing and compressing images in common formats
• inotify-tools: for watching the target folder for any new files
• (optionally) webp: for converting images to the WebP format

On Ubuntu systems, you can run:

sudo apt update
sudo apt install -y imagemagick inotify-tools webp

On Fedora, you can use:

sudo dnf -y install ImageMagick inotify-tools libwebp-tools

Once you've installed these packages, you're ready to move on to setting up the project folders.

Building out the project folders

For this endeavor, we'll build a single parent folder with three sub-directories. Technically, you can place the three sub-directories anywhere you like, but for keeping things organized, we'll keep them in a dedicated folder for this tutorial.

The structure we'll use looks something like this:

• ~/image-lab: the parent folder
  • /incoming: where you'll drop original images for optimization
  • /optimized: where optimized images will be saved
  • /logs: for storing a simple log file with timestamps and actions

To create these folders, you just need to run the following command:

mkdir -p ~/image-lab/{incoming,optimized,logs}

This will automatically create the sub-directories with ~/image-lab for you.

There are plenty of tools that help you use Docker containers more effectively and smoothly. One of the most popular was Watchtower. Was...because the project has been discontinued in December 2025.

If you've been running Watchtower to automatically keep your containers updated, you're not alone in suddenly wondering what's next after the repo has been archived.

Good news - the alternatives are actually better. Here are some solid tools worth your time in my opinion and experience.

Diun - Docker Image Update Notifier

It is a CLI application written in Go and delivered as a single executable (and a Docker image) to receive notifications when a Docker image is updated on a Docker registry.

Diun does one thing: watches your images and notifies you when they're updated. It will not touch your containers. That's intentional. If you've ever had Watchtower silently pull a Postgres major version upgrade at 2 am, you'll appreciate this approach. You stay in control of when the actual update happens.

Quick compose setup:

services:
  diun:
    image: crazymax/diun:latest
    volumes:
      - "./data:/data"
      - "/var/run/docker.sock:/var/run/docker.sock"
      - "./diun.yml:/diun.yml:ro"
    environment:
      - "DIUN_WATCH_SCHEDULE=0 */6 * * *"
    restart: always

and make one diun.yml:

# diun.yml
watch:
  schedule: "0 */6 * * *"
providers:
  docker:
    watchStopped: true
notif:
  discord:
    webhookURL: https://discordapp.com/api/YOUR/WEBHOOK

You can mention your webhook URL for Slack, Telegram, Discord, etc. if there is any update, you will receive it like:

This will notify you in all supported applications, just like what we have received on Discord: the hostname, provider, the date it was created, platform and the Docker Hub link.

Use this if: You want awareness without the risk of surprise updates. Great for production-adjacent setups.

Tugtainer

Tugtainer is a self-hosted app for automating updates of your Docker containers. Relatively new (October 2025), devs say not production-ready yet. But moves fast — v1.25.0 dropped March 2026.

Tugtainer gives you a proper web dashboard to manage container updates. Think Portainer, but focused specifically on the update workflow.

Quick setup:

# create volume
docker volume create tugtainer_data

# pull image
docker pull ghcr.io/quenary/tugtainer:1

# run container
docker run -d -p 9412:80 \
    --name=tugtainer \
    --restart=unless-stopped \
    -v tugtainer_data:/tugtainer \
    -v /var/run/docker.sock:/var/run/docker.sock:ro \
    ghcr.io/quenary/tugtainer:1

Hit http://your-server:3000 and you get this:

Some of the main features are: Notifications to a wide range of services, Per-container config (check only or auto-update), Automatic/manual check and update, Automatic/manual image pruning and Linked containers support (compose and custom).

Use this if: You want a UI to manage your homelab updates. Especially good for Docker Compose setups.

WUD - What's Up Docker

WUD is the closest thing to a drop-in Watchtower replacement - but it's smarter. It has a web dashboard, notification support, and can auto-update containers. The key difference? It lets you set thresholds.

WUD_TRIGGER_DOCKER_LOCAL_THRESHOLD=patch

With that set, WUD auto-updates 1.2.3 → 1.2.4 but just notifies you for 1.2.3 → 1.3.0 or a major bump. Watchtower had no concept of this.

Quick setup:

services:
  wud:
    image: getwud/wud:latest
    ports:
      - "3000:3000"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - WUD_NOTIFIER_TELEGRAM_BOTTOKEN=your-token
      - WUD_NOTIFIER_TELEGRAM_CHATID=your-chat-id
      - WUD_TRIGGER_DOCKER_LOCAL_THRESHOLD=patch
    restart: unless-stopped

If you hit localhost:3000 you will get a simple, minimalist UI.

Notifications go to Slack, Telegram, Discord, Gotify, Ntfy, Pushover, email and more.

Use this if: You want something close to Watchtower's auto-update behavior, but with actual guardrails and a dashboard.

dockcheck

The odd one out - it's a bash script. And it's my personal favorite.

The trick: dockcheck uses regctl to compare image digests directly against the registry. It never pre-pulls images just to check for updates. Saves bandwidth, doesn't hit Docker Hub rate limits, and is just plain faster.

Install regctl first:

curl -L https://github.com/regclient/regclient/releases/latest/download/regctl-linux-amd64 \
  -o /usr/local/bin/regctl && chmod +x /usr/local/bin/regctl

curl -fsSL https://raw.githubusercontent.com/mag37/dockcheck/main/dockcheck.sh -o dockcheck.sh
chmod +x dockcheck.sh
./dockcheck.sh

You will get output like this:

You get a numbered list of containers with updates available. Pick which ones to update, or type a for all. Clean and simple.

To automate it, just cron it:

# Every Sunday at 3AM, auto-update all, send notification
0 3 * * 0 /home/user/dockcheck.sh -a -n >> /var/log/dockcheck.log 2>&1

It also supports image backups -b so you can roll back if something breaks, and parallel checks with -x N, for more flag you can check -h flag for help.

Use this if: You're comfortable with the terminal, run a Linux homelab, and want something lightweight and auditable (it's a bash script, you can read the whole thing).

Cup

Cup might be the fastest update checker on this list. It claims to scan 58 images in 3.7 seconds on a Raspberry Pi 5!

The secret is that instead of pulling images to compare them, it makes minimal API calls - one auth request per registry, then lightweight manifest HEAD requests. This means it never burns through Docker Hub's pull rate limits, which matters a lot now that Docker Hub has been tightening limits for unauthenticated users.

Quick setup:

#Pull the image 
docker pull ghcr.io/sergi0g/cup

#Run the image with port mapping
docker run -tv /var/run/docker.sock:/var/run/docker.sock -p 9001:9001 ghcr.io/sergi0g/cup serve -p 9001

Then, if you visit localhost:9001 you will get a simple look where you will see all the monitored images, updates available and up-to-date images with a command given to update to the latest image.

It tells you what's out of date and leaves the rest to you - via a cron job, a webhook consumer, or just checking the dashboard manually. It supports Docker Hub, ghcr.io, Quay, lscr.io, Gitea and more.

Use this if: You're hitting Docker Hub rate limits with other tools, or just want the fastest possible update check without anything auto-touching your containers.

Dockwatch

Simple UI driven way to manage updates & notifications for Docker containers. Dockwatch comes from the Notifiarr team; the same folks who built one of the best notification routing systems in the self-hosted world. That DNA shows.

It's built around a beautiful web UI and a genuinely impressive notification system. The kind of thing you'd show someone to convince them that self-hosting is actually fun.

Quick compose setup:

services:
  dockwatch:
    image: ghcr.io/notifiarr/dockwatch:latest
    ports:
      - "3001:80"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./dockwatch/config:/config
    restart: unless-stopped

Once you're done, run the command:

docker compose up -d

Then visit the localhost:3001, you will see the advanced setup, which shows a beautiful UI giving you information about disk usage, network I/O, CPU usage, memory usage and updates available for the images.

Use this if: You want a feature-rich dashboard with serious notification chops, especially if you're already in the Notifiarr/Servarr ecosystem.

nicholas-fedor/watchtower

For Those Who Don't Want to Change Anything. Okay, real talk. Maybe you've been running Watchtower for years. Your whole homelab is tuned around it. Your cron jobs reference it. Your muscle memory knows the flags. You don't want to learn a new tool.

Fair. Enter nicholas-fedor/watchtower - a community-maintained fork that picks up exactly where the archived original left off.

# Before (archived, no longer works on newer Docker versions):
image: containrrr/watchtower

# After (actively maintained):
image: nickfedor/watchtower

Quick setup:

# Get the compose file 
curl -L https://raw.githubusercontent.com/nicholas-fedor/watchtower/refs/heads/main/examples/default/docker-compose.yaml -o docker-compose.yaml

# Run command
docker compose up -d

After this, the expected behaviour is it will monitor all running containers on the host and every 24 hours, it will poll if the monitored containers have updated image digests; if available, it will pull the updated image without changing the previous configurations.

auto-updates everything it can see, by default. There's no semantic versioning awareness, no dashboard, no diff before it updates

Use this if: You want zero migration friction and just need the original Watchtower to keep running on modern Docker.

So, which one to choose?

Yes, if you are impressed with all of these here, I will give you one line suggestions:

Want notification-only, no auto-updates - Diun or Cup, Want a web UI for your homelab - Tugtainer or WUD or Dockwatch, Closest Watchtower replacement with smarter auto-updates - WUD, Terminal-first, minimal dependencies - dockcheck, Running Kubernetes or Swarm - Only Diun supports that, Want zero migration from the original Watchtower - nicholas-fedor/watchtower, Already in the Notifiarr/Servarr ecosystem - Dockwatch is a natural fit.

Know another tool worth adding? Drop it in the comments.