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.

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.