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

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

What is Keycloak?

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

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

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

The Setup Challenge

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

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

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

networks:
  keycloak:

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

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

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

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

Initial Configuration

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

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

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

Real-World Test: Portainer OAuth Integration

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Social Login Integration

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

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

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

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

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

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

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

What Works Really Well In Keycloak

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

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

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

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

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

Where Keycloak Falls Short

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

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

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

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

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

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

Conclusion

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

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

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

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

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

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

Building an Automated Image Optimization Pipeline

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

Linux HandbookRoland Taylor

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

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

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

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

🎯 The goal

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

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

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

Prerequisites

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

You'll need to install:

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

On Ubuntu systems, you can run:

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

On Fedora, you can use:

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

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

Building out the project folders

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

The structure we'll use looks something like this:

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

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

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

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

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

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

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

Diun - Docker Image Update Notifier

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

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

Quick compose setup:

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

and make one diun.yml:

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

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

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

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

Tugtainer

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

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

Quick setup:

# create volume
docker volume create tugtainer_data

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

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

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

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

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

WUD - What's Up Docker

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

WUD_TRIGGER_DOCKER_LOCAL_THRESHOLD=patch

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

Quick setup:

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

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

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

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

dockcheck

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

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

Install regctl first:

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

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

You will get output like this:

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

To automate it, just cron it:

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

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

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

Cup

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

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

Quick setup:

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

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

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

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

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

Dockwatch

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

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

Quick compose setup:

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

Once you're done, run the command:

docker compose up -d

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

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

nicholas-fedor/watchtower

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

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

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

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

Quick setup:

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

# Run command
docker compose up -d

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

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

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

So, which one to choose?

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

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

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

There are two main tools for searching files in Linux:

• find for finding files by names and attributes
• grep for finding files by its content

You combine find with xargs and you have an outstanding search tool in your hands.

I am not denying the power of find command. I have just explored another tool that does the same job with much more ease.

That tool is fzf, an interactive command line utility that implements a fuzzy search algorithm to search through all sorts of list: files, command history, processes, hostnames, bookmarks, git commits, and so on.

As you can imagine, it has the ability to make your life a lot easier.

I have explored fzf, liked it and I am going to share the features I love in fzf. I hardly touch find now.

Search and Selection

fzf can be run by simply entering the command in the terminal. It searches through all the files that are the working directory where the command is being run. The basic usage is quite simple and can be understood easily. To start, just enter:

fzf

As soon as you run the command, fzf opens up and starts listing all the files inside the current working directory. You can see at the bottom two numbers in a fraction, the numerator denoting how many files match the search prompt and the denominator denoting how many total files it is searching through.

There are a number of ways to input the search, which work like this:

To fuzzy search for a keyword simply as it is:

keyword

This is the way to get exact-matched results, i.e. item that include the keyword:

'keyword

This is how you look for items that either start or end with the keyword:

'keyword'

To find items that start with the keyword:

^keyword

To find files that end with .ext extension.

.ext$

There are options using which you can find anything but the keyword you're looking for.

To find all files which do not include the keyword:

!keyword

This finds all files to that do start with the keyword:

!^keyword

Find all the files that do not have the .ext extension:

!.ext$

These options might seem like they're a bit much to remember, but as you get used to the program, remembering the syntax will become second nature.

After you give the input, you get the list of items matching the criteria, with the most relevant results closest to the search bar at the bottom. When you press enter on a result, fzf exits with the file location displayed. You can even navigate using the mouse, scrolling and clicking the results.

Preview Mode

Using the preview mode, you can run a command that you specify for every selection that you get from fzf.

For example, if you want to read every single file that you select when you search for something, you can use the cat command to do so:

fzf --preview 'cat {}'

The working of this command can be seen better in a video.

Previewing Images

You can use the preview window to even see photos on a terminal that supports graphics (duch has Ghostty) using Chafa, Kitty, ImgCat etc. The best, in my experience, has been Chafa. You can see how to install it here. Now to preview images, enter this command:

fzf --preview 'chafa {}'

Display Modes

There are 3 different display modes that come with fzf: default, full and minimal modes. On plain application with the command, the difference in the interface doesn't seem like much:

But there are a huge number of attributes you can modify to change the look of fzf as you please. Some of the most useful ones are:

Height

Using this, you can choose how much of the terminal window fzf will occupy:

fzf --height=40%

Setting the value at ~100 will cause fzf to occupy the entire window.

Border

By default, fzf has no solid border. But it does offer a number of options if you want one:

fzf --border=<style>

Some of the styles that it offers are:

• rounded: gives (obviously) round borders.
• sharp: gives (again, obviously) sharp borders.
• bold: bold-line borders.
• double: double-lined borders.
• horizontal: borders only at the top and the bottom.
• vertical: borders only on right and left edges.
• top: only at the top.
• bottom: only at the bottom.
• left: only on the left.
• right: only on the right.

There are other options as well.

Layout

In the default settings, the fzf starts from the bottom of the screen, but you can reverse that using:

fzf --layout=reverse

A simpler command to do the same is:

fzf --reverse

There is even a specific case where you can get fzf starting from the top of the window, but the prompt will be at the bottom:

fzf --layout=reverse-list

Margin

You can add a margin with a command with the following syntax:

fzf --margin T%, R%, B%, L%

Where T, R, B and L stand for top, right, bottom and left respectively. To have the same margin in all directions, you can simply enter a single value.

Padding

The padding option is relevant only if you're using a border as well. This is the gap between the actual contents of the command and the border of the same. It works the same way as margin:

fzf --padding T%, R%, B%, L%

where T, R, B and L are top, right, bottom and left percentages respectively.

There are more advanced options for modifications which change how the list section or the input section look. For the list section, you can enable/disable multi-selection, highlighting, line wrapping, and a scrollbar. You can even enable tracking, in which case the selected result will be tracked while the results are being updated. You can add a gap between result lines (and modify what the gap looks like).

For the input section, you can change the prompt, information style, enable/disable a separator, add ghost text, add borders or label, or even disable the section entirely! There are more options for modification of both of these sections, in case this doesn't satiate you.

You can see all of these options using:

fzf --man

stdin

fzf works on standard input as well, and you can pipe reults into it to search through them. For example, for searching only through the results of the ls command, you can enter:

ls | fzf

This doesn't have to be just ls, it can be the result of any command that you would want to search through.

Shell Integration

One of the most useful features of fzf is that it can directly integrate into your terminal of choice. This is great, especially if you spend a lot of time at the terminal. There are various shortcuts that search with different intentions, which are:

• Ctrl+R: To search through the command history.
• Ctrl+T: To search for files in the working directory, as you would when using fzf normally.
• Alt+C: To search for directories within the working directory.

But first, you need to integrate it into your terminal. Various shells work with different commands:

For bash:

eval "$(fzf --bash)"

For zsh:

source <(fzf --zsh)

For fish:

fzf --fish | source

Run these commands depending on what shell you're using, and you're good to go.

Fuzzy Completion in Terminal

You can use fzf to enhance the autocompletion that the terminal provides. This feature is valid only for bash and zsh, however. For any command where you have to give the location of a file or a directory, you can do with fzf integrated, simply by putting "**" before pressing Tab key. So for example, if I want to cd into a directory that is deep within my working directory, I can just type:

cd **<Tab>directory keyword

This is better shown in action in this video:

Similarly, you can use the same method to use kill/pkill to kill processes, or nano/vim files that you want to edit, and so on. It is extremely convenient as long as what you're looking for is within your working directory, working almost like Harry Potter's accio spell.

Changing the Search Parameters

There are various options to even modify how the searching works on fzf. By default, the search works on extended mode, other than that, you can toggle case sensitivity using --ignore-case or --no-ignore-case or even use --smart-case, where the case sensitivity is off by default, but turned on if there are any uppercase letters in the input.

It also offers two searching algorithms, where the default one is v2. The algorithm v1 is supposed to be faster but not as accurate as v2. You can change it using --algo=v1.

Vim Integration

In case you use Vim, here's another extra feature for you. You can enable it within the editor by adding a line to your Vim configuration file, which looks like this:

set rtp+=<fzf location>

This location is usually /usr/bin/fzf on Linux, but can be /usr/local/opt/fzf if you've used Homebrew to install it.

How to get fzf

fzf is available on the default repositories of most distributions, making it very easy to install. On Ubuntu based systems, just enter:

sudo apt install fzf

On Fedora based systems:

sudo dnf install fzf

You can use Homebrew on macOS:

brew install fzf

If you want to find the instructions for any other systems, you can find it on the website quite easily.

Final Thoughts

There are still many more advanced features that fzf provides, which can all be found on the official GitHub page right here. If not the page, you can visit the man page of fzf (which is extremely well written) to find everything modifiable on fzf. With the exhaustingly immense amount of thematic as well as search-parameter customization that fzf gives you, it can be one of the most effective tools in your roster.

Let us know what you think about this tool in the comments. Cheers!

Once you're running more than 3-4 containers, you'll run into the same questions: Which container is eating my RAM? Why did this crash at 3 am? My images are 800 MB and I have no idea why.

Here's the thing. Docker is an ecosystem and there exist tools that can help you deal with Docker containers and images more effectively.

For past couple of years, I have tried many such tools. I have used them across real scenarios and dev setups that usually involve monitoring tools, TUIs, log viewers, image analyzers, and more; and narrowed it down to the ones that actually solve real problems, which enhances the total experience of your Docker.

These tools exist specifically to answer those questions and I'll tell you exactly which situations each one is built for.

Short on time? See the details in the table below: Here's a quick overview before the full breakdowns.

Comparison Table

Now let's go through each one.

Lazydocker - All-in-one terminal UI for Docker management

Lazydocker is a keyboard-driven terminal UI that brings containers, logs, stats, images, and volumes into a single split-panel view - making it the most practical way to manage Docker entirely from the terminal without memorizing dozens of commands.

Who it's best for: Developers and homelabbers who live in the terminal and want a single interface to replace docker ps, docker logs, docker stats, and docker exec all at once.

Quick Setup:

# Homebrew (Linux or macOS):
brew install lazydocker

# Or via Go:
go install github.com/jesseduffield/lazydocker@latest

# No install needed — run via Docker:
docker run --rm -it \
  -v /var/run/docker.sock:/var/run/docker.sock \
  lazyteam/lazydocker

You can see on the left side, there is a normal Docker ps command and on the right side, there is lazydocker runnning showing all running containers, images, volumes, also logs, stats, config, CPU usage, etc.

It has many more commands to perform as shown below: you can see them by typing x in the terminal.

Verdict: The safe default for anyone who prefers the terminal. Install it once, and you'll stop missing raw Docker commands within 20 minutes.

Oxker - Lightweight TUI for speed and zero dependencies

Oxker is a Docker container TUI written in Rust that delivers a multi-panel interface including a live container list, log streaming, and resource stats, in a single binary with no runtime dependencies whatsoever.

Who it's best for: Terminal users who want Lazydocker-style visibility but with a leaner footprint - no Go runtime, no Node.js, nothing. Also great for Rust fans and anyone in constrained environments.

Quick Setup:

# Cargo:
cargo install oxker

# Homebrew:
brew install oxker

# Zero-install via Docker (read-only socket):
docker run --rm -it \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  ghcr.io/mrjackwills/oxker

# Arch Linux AUR:
paru -S oxker

After running the commands, you can see a beautiful TUI running showing containers, CPU, Memory, Ports and you can see the helpful commands to run inside, using h If you need to execute, you can use e after selecting the container, use q to quit from the current session.

Verdict: Way better than its star count suggests. If you want a leaner, faster alternative to Lazydocker with zero dependencies, give Oxker 5 minutes; you might just switch.

Dockge - Web UI for Docker Compose stack management

Dockge is a self-hosted web UI built specifically for Docker Compose stack management, letting you create, edit, start, stop, and monitor compose stacks through a clean browser interface, while keeping your compose.yaml files exactly where they are on disk.

Who it's best for: Homelab users and solo developers who manage multiple compose stacks and want a visual interface for them without switching to a heavy all-in-one tool like Portainer.

Quick Setup:

# Create directories that store your stacks and stores Dockge's stack
mkdir -p /opt/stacks /opt/dockge
cd /opt/dockge

# Download the compose.yaml
curl https://raw.githubusercontent.com/louislam/dockge/master/compose.yaml --output compose.yaml

# Start the server
docker compose up -d

# If you are using docker-compose V1 or Podman
# docker-compose up -d

After running commads you'll have a Dashboard UI on the web at customised, where you can see the stack, compose and also you can deploy your own customised stack by defining the containers and env variables, networks, ports, etc.

Dockge has a built-in docker run to compose.yaml converter. Paste in a run command from Docker Hub and get a formatted compose file out. This alone saves 10 minutes every time.

Verdict: The best Compose stack UI for homelab setups, period. If you're already using compose-based setups, this replaces the docker compose up -d + vim loop entirely.

Dozzle - Web-based real-time container log viewer

Dozzle is a lightweight, self-hosted web application that streams Docker container logs directly to your browser in real time - zero storage, zero persistence, just live log output from your containers, accessible from any device on your network.

Who it's best for: Anyone who regularly SSHs into servers just to check container logs - especially useful for teams where non-SSH users need log visibility, or for checking logs from a phone or tablet.

Quick Setup:

# Pull image
docker pull amir20/dozzle:latest

# Run the container
docker run --name dozzle -d --volume=/var/run/docker.sock:/var/run/docker.sock -p 8082:8080 amir20/dozzle:latest

This one is one of the most elegant UI for browsers I have ever used and ever seen. You see a minimalist, simple and elegant presentation of your stack, containers, the CPU and memory usage for each stack.

You also get the SQL analytics for your stack, so you can search and retrieve from your database.

Verdict: One of the most immediately useful tools on this entire list. Bookmark it, use it from your phone at midnight when something breaks, never SSH in just for logs again.

Dive - For analyzing Docker image content

Dive is an interactive terminal tool that lets you explore every layer of a Docker image, showing exactly which files each RUN, COPY, or ADD instruction added, modified, or deleted, so you can see precisely why your images are larger than they should be.

Who it's best for: Developers who suspect their images are bloated but don't know where the size is coming from and anyone who wants to find and eliminate wasted space before shipping to production or a registry.

Quick Setup:

# Set parameter
DIVE_VERSION=$(curl -sL "https://api.github.com/repos/wagoodman/dive/releases/latest" | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*/\1/')

# Download 
curl -fOL "https://github.com/wagoodman/dive/releases/download/v${DIVE_VERSION}/dive_${DIVE_VERSION}_linux_amd64.deb"

# Install
sudo apt install ./dive_${DIVE_VERSION}_linux_amd64.deb

Then, after installation, you have to run the command:

dive <image name>

You will see the layers of the image, the layer contents, the layer details and Image details, along with the permissions and the file structure it holds.

Verdict: Run this on any image you've built yourself. I promise you'll find something to trim. It's now a standard step in my build process.

Dockhand - Docker web UI with built-in security scanning

Dockhand is a self-hosted Docker management web UI that scans images for vulnerabilities before deploying them, using a "safe-pull" approach where new image versions are scanned in a temporary tag and only promoted if they pass your configured CVE thresholds.

Who it's best for: Teams and individuals who want a Docker web UI that actively prevents vulnerable images from reaching their servers, especially those who need SSO authentication without paying for Portainer Business.

Quick Setup:

docker run -d \
  --name dockhand \
  --restart unless-stopped \
  -p 3000:3000 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v dockhand_data:/app/data \
  fnsys/dockhand:latest

Just run this one single command and your dockhand is running on localhost:3000

You need to add an environment first by giving the Public IP first then you can see all your images, containers, stacks, etc.

It supports Google, Azure AD, Okta, Keycloak and Auth0 for authentication. Portainer charges for this in their Business tier. Dockh
and includes it in the free tier.

Verdict: The only Docker web UI I've seen that actively blocks vulnerable image deployments. If security matters in your setup and you want SSO without paying Portainer Business prices, Dockhand is worth knowing about.

Kompose - For K8s Migration

Kompose is a command-line tool that automatically translates Docker Compose files into Kubernetes manifests, generating Deployments, Services, PersistentVolumeClaims, and ConfigMaps so you have a working starting point for your Kubernetes migration instead of writing everything from scratch.

Who it's best for: Developers and teams who have existing Docker Compose setups and are beginning a migration to Kubernetes; Kompose handles the mechanical translation work so you can focus on the Kubernetes-specific pieces.

Quick Setup:

# Build Image
docker build -t kompose https://github.com/kubernetes/kompose.git\#main

# Run 
docker run --rm -it -v $PWD:/opt -w /opt kompose kompose convert

You can see the configmap, deployment and the service yaml files created after running the kompose.

Verdict: The fastest way to get a working starting point for a Kubernetes migration. Run it, spend 20 minutes cleaning the output instead of 3+ hours writing everything manually.

Docker Slim - For Docker image size reduction

Docker Slim (now SlimToolkit) automatically reduces Docker image sizes by running your container, observing exactly which files and libraries it uses at runtime, then rebuilding a new image containing only those things, resulting in size reductions of 10 to 30x without modifying your Dockerfile or application code.

Who it's best for: Developers shipping large Docker images to production who want dramatically smaller images for faster CI, faster deploys, and a meaningfully reduced attack surface, especially those using fat base images like Ubuntu, Debian, or full Python/node.

Quick Setup:

# Download
curl -sL https://raw.githubusercontent.com/slimtoolkit/slim/master/scripts/install-slim.sh | sudo -E bash -

# Run command
docker-slim build --target <image_name> --http-probe=false

Here you can see the difference between the node:alpine and the node.slim image size after using the docker-slim.

Verdict: If you're shipping 500MB+ images, Docker Slim should be your next step. Faster CI, faster deploys, smaller attack surface, it pays for the setup time almost immediately.

Docker Autoheal - For auto-restarting your unhealthy containers

Docker Autoheal monitors running containers for failing health checks and automatically restarts them, filling a gap in Docker's native behavior where containers fail their HEALTHCHECK but Docker leaves them running in an unhealthy state indefinitely rather than restarting them.

Who it's best for: Anyone running Docker containers with HEALTHCHECK defined who wants automatic recovery from unhealthy states without setting up Kubernetes or writing their own cron-based monitoring script.

Quick Setup:

docker run -d \
    --name autoheal \
    --restart=always \
    -e AUTOHEAL_CONTAINER_LABEL=all \
    -v /var/run/docker.sock:/var/run/docker.sock \
    willfarrell/autoheal

sample compose file:

services:
  autoheal:
    image: willfarrell/autoheal:latest
    restart: always
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - AUTOHEAL_CONTAINER_LABEL=autoheal
      - AUTOHEAL_INTERVAL=5

  my-app:
    image: nginx:alpine
    container_name: demo-app
    labels:
      - "autoheal=true"
    healthcheck:
      # Curl fails if the default Nginx page is missing
      test: ["CMD", "curl", "-f", "http://localhost/"]
      interval: 5s     # Check frequently for the demo
      timeout: 3s
      retries: 2       # Fail quickly
      start_period: 2s

And now if there is any container in unhealthy status, it will restart that container withing the time interval mentioned in our case 5s.

Here it restarted the nginx container when it was showing unhealthy status and after some time its again started with status healthy.

Verdict: Small, unassuming, and genuinely useful. If your services have healthchecks and uptime matters, add Autoheal to your compose stack and stop worrying about containers quietly dying overnight.

Cup - For checking image updates without rate limit issues

Cup is an image update checker that tells you which running containers have newer versions available in the registry, using minimal, lightweight API calls against image manifests instead of pulling images, so it never burns through Docker Hub's pull rate limits.

Who it's best for: Users who want to stay aware of available image updates but are hitting Docker Hub rate limits with other tools, or who want a fast, lightweight checker that doesn't pollute their image cache.

Quick Setup:

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

# Run the image
docker run -tv /var/run/docker.sock:/var/run/docker.sock ghcr.io/sergi0g/cup check <image_name>

Here you can see the node image having 14.10 tag showing there is a major update available, while when we checked with the lts-krypton its Up to date.

Verdict: The fastest, most rate-limit-friendly way to know which images need updating. Keep it running in server mode with the dashboard bookmarked, one less thing to chase manually.

ctop - Real-time resource monitor for Docker containers

ctop is a top like terminal UI that displays real-time resource usage for all running Docker containers, CPU, memory, network I/O, and block I/O in a constantly updating, sortable, color-coded table, making it the fastest way to answer "what is my Docker host actually doing right now?"

Who it's best for: Any Docker user who wants an instant, always-accurate view of container resource consumption, especially useful for debugging performance issues, chasing memory leaks, or just understanding what's happening on a new server.

Quick Setup:

sudo curl -Lo /usr/local/bin/ctop https://github.com/bcicen/ctop/releases/download/v0.7.7/ctop-0.7.7-linux-amd64

sudo chmod +x /usr/local/bin/ctop

After installing, you can run the command ctop and can view this terminal UI where there are containers. If you press the right arrow, you can see the CPU, memory, I/O, Environment variables, etc. If you click on any container, you get options to view logs, start, remove, single view, etc.

Verdict: The first tool I install on any new Docker host. It answers "what's going on?" in two seconds, without opening a browser. If you pick exactly one tool from this list, make it this one.

FAQ

I know you will have some questions so let me answer them, well, at least some of them.

Do I need all 11 of these tools?
No. Most people will get immediate value from 2-3. Start with ctop and Dozzle; those solve universal problems. Add the others based on the specific pain points you're hitting: image size, security scanning, compose management, and so on.

Are these tools safe to run on a production server?
Most of them mount /var/run/docker.sock, which gives them root-equivalent access to your Docker daemon. Never expose Dockge, Dozzle, Dockhand, or Lazydocker directly to the public internet without authentication. Use Tailscale, a VPN, or, at a minimum, HTTPS + basic auth in front of them.

Do any of these replace Portainer?
Dockge is the closest in terms of compose management experience and is arguably better for solo homelab use. But it lacks Portainer's multi-user RBAC, Swarm support, and Kubernetes integration. For teams or larger production environments, Portainer CE or Portainer Business still makes sense. Dockhand replaces Portainer's paid SSO feature for free.

Will Docker Slim break my application?
It can, if the probe doesn't exercise all of your app's code paths. Always test `.slim` images thoroughly before deploying to production. Start with a non-critical service, validate the output image completely, then expand from there.

Do any of these tools work with Podman?
Kompose: Yes, works with any compose file, runtime-agnostic
Dive: Partial, can analyze OCI-compliant images directly
Dockge, Lazydocker, Oxker, ctop, Dozzle, Dockhand: Docker socket only
Docker Slim: Primarily Docker; SlimToolkit is expanding broader runtime support gradually

Is ctop still actively maintained?
Not with frequent releases, no. But the Docker stats API it uses is stable and doesn't change often, so ctop just keeps working. I've run it without issues for years.

Final recommendation

Terminal users - Lazydocker or Oxker give you full management without leaving the terminal.

Browser-first access - Dockge (compose management) + Dozzle (logs) together cover most daily needs.

Images too big - Run Dive first to diagnose, then Docker Slim to fix. Security concerns - Dockhand scans before it deploys; add it if you care about CVEs reaching your server.

Moving to Kubernetes - Kompose is your first step in the migration

Use these tools together as they don't conflict. Lazydocker + ctop + Dozzle handles daily monitoring. Dive + Docker Slim handles image hygiene. Docker Autoheal + Cup handles reliability and update awareness.

If you know more such tools that could help enhance the Docker experience, feel free to drop them in the comments!

You might remember that I mentioned working on an advanced Docker course a while back. It’s now ready.

This course focuses on understanding how containers actually work. You get to learn about namespaces, cgroups, networking, image optimization, observability, and container security.

If you already know basic Docker commands and want to go beyond docker run, this course will help you understand Docker at a deeper level.

Each module also has a practice lab so that you can put your learning to some testing.

Advanced Docker Course: Container Internals, Networking, Security and Image Optimization

Level up your Docker skills. Learn container internals, networking, image optimization, observability, and security in this practical course.

Linux HandbookYash Kiran Patil

Next week, we will publish a few DIY lab scenarios. Doing it on your own is the best form of learning. Stay tuned 😄

I gather you are familiar with Docker basics by now. You can deploy simple applications through Docker, create compose files for a mult-container app and even create your own custom image.

But real-world Docker usage goes much deeper.

• Why are containers isolated?
• How do containers communicate across hosts?
• Why do some images become huge?
• How do you debug networking issues inside containers?
• How do you secure containers properly?

This Docker Level Up course is designed to answer these questions.

This course helps you understand the internal mechanisms that make containers work: namespaces, cgroups, networking layers, security controls, observability tools, and image optimization techniques.

By the end of the course, Docker will no longer feel like a black box. You’ll understand how containers actually function under the hood and how to use Docker more effectively in real environments.

👀 Who this course is for?

This course is ideal for:

Linux users who already know basic Docker commands: If you’ve used Docker before but want to understand what happens behind the scenes.

Developers deploying containerized applications: Learn how to build smaller images, debug networking issues, and run containers efficiently.

DevOps engineers and SREs: Understand observability, container networking, and security best practices.

Homelab enthusiasts and self-hosters: If you run services with Docker and want deeper control over networking and isolation.

Students learning container technologies: This course builds strong fundamentals for Kubernetes and cloud-native systems.

🧠 What you’ll learn

The course is structured in five modules, each focusing on a key aspect of how Docker actually works under the hood.

Instead of jumping randomly between concepts, the modules follow a logical progression: container fundamentals → image building → observability → security → advanced networking.

Module 1: Container Internals

Before mastering Docker, you need to understand what a container actually is.

Containers are not virtual machines. They rely on Linux kernel features like namespaces and cgroups to isolate processes and resources.

In this module, you’ll explore the Linux technologies that make containers possible.

Topics covered:

• Introduction to containers and namespaces
• Hostname, IPC and user isolation
• cgroups and resource control
• Network and device controllers
• Practice lab

By the end of this module, you’ll clearly understand why containers behave the way they do.

Module 2: Docker Images and Optimization

Docker images often become unnecessarily large and inefficient.

In this module, you’ll learn how Docker images are built and how to optimize them properly.

Topics covered:

• How Docker images work internally
• Why Docker images become bulky
• Build tools vs production environments
• Multi-stage builds
• Image optimization techniques
• Practice lab

This module will help you build smaller, cleaner, production-ready images.

Module 3: Container Observability & Debugging

Containers sometimes fail in ways that are difficult to diagnose.

Understanding how to observe container behavior is critical when troubleshooting production issues.

Topics covered:

• External observability tools
• Internal observability inside containers
• Debugging container networking
• Practice lab

You’ll learn practical techniques to inspect, monitor, and debug containers effectively.

Module 4: Container Security

Security is often overlooked when running containers.

But containers share the host kernel, so understanding security boundaries is essential.

Topics covered:

• Core container security concepts
• Security best practices
• Important container security tools
• Practice lab

This module helps you run containers more safely and responsibly.

Module 5: Advanced Container Networking

Networking is one of the most confusing areas in Docker.

This module explains how container networking works both within a host and across multiple hosts.

Topics covered:

• Multi-host container networking
• Macvlan and IPvlan networks
• Service discovery and internal DNS
• Practice lab

After this module, Docker networking will finally make practical sense instead of feeling magical.

This month, we released the Go for DevOps course. Next is GitOps video course. The work is in progress, and we are on track to release it early next month.

After that, the plan is to release Docker Advanced level course and add videos to existing Docker beginner course. Plenty of exciting content in the pipeline. Hope you are as excited about them as I am 💪