Ever wanted a dedicated touchscreen on the wall to control your smart home?
A Raspberry Pi combined with a touchscreen makes a great Home Assistant wall panel. With a little configuration, the Pi can boot automatically, launch directly into Home Assistant, hide the mouse cursor, and stay running as a dedicated touchscreen dashboard.
The goal is simple:
Power on → Raspberry Pi boots → Chromium launches → Home Assistant appears in full-screen kiosk mode.
No keyboard, no mouse, and no desktop to interact with.
Start by installing Raspberry Pi OS with Desktop onto the Raspberry Pi’s SD card.
Using the Raspberry Pi Imager makes this part straightforward.
Once the Pi boots, configure it for:
The important part is enabling Desktop Autologin so the Raspberry Pi can start the graphical environment without requiring someone to log in manually.
After the initial setup, reboot the Pi and make sure the desktop loads automatically.
The kiosk doesn’t need much software.
The main components are:
Chromium is responsible for displaying the Home Assistant dashboard.
Instead of using the browser like a normal desktop application, it will eventually launch directly in Kiosk Mode.
Unclutter hides the mouse cursor after a short period of inactivity.
This is especially useful for a wall-mounted touchscreen where you don’t want a mouse pointer sitting over your dashboard.
The next step is creating a small startup script that handles the kiosk launch.
The script has three main jobs:
The browser is configured to open directly to the Home Assistant dashboard.
For example, instead of starting on a normal browser homepage, the Raspberry Pi goes straight to your Home Assistant instance.
The result:
Raspberry Pi Desktop → Kiosk Script → Chromium → Home Assistant
No desktop interaction is required.
A kiosk isn’t very useful if you have to manually start it every time the Raspberry Pi reboots.
To solve this, create a systemd user service that starts the kiosk script when the graphical desktop session becomes available.
The service can also be configured to restart automatically if Chromium unexpectedly closes.
This gives the kiosk a simple recovery mechanism:
Power failure → Raspberry Pi reboots → Desktop loads → Kiosk starts → Home Assistant appears
This makes the setup much more suitable for a permanent wall-mounted installation.
The Raspberry Pi can already display Home Assistant in full screen, but the Home Assistant interface itself can still contain navigation elements.
For a cleaner wall-panel experience, install Kiosk Mode through HACS.
This can remove elements such as:
The result is a much cleaner dashboard designed specifically for a dedicated touchscreen.
Instead of looking like a website running inside a browser, it starts to feel more like a purpose-built smart-home control panel.
With the kiosk running, the final step is designing the Home Assistant dashboard.
For a wall-mounted display, keep things simple.
Large buttons and cards work much better than tiny controls.
Some useful sections could include:
The goal isn’t to put every Home Assistant entity on the screen.
The goal is to make the most important controls available with a quick tap.
After everything is configured, the Raspberry Pi becomes a dedicated Home Assistant wall panel.
There is no need to manually open a browser or navigate to Home Assistant.
Simply turn it on.
Boot → Auto Login → Kiosk → Home Assistant
And that’s it.
The Raspberry Pi is now a permanent touchscreen interface for the smart home.
This is one of those homelab projects that doesn’t require a huge amount of hardware or software but produces a really nice result.
A Raspberry Pi, touchscreen, and a few lightweight configuration changes can turn into a polished-looking Home Assistant control panel.
It also has the advantage of being easy to recover. If the Pi loses power or needs to reboot, the kiosk can automatically come back online without requiring manual intervention.
For a smart home, that’s exactly what you want.
Power it on and forget about it.
Hardware:
Software:
The end goal:
🖥️ Raspberry Pi + 📱 Touchscreen → 🏠 Home Assistant Kiosk
A UPS is great, but simply plugging your servers into it isn’t enough. The real goal is to make sure the servers know when the power goes out, react appropriately, and shut down cleanly before the batteries are exhausted.
After setting up my UPS devices with Network UPS Tools (NUT), I wanted to take things a little further.
The goal was to have one central NUT server managing multiple UPS devices, with remote Linux and Windows machines monitoring those UPS units over the network.
I also wanted a simple web interface to see what was happening.
The basic architecture looks like this:
UPS → NUT Server → Network → Clients
My NUT server is connected directly to the UPS devices through USB.
The NUT server handles communication with the UPS hardware and makes the UPS information available over the network.
Remote machines then connect to the NUT server and monitor the UPS status.
This means I don’t need to connect every server directly to a UPS.
One of the nice things about NUT is that a single server can manage multiple UPS devices.
In my setup, I have several UPS units connected through USB.
Each UPS gets its own name inside NUT.
For example:
trippliteapc-networkapc-modemThis makes it possible for clients to monitor a specific UPS depending on which equipment they are protecting.
The important part is identifying each UPS correctly.
nut-scanner makes this much easier because it can detect compatible USB UPS devices and provide the information needed for the NUT configuration.
When troubleshooting a UPS, one of the first things I check is USB detection.
The simplest check is:
lsusb
If the UPS appears there, Linux can at least see the USB device.
For more detailed information, lsusb -D can be used against the appropriate USB device path.
This can be especially useful when troubleshooting multiple UPS devices that use the same vendor and product IDs.
For example, two APC UPS units may both report the same USB vendor and product ID.
In that situation, the serial number can be used to distinguish between them.
The NUT server is the central part of the setup.
The UPS drivers communicate directly with the physical UPS devices.
NUT then exposes the UPS information through upsd.
The server can provide information such as:
The important part is that clients don’t need direct USB access to the UPS.
They simply connect to the NUT server over the network.
The NUT server runs in:
MODE=netserver
This allows remote clients to connect to it.
The NUT server listens on port:
3493
Once the server is listening on the network, a remote Linux machine can test the connection with upsc.
For example:
upsc yourupsname@your-nut-server
If everything is working, NUT will return the UPS information.
This is a great first test before configuring automatic shutdown.
The remote Linux machines only need the NUT client components.
They don’t need to have the UPS physically connected to them.
The client connects to the central NUT server and monitors the UPS.
The important configuration is the MONITOR entry in upsmon.conf.
This tells the machine which UPS to monitor and what credentials to use.
The client can then react to events such as:
This is where NUT becomes much more useful than simply monitoring battery percentage.
A power outage might only last a few seconds.
In that case, there’s no reason to shut down everything immediately.
Instead, the client can wait and see whether power returns.
For longer outages, upssched can be used to schedule actions.
For example:
Power goes out
↓
UPS switches to battery
↓
Start a timer
↓
Power comes back
↓
Cancel the timer
Or:
Power goes out
↓
UPS stays on battery
↓
Timer expires
↓
Trigger a controlled shutdown
This gives the system some protection against short power interruptions without unnecessarily shutting down the homelab.
upsschedupssched is useful because it gives the shutdown process some intelligence.
Instead of:
Battery detected → immediately shutdown
I can define something closer to:
Battery detected → wait → check again → shutdown only if the situation continues.
It can also react to communication problems.
For example, if the client temporarily loses communication with the NUT server, a timer can be started rather than immediately shutting down the machine.
If communication comes back, the timer can be cancelled.
This helps avoid unnecessary shutdowns caused by a temporary network or service problem.
UPS shutdown systems should be tested.
A configuration that looks correct on paper isn’t enough.
One simple test is to disconnect the UPS from utility power while keeping the equipment connected to the UPS.
The UPS should switch to battery.
The NUT server should detect the change.
The remote clients should also detect the event.
Logs can then be checked to confirm that everything is behaving as expected.
On Debian-based systems, the system logs can be inspected with:
tail /var/log/syslog
Depending on the distribution and logging configuration, journalctl can also be useful.
Once the NUT server was working, I wanted an easier way to see the UPS status.
For that, I added WebNUT.
WebNUT provides a web interface for viewing information from a NUT server.
I run it as a Docker container.
The container connects to the NUT server over port 3493 and exposes its own web interface on port 6543.
This gives me a simple dashboard for checking the UPS without having to SSH into the NUT server and run upsc manually.
The PeaNuts container is intentionally kept separate from the NUT server itself.
The architecture is:
Physical UPS
↓
NUT Server
↓
Peanuts Docker Container
↓
Web Browser
This is convenient because Peanuts doesn’t need direct access to the USB UPS devices.
It only needs network access to the NUT server.
NUT isn’t limited to Linux.
Windows machines can also monitor the NUT server.
For Windows, I use WinNUT Client.
The Windows client connects to the NUT server in the same general way as a Linux NUT client.
This is particularly useful in a homelab where you might have a mixture of:
One UPS can therefore provide power information to many different systems.
The biggest advantage of this setup is that the UPS hardware doesn’t have to be distributed everywhere.
Instead, I have a central NUT server.
Something like:
┌───────────────┐
│ UPS #1 │
│ Tripp Lite │
└───────┬───────┘
│ USB
┌───────▼───────┐
│ │
│ NUT Server │
│ │
└───────┬───────┘
│ Network
┌───────────┼───────────┐
│ │ │
▼ ▼ ▼
Linux Windows WebNUT
Client Client Docker
Additional UPS devices can be connected to the same NUT server.
The result is a centralized UPS monitoring system for the homelab.
The complete sequence now looks something like this:
1. Utility power fails
The UPS switches to battery.
2. NUT detects the change
The NUT driver reports that the UPS is running on battery.
3. Remote clients receive the event
Linux and Windows clients know that the UPS is no longer receiving utility power.
4. Timers can start
upssched can wait for a configurable amount of time.
5. Power returns
The UPS goes back online and the timers can be cancelled.
6. Power stays off
If the outage continues, the configured shutdown action can be triggered.
7. Servers shut down cleanly
Instead of suddenly losing power when the battery dies, the machines have an opportunity to shut down properly.
The important part isn’t really the web dashboard.
It’s the automation behind it.
A UPS protects hardware from sudden power loss, but NUT makes the UPS part of the infrastructure.
Instead of having a UPS silently beep during an outage, the homelab can actually understand what’s happening and react to it.
The final setup gives me:
NUT is one of those homelab services that you don’t think about much when everything is working.
That’s actually the point.
When the power goes out, I don’t want to be scrambling around trying to shut down servers manually.
I want the UPS to detect the outage, NUT to report it, the clients to react, and the systems to shut down cleanly if the outage lasts long enough.
With a central NUT server and network clients, the UPS becomes another managed service in the homelab rather than just a battery sitting underneath a server.
And hopefully, the next power outage will be boring.
I use a lot of Linux systems in my homelab, and after a while I started collecting more and more Bash aliases.
The problem?
Every time I set up a new server, I had to remember which aliases I had, copy my .bashrc, or manually recreate everything.
So I decided to build something a little more convenient: a centralized Bash alias library hosted on GitHub.
The idea is simple:
Keep my aliases in one GitHub repository and let an installation script automatically discover and install them.
Instead of putting every alias directly inside .bashrc, I keep them organized in my GitHub repository.
For example:
aliases/
├── docker.bash
├── linux.bash
├── network.bash
├── proxmox.bash
└── system.bash
Each file contains aliases related to a particular topic.
The installer downloads the repository, discovers the available alias files, and makes them available to the current user.
That means when I add a new alias to GitHub, I don’t have to manually modify .bashrc on every machine.
There are a few advantages to this approach.
Instead of having slightly different .bashrc files across multiple servers, my aliases live in one repository.
When I install a new Debian or Ubuntu server, I can simply run the installer and get my usual command shortcuts.
If I add or change an alias, I can update the repository and pull the changes onto my other systems.
Rather than having a .bashrc containing hundreds of aliases, I can separate them into logical files.
I don’t need hundreds of aliases to demonstrate the idea. Even a few simple ones make the concept useful.
For example, some Docker shortcuts:
alias dps='docker ps'
alias dpa='docker ps -a'
alias dcu='docker compose up -d'
alias dcd='docker compose down'
Some useful Linux shortcuts:
alias ll='ls -lah'
alias ..='cd ..'
alias c='clear'
And some system-related shortcuts:
alias update='sudo apt update && sudo apt upgrade'
alias ports='sudo ss -tulpn'
The important part isn’t the aliases themselves.
It’s where they are stored and how they get installed.
One of the things I wanted was to avoid hard-coding every alias file into the installation script.
Instead, the installer looks at the repository and discovers the available files automatically.
So if I add:
aliases/network.bash
later, the installer can find it without me having to modify the installer itself.
This also makes the repository easier to maintain.
I can simply create another .bash file whenever I want to add a new category.
.bashrc IntegrationThe installer doesn’t need to replace the user’s entire .bashrc.
Instead, it adds a small section that loads the alias library.
Conceptually, it looks something like this:
# My GitHub Bash Aliases
for file in ~/.bash_aliases/*.bash; do
[ -f "$file" ] && source "$file"
done
This keeps the actual aliases separate from the main Bash configuration.
It also means I can continue using my normal .bashrc without worrying about losing existing settings.
Once everything is set up, adding a new alias is simple.
I create or modify one of the files in the repository:
aliases/docker.bash
Add the alias:
alias dlogs='docker logs -f'
Commit and push the change to GitHub.
Then I can update the alias library on another machine.
No copying and pasting between servers.
The other part of the project is a small installation script.
Its job is basically:
aliases/*.bash files..bashrc section.The goal is to make installing my personal Linux environment almost as easy as installing a package.
I deliberately didn’t want to turn this into a huge configuration-management project.
For my homelab, I wanted something lightweight.
GitHub handles the version control.
Bash handles loading the aliases.
The installer handles deployment.
That’s really all I need.
This could easily be expanded later.
For example:
For now, though, the important part is having one central place for my Bash aliases.
It makes setting up a new homelab server just a little bit easier — and saves me from constantly asking myself:
]]>“What was that alias I made six months ago?”
DNS is one of those services you rarely think about—until it stops working. When your DNS server becomes unavailable, every device on your network suddenly struggles to find websites, services, and even other local machines.
In this guide, we’ll transform a single Technitium DNS Server into a resilient, highly available DNS platform using two servers. By combining Technitium’s built-in cluster replication with Keepalived’s automatic failover, you’ll create a setup that continues serving DNS even if one server unexpectedly goes offline.
Running a single DNS server creates a single point of failure. Even if your server is extremely reliable, hardware failures, maintenance, updates, or power outages can leave your entire network without name resolution.
A high-availability deployment solves this problem by using two independent components working together.
The first is cluster replication, which keeps DNS zones synchronized between multiple Technitium servers. Every record you create or modify is automatically replicated so both servers always contain identical DNS data.
The second is automatic failover using a floating Virtual IP (VIP). Instead of clients knowing about two different DNS servers, every device simply points to one IP address. If the primary server becomes unavailable, the secondary automatically assumes ownership of that IP address and continues answering DNS requests without requiring any client changes.
Neither feature is sufficient on its own. Replication ensures both servers contain the same information, while failover ensures clients always reach a healthy server.
The process begins by configuring one server as the primary cluster member.
Within the Technitium administration interface, create a new cluster and assign it a descriptive name. During this step, the server registers itself as the initial cluster node.
Next, move to your secondary DNS server and choose the option to join an existing cluster. You’ll provide the address of the primary server along with administrative credentials so the secondary can securely join.
Depending on your environment, you may temporarily allow self-signed certificates during the initial connection. Once both systems communicate successfully, the secondary server appears in the cluster management page, confirming that both nodes recognize each other and are ready to synchronize.
Before continuing, verify that both servers report a healthy status and can communicate without firewall restrictions.
With the cluster established, Technitium begins synchronizing DNS data between both nodes.
Whenever a DNS zone is created or modified on the primary server, the changes are automatically replicated to the secondary. This includes new host records, aliases, TXT records, MX records, and virtually every other zone modification.
It’s worth verifying that all of your important zones are participating in replication. If certain zones existed before clustering was configured, they may require a quick save or synchronization before becoming fully replicated.
A good practice is to make a small DNS change on the primary server and confirm that the same change appears on the secondary within a few moments.
Once replication is functioning correctly, both servers are capable of providing identical DNS responses.
Although replication keeps the DNS data synchronized, clients still need a single destination for their DNS requests.
This is where Keepalived enters the picture.
Keepalived uses the Virtual Router Redundancy Protocol (VRRP) to create a floating Virtual IP address shared between both DNS servers. At any given time, one server owns the VIP while the other remains on standby.
Every client, router, DHCP server, and network device simply uses this Virtual IP as its DNS server.
If the primary node becomes unavailable because of maintenance, hardware failure, or a system crash, Keepalived automatically transfers ownership of the Virtual IP to the secondary server. From the perspective of your clients, nothing changes—they continue sending DNS requests to the exact same IP address.
Once the primary server returns online, it can either reclaim ownership of the Virtual IP or remain as the standby node, depending on your preferred failover behavior.
This entire process happens automatically and typically completes within only a few seconds.
High availability should never be considered complete until it has been tested.
Begin by confirming that clients successfully resolve DNS using the Virtual IP instead of either server’s individual address.
Next, simulate a failure by shutting down the primary DNS server or disconnecting it from the network. Within moments, the secondary server should assume ownership of the Virtual IP.
While the failover occurs, continue performing DNS lookups from another device. Name resolution should continue without interruption.
Finally, restore the primary server and verify that the cluster returns to its expected operating state while maintaining synchronized DNS data.
Testing these scenarios before relying on the cluster in production provides confidence that failover will work when it’s actually needed.
Combining Technitium’s clustering capabilities with Keepalived provides several advantages:
DNS is one of the foundational services every network depends on, yet it’s often overlooked until something goes wrong.
By deploying two Technitium DNS servers with cluster replication and automatic failover, you create a resilient infrastructure capable of surviving server outages with little to no impact on your users.
The initial setup requires only a bit more effort than a standalone installation, but the reward is a highly available DNS platform that quietly does its job—even when one of your servers doesn’t.
]]>Keeping servers updated is one of the most important tasks in any homelab or production environment. Linux distributions such as Ubuntu and Debian make this easy through Unattended Upgrades, automatically installing security and package updates without manual intervention.
The challenge is visibility. Updates may be happening in the background, but unless you’re actively checking logs, you might never know when a system has been patched, what was updated, or whether a reboot is required.
A simple solution is to integrate unattended upgrades with Discord notifications.
For homelab operators and system administrators, notifications provide immediate awareness of maintenance activity across your infrastructure.
Benefits include:
Instead of logging into each server and reviewing package logs, you receive updates in a dedicated channel where all infrastructure events can be tracked.
Discord webhooks provide a lightweight method for servers to post messages directly into a channel.
Once configured, a server can automatically send notifications whenever unattended upgrades complete. Typical notification details might include:
This creates a simple but effective audit trail for system maintenance.
There are several ways to trigger notifications:
A notification can be sent whenever package management completes successfully. This approach is easy to implement and ensures administrators receive frequent feedback about system activity.
A more refined method is to trigger notifications only when unattended upgrades have installed packages. This reduces noise and keeps alerts focused on meaningful changes.
Modern Linux systems use systemd to manage services. By linking notification tasks to the unattended-upgrades service, notifications can be delivered automatically after update operations finish.
This approach is reliable, clean, and aligns well with standard Linux service management practices.
While Discord webhooks work well, larger homelabs often benefit from a notification platform such as Apprise.
Apprise acts as a universal notification gateway, allowing a single script to send messages to multiple destinations without modification.
Supported services include:
This makes it easy to expand your alerting strategy as your environment grows.
For example, a notification that starts in Discord today could later be delivered simultaneously to email, mobile push notifications, and team collaboration tools without rewriting automation scripts.
Discord upgrade notifications are especially useful for environments running multiple self-hosted services such as:
Instead of manually checking each machine, you receive a centralized stream of maintenance events directly in your monitoring channel.
When implementing upgrade notifications, consider the following:
Automatic updates are only half of the equation. Knowing that updates have been successfully applied is equally important.
By connecting unattended upgrades to Discord, administrators gain immediate visibility into system maintenance without adding complexity. Whether you’re managing a single server or an entire homelab, upgrade notifications provide peace of mind and help ensure that critical security updates never go unnoticed.
As your infrastructure grows, solutions like Apprise can further enhance your notification workflow by delivering alerts across multiple platforms while maintaining a single automation process.
]]>If you’ve ever needed to send emails directly from a Linux server, script, monitoring system, or homelab service, S-nail is one of the most powerful command-line mail clients available. It is lightweight, highly configurable, and works well for everything from simple notifications to full-featured email workflows.
In this guide, we’ll cover the major components of an S-nail setup and explain what each part does, without focusing on the specific configuration syntax.
S-nail is a modern implementation of the classic Unix mail client. It allows users and applications to send and receive email directly from the command line.
Many administrators use it for:
Because it has built-in SMTP support, S-nail can send emails directly through your mail provider without requiring a local mail server.
S-nail reads its settings from a configuration file. This file defines how emails are sent, which account is used, security settings, and various user preferences.
Think of this file as the central location where all mail-related settings are stored.
One of the first things you’ll configure is your sender identity.
This includes:
These settings ensure that messages appear professional and are properly formatted for recipients.
Most modern email providers require outgoing mail to be sent through an SMTP server.
This section of the configuration defines:
Without this information, S-nail won’t know how to deliver messages to the outside world.
Email providers almost always require encrypted connections.
S-nail supports:
Using proper certificate validation is strongly recommended in production environments to protect against man-in-the-middle attacks.
Most SMTP servers require users to authenticate before sending mail.
Common authentication methods include:
For personal accounts such as Gmail or Microsoft 365, application-specific passwords are often required instead of your normal account password.
One of S-nail’s most useful features is support for multiple mail profiles.
For example, you can maintain separate accounts for:
This allows a single system to send messages from different identities depending on the task being performed.
Although many users only send mail with S-nail, it can also access mailboxes through IMAP.
This enables:
For users who prefer command-line workflows, this provides a complete email solution.
When things don’t work as expected, S-nail includes extensive debugging capabilities.
Troubleshooting usually focuses on:
Enabling verbose logging can quickly reveal where a connection attempt is failing.
A common mistake is storing mail passwords in plain text without proper protection.
Best practices include:
For servers and homelabs, creating a dedicated notification account is often the safest approach.
S-nail is frequently used in environments such as:
Send alerts from:
Automatically email backup results and status reports after scheduled jobs complete.
Receive reports whenever scheduled maintenance tasks succeed or fail.
Integrate email notifications into Docker containers, home servers, and self-hosted applications.
For most homelab users, the simplest and most reliable setup is:
This approach keeps monitoring messages separate from personal email while making troubleshooting much easier.
S-nail remains one of the most flexible command-line mail clients available for Linux. Whether you’re running a small homelab or managing production infrastructure, it provides a reliable way to send and receive email without the complexity of a full mail server.
Once configured correctly, S-nail becomes an excellent tool for automation, monitoring, reporting, and system administration tasks.
]]>Get it running in two commands. Install the package, then run dpkg-reconfigure to enable it. This sets up two systemd timers — one to refresh the package list daily, one to apply updates.
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
Edit /etc/apt/apt.conf.d/50unattended-upgrades to tune the behavior. By default it only touches security packages, which is the safest scope for any internet-facing box. The two options most worth considering are unused dependency cleanup and auto-reboots — if you enable the latter, schedule it during a low-traffic window.
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";
Tip: The safest default for any internet-facing server is security-only updates with auto-reboot disabled. You stay protected without unexpected downtime.
Always verify the config works before leaving it unattended. The dry-run flag runs the full logic without touching any packages.
sudo unattended-upgrade --dry-run --debug
Silent background updates are great until something breaks quietly. s-nail lets your server send email via Gmail SMTP. You’ll need a Gmail App Password — Google blocks regular passwords for CLI tools, so generate a dedicated one from your account security settings (requires 2FA). Then drop it into ~/.mailrc with one quirk: the @ in your address must be written as %40 inside the URL string.
set v15-compat
set from="Your Name <you@gmail.com>"
set mta=smtp://you%40gmail.com:apppassword@smtp.gmail.com:587
set smtp-use-starttls
The ~/.mailrc file holds your App Password in plain text — restrict it immediately. Then fire off a test message and look for 250 2.0.0 OK in the output to confirm the handshake worked.
chmod 600 ~/.mailrc
echo "test" | s-nail -v -s "Test" you@example.com
If you have older versions of Docker installed, remove them first to prevent conflicts:
Don’t worry if apt reports that none of these packages are installed — you can safely continue.
Update your package index and install the packages needed for apt to use a repository over HTTPS:
“ca-certificates curl gnupg”
Add the official Docker repository to your system’s source list:
“deb [arch=”$(dpkg –print-architecture)” signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian
“$(. /etc/os-release && echo “$VERSION_CODENAME”)” stable” | \
Update your package index again (so it picks up the new Docker repository), then install Docker, the CLI, and Docker Compose:
hello-world test image to confirm Docker is installed and the service is running:docker run hello-world
If successful, Docker will pull a small test image, run it, and print a “Hello from Docker!” message. You’re all set. ✅
sudoBy default, Docker commands require root privileges. To run Docker as your regular non-root user, add yourself to the docker group:
Create the docker group
Add your user to the group
Apply the changes
Log out and log back in
You can verify it works by running docker run hello-world without sudo.
How many browser tabs do you have open with tools like “base64 decode online”, “jwt decoder”, or “json formatter”? If you’re a developer or sysadmin, probably more than you’d like to admit.
IT-Tools solves that. It’s a self-hosted, open-source collection of 86+ developer utilities — all in one clean web interface, running entirely in your browser, with no data sent anywhere.
Token Generator, Hash Text (MD5/SHA-256/SHA-512), Bcrypt, UUID & ULID Generator, AES Encryption/Decryption, RSA Key Pair Generator, HMAC Generator, BIP39 Passphrase, Password Strength Analyser, PDF Signature Checker.
Base64 (string & file), Color (HEX/RGB/HSL), Case (camelCase/snake_case/kebab-case), Date-Time, Integer Base, YAML ↔ JSON ↔ TOML, XML ↔ JSON, Markdown to HTML, List Converter, Text to Binary/Unicode/NATO Alphabet.
JWT Parser, URL Encoder/Decoder & Parser, HTML Entities, Basic Auth Generator, OTP Code Generator, MIME Types reference, HTTP Status Codes reference, Meta Tag Generator, User Agent Parser, JSON Diff, Slugify String, HTML WYSIWYG Editor.
Docker Run → Compose Converter, Crontab Generator, Chmod Calculator, Regex Tester & Memo, JSON Viewer/Minifier/to CSV, SQL Prettify, YAML Viewer, XML Formatter, Git Memo, Random Port Generator.
The Docker Run → Compose converter alone is worth the deployment. Paste a
docker runcommand, get a cleancompose.ymlback instantly.
IPv4 Subnet Calculator, IPv4 Address Converter, IPv4 Range Expander, MAC Address Lookup & Generator, IPv6 ULA Generator.
QR Code Generator, WiFi QR Code Generator, SVG Placeholder Generator, Camera Recorder.
Lorem Ipsum Generator, Text Diff, Text Statistics, String Obfuscator, Emoji Picker, ASCII Art, Math Evaluator, Percentage Calculator, ETA Calculator, Temperature Converter, Chronometer.
Phone Parser & Formatter, IBAN Validator & Parser.
The official demo at it-tools.tech is publicly available — but self-hosting makes sense for a few reasons:
Privacy — Even though everything runs client-side, keeping it internal is the right call when handling sensitive values like API tokens, private keys, or JWTs.
Always available — No dependency on external uptime or internet access.
It’s 20 MB. There’s genuinely no reason not to.
| Property | Value |
|---|---|
| Image | corentinth/it-tools:latest |
| Image size | ~20 MB |
| Exposed port | 80 |
| Database | None |
| Volumes | None |
| Data sent externally | Nothing — 100% client-side |
| Source | github.com/CorentinTh/it-tools |
IT-Tools docker SetUp:
Links: It-Tools
Questions / idea? Open an issue on GitHub.
]]>If you’ve ever set up a monitoring stack and found yourself staring at a list of tools wondering “wait, why do I need all of these?” — you’re not alone. The Grafana ecosystem is powerful, but it can feel like a lot of moving parts at first glance.
This post breaks down each component, what it does, and why it exists in your stack.
Before diving in, here’s the mental model: data flows from your systems → through collectors → into storage → and finally into dashboards. Each tool owns one part of that pipeline.
Your Systems → [ Exporters / Agents ] → [ Storage ] → [ Grafana ]
Role: Visualization and dashboards
Grafana is the face of your observability stack — the UI you actually look at. It doesn’t collect or store any data itself; it connects to data sources (like Prometheus or Loki) and renders charts, graphs, alerts, and dashboards from whatever those sources return.
Think of Grafana as the display screen in a control room. All the real work happens behind the scenes; Grafana just makes it human-readable.
Key features:
Role: Collect and store time-series metrics
Prometheus is a pull-based metrics system. On a schedule, it scrapes HTTP endpoints (called /metrics) exposed by your services and stores the data as time-series values. It has its own query language called PromQL, which Grafana uses to pull data for your dashboards.
How it works:
/metrics endpointPrometheus answers questions like: “What was my CPU usage over the last 6 hours?” or “How many HTTP 500 errors per minute is my app throwing?”
Role: Expose host-level metrics (CPU, RAM, disk, network)
Prometheus can only scrape what is exposed to it. Node Exporter is a small agent you run on each Linux machine that reads system-level stats from the kernel and exposes them in Prometheus format.
Without Node Exporter, Prometheus knows nothing about the machine it’s running on. With it, you get rich hardware and OS metrics automatically.
What it exposes:
One per host. Run one Node Exporter instance on each Linux machine you want to monitor.
Role: Collect and store logs
Loki is Prometheus, but for logs. It stores log lines indexed by labels (not full-text), which makes it lightweight and cost-effective compared to alternatives like Elasticsearch. Grafana queries Loki using LogQL, a language very similar to PromQL.
The key design philosophy: Loki doesn’t index the content of your logs — only the metadata (labels like app, host, env). This keeps storage costs low while still making logs searchable.
Loki answers questions like: “Show me all error logs from the payment-service in the last 30 minutes.”
Role: Gather metrics, logs, and traces — and ship them to the right backends
Alloy is Grafana’s modern, unified collector agent. It replaces Promtail (and partially replaces other agents) with a single, composable pipeline tool. You define components that connect to sources, transform data, and forward it to destinations.
Alloy can:
It uses a configuration language called River (Alloy syntax), which makes complex pipelines readable and maintainable.
New stacks should use Alloy. It’s actively developed and the strategic direction for the Grafana agent ecosystem.
Role: Gather logs from files/systemd and send to Loki
Promtail is the older, simpler agent specifically designed to ship logs to Loki. It watches log files (or systemd journal) and forwards new lines to Loki with labels attached.
It works well and is stable, but it’s single-purpose — it only ships logs. Alloy can do everything Promtail does, plus much more.
When to use Promtail: If you’re maintaining an existing setup that already uses it, there’s no urgent need to migrate. For new deployments, prefer Alloy.
| Promtail | Alloy | |
|---|---|---|
| Ships logs to Loki | ✅ | ✅ |
| Scrapes Prometheus metrics | ❌ | ✅ |
| Collects traces | ❌ | ✅ |
| Actively developed | ⚠️ Maintenance mode | ✅ |
Role: Expose resource usage metrics for Docker containers
Node Exporter tells you about the host machine. cAdvisor tells you about the containers running on it. It monitors Docker containers in real time and exposes per-container CPU, memory, network, and disk metrics in Prometheus format.
What cAdvisor exposes:
Works alongside Node Exporter, not instead of it. You typically run both on any host running Docker containers.
Here’s the complete picture of a typical stack:
┌─────────────────────────────────────────────┐
│ Grafana │ ← You look at this
│ (Dashboards & Alerts) │
└──────────────┬──────────────────────────────┘
│ queries
┌───────┴───────┐
│ │
Prometheus Loki
(metrics DB) (log DB)
│ │
│ scrapes receives logs
│ │
┌────┴────┐ ┌────┴────┐
│ Node │ │ Alloy │
│Exporter │ │(or │
│cAdvisor │ │Promtail)│
└─────────┘ └─────────┘
Host & container Log shipper
metrics
| Tool | Type | Role | Ships Data To |
|---|---|---|---|
| Grafana | Visualization | Dashboards and alerts | — |
| Prometheus | Database | Stores time-series metrics | Grafana |
| Node Exporter | Exporter | Linux host metrics | Prometheus |
| Loki | Database | Stores logs | Grafana |
| Alloy | Agent | Collects & ships metrics/logs/traces | Prometheus, Loki, Tempo |
| Promtail | Agent (legacy) | Ships logs | Loki |
| cAdvisor | Exporter | Docker container metrics | Prometheus |
Each tool in the Grafana stack has a focused, well-defined job:
Once you understand what each piece owns, the stack stops feeling complicated and starts feeling elegant — every component does exactly one thing, and they all plug together cleanly.
Grafana on docker:
Links: Grafana
Questions / idea? Open an issue on GitHub.
]]>