firstfinger

Why the OS Never Lets Your Process Touch Real Memory

2026-05-29T00:00:00Z

A while back I was staring at htop on one of our production servers. A handful of Node.js workers, a couple of Go services, the usual stack. The VIRT column was showing numbers that did not add up. One process alone was showing 18 GB of virtual memory. The machine had 16 GB of RAM. My first thought was that something was seriously wrong.

Nothing was wrong. The OS was doing exactly what it was designed to do. But that moment stuck with me because I realised I had been operating Linux systems for years without being able to explain what was actually happening when a process touched memory. I knew the terms: virtual memory, page table, MMU. I just could not connect them into a coherent picture.

This article is that picture. We will start from the raw problem, work our way through what paging is and why it exists, and then look at how the kernel and CPU work together on every single memory access. At the end there is a section on what this means when you are actually running production systems.

The Problem With Raw Physical Memory

Physical RAM is a flat array of bytes. If you have 16 GB of RAM, you have roughly 17 billion individually addressable bytes, each with a unique address. No structure, no ownership, just bytes sitting in silicon.

Now imagine running three processes simultaneously. Process A writes some data to address 0x100000. A moment later Process B also writes to 0x100000. Process A’s data is overwritten. There is no concept of ownership in raw physical memory. The address space is shared among everyone. Any process can write anywhere.

Early computing dealt with this. MS-DOS was largely single-tasking precisely because real-mode x86 had no hardware enforcement of memory boundaries. Running multiple programs at once was a recipe for instability. The moment you want a proper multitasking OS with a shell, a database, a web server all running concurrently, raw physical addressing is fundamentally broken.

Something had to change at the architecture level.

Virtual Memory

The solution the kernel offers is to give every process a private view of memory that does not correspond to physical addresses. This is virtual memory .

Every process on a 64-bit Linux system believes it has the entire address space to itself. In practice, x86-64 hardware uses 48 bits of the address (the full 64-bit space is impractically large, 2^64 bytes is more than a million times the world’s total storage capacity). That gives 2^48 = 256 TB split between user space (lower 128 TB) and kernel space (upper 128 TB). Your process sees addresses from 0x0000000000000000 to 0x00007FFFFFFFFFFF as its own private real estate.

These addresses are not real. They are virtual. When your code reads from 0x7fff1234abcd, the CPU translates that virtual address to a physical one before touching RAM. Your process never knows where in physical memory its data actually lives, and it never knows other processes exist from a memory standpoint.

Both processes use virtual address 0x1000 but they map to completely different physical frames. Isolation is enforced at the hardware level before anything reaches RAM.

What is Paging?

To understand how virtual-to-physical translation works, you need paging. Everything else builds on top of it.

Paging divides both virtual memory and physical memory into fixed-size chunks.

On Linux the standard page size is 4 KB (4096 bytes). Virtual memory is divided into virtual pages. Physical memory is divided into physical frames (also called page frames). A virtual page maps to exactly one physical frame. The kernel maintains the table of these mappings.

A few things fall directly out of this design:

The kernel tracks memory page by page, not byte by byte. If your process allocates 1 byte, you get a full 4 KB page assigned. This is why RSS in ps or htop is always a multiple of 4096 bytes.

Not every virtual page needs to be in RAM at the same time. A virtual page can be in RAM, swapped to disk, or not yet backed by any physical memory at all. The page table entry for that page records its current state. This is how swap works, and it is how the kernel can satisfy a large malloc() without immediately allocating physical frames (lazy allocation).

Each page has permission bits. Read, write, execute, user/supervisor. If your process tries to write to a read-only page (like a shared library’s code segment), the CPU fires an exception. The kernel catches it and sends SIGSEGV. This hardware enforcement of permissions is what makes memory protection possible, and it falls out naturally from paging without any extra software overhead.

The data structure that stores all the mappings (virtual page to physical frame, plus state and permissions) is called the page table. Every process has its own. The kernel creates it and keeps it updated. The CPU uses it on every memory access.

How Linux Builds the Page Table

The naive approach: a flat array indexed by virtual page number. For a 48-bit address space with 4 KB pages you need 2^36 entries. At 8 bytes each that is 512 GB per process just for the page table. Not viable.

Linux uses a multi-level page table . Instead of one flat array, it is a tree. Only the parts of the address space that are actually in use get table nodes allocated. A sparse process (most of the 128 TB virtual space unused) has a very small page table. Only the live regions exist as allocated nodes.

On x86-64 Linux, there are four levels. A 48-bit virtual address is split into five fields:

Bits | Level | Name | Entries
---------|--------|---------------------------------|--------
[47:39] | L4 | PGD - Page Global Directory | 512
[38:30] | L3 | PUD - Page Upper Directory | 512
[29:21] | L2 | PMD - Page Middle Directory | 512
[20:12] | L1 | PTE - Page Table Entry | 512
[11:0] | Offset | Byte offset within the page | 4096

9 bits per level, 512 entries per table. Each table node is exactly 4 KB, which is exactly one page, convenient for the kernel’s own allocator. Four levels of 512 each covers 2^36 pages, which maps the full 48-bit space.

To resolve any virtual address, you walk the tree from root to leaf:

Each entry in PGD, PUD, PMD points to the physical address of the next level table. The leaf PTE entry holds the physical frame address plus a set of flags:

Present: page is in RAM right now
Writable: writes allowed
User: user-mode code can access (kernel pages have this cleared)
Dirty: page has been written since last load (used by kernel to decide if it needs to be written back to disk on eviction)
Accessed: page has been read or written recently (used by eviction heuristics)
NX (No-Execute): instruction fetches from this page are blocked (enforces W^X on data pages)

The CPU’s Role in MMU and CR3 Translation

Here is where most articles hand-wave: “the OS translates addresses.” That is not quite right. The OS creates and maintains the page tables. The actual translation on every single memory access is done by the CPU in hardware.

The CPU has a dedicated unit called the Memory Management Unit (MMU). It intercepts every memory reference before it hits the memory bus and runs the translation. This includes instruction fetches, data loads, data stores, everything. There is no bypassing it once virtual addressing is enabled.

The CPU knows which page table to use via a register called CR3. CR3 holds the physical address of the current process’s PGD table. When a memory access happens, the MMU reads CR3 and starts the four-level walk through physical memory.

The walk takes four memory reads, one per level. That is expensive to do on every access. So the CPU caches recent translations in a small, fast on-chip cache called the TLB (Translation Lookaside Buffer). Most accesses hit the TLB and translate in roughly one cycle. A TLB miss falls back to the full hardware page table walk.

Page Faults

If the MMU walks the page table and hits a PTE with the present bit cleared, it fires a page fault exception. Control transfers to the kernel’s page fault handler. The handler checks why the page is not present:

Page is in swap: read it from disk, update PTE present bit, resume the process
Page was never allocated: allocate a fresh frame, zero it out, update PTE, resume
Access is genuinely illegal: wrong permissions, out of mapped range. Kernel sends SIGSEGV.

In the first two cases the process resumes as if nothing happened. It has no idea a disk read occurred. From its perspective the memory was always there.

Context Switching and CR3

When the kernel switches the CPU from process A to process B, it needs to switch the entire address space. It does this by writing process B’s PGD address into CR3.

On older hardware every context switch triggered a full TLB flush. Every cached translation from process A was invalidated because the entries had no process tag. Process B started with a cold TLB, paying the page table walk cost on its first accesses.

Modern x86 CPUs support PCID (Process-Context Identifiers), a 12-bit tag on each TLB entry. When the kernel restores CR3 for process B, it can keep valid entries from other processes in the TLB and simply start tagging new entries with B’s PCID. Returning to process A later can reuse its still-valid TLB entries.

KPTI (Kernel Page Table Isolation), introduced as the Meltdown mitigation in early 2018, added cost here. With KPTI, user space and kernel space use separate page tables, requiring a CR3 switch on every syscall entry and exit. Every read(), every write(), every epoll_wait() crosses a CR3 boundary twice. This is why Meltdown patches had measurable throughput impact on syscall-heavy workloads.

What This Architecture Unlocks ?

Swap

When physical RAM is under pressure, the kernel can evict a page by writing it to the swap partition and clearing its PTE present bit. The next access to that virtual address fires a page fault, the kernel reads the page back from disk, sets the present bit again, and resumes. The process never knew. This is how Linux can run more total allocated memory than you have physical RAM, at the cost of latency when cold pages are fetched.

Copy-on-Write

When you call fork(), the kernel does not copy all the parent’s memory. That would be prohibitively expensive for a process with several gigabytes of RSS. Instead, both parent and child get page tables pointing to the same physical frames. All those shared PTEs are marked read-only. When either process writes to a page, the MMU fires a fault (write to a read-only page). The kernel catches it, copies that specific 4 KB page for the writing process, marks the copy writable, updates the PTE, and resumes. Only the pages that actually diverge ever get copied.

This is copy-on-write. Most forked processes immediately call exec(). With COW, fork() overhead is proportional to page table size, not RSS. This matters enormously for shell scripts spawning hundreds of subprocesses.

The same mechanism serves shared libraries. libc is mapped into one set of physical frames. Every process that links against it has its PTEs for the libc region pointing to those same frames. Code pages are read-only so COW never fires. One copy in RAM serves all running processes.

Memory Protection

PTE supervisor bits mean user-mode code cannot access kernel memory pages. Attempting a read from a kernel address from userspace fires a page fault, the kernel sees the illegal access, and sends SIGSEGV to the process. No software check is involved. The MMU enforces it on every single access.

What This Means When You Operate Linux Systems

Virtual Size vs RSS vs PSS

That 18 GB VIRT I saw in htop was not a memory leak. VIRT (VSZ) is the size of the virtual address space mapped by the process, including regions that have no physical backing yet: mmapped files, reserved stack space, shared library address ranges. Most of it was not in RAM.

RSS is the count of pages currently resident in physical RAM. That is what matters for memory pressure. PSS (Proportional Set Size) is even more accurate because it divides shared pages proportionally among all processes that map them.

# VSZ vs RSS
ps -o pid,vsz,rss,comm -p <pid>

# PSS is the honest number for shared-memory-heavy processes
cat /proc/<pid>/smaps_rollup | grep Pss

# Per-mapping breakdown
cat /proc/<pid>/smaps

Memory Overcommit

Linux allows processes to commit more virtual memory than RAM plus swap can back. malloc() succeeds immediately because physical frames are only assigned when pages are actually written. This is controlled by vm.overcommit_memory:

# 0 = heuristic (default): allows overcommit up to a point
# 1 = always allow: malloc never returns NULL regardless of RAM state
# 2 = strict: total commit bounded by swap + overcommit_ratio percent of RAM
cat /proc/sys/vm/overcommit_memory

# For databases and critical services where OOM kill is worse than allocation failure
echo 2 > /proc/sys/vm/overcommit_memory
sysctl vm.overcommit_ratio=80 # allow committing up to 80% of RAM + all swap

OOM Killer

When physical RAM is exhausted and swap is full, the kernel’s OOM killer fires. It scores all processes based on memory usage plus heuristics and kills the highest scorer. You can influence the scoring:

# Protect a critical process (range is -1000 to 1000)
echo -1000 > /proc/<pid>/oom_score_adj

# Make a process the preferred OOM target
echo 1000 > /proc/<pid>/oom_score_adj

# Check current calculated score
cat /proc/<pid>/oom_score

# Watch for OOM kill events
dmesg -T | grep -i "oom\|killed process"

If your service is getting OOM killed on a machine that still shows free VIRT, check RSS and PSS. Also check if another process is the actual memory hog and your service is just collateral damage based on oom_score.

Huge Pages and TLB Pressure

Default page size is 4 KB. A process with 10 GB RSS has around 2.5 million resident pages, each potentially needing a TLB entry. Modern CPUs have L1 TLBs of a few hundred entries and L2 TLBs of a few thousand. With a large working set you will miss the TLB constantly, paying the full four-level page table walk cost on every miss.

Huge pages (2 MB) cover 512x more memory per TLB entry. For workloads with a large, frequently accessed working set, this can meaningfully reduce latency.

# Check THP (Transparent Huge Pages) status
cat /sys/kernel/mm/transparent_hugepage/enabled

# Disable THP for latency-sensitive services
# Redis and Kafka both recommend this - THP defragmentation causes latency spikes
echo never > /sys/kernel/mm/transparent_hugepage/enabled

# Reserve explicit 2 MB huge pages upfront (avoids defragmentation cost)
echo 512 > /proc/sys/vm/nr_hugepages

# Check allocation
grep -i huge /proc/meminfo

# Measure TLB pressure with perf
perf stat -e dTLB-load-misses,iTLB-load-misses,dTLB-loads -p <pid> sleep 10

THP allocates huge pages transparently but needs to find 512 contiguous 4 KB frames to form a 2 MB huge page. On a fragmented system this triggers memory compaction, which can stall allocation for tens of milliseconds. Redis latency spikes of 50-200ms on high-memory systems are commonly traced back to THP compaction. Disable it and pre-reserve explicit huge pages if the workload justifies it.

Reading /proc/meminfo Correctly

MemTotal: 65536000 kB # total physical RAM
MemFree: 2345000 kB # completely unused frames
MemAvailable: 40123000 kB # what processes can actually use
 # = MemFree + reclaimable cache
Cached: 28000000 kB # page cache (file data, reclaimable)
SwapTotal: 8388608 kB
SwapUsed: 512000 kB # non-zero = you have memory pressure
AnonPages: 18000000 kB # anonymous pages (heap, stack, mmap'd)
Mapped: 3200000 kB # pages mapped into at least one process
HugePages_Total: 512 # pre-reserved 2 MB huge pages
HugePages_Free: 312 # available huge pages

Alert on MemAvailable going low, not MemFree. MemFree being low just means the kernel has filled the page cache with file data, which is expected and fine. MemAvailable being low means processes are competing for physical frames.

Containers and cgroups v2

Containers do not change the virtual memory model. Each container process has its own virtual address space and its own page table, exactly like any other process. What cgroups v2 adds is a hard cap on the number of physical frames that group of processes can have resident:

# Set memory limit for a cgroup
echo "512M" > /sys/fs/cgroup/myservice/memory.max

# Current physical memory used by the cgroup
cat /sys/fs/cgroup/myservice/memory.current

# Swap limit (cgroups v2 tracks them separately)
echo "256M" > /sys/fs/cgroup/myservice/memory.swap.max

When a container hits memory.max, the kernel tries to reclaim pages from that cgroup first (evict page cache, swap anonymous pages) before firing an OOM kill scoped to that cgroup. The virtual address space of processes inside the container is still technically unlimited unless you set RLIMIT_AS explicitly.

Virtual memory is one of those abstractions that is completely invisible when things are working. Your process gets its pages, the kernel handles swapping, shared libraries load once for everyone, and the MMU does its four-level page table walk on every single instruction fetch and every data access, thousands of times per millisecond, without you ever thinking about it.

When it breaks down, knowing what is actually happening at the page table level gives you something most runbooks do not: an understanding of why, not just what command to run. OOM kills on a machine still showing high VIRT, latency spikes from THP compaction, throughput degradation after Meltdown patches, TLB pressure in a database under load. All of these trace back to the mechanics covered here.

Further reading

What Every Programmer Should Know About Memory.pdf912 KB

The kernel never lets your process touch real memory because the one time it did, nothing worked reliably. The private address space it hands every process is one of the best design decisions in operating systems history.

Leaving Ghost for a Static Site

2026-05-28T00:00:00Z

I write maybe two posts a month, and the writing itself was never the problem. Everything around it was.

My blog ran on Ghost , and Ghost is a real application. It needs a Node.js server, a MySQL database, and a few background services, all running in Docker on a small server I rented. Keeping it running took steady attention: database backups, version updates, and the occasional “why is the site slow today.” I was doing infrastructure work for a blog I posted to twice a month, and at some point I realized I was spending more time maintaining it than writing on it.

So I took it all down and rebuilt the blog as a plain static site. No database, no server to babysit, nothing running in the background. This is the story of why, and how I did it, including the migration tool I wrote and the way I publish posts now.

first, some credit

I don’t want this to read as a Ghost hit piece. When I moved over from WordPress in 2023, I genuinely liked Ghost. The editor was clean, setup was simple, and it stayed out of the way when I wanted to write. After years of WordPress plugins, that felt much lighter. I even sent them a small donation early on, because I wanted the project to do well.

Ghost is a good product. It just turned out to be a good product for a problem I don’t have.

the problem it solves isn’t mine

Ghost is built around paid newsletters and memberships. Subscriptions, paid tiers, email to your audience. That is where the product puts its energy, and it is genuinely good at it.

I never used any of that. No paid subscribers, no newsletter. I write posts and put them on the internet for free. So every feature built for the membership business was something I ran and maintained without ever touching.

And the stack kept growing. Over two years it got heavier instead of lighter: MySQL, the Node app, ActivityPub support, all wrapped in Docker. Every one of those makes sense if you run a newsletter business. None of it made sense for me. Ghost can also run on SQLite, which is a simple file-based database with no separate server, but officially that mode is meant for development, not production. So in practice I was running and backing up a full MySQL database for a personal blog.

running something for yourself vs for other people

There is a real difference between self-hosting something only you use and self-hosting something other people read. Once a few people are reading, a database hiccup or a bad night for the host is no longer something you can ignore. It is your site that is down, so you end up keeping an eye on it.

That is how the ratio went backwards. I was spending more attention on MySQL, backups, and keeping containers happy than on the posts themselves. That is a poor trade for any blog. For a personal one, it makes no sense.

i couldn’t write where i wanted

The other daily annoyance was writing on the move. Ghost had no app I trusted and no real way to draft from my phone when an idea showed up away from my desk. So I would write in Apple Notes or Notion wherever I was, then paste it into Ghost later when I was back at my machine. It worked, but it added a step to the one part that should be effortless.

the theming i never enjoyed

A smaller thing also wore on me. I never liked theming Ghost. WordPress, for all its faults, lets you build a template and shape the site however you like. Ghost is code-only: you either take a theme as it is or edit it by hand, and I never found that time worthwhile. I ran the Journal theme and mostly left it alone. But I like owning how my site looks, and Ghost never made that easy.

choosing what came next

For a while I thought about going back to WordPress. It is more polished than people give it credit for, and it is well optimized. But it is the same shape of problem with a different name: a database, a server, an admin panel, constant updates. That would not really solve anything.

So I made the real decision. No CMS at all. Not WordPress, not Ghost, not the next one. Just a static site: plain HTML files generated ahead of time and served as they are, with nothing running in the background.

The timing makes this easy. Hosting a static site in 2026 is basically free. Something that used to need a full-time person and a server room is now a setting you turn on. Cloudflare Pages, GitHub Pages , and others give you a global CDN, caching, and HTTPS at no cost for a site my size.

the stack

Here is what I settled on:

Hugo turns my markdown files into the finished HTML site. I looked at Eleventy (11ty) too, but I wanted a strong ready-made theme more than templating freedom, and Hugo had it. The look here is the Terminal theme by panr, with my own colour tweaks.
Cloudflare Pages builds the site and serves it from servers close to whoever is reading.
Cloudflare R2 stores the images. R2 is cheap, and more importantly it has no egress fees, which means you don’t get charged every time someone loads one of your images. That surprise cost is what S3-style storage is famous for, and R2 simply doesn’t have it.
Pagefind handles search. It builds a search index when the site is built and runs the search entirely in the reader’s browser, so there is full-text search with nothing running on a server.

the migration tool

The actual move took about three days. Day one was planning: what the content looked like coming out of Ghost, where each piece needed to land in Hugo, and how Cloudflare and R2 fit together. The other two days went into writing and testing a migration tool in Python, because I wanted this done properly and repeatably, not by hand.

I had around 150 posts and four years of writing, and two hard rules. Don’t lose any SEO, so every old URL had to keep working. And don’t break a single image. So I built the tool to be careful and to check its own work.

one post at a time, many posts at once

The tool is built as a pipeline. Each post flows through a fixed sequence of stages, and every stage does one small job. Posts don’t depend on each other, so the stages inside a single post run in order, but many posts run through the pipeline at the same time across a pool of workers (eight by default). One worker takes one post and carries it all the way through. That is why the whole migration finishes in about the time the slowest post takes, not the sum of all of them.

the layers

Here is the path each post takes, end to end:

flowchart TB
export[("Ghost JSON export<br/>~150 posts")]
subgraph worker["one worker, one post · eight running in parallel"]
direction TB
p1["Parse source"] --> p2["Metadata + slug"]
p2 --> p3["Body into blocks"]
p3 --> p4["Clean text + format"]
p4 --> p5["Re-host assets"]
p5 --> p6["Map cards to<br/>shortcodes"]
p6 --> p7["Assemble markdown"]
end
export --> p1
p7 --> gate{"Validate<br/>every stage"}
gate -->|pass| out["content/posts/<br/>slug/index.md"]
gate -->|fail| quar[["Quarantine<br/>+ reason"]]
p5 -.->|"sha256<br/>dedupe"| r2[("Cloudflare R2")]
out --> report["Report +<br/>resume state"]
quar --> report
report -.->|"re-run skips<br/>finished posts"| export

There are eleven stages in total. The main ones, in plain terms:

Parse the source. Ghost has changed editors over the years, so posts are stored in a few different internal formats. The first stage reads all of them and converts each post into one common structure the rest of the tool understands.
Pull out the metadata. Title, slug, dates, tags, authors, cover image, social tags. The slug is the URL, so this stage makes sure it matches the old one exactly. That is the “zero SEO loss” rule in action.
Break the body into blocks. Headings, paragraphs, lists, code, images, cards, each as its own typed piece, so later stages can handle them precisely.
Clean up the text. Strip invisible characters, fix non-breaking spaces, and catch mojibake (garbled characters left over from bad encoding) so none of it leaks into the new files.
Render the formatting. Bold, italics, links, properly nested lists, and code blocks preserved exactly, byte for byte. This is really a few stages doing one job: turning the structured blocks back into clean markdown.
Re-host every asset. This is the important one for “no broken images.” Every image, file, and video is downloaded from the old site, hashed, uploaded to R2 under a filename based on its contents, and its URL rewritten to point at R2. Because the filename is the hash of the contents, an image used by five posts is uploaded once and reused. After this stage, no link to the old Ghost domain is left.
Map Ghost’s special cards. Ghost has custom blocks (callouts, bookmarks, galleries, embeds, toggles, audio, video) that aren’t plain markdown. Each kind gets translated: some become plain markdown, and the interactive ones become Hugo shortcodes.
Assemble and write. Combine the metadata and body, write the final content/posts/<slug>/index.md, and confirm it is valid and Hugo can build it.

it checks its own work

This is the part I cared about most. Every stage has a validator. If a stage produces something wrong, the post is quarantined: it gets set aside, and the tool records exactly which stage failed and why, instead of writing a broken post and moving on. At the end of a run it produces a report: how many posts were in the export, how many were written, how many were quarantined, and a pass rate for every single layer.

The point was simple. I didn’t want to discover broken posts weeks later. A run isn’t “done” until the report shows zero quarantined posts, every layer at 100%, Hugo builds with no warnings, and a search for any leftover old-domain URLs comes back empty.

It is also resumable. Every finished post is recorded, so if the network drops halfway or one post fails, I fix it and re-run, and it only processes what’s left. The R2 uploads are safe to repeat too, because the content-based filenames mean re-uploading the same image does nothing.

where it actually got hard

The difficult parts were exactly where you’d guess. Ghost’s custom cards don’t map cleanly onto markdown, so each type needed its own translation rule. On top of that were the usual formatting edge cases and getting code blocks to survive exactly as written. Most of the testing time went into those odd cases, not the normal posts. The normal posts were never the problem.

I’ve open-sourced this tool: ghost2hugo . It started out tuned to my own content, but the shape of it, a layered pipeline that validates each step and re-hosts assets, carries over to anyone making the same move.

keeping every old url working

The thing that scares people most about leaving a CMS is breaking their own links. Years of posts, search rankings, and inbound links all point at URLs that are about to change. If the new site serves those same paths, nobody notices the move. If it doesn’t, you get a lot of 404s and your search traffic drops off.

So this was a hard requirement, not a nice-to-have. Two things made it work:

The post URLs didn’t change at all. Ghost served my posts at the top level, like /my-post-slug/. I set Hugo up to do exactly the same, so every old post link resolves to the same place on the new site. No redirect needed, because nothing actually moved.
The one path that did change gets a redirect. Ghost puts tags at /tag/<name>/; Hugo uses /tags/<name>/. That is the only structural difference, and a single 301 rule on Cloudflare Pages forwards the old shape to the new one.

That is the whole SEO story. Because the migration tool treats the slug as something to preserve exactly rather than regenerate, the new site is URL-for-URL compatible with the old one, and the move was invisible to anyone reading or linking to it.

how i publish now

With the old blog gone, I needed a way to actually publish. The site is just markdown files in a Git repository, so in the simplest case publishing a post is one move: write the markdown, commit, push. I can do that from VS Code, from the terminal, from any editor, on any machine. No login, no admin panel.

Before I settled on that, I did look at whether some existing tool could smooth it out. There is a whole category of git-based CMSs now, editors that read and write your content straight in a GitHub repo, so you get a writing interface without giving up plain files. I tried a few of them.

None did exactly what I wanted, and each one came with something I hadn’t asked for: an account to sign into, a config schema to keep in sync, or yet another editing UI to learn. After two years of living inside Ghost’s admin panel, signing up for one more dashboard was the exact thing I was trying to get away from. So I dropped the idea of a CMS altogether and built my own small tool instead.

It is an Obsidian plugin I call Smithy, and I kept its job deliberately tiny. It does three things, and nothing else:

Publish over git. It pushes the finished post to the blog’s GitHub repo for me. It talks to GitHub through its API rather than shelling out to Git, so it behaves the same on my phone as on my laptop.
Auto-upload assets. Any image in the post is uploaded to my S3-compatible storage (Cloudflare R2) on publish, and the links are rewritten to point at it. The same bucket the migration tool filled.
Keep the content in the repo. The markdown stays as plain files inside the GitHub repo. Nothing lives in a database or a hosted service I don’t own.

That is the entire plugin. I write a post as a normal Obsidian note, run one command, and those three things happen. It needs a GitHub token and my R2 keys entered once, and after that publishing is a single command. The remote-writing problem that pushed me off Ghost in the first place is simply gone: I can draft and publish from my phone if I feel like it.

Here is how the whole thing fits together once a post is ready to go out:

flowchart LR
subgraph author["write anywhere"]
direction TB
obs["Obsidian + Smithy"]
phone["iPhone + Smithy"]
code["VS Code / terminal"]
end
subgraph repo["GitHub repo"]
direction TB
md["Markdown + frontmatter"]
end
r2[("Cloudflare R2<br/>images & assets")]
subgraph cf["Cloudflare Pages"]
direction TB
build["Hugo build<br/>+ Pagefind index"] --> edge["CDN edge cache"]
end
reader(["reader"])
obs -->|"GitHub API"| md
phone -->|"GitHub API"| md
code -->|"git push"| md
obs -.->|"S3 API upload"| r2
phone -.->|"S3 API upload"| r2
md ==>|"on push, auto-build"| build
r2 --> edge
edge ==> reader

It’s here if you want to try it: Smithy .

Is any of this as instant as clicking “Publish” in a CMS? Not quite. There is a little friction. But for two or three posts a month it is nothing, and in return I get no servers, no database, no lock-in, and content that lives as plain files I will still be able to open years from now.

what changed, in practice

The honest summary is that there is no infrastructure left to run. The site is static files on Cloudflare’s edge, so uptime is their job, not mine. R2 holds the images for almost nothing. There is no server to patch, no database to back up, no security hardening, and nothing exposed to attack. The operations side of running a blog basically disappeared.

It is also just faster. Plain files on a CDN beat a Node app querying a database on every request. The site loads quicker than it ever did on Ghost, from more places.

what i gave up

A static site isn’t free of trade-offs, and it would be dishonest to pretend otherwise. Moving to one means giving up a few things a CMS hands you for free:

No built-in comments. A static page can’t run a comment system on its own. If you want one, you bolt on a third-party service. I don’t, so for me this was a feature to delete, but it is a real loss if a comment section matters to you.
No dynamic anything. No server means no forms, no member logins, no per-visitor pages, no newsletter or paid membership built in. Every reader gets the same files. For me that is the whole point; for a different blog it would be a dealbreaker.
No writing in the browser. Ghost let me open a tab and write from anywhere. Now I write in an editor and publish through Smithy or a git commit. That is friction I chose on purpose, but it is still friction.
Search ships with the page. Pagefind builds the search index at build time, so it grows with the site and the reader downloads part of it to search. At my size that is nothing. A site with tens of thousands of pages would have to think harder about it.

None of these were hard to give up for a personal blog. But they are exactly why “just go static” is the right call for me and the wrong one for plenty of other people.

the part i keep relearning

This is the lesson I keep coming back to as someone who does infrastructure for a living. Keep it simple, and don’t take on complexity just because you can handle it. I could run the Ghost stack. I did, for two years. Being able to manage something is not a reason to. For a personal blog, the right amount of infrastructure turned out to be almost none.

One last honest note. Blogs aren’t what they were. As AI gets better at answering the questions people used to type into a search box, fewer of them end up on posts like this one, and I expect my traffic to keep drifting down. That is fine. I’m not writing for the traffic. I write this for myself, as a place to keep the things I work out so I don’t have to work them out again, and as a kind of memory. If you got here and something helped, even better.

If you want to see what else I’m building, my projects are on GitHub , and my DMs are open. Say hi.

Running Hermes Agent on Your Own Box

2026-05-28T00:00:00Z

Self-hosted AI agent on Linux. Talks to you on Telegram, runs commands, manages servers, connects to tools via MCP. This is the fast path. Run the blocks top to bottom. Replace youruser with your Linux username everywhere.

Hermes is the agent. You plug a model into it (OpenAI, Gemini, local endpoint). Keep that straight.

1. Install

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
source ~/.bashrc
which hermes

Note the path (usually ~/.local/bin/hermes). You need it for the service.

2. Setup wizard

hermes setup

Pick your model provider and API key. Terminal: local. Skip TTS.

3. Telegram bot

In Telegram: message @BotFather, /newbot, copy the token. Message @userinfobot, copy your numeric ID.

cat >> ~/.hermes/.env <<'EOF'
TELEGRAM_BOT_TOKEN=your_bot_token
TELEGRAM_ALLOWED_USERS=your_numeric_id
TELEGRAM_HOME_CHANNEL=your_numeric_id
EOF

4. Run as a system service

sudo $(which hermes) gateway install --system --run-as-user youruser
sudo $(which hermes) gateway start --system
sudo systemctl status hermes-gateway

Message your bot “hi” on Telegram. It should reply.

5. Voice (Groq STT)

Key from console.groq.com.

cat >> ~/.hermes/.env <<'EOF'
GROQ_API_KEY=your_groq_key
STT_GROQ_MODEL=whisper-large-v3-turbo
EOF
hermes config set stt.provider groq
sudo systemctl restart hermes-gateway

6. Web search (Tavily)

Free key from app.tavily.com.

echo 'TAVILY_API_KEY=your_tavily_key' >> ~/.hermes/.env
sudo systemctl restart hermes-gateway

7. GitHub

sudo apt update && sudo apt install -y curl
curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg
sudo chmod go+r /usr/share/keyrings/githubcli-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null
sudo apt update && sudo apt install -y gh
gh auth login

Pick GitHub.com, HTTPS, browser login. Open github.com/login/device, paste the code. Then:

echo "GITHUB_TOKEN=$(gh auth token)" >> ~/.hermes/.env
sudo systemctl restart hermes-gateway

8. Persona (SOUL.md)

cat > ~/.hermes/SOUL.md <<'EOF'
# Identity
You are a pragmatic senior engineer. Talk to me as a technical peer.

# Style
- Lead with the answer or command. No preamble.
- Terse by default. Code first, short explanation after.
- No em-dashes. No emojis. Plain, direct language.
- Say when something is a bad idea and give the better option.
- State uncertainty instead of guessing. Verify with tools.

# Defaults
- On ambiguity, assume the reasonable thing, state it, proceed.
- Multi-step work: brief plan, then execute end to end.
EOF
sudo systemctl restart hermes-gateway

9. Fallback model (Gemini)

Free key from aistudio.google.com.

echo 'GOOGLE_API_KEY=your_aistudio_key' >> ~/.hermes/.env
hermes fallback add

Pick Gemini, API key, gemini-2.5-flash. Check: hermes fallback list.

10. MCP servers

cat >> ~/.hermes/.env <<'EOF'
CONTEXT7_API_KEY=your_context7_key
N8N_MCP_TOKEN=your_n8n_token
EOF
nano ~/.hermes/config.yaml

Add under mcp_servers: (2-space indent, spaces only):

mcp_servers:
 github:
 command: "npx"
 args: ["-y", "@modelcontextprotocol/server-github"]
 env:
 GITHUB_PERSONAL_ACCESS_TOKEN: "${GITHUB_TOKEN}"

 context7:
 url: "https://mcp.context7.com/mcp"
 headers:
 Authorization: "Bearer ${CONTEXT7_API_KEY}"

 n8n:
 url: "https://your-n8n-domain/mcp-server/http"
 headers:
 Authorization: "Bearer ${N8N_MCP_TOKEN}"

Validate and restart:

python3 -c "import yaml; yaml.safe_load(open('$HOME/.hermes/config.yaml'))" && echo valid
sudo systemctl restart hermes-gateway
hermes mcp list
hermes mcp test github

Servers with url: are HTTP. Servers with command: are spawned by Hermes. Use what the server documents.

11. Fix the auto-update password problem

hermes update restarts the service, which needs passwordless sudo. Without this it prompts for a password and the nightly cron breaks. Check your systemctl path first:

which systemctl

Use that exact path in the rule. If it says /usr/bin/systemctl but your rule says /bin/systemctl, sudo ignores it and asks for a password. This is the most common mistake.

sudo tee /etc/sudoers.d/hermes-gateway > /dev/null <<'EOF'
youruser ALL=(root) NOPASSWD: /usr/bin/systemctl restart hermes-gateway, /usr/bin/systemctl start hermes-gateway, /usr/bin/systemctl stop hermes-gateway, /usr/bin/systemctl reset-failed hermes-gateway, /usr/bin/systemctl is-active hermes-gateway, /usr/bin/systemctl status hermes-gateway
EOF
sudo chmod 440 /etc/sudoers.d/hermes-gateway
sudo visudo -c

Test, should NOT ask for a password:

sudo systemctl restart hermes-gateway
hermes update

12. Nightly auto-update cron

sudo apt install -y cron
sudo systemctl enable --now cron
sudo timedatectl set-timezone Your/Timezone
crontab -e

Add this line (runs 3:30 AM):

30 3 * * * $HOME/.local/bin/hermes update --check >/dev/null 2>&1 && $HOME/.local/bin/hermes update >> $HOME/.hermes/logs/auto-update.log 2>&1; sleep 30; /usr/bin/systemctl is-active hermes-gateway >> $HOME/.hermes/logs/auto-update.log 2>&1

13. Validate

sudo systemctl is-active hermes-gateway
hermes -z "say hi in 3 words"
hermes mcp list
hermes doctor

From Telegram: send text, send a voice note, ask “list files in /tmp”, ask “list my GitHub issues”. If all work, done.

Notes

Lock TELEGRAM_ALLOWED_USERS to just your ID. Anyone on that list can run commands through the agent.

Use a dedicated Linux user and a dedicated VM. The agent gets shell access, treat the box as disposable.

For zero approval prompts on a trusted box, set in config.yaml:

approvals:
 mode: auto
 cron_mode: allow

This lets the agent run anything without asking. Right for a single-user locked-down VM, wrong if others can reach the bot.

Manage the service

sudo systemctl restart hermes-gateway
sudo systemctl status hermes-gateway
sudo journalctl -u hermes-gateway -f

That is the whole setup. The real value comes after: tell the agent to save useful multi-step solutions as skills, and tell it facts about your environment so it learns you over time.

Fixing xterm-ghostty: unknown terminal type Over SSH

2026-05-27T13:10:00Z

If you use Ghostty as your terminal on macOS and SSH into remote Linux servers, you’ve probably seen this:

root@server:~# clear
'xterm-ghostty': unknown terminal type.

Or this:

missing or unsuitable terminal: xterm-ghostty

This happens to everyone who uses Ghostty with remote servers. Here’s why it happens and how to fix it properly.

Why this happens

Ghostty ships with its own terminfo entry called xterm-ghostty. When you open a terminal, Ghostty sets TERM=xterm-ghostty in your local shell. When you SSH into a remote server, that TERM value gets forwarded. The remote server then looks up xterm-ghostty in its terminfo database — and finds nothing, because xterm-ghostty is not in any standard Linux distribution yet.

Commands like clear, vim, tmux, and htop all rely on terminfo to know how to talk to your terminal. No terminfo entry means broken output.

The trap: `ssh-terminfo` makes it worse

Ghostty has a built-in feature called ssh-terminfo that tries to automatically install the xterm-ghostty terminfo on remote hosts before connecting. On paper this sounds like the right fix. In practice it causes a worse problem.

The feature wraps your ssh command as a shell function. Every time you SSH, it tries to run tic on the remote host to install the terminfo. For servers behind a ProxyJump, air-gapped servers, or servers with restricted environments, the install process partially succeeds — returns exit 0 — but the terminfo is not actually usable. The function then assumes success and sets TERM=xterm-ghostty for the session anyway. You land on the server with a broken terminal.

Worse, this shell function override happens after your ~/.ssh/config is read, so any SetEnv TERM=xterm-256color you put there gets silently overridden.

This is the config that enables the broken behavior:

shell-integration-features = ssh-env,ssh-terminfo

The actual fix

There are two parts. Fix them both.

1. Disable ssh-terminfo in Ghostty config

Find your Ghostty config file. On macOS it is usually at:

~/Library/Application Support/com.mitchellh.ghostty/config

Change your shell-integration-features line to remove ssh-env and ssh-terminfo:

shell-integration-features = cursor,title,path

Reload the config with Cmd+Shift+, or fully quit and reopen Ghostty.

Verify the ssh shell function is no longer overriding TERM:

echo $GHOSTTY_SHELL_FEATURES
# should not contain ssh-env or ssh-terminfo

2. Set TERM globally in ~/.ssh/config

Add SetEnv TERM=xterm-256color to your global Host * block. This tells the remote server to use xterm-256color, which has been in every Linux terminfo database for over 20 years.

One important rule: Host * must be at the bottom of your ~/.ssh/config. SSH reads the file top to bottom and the first match wins for each option. If Host * is at the top, it overrides all your specific host blocks.

# specific hosts first
Host myserver
 HostName 10.0.0.1
 User deploy

# global defaults last
Host *
 User root
 StrictHostKeyChecking no
 UserKnownHostsFile /dev/null
 SetEnv TERM=xterm-256color

After both changes, SSH into any server and run clear — it works.

Why not just push terminfo to every server?

The official Ghostty docs suggest running this on each remote host:

infocmp -x xterm-ghostty | ssh user@server -- tic -x -

This works for servers you own and access regularly. It is not practical if you manage dozens or hundreds of servers, have air-gapped hosts with no outbound connectivity, or SSH into servers you do not control.

The xterm-256color approach trades a small amount of Ghostty-specific terminal features for universal compatibility. In practice you keep full 256 color support, all standard cursor sequences, and everything TUI apps need. The only things you lose are a few Ghostty-specific extensions that most remote workflows do not use anyway.

Summary

Problem	Cause	Fix
`xterm-ghostty: unknown terminal type`	Remote server has no Ghostty terminfo	Set `TERM=xterm-256color` via `~/.ssh/config`
`SetEnv` in ssh config is ignored	Ghostty `ssh-terminfo` shell function overrides it	Disable `ssh-terminfo` in Ghostty config
Specific hosts use wrong user	`Host *` is at top of ssh config	Move `Host *` to bottom

Two files to get right, and the problem never comes back.

Why Postgres is the last database you'll need ?

2026-04-24T20:10:12Z

Every few months someone on the team opens a Slack thread with “should we add Redis?” or “do we really need Kafka for this?” The answer is usually the same. Not yet. Possibly never.

I have been running Postgres in production for a while now. Over the years I have watched it quietly absorb features that people used to stand up entirely separate services for. At some point you stop thinking of Postgres as “the relational database” and start thinking of it as the default place data goes. Everything else has to earn its spot on the architecture diagram.

This is a short tour of what a single Postgres instance can do before you start adding other boxes to that diagram.

It is a relational database. That is the boring part.

ACID transactions, foreign keys, joins, row level security, materialised views, window functions, CTEs, declarative partitioning. You already know this part. MVCC means readers don’t block writers and writers don’t block readers. The planner is mature. Decades of production hardening sit behind it. None of this is new.

What people miss is that the same engine running your OLTP workload is also good enough to replace three or four other services in most applications.

A cache that you already have

For session data, rate limit counters, or computed results that are annoying to regenerate, an UNLOGGED table gets you most of the way there.

CREATE UNLOGGED TABLE cache_entries (
 key TEXT PRIMARY KEY,
 value JSONB NOT NULL,
 expires_at TIMESTAMPTZ
);

UNLOGGED tells Postgres to skip the WAL for this table. Writes are faster because nothing is being streamed to the write-ahead log, and there is no replication overhead. The tradeoff is that the table is truncated on crash recovery. For a cache, that is acceptable behaviour. It is a cache only. It is supposed to be refillable.

The write path tells the story:

Fewer fsyncs, no WAL record, no network traffic to replicas. On a write-heavy cache workload, this is where the speed comes from.

You will not beat Redis on sub-millisecond hot path work. If you are running a real-time bidding system or a game leaderboard with thousands of concurrent updates per key, keep Redis. For most web applications where the user cannot tell the difference between 2 ms and 5 ms, an unlogged table works fine and you have one less daemon to operate.

A job queue, without the broker

SELECT ... FOR UPDATE SKIP LOCKED turns a regular table into a proper worker queue.

UPDATE job_queue SET status = 'processing', started_at = NOW()
WHERE id = (
 SELECT id FROM job_queue
 WHERE status = 'pending'
 ORDER BY created_at
 LIMIT 1
 FOR UPDATE SKIP LOCKED
)
RETURNING *;

Each worker locks exactly one row. Other workers see the lock, skip it, and take the next available row. No duplicate delivery. If a worker crashes mid-job, the transaction rolls back and the row goes back into the pool on its own.

Pair it with a partial index on WHERE status = 'pending' and the index stays small forever, even after you have processed ten million jobs. The completed rows drop out of the index as their status changes.

pg-boss in Node, river in Go, Solid Queue in Rails, all of them are built on this exact pattern. If your job volume is under a few thousand per second, you do not need RabbitMQ. A table and a partial index will do.

Full-text search, properly indexed

If you have written WHERE title ILIKE '%something%' on a production table, you know how this ends. A leading wildcard forces a sequential scan, and sequential scans get slower as the table grows.

tsvector and GIN indexes solve this properly.

CREATE TABLE articles (
 id SERIAL PRIMARY KEY,
 title TEXT NOT NULL,
 body TEXT NOT NULL,
 search_vector tsvector
);

CREATE INDEX idx_articles_search ON articles USING GIN (search_vector);

The difference at the planner level is stark:

You also get stemming, stop-word removal, ranking with ts_rank, phrase search, prefix matching, weighted fields. All of it in core. No extension required. If you need more, pg_trgm adds trigram similarity for typo-tolerant search, and pgvector handles semantic search through embeddings.

For a product catalog, blog search, or an internal admin tool, this is enough. You probably do not need Elasticsearch until well past the first million documents.

Pub/sub without another daemon

LISTEN/NOTIFY has been in Postgres for a long time and most people have not touched it.

-- subscriber side
LISTEN new_order;

-- publisher side, from another session or a trigger
SELECT pg_notify('new_order', '{"id": 42, "amount": 1500}');

Drop a trigger on INSERT that calls pg_notify, and every new row fans out to whoever is listening.

Works for real-time dashboards, cache invalidation, websocket fan-out, and background worker wake-ups.

The caveats are real. Payload limit is 8000 bytes. It does not play well with PgBouncer in transaction pooling mode because connection affinity breaks. Messages are not persisted, so if nobody is listening when NOTIFY fires, the message is gone. For what it is, it solves a real problem without adding infrastructure.

JSONB, for when your schema is not ready

Sometimes you have genuinely unstructured data. Webhook payloads from vendors who change their schema on a whim. Feature flags. User preferences. Audit logs where each event type has different fields.

JSONB gives you document storage inside your relational database. You can index individual keys with GIN, query with ->, ->>, @>, jsonb_path_query. You can enforce partial schema through check constraints where it matters, and leave the rest flexible.

This is not a reason to stop using proper columns when you know the schema. It is a reason to stop running MongoDB next to Postgres for one table full of half-known JSON.

Extensions

Core Postgres is already doing a lot. Then you have the extension ecosystem.

pgvector for vector similarity search with HNSW and IVFFlat indexes. RAG pipelines, recommendation engines, semantic search.
TimescaleDB turns Postgres into a proper time-series database with hypertables, native compression, and continuous aggregates. Metrics, IoT telemetry, financial ticks.
PostGIS is still the gold standard for geospatial. Not “good enough”, actually best in class.
pg_cron schedules jobs inside the database itself. No separate cron container, no Kubernetes CronJob object. A row in a table that says “run this SQL every five minutes”.
pg_partman automates partition creation and retention for time-based tables.
pg_stat_statements and auto_explain are how you figure out what is slow in production. If you are not using these, you are flying blind.
Foreign Data Wrappers let you query other Postgres instances, MySQL, MongoDB, even a CSV file, as if they were local tables.

Extensions are first class citizens. CREATE EXTENSION pgvector; and you are done. No separate service, no separate wire protocol, no separate auth model.

Who actually runs on Postgres

You do not have to take this on faith. Some of the largest workloads on the internet run on Postgres, and the engineering teams have written publicly about how.

OpenAI

OpenAI runs ChatGPT and the API platform for roughly 800 million users on a single-primary Postgres instance on Azure, backed by close to 50 read replicas spread across regions. Millions of queries per second, p99 latency in the low double-digit milliseconds. They did not shard the primary, they tuned and optimised aggressively.

Their engineering writeup: https://openai.com/index/scaling-postgresql/

Scaling Postgres to the next level at OpenAI | POSETTE: An Event for Postgres 2025

“Scaling Postgres to the next level at OpenAI” is a talk by Bohan Zhang for Livestream 1 of POSETTE: An Event for Postgres 2025.

POSETTE

Notion

Notion stores roughly 200 billion blocks across 480 logical shards on 96 physical Postgres instances. Every page, every block, every comment is a relatively simple Postgres row, replicated across shards with application-level routing keyed on workspace_id.

Their “Herding Elephants” post covers the original 2021 shard & The follow-up on adding capacity with zero downtime:

Herding elephants: lessons learned from sharding Postgres at Notion

With an effort to make Notion faster and more reliable for years to come — we migrated Notion’s PostgreSQL monolith into a horizontally-partitioned database fleet.

Notion · Garrett Fidalgo

The Great Re-shard: adding Postgres capacity (again) with zero downtime

Why and how we horizontally re-sharded our databases

Notion · Arka Ganguli, Tanner Johnson, Ben Kraft, Nathan Northcutt

Figma

Figma went the other direction from Notion and did vertical partitioning, splitting tables across servers rather than sharding rows across instances. Different approach, same underlying database.

How Figma’s Databases Team Lived to Tell the Scale | Figma Blog

Our nine month journey to horizontally shard Figma’s Postgres stack, and the key to unlocking (nearly) infinite scalability.

Figma · Sammy Steele

Instagram

Instagram has run on Postgres since before the Facebook acquisition and publicly stayed with it through hundreds of millions of users. Their early engineering posts on scaling Postgres are still referenced in sharding discussions today.

Others worth knowing about

GitLab runs on Postgres. Heroku’s own control plane does. Reddit has used it for core metadata for years. A long tail of fintechs, SaaS companies, and government systems sit on Postgres and do not talk about it publicly.

The common thread across these stories is the same. They hit scaling limits, they optimised, they sharded or partitioned when they had to, but they did not abandon Postgres. The engineering effort to scale it turned out to be meaningfully less than the engineering effort to migrate off it.

The part nobody talks about - you own your data

Every managed cloud database is also a vendor lock-in story. DynamoDB data lives inside AWS. Firestore is GCP only. Cosmos DB belongs to Azure. Moving off any of them is a migration project, not a config change.

Postgres is open source under a permissive license. Your data sits in a format a hundred tools can read. You can run it on RDS, Aurora, Cloud SQL, Azure Database, Neon, Supabase, Crunchy Data, or your own Ubuntu box in a rack. The wire protocol is the same. The dump format is the same. pg_dump from one provider, pg_restore to another, a weekend of work rather than a quarter.

This matters when pricing changes. When a provider has an outage pattern you cannot tolerate. When compliance requirements shift and data has to sit inside the country. When you simply want to leave. Optionality is a feature and very few databases actually give it to you.

Where you genuinely should stop

Postgres does not do everything, and pretending otherwise is how teams end up with production incidents.

Sub-millisecond cache hits at a million QPS, you want Redis or Memcached.
Millions of messages per second with durable fan-out, consumer groups, and replay semantics, you want Kafka.
Distributed search across terabytes with complex CJK analyzers and deep faceted aggregations, you want Elasticsearch or OpenSearch.
Petabyte-scale analytical scans, you want ClickHouse, Druid, or a proper warehouse like Snowflake or BigQuery.

These tools exist because the problems they solve are real. If you hit those walls, your benchmarks will tell you which workload is the actual bottleneck.

In simple words…

Start with Postgres. One database to back up, one to monitor, one connection pooler to tune, one replication topology, one set of alerts in Grafana, one thing to patch when the next CVE drops. When Postgres starts hurting on a specific workload, and only then, extract that workload into a dedicated service. By that point you will have production metrics that tell you exactly why, which is a much better place to be than guessing on day one.

The Userspace Tax Behind Protocols - QUIC(UDP) vs TCP

2026-03-19T11:24:27Z

When you’re building a service that requires inter-node communication, one of the earliest decisions is choosing a transport protocol. Nodes need to talk to each other reliably, consistently, and fast. That means picking a foundation to build on.

At the transport layer, there are really only two foundations: TCP and UDP. Everything else is built on top of one of these two. On top of TCP, we have protocols battle-tested in production for years like HTTPS, gRPC, WebSocket, and other custom protocols. These inherit TCP’s reliability, ordering, and congestion control for free because TCP handles all of that at the kernel level. On top of UDP, the most prominent protocol today is QUIC. Designed by Google, standardized as RFC 9000, and powering HTTP/3, QUIC is the one that keeps coming up when teams discuss transport choices.

So when a team needs to decide how their cluster nodes communicate internally, the conversation often lands on: should we use something over TCP, or should we use QUIC over UDP? And this is where the misconception begins.

The misconception

QUIC sounds like a strong candidate. It is modern. It has built-in encryption. It solves head-of-line blocking. Google uses it. HTTP/3 runs on it. It is, by most accounts, a well-engineered protocol.

Push back with TCP, and the rebuttal is almost always: “gRPC also runs in userspace too. So does HTTP. So does WebSocket. Every protocol above the kernel is userspace. QUIC being in userspace is no different.” That sounds convincing. It is also wrong. But the reason it’s wrong is not obvious unless you trace the actual packet flow for both approaches.

Comparing QUIC to TCP for inter-node communication is not a matter of trade-offs. It is a category error. QUIC was designed for a specific environment that looks nothing like the inside of a cluster.

Understanding the protocol layers

This is where most of the confusion comes from, and where the conversation usually goes sideways. People treat TCP and QUIC as direct alternatives. Swap one for the other. But they sit differently in the protocol stack, and that difference is the entire point.

TCP is a transport protocol that lives in the kernel. UDP is a transport protocol that lives in the kernel. They are peers.

QUIC is also a transport protocol but it does not live in the kernel. It lives in userspace and uses UDP underneath as a tunneling layer. UDP is there because it’s the simplest way to get packets through internet middleboxes, NATs, and firewalls that would otherwise drop unknown protocol numbers.

So when someone says “let’s use QUIC instead of TCP,” what they are actually proposing is: let’s use UDP as a dumb packet pipe, and rebuild all of TCP’s guarantees (reliability, ordering, congestion control, flow control) in our application process. Then add mandatory encryption on top.

That is not a minor architectural detail. That is the entire discussion.

The environment matters more than the protocol

QUIC was born at Google. Not for cluster communication. For the internet. Specifically, for Chrome talking to Google’s edge servers across unpredictable network paths, through NATs, over connections that break when your phone switches from WiFi to cellular.

Every design decision in QUIC traces back to internet-scale problems:

Now look at a private network. None of these problems exist:

 Property in a private LAN Reality
 ────────────────────────────── ──────────────────────────────
 Packet loss < 0.001% (basically zero)
 Latency < 0.1ms (sub-microsecond with RDMA)
 IP changes mid-connection Never happens
 Middleboxes None. You own the network.
 Trust model Trusted, or mTLS if needed
 Connection count Tens. Maybe low hundreds.
 Connection lifetime Hours, days, weeks

Every problem QUIC was designed to solve does not exist inside a private LAN network. You are paying for solutions to problems you do not have.

Where the work actually happens

The common rebuttal “gRPC is in userspace too, so QUIC being userspace doesn’t matter” falls apart once you trace what actually happens when data moves from your application to the wire. Not the conceptual model. The actual execution path.

Here is the fundamental difference:

With TCP, the application does almost nothing. The kernel and NIC hardware handle the heavy lifting. With QUIC, the application process does all the transport work itself.

Path 1: gRPC over TCP

Your application serializes a protobuf message. Let’s say it’s 64KB. A chunk of data destined for another node.

Count the syscalls your application made: one. A single write(). Everything else happened in the kernel and NIC hardware. Your process didn’t wake up again until it had more data to send.

Path 2: Application protocol over QUIC over UDP

Same scenario. 64KB of data. But now over QUIC.

Count what happened in your application process: segmentation, packet numbering, encryption (per packet), congestion control, flow control, loss detection, retransmission. All of it. Plus roughly 45 syscalls instead of 1 (or ~3-4 with aggressive GSO batching, but still more).

Now look at both paths side by side and ask: where is “the work?”

**With TCP, 90% of the transport work happens in the kernel and NIC hardware. With QUIC, 90% of the transport work happens in your application process. **

gRPC and HTTP being in userspace is the small box at the top: serialization and framing. QUIC being in userspace is the entire middle section: the actual transport layer. The people saying “gRPC/HTTP/WS is userspace too” are pointing at the small box and saying “see, same thing.” It is not the same thing.

The kernel optimizations that QUIC structurally cannot use

This is not about TCP being “more mature.” These are architectural advantages that come from the transport layer living in kernel space with direct access to hardware.

TCP Segmentation Offload (TSO)

When your application writes 64KB to a TCP socket, the kernel does not split it into 45 packets using CPU time. It constructs a large segment descriptor and hands it to the NIC. The NIC hardware splits it into MTU-sized packets right before putting them on the wire.

Your CPU does almost nothing for this. The NIC is doing the segmentation.

QUIC cannot use TSO. Each QUIC packet must be individually encrypted in userspace before it crosses the syscall boundary. You cannot hand the NIC a 64KB encrypted blob and say “split this into packets.” The encryption is per-packet, so the splitting must happen before encryption, which must happen in userspace.

Generic Receive Offload (GRO)

On the receive side, the NIC and kernel coalesce multiple incoming TCP segments into large buffers. Your application calls recv() once and gets 64KB+ of data that physically arrived as dozens of packets.

With QUIC, the kernel cannot coalesce incoming UDP datagrams because it cannot see inside the encrypted QUIC packets. Each one must be individually delivered to userspace, individually decrypted, and individually reassembled by the QUIC library.

Zero-copy I/O with sendfile()

This is the critical one for any data-intensive system. TCP supports sendfile() and splice(), which move data directly from the filesystem page cache to the NIC without ever copying it into userspace memory.

Data never enters userspace. Zero copies, zero context switches for the data path.

Two extra copies, two extra context switches. For any distributed system moving large volumes of data between nodes, this is not a small difference. It is the difference between the data touching userspace memory zero times versus two or more times per operation. Each copy burns memory bandwidth. Each context switch burns CPU cycles.

Apache Kafka famously depends on sendfile() for its performance, transferring log segments directly from disk to network without ever reading them into the application process. This optimization is structurally impossible with QUIC.

Kernel TLS (kTLS)

If you need encryption between cluster nodes for compliance or zero-trust requirements, Linux supports kernel TLS. The TLS record layer executes in kernel space, preserving the zero-copy path:

You get encryption without giving up any of TCP’s performance advantages. QUIC’s mandatory per-packet encryption in userspace cannot match this.

Packet-level breakdown

Let’s look at exactly what goes on the wire.

TCP packet (no encryption)

┌─────────────────────────────────────────────────┐
│ IPv4 Header │ 20 bytes │
├─────────────────────────────────┼───────────────┤
│ TCP Header │ 20 bytes │
├─────────────────────────────────┼───────────────┤
│ Payload │ up to 1460 │
│ (your actual data) │ bytes │
└─────────────────────────────────┴───────────────┘

 Total overhead: 40 bytes per packet
 Payload efficiency: 1460 / 1500 = 97.3%
 CPU cost per packet: near zero (checksums offloaded to NIC)

QUIC packet (short header, post-handshake)

┌─────────────────────────────────────────────────┐
│ IPv4 Header │ 20 bytes │
├─────────────────────────────────┼───────────────┤
│ UDP Header │ 8 bytes │
├─────────────────────────────────┼───────────────┤
│ QUIC Short Header │ ~20 bytes │
│ (flags, connection ID, │ │
│ packet number, encrypted) │ │
├─────────────────────────────────┼───────────────┤
│ Encrypted Payload │ up to 1407 │
│ (your data, encrypted) │ bytes │
├─────────────────────────────────┼───────────────┤
│ AEAD Authentication Tag │ 16 bytes │
└─────────────────────────────────┴───────────────┘

 Total overhead: 64 bytes per packet
 Payload efficiency: 1407 / 1500 = 93.8%
 CPU cost per packet: one AES-128-GCM encrypt/decrypt (userspace)

24 extra bytes of overhead per packet, plus a cryptographic operation for every single packet. Let’s see what that means at scale.

Cost at scale

 At 10 Gbps inter-node throughput, 1500-byte MTU:

 TCP QUIC
 ──────────────────────────────────────────────────────────
 Packets per second ~833,000 ~833,000
 Header overhead/sec 33.3 MB/s 53.3 MB/s
 Wasted bandwidth ── ~20 MB/s extra
 Syscalls/sec ~1 per write() ~55,000 (with GSO)
 (kernel batches) up to 833,000 (without)
 Crypto operations/sec 0 ~833,000
 Context switches/sec minimal ~55,000+

At 10 Gbps, QUIC adds ~55,000 context switches per second and 833,000 cryptographic operations that TCP avoids entirely.

 With jumbo frames (9000-byte MTU, standard in clusters):

 TCP QUIC
 ──────────────────────────────────────────────────────────
 Packets per second ~139,000 ~139,000
 Crypto operations/sec 0 ~139,000
 Syscalls/sec ~1 per write() ~10,000 (with GSO)

Jumbo frames reduce the packet rate for both, but QUIC still pays per-packet encryption cost. TCP’s cost is essentially constant because the NIC handles segmentation regardless of MTU.

What production systems actually chose

This is not a theoretical argument. Every major distributed system in production uses TCP for internal node-to-node communication. Not one uses QUIC.

etcd uses gRPC over TCP for Raft consensus and peer communication. The entire consistency model of Kubernetes depends on etcd’s Raft log replication, which relies on TCP’s reliable ordered delivery at the kernel level.

CockroachDB uses gRPC over TCP for all inter-node RPC. Distributed SQL execution, Raft replication, leaseholder coordination. Heavy cross-node traffic, all on TCP.

ScyllaDB uses a custom RPC protocol over raw TCP sockets through the Seastar framework. Each CPU core gets its own TCP connections in a shared-nothing architecture. When they needed to go faster than kernel TCP, they went toward DPDK (kernel bypass with a custom userspace TCP stack), not toward QUIC. They kept TCP semantics and eliminated the kernel. QUIC goes the other direction: keeps the kernel in the path via UDP while moving the expensive transport work to userspace.

Apache Kafka uses a custom binary protocol over TCP. Its throughput depends on the zero-copy sendfile() path described earlier is structurally impossible with QUIC.

Redis Cluster uses TCP for both the data port and the cluster bus (a gossip protocol on port+10000 for failure detection and configuration).

Ceph supports two messenger implementations, both TCP-based: the simple messenger and the async (epoll-based) messenger. RADOS replication and recovery, which involves massive data movement during rebalancing, runs entirely over TCP.

TiKV (the storage engine behind TiDB) uses gRPC over TCP for Raft communication and data transfer between nodes.

The pattern is not a coincidence. These systems were built by teams who deeply understand transport layer performance. They all arrived at the same answer.

When QUIC genuinely makes sense

QUIC is a well-engineered protocol. The goal of this article is not to dismiss it, it is to be precise about where it belongs.

Browser-to-CDN, mobile clients, multiplexed streams over lossy links, and cross-region traffic over public internet these are the environments QUIC was built for. Inside a cluster LAN with sub-millisecond latency and near-zero packet loss, none of these conditions exist.

The right architecture for cluster internals

For a multi-node cluster, the transport choice is straightforward:

And if you ever need to go faster than kernel TCP, the direction is not QUIC. The direction is:

All three of these either keep TCP or go below it. None of them add a layer on top of UDP and call it progress.

TCP, inside a cluster, is not just the better option. It is the only option that makes engineering sense. The kernel handles your transport. The NIC accelerates it in hardware. Your application process stays free to do application work. Thirty years of optimization, hardware offload, and zero-copy I/O support this path. Inside a cluster network where you control every switch, every cable, every MTU setting, QUIC’s trade-offs buy you nothing and cost you everything.

How Does Your Database Store Millions of Records?

2026-01-02T05:38:36Z

Every time you save a photo, complete a purchase, or send a message, your data travels from application code to permanent storage. But how does this actually work at the physical level?

During my years working with production systems, I’ve seen teams choose the wrong storage engine and suffer 10x performance penalties. The difference between B-Trees and LSM Trees isn’t academic, it’s the reason Discord’s migration to Cassandra made their writes 10x faster, and why Netflix uses different approaches for viewing history versus recommendations.

The Fundamental Problem: Disk is Slow

Before getting into data structures, understand the constraint we’re solving for.

In-memory storage is fast but expensive and volatile & power off, data gone. Disk storage (SSDs or HDDs) is cheap and persistent, but dramatically slower:

RAM: ~100 nanoseconds
SSD: ~100 microseconds (1,000x slower)
HDD: ~10 milliseconds (100,000x slower)

This performance gap shapes everything. You can’t just dump a hash table to disk and expect decent performance.

Here’s the insight:* disks hate random access but excel at sequential access. Reading 1 byte at a random location is slow. Reading 1MB of consecutive bytes is much faster per byte.*

Database storage engines exist to minimize random disk access. This leads us to two fundamentally different approaches.

B-Trees: The Read-Optimized Classic

PostgreSQL, MySQL, and SQLite all use B-Trees by default. They’ve been around since the 1970s for good reason.

How B-Trees Work?

Think of a B-Tree as a sorted, balanced tree structure. The root node acts as an index, directing you left or right. Each level narrows your search until you reach a leaf node containing your data.

Looking up user_789:

Read root node: “keys 501-999 go right”
Read right child: “keys 751-999 go right”
Read that node: find user_789

That’s typically 3-4 disk reads for any lookup, guaranteed by the balanced tree structure.

B-Tree Strengths

Point lookups are fast. Need a specific user? 3-4 disk reads.

Range queries are efficient. “Give me users 100-200” works well because data is sorted and stored contiguously.

This makes B-Trees perfect for OLTP (Online Transaction Processing) systems with frequent random reads, think bank accounts, e-commerce orders, user profiles.

B-Tree Weaknesses

Writes are expensive. To insert data:

Read multiple nodes to find the insertion point
Split nodes if full
Update parent pointers
Potentially rebalance the tree

One write can trigger dozens of disk operations. If your disk is nearly full and you’re doing random inserts, you’re constantly seeking different locations is painful for HDDs, inefficient even for SSDs.

B-Trees optimize for reads at the cost of writes.

LSM Trees: The Write-Optimized Modern Approach

LSM (Log-Structured Merge) Trees power Cassandra, RocksDB, LevelDB, and most NoSQL databases handling high write volumes.

The philosophy is radically different: instead of maintaining sorted organization on disk, write things down as they arrive just like a journal.

How LSM Trees Work?

When a write arrives:

Write to MemTable (in-memory sorted buffer)
When MemTable fills (~64MB), flush to disk as an immutable SSTable (Sorted String Table)
Write sequentially in one operation

Sequential writes are fast: 100-500 MB/s even on HDDs, compared to 1-2 MB/s for random writes.

The Read Trade-off

To read user_789:

Check current MemTable
Check most recent SSTable
Check next SSTable
Continue until found

Unlike B-Trees, data isn’t in one organized tree, it’s across multiple sorted files.

How LSM Trees Stay Fast

Bloom Filters: Before checking each SSTable, ask: “Does this file contain user_789?” If no, skip entirely. This avoids unnecessary disk reads.

Compaction: Background process merges SSTables, removes deleted data, combines duplicates. Data ages through levels (hence “leveled compaction”).

Result: Writes stay fast (always sequential), reads are slower than B-Trees for point lookups but manageable with Bloom filters and caching.

LSM Trees handle millions of writes per second because you’re appending to memory and occasionally flushing to disk.

When to Use Each Approach

Use B-Trees When You Have:

Read-heavy workloads (80:20 read-to-write ratio)
Need for fast point lookups and range scans
Transactional workloads (bank accounts, orders)
Data fitting in memory or fast SSDs available

Examples: PostgreSQL for user accounts, MySQL for product catalogs, SQLite for mobile app databases

Use LSM Trees When You Have:

Write-heavy workloads (tons of inserts/updates)
Acceptable slightly slower reads
Time-series data (logs, metrics, sensors)
Need to ingest massive data volumes quickly

Examples: Cassandra for Netflix’s viewing history (300M writes/day), RocksDB for Facebook messaging, InfluxDB for monitoring metrics

Example: Discord’s Migration

Discord initially used MongoDB (B-Trees) for message storage. Worked fine initially, but at scale with billions of messages:

Reads were acceptable
Writes became a bottleneck
Random B-Tree inserts caused disk fragmentation
Insert performance degraded

They migrated to Cassandra (LSM Trees):

Writes became 10x faster
Now handle millions of messages per second
Sequential write pattern eliminated fragmentation

The Actual Reality

Modern databases often blend approaches:

RocksDB: LSM Trees with read optimizations
PostgreSQL: B-Trees + WAL (Write-Ahead Log, append-only)

The best choice depends on your access patterns. In my experience running production systems, I’ve learned:

Start with B-Trees (PostgreSQL/MySQL) for general-purpose applications
Switch to LSM Trees when write volume becomes the bottleneck
Monitor disk I/O patterns if they’ll tell you when you’ve chosen wrong

Quick Takeaways

**Disks are 1,000-100,000x slower than RAM **this constraint shapes everything
B-Trees optimize for reads with logarithmic lookup but expensive writes
LSM Trees optimize for writes with sequential I/O but trade-off read performance
Real-world systems often use hybrid approaches
**Your access pattern determines the right choice **not theoretical performance

The storage engine matters more than most developers realize.

Why Your App is Still Slow After Optimization?

2025-08-30T12:31:22Z

You have optimized your database queries, your API responds in under 100ms, and your CDN is correctly configured. Yet users still report slow load times, and performance monitoring shows latency spikes that appear without explanation.

The issue often lies outside your application or infrastructure. Two core network protocols can directly impact performance. TCP congestion control may make inefficient decisions about how data flows under varying conditions, and BGP routing can send traffic along longer, suboptimal paths across the internet.

This is not the result of poor coding or misconfigured servers. It is a reminder that the behavior of foundational internet protocols can override even the best optimizations, and understanding them is critical to reducing unpredictable latency.

What is TCP Congestion?

Every TCP connection needs to answer a fundamental question: how fast should data be sent? Send too slowly and you waste available bandwidth. Send too quickly and you’ll overwhelm the network, causing packet loss and retransmissions.

TCP congestion control algorithms handle this decision automatically, but their choices directly impact your application’s performance in ways that can override all your code-level optimizations.

There are two types of TCP congestion control algorithms, but they approach the problem very differently.

1. CUBIC

Most internet servers still use CUBIC, a loss-based congestion control algorithm.

CUBIC’s strategy is straightforward: increase the data transmission rate until packet loss occurs, then back off and gradually increase again.

This approach works well for bulk data transfers, but it creates problems for modern applications. CUBIC treats packet loss as the primary signal of network congestion, which means it needs to overfill network buffers to detect when to slow down. Those overfilled buffers translate directly into increased latency for your application.

When a user clicks on a video thumbnail, CUBIC might send the first few data packets quickly, but as it ramps up transmission speed, it begins filling intermediate network buffers. Your video data sits in these buffers, adding 100-200ms of delay before reaching the user’s device. From your monitoring perspective, the server responded quickly, but the user experiences the additional buffer delay.

CUBIC is probably the best, most robust congestion control algorithm available. But, as internet bandwidths grow and wireless represents a larger share of network links, TCP doesn’t perform as desired.

2. BBR (Bottleneck Bandwidth and RTT)

Google’s BBR takes a different approach. Instead of waiting for packet loss to detect congestion, BBR actively measures available bandwidth and round-trip time to calculate the optimal sending rate.

***BBR continuously estimates two key metrics: the maximum bandwidth available on the path to the destination, and the minimum round-trip time. ***Using these measurements, it calculates the ideal transmission rate without needing to fill network buffers.

Real-world use-cases show significant improvements. Companies handling large-scale video delivery report 21% performance improvements when switching from CUBIC to BBR. More importantly for interactive applications, BBR maintains much lower latency because it doesn’t rely on buffer overflow to detect congestion.

The difference becomes particularly noticeable for mobile users, where network conditions change frequently and CUBIC’s loss-based approach struggles to adapt quickly to varying bandwidth and latency conditions.

BGP (Border Gateway Protocol) Routing

While TCP congestion control controls how fast data moves, BGP decides the path that data takes across the internet. BGP is the backbone of the internet because it allows one network to talk to another. It is the protocol that connects thousands of independent networks such as ISPs, cloud providers, and data centers, making the internet work as a whole.

BGP works at the application layer of the OSI model but runs on top of TCP using port 179. Its main job is to let networks advertise which IP prefixes they can reach and to choose a path for traffic between them.

The problem is that BGP focuses on reachability, not performance. As long as the data can reach its destination, BGP considers the task complete even if the chosen route is longer or slower than required.

What is BGP Hijacking ?

Your application might send data to a user in London, and you’d naturally expect that data to take a direct path through European internet infrastructure. But BGP routing decisions made by various network operators along the way might send that traffic through entirely different paths.

Data could travel from your London server to a user in London by way of internet exchanges in Frankfurt, Amsterdam, and back to London. Each additional hop adds latency, and each network transition introduces potential performance variations that your application has no control over.

More concerning are BGP hijacking incidents , where malicious or misconfigured network operators advertise routes for IP address ranges they don’t actually control. When this happens, traffic intended for your servers gets redirected through unintended networks which leads to unexpcted results.

What This Means for Application Performance ?

TCP congestion control and BGP routing can amplify each other’s weaknesses. When BGP shifts traffic to a new path, the latency and bandwidth may differ significantly from what the TCP algorithm has been tuned for.

CUBIC, which relies on packet loss and recovery cycles, struggles in this situation. It interprets the sudden change as congestion and cuts transmission speed, even if the new path has sufficient capacity. Performance remains poor until CUBIC slowly recalibrates.

BBR adapts more effectively. Instead of relying on past behavior, it continuously measures bandwidth and round-trip time. When BGP reroutes traffic, BBR quickly adjusts its sending rate to the new path’s conditions.

These interactions explain why users may see latency spikes even when your servers and APIs are healthy. Geographic variations often stem from BGP routing choices rather than application issues, and mobile users are especially affected since variable bandwidth and latency expose CUBIC’s limitations. BBR’s active measurement approach tends to handle such conditions more gracefully.

Summary

You can’t control BGP routing choices, but understanding them helps with architecture and troubleshooting. Enabling BBR at the server level often improves performance, especially for mobile and real-time applications, since it’s built into modern Linux kernels and requires no code changes.

For routing resilience, diversify across multiple CDNs or cloud regions so that a single BGP issue doesn’t affect all users. Geographic redundancy ensures alternative paths are available when routing problems occur.

Monitoring should go beyond application response times. Metrics like TCP retransmissions, round-trip latency, and regional performance differences reveal when protocol-level issues are degrading user experience.

The takeaway is that network protocols can override even the best application optimizations. The internet’s core protocols were never designed for today’s performance demands, yet they still decide how data flows. Recognizing their influence helps you build more resilient systems and debug issues that aren’t in your code.

Layer 4 vs Layer 7 Load Balancing Explained

2025-08-28T09:37:04Z

When you browse Instagram, stream Netflix, or shop on Amazon, robust load balancing technology works silently in the background, handling millions of simultaneous requests across multiple server. This critical infrastructure component prevents system overloads and ensures consistent user experiences even during traffic spikes.

Load Balancing Fundamentals

Load balancing distributes incoming network traffic across multiple servers to ensure no single server becomes overwhelmed. This improves application responsiveness and availability while preventing server failures. The choice between Layer 4 and Layer 7 load balancing represents a crucial architectural decision with significant implications for performance, security, and functionality.

The Network Layer Context

To understand these approaches, we need to reference the OSI model that categorizes network functions:

The OSI model provides a framework for understanding network communications. For load balancing, we focus primarily on Layer 4 (Transport) and Layer 7 (Application).

Layer 4 Load Balancing: Transport Layer

Layer 4 load balancers operate at the transport protocol level, making routing decisions based solely on:

Source and destination IP addresses
TCP/UDP port information
Network-level client information

These load balancers maintain a single TCP connection from client to server, using Network Address Translation (NAT) to route packets without inspecting their contents.

Advantages

Performance Efficiency: Minimal packet inspection results in lower processing overhead
Protocol Agnosticism: Works with any TCP/UDP traffic, not just HTTP
Security Isolation: Cannot decrypt encrypted traffic, maintaining end-to-end encryption
Connection Efficiency: Maintains a single TCP connection throughout the request lifecycle
Lower Latency: Fewer processing steps means faster packet forwarding

Limitations

Content Blindness: Cannot make decisions based on request content or headers
Limited Routing Logic: Unable to route based on URLs, cookies, or application-specific data
No Content Manipulation: Cannot modify headers or rewrite request content
Microservice Limitations: Difficult to implement path-based routing needed for microservices
No Application-Level Features: Cannot implement caching or application-aware health checks

NGINX Layer 4 Load Balancing Example

# Layer 4 TCP load balancing

stream {

 # Web server group
 upstream web_servers {
 server backend1.example.com:80;
 server backend2.example.com:80;
 }

 # Database server group
 upstream db_servers {
 server db1.example.com:5432;
 server db2.example.com:5432;
 }

 # HTTP traffic forwarding
 server {
 listen 80;
 proxy_pass web_servers;
 }

 # PostgreSQL traffic forwarding
 server {
 listen 5432;
 proxy_pass db_servers;
 }
}

**This above configuration shows: **

Creates two upstream server groups: web servers and database servers
Listens on port 80 and forwards web traffic to the web servers
Listens on port 5432 and forwards database traffic to the database servers
Makes decisions based solely on IP addresses and ports

Layer 7 Load Balancing: Application Layer

Technical Operation

Layer 7 load balancers operate at the application layer, which means they:

Terminate client connections at the load balancer
Inspect and potentially modify request content
Establish new connections to appropriate backend servers
Create two distinct TCP connections (client-to-LB and LB-to-server)

Advantages

Content-Based Routing: Can route based on URL paths, headers, cookies, or message content
Microservice Architecture Support: Enables routing different API endpoints to specialized services
Advanced Health Checking: Can verify application functionality, not just server availability
Content Manipulation: Ability to add/modify headers or transform request/response content
Caching Implementation: Can cache responses for improved performance
TLS Termination: Can offload SSL/TLS processing from backend servers

Limitations

Computational Overhead: Content inspection requires more processing power
TLS Processing: Must decrypt and re-encrypt secure traffic
Increased Latency: Additional processing steps add some latency
Security Considerations: Decrypted traffic visibility at the load balancer level
Certificate Management: Requires TLS certificates to be installed on the load balancer

NGINX Layer 7 Load Balancing Example

# Layer 7 HTTP load balancing
http {
 # API server group
 upstream api_servers {
 server api1.example.com:8080;
 server api2.example.com:8080;
 }

 # Media server group
 upstream media_servers {
 server media1.example.com:9000;
 server media2.example.com:9000;
 }

 # Auth server group
 upstream auth_servers {
 server auth1.example.com:8081;
 server auth2.example.com:8081;
 }

 # Main server configuration
 server {
 listen 80;
 server_name example.com;

 # Route API requests
 location /api/ {
 proxy_pass http://api_servers;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 }

 # Route media requests
 location /media/ {
 proxy_pass http://media_servers;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 }

 # Route authentication requests
 location /auth/ {
 proxy_pass http://auth_servers;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 }
 }
}

This above configuration shows Layer 7’s capabilities:

Creates three upstream server groups for different services
Routes requests based on URL paths (/api/, /media/, /auth/)
Forwards requests to the appropriate backend servers
Adds headers to provide original client information to backend servers

Hybrid Implementation with NGINX

For environments that need both Layer 4 and Layer 7 capabilities, NGINX supports a hybrid approach:

# Combined Layer 4 and Layer 7 load balancing

# Layer 4 for database traffic
stream {
 upstream database {
 server db1.example.com:5432;
 server db2.example.com:5432;
 }

 server {
 listen 5432;
 proxy_pass database;
 }
}

# Layer 7 for HTTP traffic
http {
 upstream web_servers {
 server web1.example.com:8080;
 server web2.example.com:8080;
 }

 server {
 listen 80;
 server_name example.com;

 location / {
 proxy_pass http://web_servers;
 proxy_set_header Host $host;
 }
 }
}

This simple hybrid configuration:

Uses Layer 4 load balancing for database connections
Uses Layer 7 load balancing for web traffic
Leverages the strengths of both approaches in a single NGINX instance

Making the Right Choice

When deciding which approach to go with, consider these factors:

Performance Requirements: Layer 4 offers lower overhead for high-throughput scenarios
Protocol Diversity: Layer 4 handles any TCP/UDP protocol; Layer 7 is typically HTTP-focused
Routing Complexity: Layer 7 enables path/content-based routing
Security Model: Layer 4 maintains end-to-end encryption; Layer 7 requires TLS termination
Architecture: Microservices typically require Layer 7’s path-based routing capabilities

Summary

For most modern web applications, a hybrid approach often provides the best balance, using Layer 4 for raw performance where needed and Layer 7 for intelligent content routing. This combination delivers both the efficiency and the flexibility required by complex distributed systems.

What is Kernel TLS (kTLS) and Why Offload TLS to the Kernel or NIC?

2025-08-27T18:55:56Z

Most applications today handle TLS encryption in userspace, which creates performance bottlenecks that many developers don’t realize exist. When your web server processes HTTPS requests or your API handles secure connections, every byte of encrypted data requires CPU-intensive cryptographic operations performed by your application process.

This approach works, but it leaves performance on the table. Linux Kernel TLS (kTLS) offers a better way by moving TLS operations closer to the hardware, potentially freeing up significant CPU resources for your actual application logic.

What’s the Difference Between Kernel Space and User Space in Linux?

Image Source : Redhat

In Linux, the kernel is the core of the operating system. It manages hardware like the CPU, memory, and network devices, and provides the low-level services everything else relies on. User space is where normal applications run something like web servers, browsers, databases but they can’t touch hardware directly. Instead, they must go through the kernel using system calls.

Architecting Containers Part 1: Why Understanding User Space vs. Kernel Space Matters

Before diving head-first into a discussion about the architecture and deployment of containers in a production environment, there are some important things that developers, architects, and systems administrators, need to know. While containers are sometimes treated like virtual machines, it is important to note, unlike virtual machines, the kernel is the only layer of abstraction between programs and the resources they need access to. Let’s see why.

Red Hat · Scott McCarty (fatherlinux)

How TLS Currently Works in Most Applications ?

Before we start with understanding kernel TLS, let’s understand the traditional TLS handshake flow. When your application handles a secure connection:

TCP connection establishes normally
Your application performs the TLS handshake using libraries like OpenSSL
For every request/response, your application encrypts outgoing data and decrypts incoming data
Data gets copied between kernel space and userspace multiple times

This creates two main performance issues:

CPU overhead: Your application spends cycles on cryptography instead of business logic
Memory copies: Data moves between kernel and user space multiple times

Understanding Kernel TLS Options

Linux Kernel TLS provides three different approaches to handle TLS operations more efficiently. Each mode addresses different performance requirements and hardware capabilities.

1. Software Crypto Mode (TLS_SW)

In software mode, the kernel takes over TLS encryption and decryption instead of your application doing it, but still uses the host CPU for cryptographic operations.

How it works:

Your application performs the TLS handshake (for certificate validation and key exchange)
Once established, you provide the encryption keys to the kernel
The kernel handles all subsequent encryption/decryption automatically
All crypto operations happen in kernel space using the host CPU

What changes for your application ?

write() calls: You write plain text, kernel encrypts it
read() calls: Kernel decrypts data before giving it to you
Performance impact: You still use CPU for crypto, but kernel-level operations are more efficient than userspace libraries

2. Packet-based NIC Offload Mode (TLS_HW)

Hardware mode moves TLS operations to your network interface card (NIC). Modern enterprise NICs include processors specifically designed for cryptographic operations.

Benefits:

CPU freedom: Your main CPU never touches cryptographic operations
Faster reads: Data arrives already decrypted
Better scaling: Handle more connections with the same CPU resources

Requirements:

NIC must support TLS offload capabilities
Hardware checksum offload must be enabled
Packets must arrive in order for proper crypto state management

3. Full TCP NIC Offload Mode (TLS_HW_RECORD)

The most aggressive option lets your NIC handle both TCP connection management and TLS operations entirely. The NIC firmware completely replaces the kernel networking stack for offloaded connections.

Benefits: Maximum throughput for pure data transfer scenarios
Limitations: You lose Linux networking features like iptables, traffic shaping, and packet filtering

This mode works best for dedicated high-throughput applications where you don’t need advanced networking features. It’s essentially creating a hardware-accelerated bypass of the entire Linux networking stack.

Zero-Copy Operations: A Practical Example

One of the most significant advantages of kernel TLS is enabling zero-copy operations, which can dramatically improve performance for data-intensive applications.

To understand the impact, let’s examine a real-world scenario: a file upload service handling large files.

The Problem with Traditional TLS

In traditional userspace TLS implementations, every byte of data must pass through multiple layers and memory copies. When a client uploads a 1GB file to your server:

Network Reception: Encrypted data arrives at your network interface
Kernel Copy: Data gets copied from network buffers to socket buffers
Userspace Copy #1: Your application reads the encrypted data (copy from kernel to userspace)
CPU Decryption: Your application’s TLS library decrypts the data using CPU cycles
Userspace Copy #2: Your application writes the decrypted data back to kernel for file operations
File Write: Kernel writes the data to disk

This process results in:

2+ memory copies between kernel and userspace
High CPU utilization for cryptographic operations
Memory bandwidth waste (processing ~2GB of data to store 1GB)
Context switching overhead between kernel and userspace

The kTLS Zero-Copy Advantage

With kernel TLS hardware offload, the entire data flow changes fundamentally:

Hardware Decryption: Your NIC’s crypto processor decrypts data as it arrives
Direct DMA: Decrypted data goes directly to kernel memory via DMA
Zero-Copy Transfer: Application uses sendfile() or splice() system calls
Direct File Write: Kernel writes directly from socket buffer to disk

The result: Your application never touches the actual file data, and your CPU never performs cryptographic operations.

Some Real-World Performance Impact

1. Web Servers

Before kTLS: Each HTTPS connection consumes CPU cycles for every encrypted byte processed
With kTLS: CPU focuses entirely on application logic, handling more concurrent connections

2. File Transfer Services

Before kTLS: Large file uploads bottlenecked by encryption overhead and memory copies
With kTLS: Near-native file transfer speeds with full encryption

3. API Gateways

Before kTLS: TLS termination creates CPU hotspots under heavy load
With kTLS: Linear scaling with hardware-accelerated crypto operations

Checking if Hardware/NIC Support kTLS

You need to verify that your network interface card (NIC) has the necessary hardware capabilities for TLS offload. Not all network cards support hardware TLS acceleration, and the level of support varies significantly between vendors and models.

NIC TLS Offload Capabilities

Modern enterprise network cards include dedicated processors and crypto engines that can handle TLS operations independently of your host CPU. However, support varies across three levels:

No TLS Support: Basic NICs without any TLS acceleration
Partial TLS Support: NICs that support some TLS operations (TX only, or specific cipher suites)
Full TLS Support: Enterprise NICs with complete hardware TLS offload capabilities

Step 1: Identify Your Network Hardware

Start by identifying your network interface hardware and current capabilities:

# List all network interfaces
ip link show

# Get detailed information about your ethernet controller
lspci | grep -i ethernet
# Example output: 02:00.0 Ethernet controller: Intel Corporation X710 for 10GbE SFP+ (rev 02)

# Get comprehensive PCI device information
lspci -vv | grep -A 25 "Ethernet controller"

# Check current driver information
ethtool -i eth0
# Look for driver name, version, and firmware version

Step 2: Check Current TLS Offload Status

Verify what TLS features your NIC currently supports and their status:

# Check TLS-specific offload features
ethtool -k eth0 | grep tls
# Expected output shows three key features:
# tls-hw-tx-offload: off [fixed] or on/off
# tls-hw-rx-offload: off [fixed] or on/off 
# tls-hw-record: off [fixed] or on/off

# View all available offload features
ethtool --show-offload eth0

# Check hardware features in detail
ethtool --show-features eth0 | grep -E "(tls|csum|gso|gro)"

Understanding the output:

on: Feature is enabled and working
off: Feature is disabled but can be enabled
[fixed]: Feature cannot be changed (usually means not supported by hardware)
[requested on]: Feature was requested but couldn’t be enabled

Step 3: Hardware Compatibility Database

Check if your specific NIC model supports TLS offload:

# Get exact NIC model and vendor information
lspci -nn | grep -i ethernet
# Example: 02:00.0 Ethernet controller [0200]: Intel Corporation X710 for 10GbE SFP+ [8086:1572]

# Check driver module information for TLS support
modinfo $(ethtool -i eth0 | grep driver | awk '{print $2}') | grep -i tls

# Verify driver version supports TLS features
ethtool -i eth0 | grep -E "(driver|version|firmware)"

Known TLS-Capable Hardware

** Intel Network Cards:**

# Intel X700 series (X710, X722) - i40e driver
# Check for Intel X710/X722 support:
lspci | grep -E "(X710|X722|82599)"

# Intel E800 series (E810) - ice driver 
# Check for Intel E810 support:
lspci | grep E810

Mellanox/NVIDIA ConnectX Series:

# ConnectX-5, ConnectX-6 series - mlx5_core driver
# Check for Mellanox cards:
lspci | grep -i mellanox

# Verify ConnectX model:
lspci -vv | grep -A 10 -i mellanox | grep "Part number"

Broadcom NetXtreme Series:

# NetXtreme-E series - bnxt_en driver
# Check for Broadcom cards:
lspci | grep -i broadcom

Step 4: Test Hardware TLS Capabilities

Attempt to enable TLS offload features to verify hardware support:

# Test if TLS TX offload can be enabled
sudo ethtool -K eth0 tls-hw-tx-offload on
echo "TX Offload test: $?"

# Test if TLS RX offload can be enabled 
sudo ethtool -K eth0 tls-hw-rx-offload on
echo "RX Offload test: $?"

# Check the results
ethtool -k eth0 | grep tls

# Look for any error messages
dmesg | tail -5

Interpreting results:

Success (return code 0): Hardware supports the feature
Failure (return code ≠ 0): Hardware doesn’t support this feature
No change in status: Feature may be already enabled or hardware doesn’t support it

Step 5: Verify Prerequisites

Some NICs require specific prerequisites before TLS offload can work:

# Check if checksum offload is enabled (required for TLS offload)
ethtool -k eth0 | grep -E "(rx-checksumming|tx-checksumming)"

# Enable checksum offload if disabled
sudo ethtool -K eth0 rx-checksumming on tx-checksumming on

# Check for other required features
ethtool -k eth0 | grep -E "(scatter-gather|tcp-segmentation-offload)"

# Some drivers require specific firmware versions
ethtool -i eth0 | grep firmware

Step 6: Advanced Hardware Detection

For more detailed hardware analysis:

# Check NIC's crypto capabilities at kernel level
cat /sys/class/net/eth0/device/vendor
cat /sys/class/net/eth0/device/device

# Look for hardware crypto engines
lspci -vv | grep -A 50 "Ethernet controller" | grep -i crypto

# Check interrupt vectors (more vectors often indicate more features)
cat /proc/interrupts | grep eth0

# Examine network device features at kernel level
cat /sys/class/net/eth0/features

Step 7: Validate with Kernel TLS Support

Verify that your kernel can work with your hardware:

# Ensure kernel TLS module is available
lsmod | grep tls || sudo modprobe tls

# Check kernel version compatibility
uname -r
# Minimum versions:
# - 4.13+ for basic kTLS
# - 4.17+ for RX offload 
# - 5.2+ for improved hardware support

# Test TLS ULP availability
cat /proc/sys/net/ipv4/tcp_available_ulp | grep tls

Once you’ve verified hardware support, you can proceed with confidence that your system can take full advantage of kernel TLS performance benefits. If your hardware doesn’t support TLS offload, you can still benefit from kTLS software mode, which provides kernel-level TLS processing advantages over userspace implementations.

kTLS makes TLS faster and simpler by moving encryption into the kernel and hardware instead of relying on complex userspace libraries. It reduces CPU load, streamlines operations, and gives high-performance secure apps a clear advantage.

References:

Kernel TLS offload — The Linux Kernel documentation The Linux Kernel

Kernel Transport Layer Security (kTLS) Offloads - NVIDIA Docs NVIDIA Docs

Kernel TLS — The Linux Kernel documentation The Linux Kernel

GitHub - oracle/ktls-utils: TLS handshake utilities for in-kernel TLS consumers

TLS handshake utilities for in-kernel TLS consumers - oracle/ktls-utils

GitHub · oracle

What Makes Bootable Containers Different from Traditional Containers?

2025-08-17T10:20:47Z

If you’ve used containers before, you already know how much they’ve changed the way we build and run apps. Tools like Docker and Kubernetes made packaging and deploying software simpler than ever. But there’s another step forward you might not have seen yet: bootable containers.

The Container Recap

Image Source: Docker

Traditional containers work by sharing the host’s kernel while providing isolated userspace environments for applications. When you run a Docker container, you’re essentially starting a segregated process on your host OS with its own filesystem, network interfaces, and process tree. The container runtime manages these containers on top of your existing operating system.

What Makes Bootable Containers Different?

Bootable containers flip this model on its head. Instead of running on top of an existing OS, they become the OS. A bootable container is packaged using container technologies but is designed to boot directly on bare metal or in a virtual machine.

Architecture comparison of Linux OS, regular containers, and bootable containers.

Bootable Containers vs. Traditional Linux OS

Aspect	Traditional Linux OS	Bootable Containers
Update Mechanism	Package-by-package with package manager	Atomic, image-based updates
Configuration	Often diverges between systems	Consistent across fleet
Filesystem	Mutable, changes in place	Immutable root filesystem
Installation	Unique per machine	Identical images across all systems
Customization	Ad-hoc changes on running system	Image rebuilding with version control
Rollbacks	Complex, often manual	Simple, atomic image rollback
Footprint	Often includes unnecessary packages	Minimal, purposefully designed
Security Profile	Larger attack surface	Reduced attack surface

Image Source: Redhat

With traditional OS, you typically install a base system and then modify it over time with package managers. Each system tends to evolve independently, leading to “configuration drift” where supposedly identical systems have subtle differences that cause problems.

Feature	Traditional Linux	Regular Containers	Bootable Containers
Execution	Direct on hardware	On host OS	Direct on hardware
Kernel	Own kernel	Shared host kernel	Own kernel
Updates	Package manager	Image replacement	OS image replacement
Isolation	None (full system)	Process/filesystem isolation	None (full system)
State	Stored on local disk	Ephemeral or volumes	Separate data volumes
Packaging	RPM/DEB packages	Container images	Container images
Boot Process	Traditional boot loader	Container runtime	Boot loader to container
Ideal For	General purpose	Application deployment	Infrastructure as code
Management	Configuration management	Container orchestration	Image-based orchestration

Bootable containers, on the other hand, treat the operating system as an immutable artifact. Rather than updating packages in place, you replace the entire OS image when updates are needed, ensuring consistency across your infrastructure.

Open Source Projects

Several projects are making bootable containers accessible:

1. bootc

bootc is Red Hat’s initiative for creating bootable containers. It enables:

Direct booting of OCI container images as the host OS
Integration with Fedora and RHEL ecosystems
Standardized approach to bootable containers
Simple transactional updates and rollbacks

bootc: Getting started with bootable containers | Red Hat Developer

With bootc (bootable containers), you can use the same container technology for building and managing immutable operating systems. Check out these two video demos and learn how to get started

Red Hat Developer · Valentin Rothberg

GitHub - bootc-dev/bootc: Boot and upgrade via container images

Boot and upgrade via container images. Contribute to bootc-dev/bootc development by creating an account on GitHub.

GitHub · bootc-dev

Introduction - bootc bootc

2. LinuxKit

Created by Docker, LinuxKit is a toolkit for building custom operating systems that run containers. It offers:

Modular approach to OS building with containers
Security-first design philosophy
Minimal base with just what you need
Ability to target multiple platforms including cloud and IoT

Announcing LinuxKit: A Toolkit for building Secure, Lean and Portable Linux Subsystems | Docker

Learn from Docker experts to simplify and advance your app development and management with Docker. Stay up to date on Docker events and new version

Docker · Justin Cormack

GitHub - linuxkit/linuxkit: A toolkit for building secure, portable and lean operating systems for containers

A toolkit for building secure, portable and lean operating systems for containers - linuxkit/linuxkit

GitHub · linuxkit

3. Other Notable Projects

Flatcar Container Linux : A community-driven immutable Linux distribution forked from CoreOS
AWS Bottlerocket : AWS’s minimal OS designed specifically for running containers
Fedora CoreOS : Red Hat’s immutable OS combining the best of CoreOS and Project Atomic
Talos Linux: ** **Kubernetes-focused OS built from container images.

What are the Use Cases?

1. Edge Computing at Scale

Scenario: A telecommunications company managing thousands of edge computing nodes across multiple countries.

Solution: Using bootable containers allows them to:

Deploy identical OS environments to all edge nodes
Update the entire fleet with a single tested image
Rollback problematic updates with a simple reboot
Reduce edge device management overhead

2. Hybrid Cloud Consistency

Scenario: An enterprise running workloads across on-premises data centers, AWS, and Azure.

Solution: Bootable containers provide:

The same base OS across all environments
Consistent behavior regardless of underlying infrastructure
Simplified compliance and security auditing
Reduced “works in my environment” issues

3. IoT Fleet Management

Scenario: Smart manufacturing deployment with hundreds of specialized devices on the factory floor.

Solution: Bootable containers deliver:

Reliable, atomic updates to all devices
Minimal OS footprint for resource-constrained devices
Automatic rollback if devices fail to come online after update
Unified management plane for the entire fleet

4. Security-Focused Operations

Scenario: Financial services company with strict security requirements.

Solution: Bootable containers enhance security through:

Reduced attack surface with minimal OS components
Immutable infrastructure preventing runtime modifications
Cryptographically verified OS images
Consistent security controls across all systems

Summary

Bootable containers reduce configuration drift, shrink the attack surface, and let you manage OS updates much like application releases. They’re especially useful for edge fleets, IoT, cloud-native node images, and security-sensitive environments.

Bootable containers package an entire operating system as an immutable, container-style image that can boot directly on hardware or in a VM. Unlike regular containers that depend on a host OS and share its kernel, bootable images become the OS: they provide a minimal, consistent runtime, atomic updates, and simple rollbacks.

What's Inside My Home Lab?

2025-08-07T08:50:48Z

Picture this: It’s 2 AM, and I’m staring at my AWS bill with a mix of horror and fascination. Another $100 gone, just for experimenting with some Kubernetes deployments and testing a few CI/CD pipelines. As a DevOps engineer, I live and breathe infrastructure, but those cloud costs were eating into my wallet faster than I could learn.

That’s when it hit me – why not bring the cloud home?

Why I Built a Home Lab ?

Let me be honest with you. Home labbing isn’t just a hobby; it’s an addiction. It’s that irresistible urge to understand how things really work beneath the abstractions of managed services and cloud platforms. When you’re in DevOps, SRE, or any infrastructure role, you quickly realize that reading documentation only gets you so far. You need to feel the pain of a failed deployment, experience the satisfaction of a perfectly configured load balancer, and yes, even troubleshoot why your DNS is acting up at 3 AM.

A home lab gives you something precious: a consequence-free environment where breaking things is not just acceptable, it’s encouraged. No angry Slack messages, no incident reports, just pure learning through experimentation.

But here’s the real kicker, it’s addictive. Once you taste the freedom of having your own infrastructure, you’ll find yourself constantly thinking: “What if I add another node?” or “Maybe I should try that new monitoring stack.” Before you know it, you’re explaining to your family why the internet cabinet now sounds like a small data center.

The Hardware Setup

My journey started with a simple principle: maximum learning for minimum cost. After getting burned by those cloud bills, I was determined to build something sustainable.

Dell OptiPlex 7040 with a Raspberry Pi 4B on the left side and a TP-Link Gigabit Fibre Router placed on top

One of the most cost-effective parts of my setup is a second-hand Dell OptiPlex 7040 Small Form factor (SFF) PC I found for just ₹4,000 (around $50). To complement it, I added two Raspberry Pis, each costing about $10, complete with a 3-month replacement warranty, 4GB of RAM, and a 32GB SanDisk memory card and all for ₹1,600 ($20).

This little machine packs some serious punch:

Intel i5 6th generation processor with Intel® HD Graphics 630
32GB DDR4 RAM (I upgraded this myself)
512GB Samsung 980 NVMe SSD for the OS and using as root drive
2TB SATA SSD for data and VM storage

Then there are my two Raspberry Pi 4B companions. One sits at home with a 32GB SanDisk SD card, while its sibling lives at my relative’s house with 64GB storage. Why the geographic distribution? Well, what’s the fun in a home lab without some multi-site complexity?

The total hardware investment? Around $70 USD. Compare that to a few months of serious cloud experimentation, and you’ll see why this made sense.

Networking and Connectivity

Here’s where things get interesting. My home setup runs on a TP-Link router with gigabit connections throughout. I invested in a dedicated public IP from my ISP, about 1,800 rupees ($20) annually. This gives me the flexibility to expose services properly and experiment with different networking configurations.

Dell OptiPlex 7040 PC with a TP-Link Gigabit router placed on top, connected with Ethernet and power cables.

The real magic happens with Tailscale. Initially, I planned to use WireGuard for connecting my distributed nodes. But after considering the config management overhead like generating keys, distributing configs, maintaining connections this is headache for me so I opted for Tailscale instead.

Tailscale creates a mesh network between all my devices. My home setup uses Tailscale’s subnet router feature to expose my entire LAN network, while the remote Raspberry Pi connects seamlessly from across the city. The beauty? No exposed ports, no complex firewall rules, just secure, encrypted communication between all nodes.

Tailscale dashboard showing all connected devices in my homelab and personal network.

The ease of management sold me completely. Instead of juggling WireGuard configs across multiple devices, I just setup Tailscale on each machine with pre auth tokens, and they instantly see each other. It’s like having a private cloud network that spans locations.

Running VMs with QEMU

Here’s where my home lab really comes alive. With only two physical nodes, I needed a way to create a realistic multi-node environment for learning.

I use QEMU-KVM as the hypervisor to run virtual machines with Ubuntu cloud-based images, and I leverage cloud-init for automated setup. For the initial configuration, such as creating users, adding SSH keys, and setting up the network with a static IP, I use Cockpit. Cockpit is a great tool for managing servers.

As you can see in the screenshots, I can easily manage virtual machines, monitor system resources, create or delete users, add SSH keys, and check the overall health of the system.

I run five virtual machines on the Dell OptiPlex each with 2 CPU cores, 4GB RAM, 100GB of storage.

3 Master nodes
2 Worker nodes

This configuration gives me a proper mini Kubernetes cluster with realistic resource constraints. Each VM runs Ubuntu Server, and the resource allocation ensures I can simulate real-world scenarios without overwhelming my physical hardware.

Why this specific setup? In production, you want odd numbers of master nodes for etcd quorum, and having separate workers lets me experiment with node affinity, taints, tolerations, and all those Kubernetes concepts that only make sense when you have multiple nodes to work with.

My Kubernetes Setup

Running full Kubernetes on resource-constrained hardware is like trying to fit an elephant in a Mini Cooper. That’s why I chose K3s, Rancher’s lightweight Kubernetes distribution. It gives me the complete Kubernetes API and functionality while being designed exactly for setups like mine.

K3s strips out the bloat while keeping everything you need for learning and development. It uses SQLite instead of etcd for single-node setups (though my cluster uses etcd), includes Traefik as the default ingress controller but i’m not using that, and comes with a built-in service load balancer.

This is where my setup gets really exciting. I practice GitOps using ArgoCD connected to my private GitHub repository.

My ArgoCD repo structure looks like this:

argocd/
├── Project-1/
│ ├── deployment.yaml
│ └── svc.yaml
├── Project-2/
└── Project-3/

Each project folder contains Kubernetes manifests – deployments, services, ingress rules, config maps. When I push changes to GitHub, I sync Argo CD (though I’m planning to automate this with webhooks), and my cluster updates accordingly.

This workflow mirrors what I use professionally, giving me hands-on experience with modern deployment practices. I can experiment with blue-green deployments, canary releases, and rollback strategies in a safe environment.

My Kubernetes networking uses Flannel for pod-to-pod communication across nodes. For exposing services, I primarily use NodePort, though I’m planning to implement MetalLB as a load balancer to get closer to production-like service exposure.

Docker and Container Management

While Kubernetes handles orchestration, I also run standalone Docker containers for services that don’t need the full Kubernetes treatment.

I use Portainer Business (free for individual users for one year) as my Docker management interface. It provides a web UI for managing containers, images, networks, and volumes. Through Portainer, I can quickly deploy new containers, monitor resource usage, check logs, and manage container lifecycles without dropping to the command line.

I’ve configured custom Docker bridge networks instead of using the default bridge. This gives me DNS resolution between containers – they can communicate using container names instead of IP addresses. It also provides network isolation and makes my reverse proxy configs much cleaner.

This setup makes my configurations much simpler – instead of hardcoding IP addresses, I reference containers by name, making everything more maintainable.

Exposing Services to the Internet

Getting my services accessible from the internet involves several layers. My TP-Link router handles port forwarding, directing incoming HTTP (80) and HTTPS (443) traffic to my Dell OptiPlex server. Having a dedicated public IP really helps here – no double NAT complications.

This is where Caddy comes in. I compiled Caddy with the Cloudflare DNS plugin to handle automatic SSL certificate provisioning and renewal through Let’s Encrypt.

Here’s how it works:

Caddy uses my Cloudflare DNS API token to create TXT records for domain validation
Let’s Encrypt validates domain ownership and issues certificates
Caddy handles certificate renewals automatically before expiration
Based on the domain/subdomain, Caddy routes traffic to appropriate backends

Final Caddyfile looks something like this:

{
 email {env.EMAIL}
# acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
 acme_ca https://acme-v02.api.letsencrypt.org/directory
 servers {
 protocols h1 h2 h3
 }
 admin off
 storage file_system {
 root /data
 }
 log {
 level DEBUG
 }
}

(tls_config) {
 tls {
 dns cloudflare {env.CLOUDFLARE_API_TOKEN}
 }
 header {
 Strict-Transport-Security "max-age=31536000;"
 X-Content-Type-Options "nosniff"
 X-Frame-Options "DENY"
 Referrer-Policy "strict-origin-when-cross-origin"
 }
}

cvscore.srvr.site {
 import tls_config
 reverse_proxy cvscore-dev:3000 {
 header_up X-Forwarded-For {remote_host}
 header_up X-Real-IP {remote_host}
 }
}

share.srvr.site {
 import tls_config
 reverse_proxy anyshare:3000
}

ip.srvr.site {
 import tls_config
 reverse_proxy http://10.1.1.15:30010
}

falcon.srvr.site {
 import tls_config
 reverse_proxy http://10.1.1.20:4000 {
 header_up X-Forwarded-For {remote_host}
 header_up X-Real-IP {remote_host}
 }
}

dev.srvr.site {
 import tls_config

 handle_path /api/* {
 reverse_proxy 10.1.1.20:4000
 }

 handle {
 reverse_proxy 10.1.1.20:3000
 }
}

ghost.srvr.site {
 import tls_config
 reverse_proxy http://10.1.1.20:2368
}

my.srvr.site {
 import tls_config

 header {
 -X-Frame-Options
 X-Frame-Options "SAMEORIGIN"
 }

 handle {
 reverse_proxy https://10.1.1.10:9090 {
 transport http {
 tls_insecure_skip_verify
 }
 header_up Host {host}
 header_up X-Forwarded-Proto https
 header_up Upgrade {http.request.header.Upgrade}
 header_up Connection {http.request.header.Connection}
 flush_interval -1
 }
 }
}


pi.srvr.site {
 import tls_config

 header {
 -X-Frame-Options
 X-Frame-Options "SAMEORIGIN"
 }

 handle {
 reverse_proxy https://10.1.1.100:9090 {
 transport http {
 tls_insecure_skip_verify
 }
 header_up Host {host}
 header_up X-Forwarded-Proto https
 header_up Upgrade {http.request.header.Upgrade}
 header_up Connection {http.request.header.Connection}
 flush_interval -1
 }
 }
}

monitor.srvr.site {
 import tls_config
 reverse_proxy 10.1.1.100:8090
}

argo.srvr.site {
 import tls_config
 reverse_proxy https://10.1.1.11:30443 {
 transport http {
 tls_insecure_skip_verify
 }
 }
}


drive.srvr.site {
 import tls_config
 reverse_proxy https://nextcloud:443 {
 transport http {
 tls_insecure_skip_verify
 }
 }
}

launch-stack.srvr.site {
 import tls_config
 reverse_proxy launchstack:3000
}

dm.srvr.site {
 import tls_config
 reverse_proxy jdownloader:5800
}

n8n.srvr.site {
 import tls_config
 reverse_proxy n8n:5678
}

registry.srvr.site {
 import tls_config
 reverse_proxy registry:5000
}

minio.srvr.site {
 import tls_config
 reverse_proxy minio:9001
}

s3.srvr.site {
 import tls_config
 reverse_proxy minio:9000
}

pin.srvr.site {
 import tls_config
 reverse_proxy karakeep:3000
}

code.srvr.site {
 import tls_config
 reverse_proxy code-server:8443
}

dns.srvr.site {
 import tls_config
 reverse_proxy 10.1.1.100:3000
}

photos.srvr.site {
 import tls_config
 reverse_proxy immich-server:2283
}

media.srvr.site {
 import tls_config
 reverse_proxy jellyfin:8096
}

portainer.srvr.site {
 import tls_config
 reverse_proxy https://portainer:9443 {
 transport http {
 tls_insecure_skip_verify
 }
 }
}

# Dynamic Proxy

*.srvr.site {
 import tls_config
 reverse_proxy {labels.2}.docker:5678
}

#Simp Today
(tls_config_simp) {
 tls {
 issuer acme {
 email {env.EMAIL_SIMP}
 dns cloudflare {env.CLOUDFLARE_API_TOKEN_SIMP}
 }
 }
 header {
 Strict-Transport-Security "max-age=31536000;"
 X-Content-Type-Options "nosniff"
 X-Frame-Options "DENY"
 Referrer-Policy "strict-origin-when-cross-origin"
 }
}

simp.today {
 import tls_config_simp
 reverse_proxy simp-frontend:80
}

api.simp.today {
 import tls_config_simp
 reverse_proxy simp-backend:3001
}

For Kubernetes services, I use NodePort exposures and route to the appropriate node and port combination. This gives me production-like HTTPS endpoints for all my services without manual certificate management.

When someone accesses my services, the request flows like this: DNS resolves to my public IP, hits my router on port 443, router forwards to Caddy, Caddy terminates SSL and routes to the appropriate container or Kubernetes service.

What I’m Actually Running

My home lab runs real services that I use daily, making the investment worthwhile beyond just learning.

AdGuard Home runs on my Raspberry Pi as both my home DNS server and network-wide ad blocker. I’ve configured multiple blocklists that filter ads, trackers, and malicious domains for every device on my network. Sometimes it blocks 30-40% of DNS queries!

Jellyfin is my personal media server – think Netflix, but completely under my control. I can stream my media collection to any device, anywhere (thanks to Tailscale), with transcoding capabilities.

Immich provides AI-powered photo organization and face recognition, like Google Photos but self-hosted. It’s connected to my MinIO storage backend for a complete photo management pipeline.

MinIO serves as S3-compatible object storage. This gives me backend storage for applications like Immich and a testing ground for any projects that need S3 integration, all without AWS costs.

Beszel is my lightweight monitoring solution that keeps tabs on all my nodes – both local and remote. It provides system metrics and dashboards without the complexity of a full monitoring stack.

What This Has Taught Me

Every component of this setup has taught me something valuable. I’ve learned about networking, from subnetting to DNS to reverse proxies. Security concepts like certificate management and network segmentation. Automation through GitOps workflows and infrastructure as code. Monitoring and observability. And lots of troubleshooting, because something always breaks at 2 AM.

The best part? These skills directly translate to my professional work. Concepts I experiment with at home often help me solve complex problems at work.

What’s Next

I’m already planning the next phase of my setup like adding more Raspberry Pi nodes for edge computing experiments, implementing a proper monitoring stack with Prometheus and Grafana, setting up a CI/CD pipeline, and experimenting with service mesh technologies.

The beauty of a home lab is that it’s never truly finished. There’s always another technology to explore, another problem to solve, another optimization to implement. And unlike those scary cloud bills, the only limit is your imagination (and maybe your electricity bill).

If you’re considering building your own home lab, my advice is simple: start small, start now, and prepare to be obsessed.

Ubuntu Server 24.04 LTS vs 22.04 LTS

2024-05-25T07:22:38Z

Ubuntu has long been a favourite among developers and system administrators for its stability, security, and ease of use. With the release of Ubuntu Server Core 24.04 LTS (Noble Numbat), there are several exciting updates and improvements over its predecessor, Ubuntu Server Core 22.04 LTS (Jammy Jellyfish).

Let’s see what exciting changes this latest release brings to the table.

Linux Kernel and System Updates

First things first, Ubuntu 24.04 LTS comes with Linux kernel 6.8, which is a major upgrade over the 5.15 kernel used in 22.04 LTS. This new kernel promises better performance, improved hardware support, and stronger security measures.

Feature	Ubuntu 22.04 LTS	Ubuntu 24.04 LTS
Kernel Version	5.15	6.8
Performance	Standard	Enhanced
Hardware Support	Limited	Improved

Performance Engineering

Ubuntu 24.04 LTS brings several improvements to performance:

Performance tools are now pre-enabled and pre-loaded, allowing you to use them right away.
Low-latency kernel features have been merged into the default kernel, reducing task scheduling delays.
Frame pointers are enabled by default on 64-bit architectures, enabling accurate and complete flame graphs for performance engineers.
bpftrace is now a standard tool alongside existing profiling utilities.

Feature	Ubuntu 22.04 LTS	Ubuntu 24.04 LTS
Performance Tools	Basic	Pre-enabled
Low-latency Kernel Features	No	Yes
Frame Pointers	No	Yes
bpftrace	No	Yes

Security Enhancements

Ubuntu 24.04 LTS takes security very seriously, and you’ll find significant improvements in this area:

Free security maintenance for the main repository has been extended to 5 years, with an option to add 5 more years and include the universe repository via Ubuntu Pro.
A legacy support add-on is now available for organizations that require long-term stability beyond 10 years.

Security Feature	Ubuntu 22.04 LTS	Ubuntu 24.04 LTS
Free Security Maintenance	5 years	5 years + 5 optional
Legacy Support	No	Yes

Support Lifespan and Upgrades

Ubuntu 24.04 LTS comes with an extended support lifespan and improved upgrade options:

Support duration has been increased to 5 years, with the option to extend it further.
Automatic upgrades will be offered to users of Ubuntu 23.10 and 22.04 LTS when 24.04.1 LTS is released.

Feature/Support	Ubuntu 22.04 LTS	Ubuntu 24.04 LTS
Support Duration	5 years (specific editions)	5 years + optional extension
Automatic Upgrades	No	Yes (for 23.10 and 22.04)

New Features and Package Updates

Ubuntu 24.04 LTS brings a few exciting new features and package updates:

Year 2038 support has been added for the armhf architecture.
Linux kernel 6.8 and systemd v255.4 are the latest versions included.

New Feature	Ubuntu 22.04 LTS	Ubuntu 24.04 LTS
Year 2038 Support	No	Yes
Linux Kernel Version	5.15	6.8
Systemd Version	249	255.4

Application and Service Improvements

Several key applications and services have received updates in Ubuntu 24.04 LTS:

Nginx has been updated to version 1.24, offering better support for modern web protocols and improved performance.
OpenLDAP has been upgraded to version 2.6.7, bringing bug fixes and enhancements.
LXD is no longer pre-installed, reducing the initial footprint, but will be installed upon first use.
Monitoring plugins have been updated to version 2.3.5, including multiple enhancements and new features for better system monitoring.

Service/Feature	Ubuntu 22.04 LTS	Ubuntu 24.04 LTS
Nginx	1.20	1.24
OpenLDAP	2.5	2.6.7
LXD	Pre-installed	Installed on use
Monitoring Plugins	2.3.2	2.3.5

Infrastructure and Deployment

Ubuntu 24.04 LTS also brings improvements to infrastructure and deployment:

The new Landscape web portal is built with Canonical’s Vanilla Framework, providing an improved API, better accessibility, and a new repository snapshot service.
Enhanced management capabilities for snaps, supporting on-premises, mixed, and hybrid cloud environments.

Should You Upgrade from Ubuntu Server 22.04 LTS to 24.04 LTS?

Currently Ubuntu Server 24.04 LTS offers:

Improved hardware support and compatibility with linux kernel 6.8
Performance enhancements and faster boot times
Extended 5-year support lifespan until June 2029
Stronger security with 5+5 years of maintenance, legacy support add-on
Seamless upgrade path from 23.10 and 22.04 LTS
Updated packages like NGINX, OpenLDAP, and monitoring plugins

The decision to upgrade from 22.04 LTS should consider:

New hardware/peripheral compatibility needs
Performance requirements for workloads
Security and compliance priorities
Support window and maintenance needs
Ease of upgrade and potential downtime

Also, Testing for stability and compatibility is crucial, especially for critical applications.

Ubuntu Release Notes:

Is FaaS the Same as Serverless?

Are you confused about the difference between FaaS and serverless computing? All FaaS is serverless, but not all serverless is FaaS.

firstfinger · Anurag Vishwakarma

How Companies Are Saving Millions by Migrating Away from AWS to Bare Metal Servers?

Many startups initially launch on AWS or other public clouds because it allows rapid scaling without upfront investments. But as these companies grow, the operating costs steadily rise.

firstfinger · Anurag Vishwakarma

Is FaaS the Same as Serverless?

2024-04-21T10:38:24Z

Suppose, as a small business owner, you’ve worked hard to build an e-commerce website that showcases your unique products. Your website is gaining traction, and you’re starting to see a steady increase in customer traffic. However, with this growth comes a new challenge - scalability.

Credit: Melody Onyeocha on Dribble

Whenever a customer clicks your site’s “Buy Now” button, your web application needs to process the order instantly, update the inventory, and send a confirmation email. But what happens when hundreds of customers start placing orders simultaneously? Your current server-based architecture simply can’t keep up, leading to slow response times, frustrated customers, and lost sales.

So you need a more scalable solution for your web application. This is where serverless computing comes in, allowing you to focus on code rather than infrastructure.

What is FaaS (Functions as a Service)?

Functions as a Service (FaaS) is a cloud computing service that allows you to run your code in response to specific events or requests, without the need to manage the underlying infrastructure. With FaaS, you simply write the individual functions (or “microservices”) that make up your application, and the cloud provider takes care of provisioning servers, scaling resources, and managing the runtime environment.

The benefits of FaaS:

Pay-per-use: You only pay for the compute time when your functions are executed, rather than paying for always-on server capacity.
Automatic scaling: The cloud provider automatically scales your functions up or down based on incoming traffic, ensuring your application can handle sudden spikes in demand.
Focus on code: With the infrastructure management handled by the cloud provider, you can focus solely on writing the business logic for your application.

FaaS is specifically focused on building and running applications as a set of independent functions or microservices. Major cloud providers like AWS (Lambda) , Microsoft Azure (Functions) , and Google Cloud (Cloud Functions) offer FaaS platforms that allow developers to write and deploy individual functions without managing the underlying infrastructure.

How Companies Are Saving Millions by Migrating Away from AWS to Bare Metal Servers?

Many startups initially launch on AWS or other public clouds because it allows rapid scaling without upfront investments. But as these companies grow, the operating costs steadily rise.

firstfinger · Anurag Vishwakarma

What is Serverless?

Serverless is a broader cloud computing model that involves FaaS but also includes other fully managed services like databases (e.g., AWS DynamoDB, Azure Cosmos DB, Google Cloud Datastore), message queues (e.g., AWS SQS, Azure Service Bus, Google Cloud Pub/Sub), and storage (e.g., AWS S3, Azure Blob Storage, Google Cloud Storage).

In a serverless architecture, the cloud provider is responsible for provisioning, scaling, and managing the entire backend infrastructure required to run your application.

The benefits of Serverless Computing:

Reduced operational overhead: With no servers to manage, you can focus entirely on building your application without worrying about infrastructure.
Event-driven architecture: Serverless applications are designed around event triggers, allowing you to react to user actions, data changes, or scheduled events in real time.
Seamless scalability: Serverless platforms automatically scale your application’s resources up and down based on demand, with no additional configuration required on your part.

Monolithic vs Microservices Architecture

Monolithic architectures accelerate time-to-market, while Microservices are more suited for longer-term flexibility and maintainability at a substantial scale.

firstfinger · Anurag Vishwakarma

FaaS vs Serverless

Feature	FaaS	Serverless
Infrastructure Management	Handles provisioning and scaling of servers/containers for your functions	Handles provisioning and scaling of the entire backend infrastructure, including servers, databases, message queues, etc.
Pricing Model	Pay-per-execution (cost per function invocation)	Pay-per-use (cost per resource consumption, e.g., CPU, memory, data transfer)
Scalability	Automatically scales functions up and down based on demand	Automatically scales the entire application infrastructure up and down based on demand
Stateful vs. Stateless	Functions are typically stateless	Supports both stateful and stateless services
Event-Driven Architecture	Supports event-driven execution of functions	Natively supports event-driven architecture with managed event services
Third-Party Service Integration	Integrates with other cloud services through API calls	Seamless integration with a rich ecosystem of managed cloud services
Development Focus	Concentrate on writing the application logic in the form of functions	Concentrate on building the overall application structure and leveraging managed services
Vendor Lock-in	Some vendor lock-in, as functions are typically tied to a specific FaaS platform	Potential for vendor lock-in, as Serverless often relies on a broader set of managed services
Examples	AWS Lambda, Azure Functions, Google Cloud Functions, IBM Cloud Functions	AWS (Lambda, API Gateway, DynamoDB), Azure (Functions, Cosmos DB, Event Grid), Google Cloud (Functions, Datastore, Pub/Sub), IBM Cloud (Functions, Object Storage, Databases)
Infrastructure Management	Handles provisioning and scaling of servers/containers for your functions	Handles provisioning and scaling of the entire backend infrastructure, including servers, databases, message queues, etc.

1. Scope

FaaS is a specific type of serverless architecture that is focused on building and running applications as a set of independent functions. Serverless computing, on the other hand, is a broader term that encompasses a range of cloud computing models, including FaaS, BaaS, and others.

2. Granularity

FaaS is a more fine-grained approach to building and running applications, as it allows developers to break down applications into smaller, independent functions. Serverless computing, on the other hand, can be used to build and run entire applications, not just individual functions.

3. Pricing

FaaS providers typically charge based on the number of function executions and the duration of those executions. Serverless computing providers, on the other hand, may charge based on a variety of factors, such as the number of API requests, the amount of data stored, and the number of users.

Monorepos vs Microrepos: Which is better?

Find out why companies choose Monorepos over Microrepos strategies and how they impact scalability, governance, and code quality.

firstfinger · Anurag Vishwakarma

Major cloud providers that offer FaaS and serverless computing services:

AWS Lambda - AWS Lambda is a FaaS platform that allows developers to run code without provisioning or managing servers. Lambda supports a variety of programming languages, including Python, Node.js, Java, and C#.
Azure Functions - Azure Functions is a serverless computing service that allows developers to build event-driven applications using a variety of programming languages, including C#, Java, JavaScript, and Python.
Google Cloud Functions - Google Cloud Functions is a FaaS platform that allows developers to run code in response to specific events, such as changes to a Cloud Storage bucket or the creation of a Pub/Sub message.
IBM Cloud Functions - IBM Cloud Functions is a serverless computing platform that allows developers to build and run event-driven applications using a variety of programming languages, including Node.js, Swift, and Java.
Oracle Cloud Functions - Oracle Cloud Functions is a FaaS platform that allows developers to build and run serverless applications using a variety of programming languages, including Python, Node.js, and Java.

Choosing Between FaaS and Serverless

Use FaaS for:

Microservices-based applications where you need flexibility and the ability to scale individual functions.
Real-time data processing and event-driven architectures .

Opt for serverless computing when:

You’re deploying complex applications that require a unified environment for all components.
You want to reduce the operational overhead of managing servers while maintaining control over application configurations.

AWS Lambda vs. Lambda@Edge: Which Serverless Service Should You Use?

Lambda is regional while Lambda@Edge runs globally at edge locations. Lambda integrates with more AWS services. Lambda@Edge works with CloudFront.

firstfinger · Anurag Vishwakarma

Understand with an Example

Suppose you want to build a simple web application that allows users to upload images and apply filters to them. With a traditional server-based architecture, you would need to provision and manage servers, install and configure software, and handle scaling and availability. This can be time-consuming and expensive, especially if you’re just starting out.

***With a serverless architecture, on the other hand, you can focus on writing the code for the application logic, and let the cloud provider handle the rest. ***

For instance, you could use AWS Lambda (FaaS) to run the code that processes the uploaded images, AWS S3 for storage, and other AWS services like API Gateway and DynamoDB as part of the overall serverless architecture. The cloud provider would automatically scale the resources up or down based on demand, and you would only pay for the resources you actually use.

FaaS is a type of serverless architecture, but the two terms are not the same. FaaS is all about creating and running applications as separate functions, while serverless computing is a wider term that covers different cloud computing models. In other words, FaaS is a specific way of doing serverless computing that involves breaking down an application into small, independent functions that can be run separately. Serverless computing, on the other hand, is a more general approach that can involve using different cloud services to build and run an application without having to manage servers.

Development Tooling and Community Support

The major cloud providers offer varying levels of tooling and community support for their FaaS and serverless offerings. AWS has the largest community and a mature set of tools like AWS SAM for local development and testing of serverless applications.

Microsoft Azure has good tooling integration with Visual Studio Code, while Google Cloud’s tooling is still catching up. A strong developer ecosystem and community support can be crucial when building and maintaining serverless applications.

AWS vs Azure vs Google Cloud in Serverless Computing

FaaS Platform

Feature	Lambda	Azure Functions	Cloud Functions
Arm64 architecture	✅	❌	❌
Compiled binary deployment	✅	✅	❌
Wildcard SSL certificate free	✅	❌	✅
Serverless KV store	DynamoDB	CosmosDB	Datastore
Serverless SQL	Aurora Serverless	Azure SQL	BigQuery
IaC deployment templates	SAM, CloudFormation	ARM, Bicep	GDM
IaC drift detection	✅	❌	❌
Single shot stack deployment	✅	❌	❌

Developement

Feature	Lambda	Azure Functions	Cloud Functions
Virtualized local execution	✅	❌	❌
FaaS dev tools native for arm64	✅	❌	✅
Go SDK support	✅	✅	✅
PHP SDK support	✅	✅	✅
VSCode tooling	✅	✅	✅
Dev tools native for Apple Silicon	✅	❌	✅

Community

Feature	Lambda	Azure Functions	Cloud Functions
Reddit community members	278,455	141,924	46,415
Stack Overflow members	256,700	216,100	54,300
Videos on YouTube channel	16,308	1,475	4,750
Twitter/X followers	2.2 M	1 M	533 K
GitHub stars for JS SDK	7.5 K	1.9 K	2.8 K
GitHub stars for .NET SDK	2 K	5 K	908
GitHub stars for Python SDK	8.7 K	2.7 K	4.6 K
GitHub stars for Go SDK	8.5 K	1.5 K	3.6 K

Runtimes

Runtime	Lambda	Azure Functions	Cloud Functions
Custom (Linux)	✅	✅	❌
Custom (Windows)	❌	✅	❌
Python	✅	✅	✅
Node.js	✅	✅	✅
PHP	❌	❌	✅
Ruby	✅	❌	✅
Java	✅	✅	✅
.NET	✅	✅	✅
Go	✅	✅	✅
Rust	✅	✅	❌
C/C++	✅	✅	❌

Serverless AI

Provider	Lambda	Azure Functions	Cloud Functions
Open AI	❌	✅	❌
Gemini	❌	❌	✅
Anthropic	✅	✅	✅
Meta Llama2	✅	✅	✅
Cohere	✅	✅	✅
AI21	✅	❌	❌
Amazon Titan	✅	❌	❌
Mistral	✅	✅	✅
Stability (SDXL)	✅	❌	✅
Computer Vision	✅	✅	✅

Bare Metal Servers vs. Dedicated Host

Bare metal gives you total control over the hypervisor for maximum flexibility and resource optimization. Dedicated hosts keep things simple with the cloud provider managing the VMs for you.

firstfinger · Anurag Vishwakarma

Ansible vs Terraform

Infrastructure automation and configuration management are two essential practices in modern IT operations, particularly in the DevOps & Cloud.

firstfinger · Anurag Vishwakarma

Bare Metal Servers vs. Dedicated Host

2024-04-04T05:13:14Z

Let’s imagine you’re the owner of a fastest-growing e-commerce business. Your online store is getting more and more traffic every day, and you need to scale up your server infrastructure to handle the increased load. You’ve decided to move your operations to the cloud, but you’re unsure whether to go with bare metal servers or dedicated hosts. How does it impact your growth of business?

What are Bare Metal Servers & Dedicated Hosts, and what is the main difference?

Bare Metal vs. Dedicated Host

Both bare metal servers and dedicated hosts are physical machines located in a cloud provider’s data center. The main difference lies in who manages the hypervisor layer – the software that allows you to run multiple virtual machines (VMs) on a single physical server.

What is a Hypervisor and What Does It Do?

A hypervisor is a software layer that creates and runs virtual machines (VMs) on a physical host machine. It allows multiple operating systems to share the same hardware resources, such as CPU, memory, and storage. Each VM runs its own operating system and applications, isolated from the others, providing a secure and efficient way to run multiple workloads on a single physical server.

Types of Hypervisors Used in Cloud Data Centers

Type 1 (Bare-Metal)
Type 2 (Hosted)

Type 1 Hypervisor vs Type 2 Hypervisor

Type 1 (Bare-Metal) Hypervisors run directly on the host’s hardware, providing better performance and efficiency. Examples include VMware ESXi, Microsoft Hyper-V, and Citrix Hypervisor.

Type 2 (Hosted) Hypervisors run on top of a host operating system, like Windows or Linux. Examples include VMware Workstation, Oracle VirtualBox, and Parallels Desktop .

Bare Metal vs Virtual Machines vs Containers: The Differences

When deploying a modern application stack, how do we decide which one to use? Bare Metal, VMs or Containers?

firstfinger · Anurag Vishwakarma

Bare Metal Servers: Full Control but More Complexity

With a bare metal server, you’re essentially renting the entire physical machine from the cloud provider. However, you’re also responsible for installing and managing the hypervisor software yourself. This gives you a lot of control and flexibility. You can tweak the hypervisor settings to optimize performance, overcommit resources (like CPU and RAM) to squeeze more virtual machines onto the physical server, and have direct access to the hypervisor for monitoring, logging, and backing up your VMs.

Feature	Bare Metal Server	Dedicated Host
Hardware	Physical server rented from cloud provider	Physical server rented from cloud provider
Hypervisor Management	Customer installs and manages the hypervisor software	Cloud provider installs and manages the hypervisor software
Hypervisor Control	Full control over hypervisor configuration settings	Limited or no control over hypervisor settings
Resource Allocation	Can overcommit CPU, RAM across VMs for efficiency	Limited ability to overcommit resources across VMs
Monitoring	Direct access to hypervisor for monitoring and logging	Rely on cloud provider’s monitoring tools
Backup/Recovery	Can backup VMs directly through hypervisor	Must use cloud provider’s backup/recovery services
Scalability	Scale VMs up/down based on available server resources	Request cloud provider to scale VMs up/down
Security	Responsible for securing the hypervisor layer	Cloud provider secures the hypervisor layer
Management Complexity	High, requires hypervisor expertise	Low, cloud provider handles hypervisor management
Pricing Model	Pay for entire physical server capacity	Pay for VM instances based on usage
Use Cases	High performance, legacy apps, regulatory compliance	General-purpose applications, simplified operations
Examples	IBM Cloud Bare Metal, AWS EC2 Bare Metal	IBM Cloud Dedicated Hosts, AWS Dedicated Hosts

Dedicated Hosts: Simplicity but Less Control

On the other hand, a dedicated host is like renting an apartment in a managed building. The cloud provider takes care of the hypervisor layer for you. All you have to do is tell them how many virtual machines you want, and they’ll set them up on the dedicated host for you. You don’t have to worry about managing the hypervisor or any of the underlying infrastructure.

The trade-off, of course, is that you have less control over the specifics. You can’t overcommit resources or tinker with the hypervisor settings. But for many businesses, the simplicity and convenience of a dedicated host are worth it.

How Companies Are Saving Millions by Migrating Away from AWS to Bare Metal Servers?

Many startups initially launch on AWS or other public clouds because it allows rapid scaling without upfront investments. But as these companies grow, the operating costs steadily rise.

firstfinger · Anurag Vishwakarma

Open-Source Hypervisor Alternatives

While cloud providers typically use proprietary hypervisors like VMware ESXi or Hyper-V, there are also free and open-source alternatives available, such as:

Proxmox Virtual Environment (Proxmox VE): A complete open-source server virtualization management solution that includes a KVM hypervisor and a web-based management interface.
Kernel-based Virtual Machine (KVM): A type 1 hypervisor that’s part of the Linux kernel, providing virtualization capabilities without requiring proprietary software.
Xen Project Hypervisor: An open-source type 1 hypervisor that supports a wide range of guest operating systems and virtualization use cases.

Which Option is Right for Your E-commerce Business?

If you have a team of skilled system administrators who love getting their hands dirty with server configurations, and you need the flexibility to fine-tune your infrastructure for optimal performance, a bare metal server might be the way to go.

However, if you’d rather focus on your core business and leave the nitty-gritty server management to the experts, a dedicated host could be a better fit. It’s a more hands-off approach, allowing you to concentrate on building and scaling your e-commerce platform without worrying about the underlying infrastructure.

Should You Use Open Source Large Language Models?

The benefits, risks, and considerations associated with using open-source LLMs, as well as the comparison with proprietary models.

firstfinger · Anurag Vishwakarma

DevOps vs SRE vs Platform Engineering - Explained

At small companies, engineers often wear multiple hats, juggling a mix of responsibilities. Large companies have specialized teams with clearly defined roles in DevOps, SRE, and Platform Engineering.

firstfinger · Anurag Vishwakarma

Ansible vs Terraform

2024-04-02T20:15:01Z

Imagine, As your business grows bigger, setting up and configuring things like servers, databases, and networks becomes a real pain if you do it by hand. Spinning up new servers one by one, copying and pasting commands, and keeping track of everything is super time-consuming and mistakes happen easily. Keeping all your servers configured the same way, installing updates, and deploying new code versions is a nightmare without help.

That’s where tools like Terraform and Ansible come to the rescue. Terraform is awesome at setting up your infrastructure like servers, networks, and databases. Instead of doing everything manually, you write code that describes what you want, and Terraform handles it for you. Need 10 new servers? Terraform gets it done with just a few commands.

Ansible is the superhero for configuring those servers. You create instructions called playbooks that tell Ansible how to set up each server. Install software? Check. Deploy your code? Check. Update everything? Easy peasy. Ansible makes sure all your servers are configured consistently.

But it gets even better! With Terraform and Ansible, you have your entire infrastructure and configurations defined as code. This makes it super easy to see what changed, roll back to an earlier version if needed, and prove you’re following regulations.

6 Reasons: Why Do We Need Infrastructure Automation and Configuration Management (IaC) Tools?

Eliminating Manual Errors
Increasing Speed and Efficiency
Ensuring Consistency and Standardization
Improving Security and Compliance
Facilitating Collaboration and Version Control
Simplifying Disaster Recovery and Rollbacks

Infrastructure automation refers to the process of using software tools and scripts to automate the provisioning, configuration, and management of IT infrastructure resources, such as virtual machines , networks , load balancers , and storage systems .

Configuration management is the practice of maintaining the desired state and configuration of IT systems and services throughout their lifecycle. It involves tracking, managing, and updating the configuration items (CIs) that make up an IT system, such as software, hardware, and network devices.

How Companies Are Saving Millions by Migrating Away from AWS to Bare Metal Servers?

Many startups initially launch on AWS or other public clouds because it allows rapid scaling without upfront investments. But as these companies grow, the operating costs steadily rise.

firstfinger · Anurag Vishwakarma

Terraform: The Infrastructure Provisioning Tool

Terraform is a declarative infrastructure provisioning tool that shines when it comes to spinning up resources across multiple cloud providers.

Terraform’s strengths lie in:

1. Declarative Approach

Terraform’s declarative nature means you define your desired infrastructure state, and it figures out the necessary steps to achieve that state. This approach simplifies complex provisioning scenarios and ensures consistent, repeatable deployments.

2. State Management and Lifecycle Management

Terraform maintains a state file that tracks the resources it has provisioned. This state file enables seamless lifecycle management, allowing you to modify or delete resources without manual intervention. If you remove a resource from your configuration, Terraform will automatically delete it during the next application.

3. Idempotency

Terraform is idempotent, meaning you can run it multiple times without unintended changes to your infrastructure. If no changes are required, Terraform won’t perform any actions, saving you time and effort.

DevOps vs SRE vs Platform Engineering - Explained

At small companies, engineers often wear multiple hats, juggling a mix of responsibilities. Large companies have specialized teams with clearly defined roles in DevOps, SRE, and Platform Engineering.

firstfinger · Anurag Vishwakarma

Ansible: The Configuration Management Tool

Ansible is a powerful configuration management tool that excels at automating application deployments, system configurations, and ongoing maintenance tasks.

Ansible strengths are:

1. Hybrid Approach

Ansible combines declarative resources with procedural execution, providing a flexible approach to configuration management. While resources are defined in a declarative manner, they are executed procedurally.

2. Application Deployment

Ansible simplifies the process of deploying applications by automating tasks like installing dependencies, copying files, and starting services.

3. Agentless

Unlike some other configuration management tools, Ansible doesn’t require an agent to be installed on the managed nodes. This agentless architecture makes it easy to manage diverse environments without additional overhead.

System Design vs Software Architecture : What You Need to Know

System design and software architecture are two sides of same coin, both integral to the process of creating a software system. But, they’re not the same thing.

firstfinger · Anurag Vishwakarma

Ansible vs Terraform

Category	Ansible	Terraform
Primary Focus	Configuration management, application deployment, orchestration	Infrastructure as Code (IaC)
Language	YAML (Playbooks)	HCL (Configuration files)
Agent	Agentless (connects via SSH)	Agent-based (Terraform agent)
Resource Management	Manages existing resources	Creates and manages resources
Change Handling	Idempotent; handles changes in config	Versioning and drift detection
Providers	Limited to supported modules	Extensive list of providers
Cloud Support	Good cloud support	Excellent cloud support
Use Cases	Application Deployment, Configuration Management, Orchestration	Infrastructure Provisioning, Resource Management

What is the Difference Between Snapshot & Image in AWS EC2?

Differentiating between ‘Snapshot’ and ‘Image’: their purposes for backups and launching instances on AWS EC2.

firstfinger · Anurag Vishwakarma

Using Terraform and Ansible Together

While Terraform and Ansible have distinct strengths, they can work together seamlessly to provide a complete infrastructure automation solution.

Here are two common approaches:

First Approach: Start with Terraform for Provisioning, then Use Ansible for Configuration Management

In this approach, you begin by defining your infrastructure resources using Terraform. Once the provisioning is complete, you can invoke Ansible from within your Terraform configuration to handle configuration management tasks on the newly created resources.

# Terraform configuration
resource "aws_instance" "web_server" {
 # ... instance details ...

 provisioner "local-exec" {
 command = "ansible-playbook -i '${aws_instance.web_server.public_ip},' playbook.yml"
 }
}

Second Approach: Start with Ansible and Call Terraform for Initial Provisioning

Alternatively, you can start with an Ansible playbook and call Terraform from within it to handle the initial infrastructure provisioning. Once the resources are ready, Ansible can take over and manage their configuration.

# Ansible playbook
- hosts: localhost
 tasks:
 - name: Provision infrastructure with Terraform
 terraform:
 project_path: '/path/to/terraform/project'
 state: present

 - name: Configure provisioned resources
 # ... configuration management tasks ...

What Makes Load Balancer vs. API Gateway Different and Use Cases ?

Discover the key distinctions between Load Balancer and API Gateway, along with their unique use cases like efficient traffic distribution & integration.

firstfinger · Anurag Vishwakarma

Example: Setting up a Jenkins Environment Using Terraform and Ansible

Now, let’s put our knowledge into action by setting up a Jenkins environment using Terraform and Ansible.

1. Terraform for Provisioning an EC2 Instance on AWS

provider "aws" {
 region = var.region
}

resource "aws_vpc" "main" {
 # ... VPC configuration ...
}

resource "aws_instance" "jenkins" {
 ami = data.aws_ami.ubuntu.id
 instance_type = var.instance_type
 # ... other instance details ...
}

variable "region" {
 default = "us-east-1"
}

variable "instance_type" {
 default = "t2.micro"
}

How to Create & Deploy EC2 Instance Using Terraform?

2. Ansible for Deploying Docker and Running Jenkins Container

Once the EC2 instance is provisioned, Ansible takes over to deploy Docker and run the Jenkins container .

Here’s what the Ansible playbook looks like:

- hosts: jenkins_hosts
 become: yes
 tasks:
 - name: Install prerequisites
 apt:
 name:
 - apt-transport-https
 - ca-certificates
 - curl
 - software-properties-common
 state: latest

 - name: Add Docker GPG key
 apt_key:
 url: https://download.docker.com/linux/ubuntu/gpg
 state: present

 # ... additional tasks to install Docker ...

 - name: Pull Jenkins Docker image
 docker_image:
 name: jenkins/jenkins:lts
 source: pull

 - name: Run Jenkins container
 docker_container:
 name: jenkins
 image: jenkins/jenkins:lts
 ports:
 - "8080:8080"

We start by defining our infrastructure resources using Terraform. Then, we run terraform apply to provision the required resources. Once the infrastructure is provisioned, we invoke an Ansible playbook to configure and manage the resources as needed.

Terraform and Ansible are not competitors; they are complementary tools that, when used together, can unlock the full potential of infrastructure automation.

How to Create & Deploy EC2 Instance Using Terraform?

Learn how to create and deploy AWS EC2 instances using Terraform for efficient cloud infrastructure management.

firstfinger · Anurag Vishwakarma

Self-Host Open-Source Slash Link Shortener on Docker

2024-04-02T06:33:50Z

Sharing links is an integral part of our daily online communication. However, dealing with long, complex URLs can be a hassle, making remembering and sharing links efficiently difficult.

What is Slash?

Slash Link Shortener Dashboard

Slash is an open-source, self-hosted link shortener that simplifies the managing and sharing of links. Slash allows you to create customizable, shortened URLs (called “shortcuts”) for any website or online resource. With Slash, you can say goodbye to the chaos of managing lengthy links and embrace a more organized and streamlined approach to sharing information online.

One of the great things about Slash is that it can be self-hosted using Docker. By self-hosting Slash, you have complete control over your data.

Features of Slash:

Custom Shortcuts: Transform any URL into a concise, memorable shortcut for easy sharing and access.
Tag Organization: Categorize your shortcuts using tags for efficient sorting and retrieval.
Team Sharing: Collaborate by sharing shortcuts with your team members.
Link Analytics: Track link traffic and sources to understand usage.
Browser Extension: Access shortcuts directly from your browser’s address bar on Chrome & Firefox.
Collections: Group related shortcuts into collections for better organization.

Deploying WordPress with MySQL, Redis, and NGINX on Docker

Set up WordPress with a MySQL database and Redis as an object cache on Docker with an NGINX Reverse Proxy for blazing-fast performance.

firstfinger · Anurag Vishwakarma

Setup Slash Link Shortner with Docker

Follow the simple steps to get Slash up and running on your server or local machine.

Prerequisites:

Basic knowledge of Docker and Docker Compose
Docker & Docker Compose installed on your machine
A domain name or IP address pointing to your server

Method 1: Docker Run CLI

The docker run command is used to create and start a new Docker container. To deploy Slash, run:

docker run -d --name slash -p 5231:5231 -v ~/.slash/:/var/opt/slash yourselfhosted/slash:latest

Let’s break down what this command does:

docker run tells Docker to create and start a new container
-d runs the container in detached mode (in the background)
--name slash gives the container the name “slash” for easy reference
-p 5231:5231 maps the container’s port 5231 to the host’s port 5231, allowing access to Slash from your browser
-v ~/.slash/:/var/opt/slash creates a volume to store Slash’s persistent data on your host machine
yourselfhosted/slash:latest specifies the Docker image to use (the latest version of Slash)

After running this command, your Slash instance will be accessible at http://your-server-ip:5231.

Method 2: Docker Compose

Docker Compose is a tool that simplifies defining and running multi-container Docker applications. It uses a YAML file to configure the application’s services.

Create a new file named docker-compose.yml and paste the contents of the Docker Compose file provided below.

version: '3'

services:
 slash:
 image: yourselfhosted/slash:latest
 container_name: slash
 ports:
 - 5231:5231
 volumes:
 - slash:/var/opt/slash
 restart: unless-stopped

volumes:
 slash:

Start Slash using the Docker Compose command:

docker compose up -d

This command will pull the required Docker images and start the Slash container in the background.

After running this command, your Slash container will be accessible at http://your-server-ip:5231

Slash is ready & allows you to create, manage, and share shortened URLs without relying on third-party services or compromising your data privacy.

Setup Memos Note-Taking App with MySQL on Docker & S3 Storage

Self-host the open-source, privacy-focused note-taking app Memos using Docker with a MySQL database and integrate with S3 or Cloudflare R2 object storage.

firstfinger · Anurag Vishwakarma

Benefits of Self-Hosting Slash Link Shortener

By self-hosting you gain several advantages:

Data Privacy: Keep your data and links secure within your infrastructure, ensuring complete control over your information.
Customization: Tailor Slash to your specific needs, such as branding, integrations, or additional features.
Cost-Effective: Eliminate recurring subscription fees associated with third-party link-shortening services.
Scalability: Scale your Slash instance according to your requirements, ensuring optimal performance as your link management needs to grow.

Slash offers a seamless solution for managing and sharing links, empowering individuals and teams to streamline their digital workflows.

13 Tips to Reduce Energy Costs on Your HomeLab Server

HomeLabs can be expensive when it comes to energy costs. It’s easy to accumulate multiple power-hungry servers, networking equipment, and computers.

firstfinger · Anurag Vishwakarma

Deploying WordPress with MySQL, Redis, and NGINX on Docker

2024-03-27T17:06:34Z

WordPress is a popular content management system (CMS) that powers millions of websites worldwide. However, as your website grows, you may experience performance issues. To improve WordPress performance, you can use object caching, which stores frequently accessed data in memory, reducing the number of database queries.

Prerequisites:

Basic knowledge of Docker and Docker Compose
Docker & Docker Compose installed on your machine
A domain name or IP address pointing to your server

Why do we need better performance in WordPress?

Website performance is crucial for user experience and search engine optimization (SEO). A slow website can lead to a high bounce rate, meaning visitors leave your site without interacting. Additionally, search engines like Google consider website speed as a ranking factor.

What does Object Cache do in WordPress?

WordPress, by default, caches internal application objects like breadcrumbs and menu items in the MySQL database. This can be taxing since the database also handles queries for page requests, potentially increasing website load times.

Object caching is a technique used to store frequently accessed data in memory, reducing the number of database queries. In WordPress, object caching is disabled by default. When a user requests a page, if the data is already cached in Redis, it is served directly from the cache, bypassing the database. This significantly reduces response times and improves the overall performance of your WordPress site .

In-Memory Caching vs. In-Memory Data Store

In-memory caching and in-memory data storage are both techniques used to improve the performance of applications by storing frequently accessed data in memory. However, they differ in their approach and purpose.

firstfinger · Anurag Vishwakarma

Why Use Redis for Object Caching?

Redis is an open-source, in-memory data store that can be used as a database , cache, and message broker.

Compared to alternatives like Memcached, Redis offers:

Persistent data storage
Data replication and high availability
Richer data structures like lists, hashes, and sets
Better performance for WordPress object caching

Why Redis is So Fast It Will Blow Your Mind!

Find out Why Redis is so fast, even after over a decade since its creation.

firstfinger · Anurag Vishwakarma

WordPress with MySQL Database and Redis as Object Cache with NGINX Reverse Proxy on Docker

We’ll use Docker Compose to orchestrate a multi-container setup

Step 1: Create a Docker Compose file

Create a new file named docker-compose.yml in your project directory and add the following code:

version: '3'
services:
 wordpress:
 image: wordpress:latest
 ports:
 - "8080:80" # Change port
 restart: always
 environment:
 WORDPRESS_DB_HOST: db
 WORDPRESS_DB_USER: exampleuser
 WORDPRESS_DB_PASSWORD: examplepassword
 WORDPRESS_DB_NAME: exampledb
 volumes:
 - wordpress:/var/www/html
 depends_on:
 - db
 - redis

 db:
 image: mysql:8.0
 restart: always
 environment:
 MYSQL_DATABASE: exampledb
 MYSQL_USER: exampleuser
 MYSQL_PASSWORD: examplepassword
 MYSQL_ROOT_PASSWORD: rootpassword
 volumes:
 - db:/var/lib/mysql

 redis:
 image: redis:alpine
 restart: always

volumes:
 wordpress:
 db:

This Docker Compose file creates three services: WordPress, MySQL, and Redis.
The WordPress service uses the latest WordPress image and connects to the MySQL service using the environment variables defined in the file.
The MySQL service uses version 8.0 of the MySQL image, and the Redis service uses the Redis Alpine image.
The WordPress data is persisted in the wordpress directory for easy access.
Run docker-compose up -d to start the containers.
You can access your WordPress site by visiting the URL http://your-server-ip:8080

Top Container Orchestration Platforms: Kubernetes vs. Docker Swarm

Kubernetes and Docker Swarm are both open-source container orchestration platforms that automate container deployment, scaling, and management.

firstfinger · Anurag Vishwakarma

Step 2: Accessing the WordPress Container Shell

To edit the changes in the WordPress config file we need to access the container shell, to do that follow:

Run docker ps to see running container details such as name, ID, status etc, and get WordPress container ID.
Use the command docker exec -it <container_id> /bin/bash to access the WordPress container.
Run this command in the WordPress container shell: apt update && apt upgrade -y && apt install nano. This command will update the system packages and install the Nano text editor in the shell.

Kubernetes for Noobs

Kubernetes is an open-source system that helps with deploying, scaling, and managing containerized applications.

firstfinger · Anurag Vishwakarma

Step 3: Add Redis Configuration to wp-config.php

Now run nano wp-config.php to edit the code in the WordPress container shell & add the following code on top of the code in wp-config.php

define ( 'WP_CACHE', true);

Add the following lines to enable Redis object caching:

define('WP_REDIS_HOST', 'redis');
define('WP_REDIS_PORT', '6379');
define('WP_CACHE_KEY_SALT', 'your-domain-name');

Replace your-domain-name with your actual domain name.
Confirm & press Ctrl + X then Shift + Y to save the changes.

Step 4: Install the Redis Object Cache Plugin

To enable object caching in WordPress, you need to install and activate the Redis Object Cache plugin.

Step 5: Run NGINX Reverse Proxy Manager Container

The reverse proxy acts as a gateway, routing external traffic to your Docker containers while providing additional features like SSL termination, load balancing, and caching, making it easier to manage and secure your containerized applications.

version: '3.8'
services:
 app:
 image: 'jc21/nginx-proxy-manager:latest'
 restart: unless-stopped
 ports:
 - '80:80'
 - '81:81'
 - '443:443'
 volumes:
 - ./data:/data
 - ./letsencrypt:/etc/letsencrypt

version: '3.8'
services:
 app:
 image: 'jc21/nginx-proxy-manager:latest'
 restart: unless-stopped
 ports:
 - '80:80'
 - '443:443'
 - '81:81'
 environment:
 DB_MYSQL_HOST: "db"
 DB_MYSQL_PORT: 3306
 DB_MYSQL_USER: "npm"
 DB_MYSQL_PASSWORD: "npm"
 DB_MYSQL_NAME: "npm"
 volumes:
 - ./data:/data
 - ./letsencrypt:/etc/letsencrypt
 depends_on:
 - db

 db:
 image: 'jc21/mariadb-aria:latest'
 restart: unless-stopped
 environment:
 MYSQL_ROOT_PASSWORD: 'npm'
 MYSQL_DATABASE: 'npm'
 MYSQL_USER: 'npm'
 MYSQL_PASSWORD: 'npm'
 MARIADB_AUTO_UPGRADE: '1'
 volumes:
 - ./mysql:/var/lib/mysql

Save the above content to a file named docker-compose.yml in a new directory.
Open a terminal, navigate to the directory with the docker-compose.yml file.
Run docker-compose up -d to start the containers in detached mode.
Let’s Encrypt SSL certificates are stored in ./letsencrypt the directory.
Access the Nginx Proxy Manager GUI admin interface at http://your_server_ip:81
Default Admin Login :

Email: admin@example.com
Password: changeme

What is the difference between Forward Proxy vs Reverse Proxy?

Understand, The role that proxies play in web architecture and consider using them to improve the performance, security, and scalability of your site.

firstfinger · Anurag Vishwakarma

Step 6: Setting up WordPress with NGINX Reverse Proxy

Click on “Hosts” > “Add Proxy Host”
Enter the following details:

Domain Names: Enter your WordPress site’s domain name (e.g., example.com)
Scheme: Choose “http://” unless you have a valid SSL certificate for your domain
Forward Hostname / IP: Enter the IP address of your WordPress container (e.g., 172.17.0.3)
Forward Port: Enter the port your WordPress container is listening on (usually 80)

Click on “Save” to create the proxy host
If you want to enable SSL with a Let’s Encrypt certificate:

Click on the proxy host you just created
Go to the “SSL” tab section
Check the “Force SSL” & “HTTP/2” box
Choose “Request a new SSL Certificate” by entering a valid email then save.

Your WordPress site should now be accessible via the Nginx Proxy Manager, with a valid SSL Certificate.

VPN vs. Zero Trust Network: Which is More Secure for Remote Access?

Zero trust fixes vulnerable trust models and limited visibility in VPNs by verifying all users and devices, encrypting everything, and monitoring all activity - before authorizing access.

firstfinger · Anurag Vishwakarma

Step 7: Backing Up WordPress Site

To ensure data safety, it’s essential to regularly back up your WordPress site.

UpdraftPlus is a popular backup plugin that simplifies and automates this process. It supports backup to remote storage like Dropbox, Google Drive and affordable paid add-ons.

You can take a manual backup or set automated schedules daily or after every hour.

This setup provides a robust and efficient environment for your WordPress site, improving both performance and data security.

10 Tips for improving WordPress site performance

1. Use a Content Delivery Network (CDN)

A CDN is a network of servers that delivers static content like images, videos, and CSS files from the server closest to the user’s location. By using a CDN, you can reduce the load on your server and improve website speed. Popular CDN providers include Cloudflare, Amazon CloudFront, and MaxCDN.

2. Enable Cloudflare Caching

Cloudflare is a popular CDN and web application firewall that offers caching and performance optimization features. By enabling Cloudflare caching, you can store frequently accessed data on Cloudflare’s servers, reducing the number of requests to your server. This can significantly improve website speed and reduce server load.

3. Optimize Images

Large images can slow down your website. Therefore, it’s essential to optimize images for the web by compressing them and using the correct file format. You can use image optimization plugins like WP Smush or ShortPixel to optimize images automatically. These plugins can also lazy load images, which means they only load when they’re visible on the screen.

4. Minimize HTTP Requests

Each file on your website, such as images, CSS, and JavaScript files, requires an HTTP request to load. By minimizing the number of HTTP requests, you can improve website speed. You can use plugins like Autoptimize to minify and combine CSS and JavaScript files, reducing the number of requests required to load your website.

5. Use a Caching Plugin

Caching plugins like W3 Total Cache or WP Super Cache can improve website speed by caching frequently accessed data and serving it from the cache instead of generating it dynamically. These plugins can also minify HTML, CSS, and JavaScript files, reducing the size of the files and improving website speed.

6. Enable Gzip Compression

Gzip compression reduces the size of files sent from your server to the user’s browser, reducing the amount of data transferred and improving website speed. You can enable Gzip compression using a plugin like WP Rocket or by adding code to your .htaccess file.

7. Disable Unused Plugins and Themes

Unused plugins and themes can slow down your website and pose security risks. Therefore, it’s essential to disable and delete any plugins and themes that you’re not using. This can improve website speed and reduce security risks.

8. Use a Fast Web Host

The speed of your website depends on the speed of your web host. Therefore, it’s essential to choose a fast and reliable web host that can handle your website’s traffic. Look for a web host that offers fast load times, good uptime, and reliable customer support.

9. Optimize Database

Over time, your WordPress database can become cluttered with unused data, such as post revisions, spam comments, and transient options. By optimizing your database, you can improve website speed and reduce database size. You can use plugins like WP-Optimize or WP-Sweep to optimize your database.

10. Use a Lightweight Theme

A lightweight theme with minimal features and optimized code can improve website speed. Therefore, it’s essential to choose a lightweight theme that’s optimized for performance. Look for a theme that’s well-coded, fast-loading, and responsive.

By implementing these tips, you can improve the performance of your WordPress site and provide a better user experience.

Setup Memos Note-Taking App with MySQL on Docker & S3 Storage

Self-host the open-source, privacy-focused note-taking app Memos using Docker with a MySQL database and integrate with S3 or Cloudflare R2 object storage.

firstfinger · Anurag Vishwakarma

Why is WordPress good for beginners?

Find out why WordPress is considered one of the best options for beginners looking to build a website. Discover the benefits and limitations of this popular CMS.

firstfinger · Anurag Vishwakarma

Mistral 7B vs. Mixtral 8x7B

2024-03-26T07:53:03Z

A French startup, Mistral AI has released two impressive large language models (LLMs) - Mistral 7B and Mixtral 8x7B. These models push the boundaries of performance and introduce a better architectural innovation aimed at optimizing inference speed and computational efficiency.

Mistral 7B: Small yet Mighty

Mistral 7B is a 7.3 billion parameter transformer model that punches above its weight class. Despite its relatively modest size,** it outperforms the 13 billion parameters Llama 2 model across all benchmarks.** It even surpasses the larger 34 billion parameter Llama 1 model on reasoning, mathematics, and code generation tasks.

**Two foundations of Mistral 7B’s efficiency: **

Grouped Query Attention (GQA)
Sliding Window Attention (SWA)

GQA significantly accelerates inference speed and reduces memory requirements during decoding by sharing keys and values across multiple queries within each transformer layer.

SWA, on the other hand, enables the model to handle longer input sequences at a lower computational cost by introducing a configurable “attention window” that limits the number of tokens the model attends to at any given time.

Name	Number of parameters	Number of active parameters	Min. GPU RAM for inference (GB)
Mistral-7B-v0.2	7.3B	7.3B	16
Mistral-8X7B-v0.1	46.7B	12.9B	100

How Do (LLM) Large Language Models Work? Explained

A large language model (LLM) is an AI system trained on extensive text data, designed to produce human-like and intelligent responses.

firstfinger · Anurag Vishwakarma

Mixtral 8x7B: A Sparse Mixture-of-Experts Marvel

While Mistral 7B impresses with its efficiency and performance, Mistral AI took things to the next level with the release of Mixtral 8x7B, a 46.7 billion parameter sparse mixture-of-experts (MoE) model. Despite its massive size, Mixtral 8x7B leverages sparse activation, resulting in only 12.9 billion active parameters per token during inference.

Image Credit: Mistral.ai

***The key innovation behind ***Mixtral 8x7B is its MoE architecture. Within each transformer layer, the model has eight expert feed-forward networks (FFNs). For every token, a router mechanism selectively activates just two of these expert FFNs to process that token. This sparsity technique allows the model to harness a vast parameter count while controlling computational costs and latency.

According to Mistral AI’s benchmarks, Mixtral 8x7B outperforms or matches the large language models like Llama 2 70B and GPT-3.5 across most multiple tasks, including reasoning, mathematics, code generation, and multilingual benchmarks. Additionally, it provides 6x faster inference than Llama 2 70B, thanks to its sparse architecture.

Should You Use Open Source Large Language Models?

The benefits, risks, and considerations associated with using open-source LLMs, as well as the comparison with proprietary models.

firstfinger · Anurag Vishwakarma

Capabilities and Performance

Mistral 7B vs. Mixtral 8x7B

Both Mistral 7B and Mixtral 8x7B are good at code generation tasks like HumanEval and MBPP, with Mixtral 8x7B having a slight edge and it’s better. Mixtral 8x7B also supports multiple languages, including English, French, German, Italian, and Spanish, making them valuable assets for multilingual applications.

On the MMLU benchmark, which evaluates a model’s reasoning and comprehension abilities, Mistral 7B performs equivalently to a hypothetical Llama 2 model over three times its size.

What is Vector Database and How does it work?

Vector databases are highly intriguing and offer numerous compelling applications, especially when it comes to providing extensive memory.

firstfinger · Anurag Vishwakarma

LLMs Benchmark Comparison Table

Model	Average MCQs	Reasoning	Python coding	Future Capabilities	Grade school math	Math Problems
Claude 3 Opus	84.83%	86.80%	95.40%	84.90%	86.80%	95.00%
Gemini 1.5 Pro	80.08%	81.90%	92.50%	71.90%	84%	91.70%
Gemini Ultra	79.52%	83.70%	87.80%	74.40%	83.60%	94.40%
GPT-4	79.45%	86.40%	95.30%	67%	83.10%	92%
Claude 3 Sonnet	76.55%	79.00%	89.00%	73.00%	82.90%	92.30%
Claude 3 Haiku	73.08%	75.20%	85.90%	75.90%	73.70%	88.90%
Gemini Pro	68.28%	71.80%	84.70%	67.70%	75%	77.90%
Palm 2-L	65.82%	78.40%	86.80%	37.60%	77.70%	80%
GPT-3.5	65.46%	70%	85.50%	48.10%	66.60%	57.10%
Mixtral 8x7B	59.79%	70.60%	84.40%	40.20%	60.76%	74.40%
Llama 2 - 70B	51.55%	69.90%	87%	30.50%	51.20%	56.80%
Gemma 7B	50.60%	64.30%	81.2%	32.3%	55.10%	46.40%
Falcon 180B	42.62%	70.60%	87.50%	35.40%	37.10%	19.60%
Llama 13B	37.63%	54.80%	80.7%	18.3%	39.40%	28.70%
Llama 7B	30.84%	45.30%	77.22%	12.8%	32.6%	14.6%
Grok 1	-	73.00%	-	63%	-	62.90%
Qwen 14B	-	66.30%	-	32%	53.40%	61.30%
Mistral Large	-	81.2%	89.2%	45.1%	-	81%

This model comparison table was last updated in March 2024. Source

When it comes to fine-tuning for specific use cases, Mistral AI provides “Instruct” versions of both models, which have been optimized through supervised fine-tuning and direct preference optimization (DPO) for careful instruction following.

Deployment and Accessibility

Mistral AI has made both Mistral 7B and Mixtral 8x7B available under the permissive Apache 2.0 license , allowing developers and researchers to use these models without restrictions. The weights for these models can be downloaded from Mistral AI’s CDN, and the company provides detailed instructions for running the models locally, on cloud platforms like AWS, GCP, and Azure , or through services like HuggingFace.

LLMs Cost and Context Window Comparison Table

Models	Context Window	Input Cost / 1M tokens	Output Cost / 1M tokens
Gemini 1.5 Pro	128K	N/A	N/A
Mistral Medium	32K	$2.7	$8.1
Claude 3 Opus	200K	$15.00	$75.00
GPT-4	8K	$30.00	$60.00
Mistral Small	16K	$2.00	$6.00
GPT-4 Turbo	128K	$10.00	$30.00
Claude 2.1	200K	$8.00	$24.00
Claude 2	100K	$8.00	$24.00
Mistral Large	32K	$8.00	$24.00
Claude Instant	100K	$0.80	$2.40
GPT-3.5 Turbo Instruct	4K	$1.50	$2.00
Claude 3 Sonnet	200K	$3.00	$15.00
GPT-4-32k	32K	$60.00	$120.00
GPT-3.5 Turbo	16K	$0.50	$1.50
Claude 3 Haiku	200K	$0.25	$1.25
Gemini Pro	32K	$0.125	$0.375
Grok 1	64K	N/A	N/A

This cost and context window comparison table was last updated in March 2024. Source

For those looking for a fully managed solution, Mistral AI offers access to these models through their platform, including a beta endpoint powered by Mixtral 8x7B.

DevOps vs SRE vs Platform Engineering - Explained

At small companies, engineers often wear multiple hats, juggling a mix of responsibilities. Large companies have specialized teams with clearly defined roles in DevOps, SRE, and Platform Engineering.

firstfinger · Anurag Vishwakarma

Conclusion

Mistral AI’s language models, Mistral 7B and Mixtral 8x7B, are truly innovative in terms of architectures, exceptional performance, and computational efficiency, these models are built to drive a wide range of applications, from code generation and multilingual tasks to reasoning and instruction.

How does the Groq’s LPU work?

Each year, language models double in size and capabilities. To keep up, we need new specialized hardware architectures built from the ground up for AI workloads.

firstfinger · Anurag Vishwakarma

Setup Memos Note-Taking App with MySQL on Docker & S3 Storage

2024-06-20T17:05:24Z

What is Memos?

Memos is an open-source, privacy-first, and lightweight note-taking application service that allows you to easily capture and share your thoughts.

Memos features:

Open-source and free forever
Self-hosting with Docker in seconds
Pure text with Markdown support
Customize and share notes effortlessly
RESTful API for third-party integration

Self-Hosting Memos with Docker and MySQL Database

You can self-host Memos quickly using Docker Compose with a MySQL database .

Prerequisites: Docker and Docker Compose installed

You have two options to choose MySQL or MariaDB as a Database both are stable versions and MariaDB consumes less memory than MySQL.

Memos with MySQL 8.0

version: "3.0"

services:

 mysql:
 image: mysql:8.0
 environment:
 TZ: Asia/Kolkata
 MYSQL_ROOT_PASSWORD: memos
 MYSQL_DATABASE: memos-db
 MYSQL_USER: memos
 MYSQL_PASSWORD: memos
 volumes:
 - mysql_data:/var/lib/mysql
 healthcheck:
 test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
 timeout: 20s
 retries: 10
 restart: always

 memos:
 image: neosmemo/memos:stable
 container_name: memos
 environment:
 MEMOS_DRIVER: mysql
 MEMOS_DSN: memos:memos@tcp(mysql:3306)/memos-db
 depends_on:
 mysql:
 condition: service_healthy
 volumes:
 - ~/.memos/:/var/opt/memos
 ports:
 - "5230:5230"
 restart: always

volumes:
 mysql_data:

Memos with MariaDB 11.0

version: "3.0"
services:
 mariadb:
 image: mariadb:11.0
 environment:
 TZ: Asia/Kolkata
 MYSQL_ROOT_PASSWORD: memos
 MYSQL_DATABASE: memos-db
 MYSQL_USER: memos
 MYSQL_PASSWORD: memos
 volumes:
 - mariadb_data:/var/lib/mysql
 healthcheck:
 test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
 start_period: 10s
 interval: 10s
 timeout: 5s
 retries: 3
 restart: always

 memos:
 image: neosmemo/memos:stable
 container_name: memos
 environment:
 MEMOS_DRIVER: mysql
 MEMOS_DSN: memos:memos@tcp(mariadb:3306)/memos-db
 depends_on:
 mariadb:
 condition: service_healthy
 volumes:
 - ~/.memos/:/var/opt/memos
 ports:
 - "5230:5230"
 restart: always

volumes:
 mariadb_data:

Create a new file named docker-compose.yml and copy the above content.
This sets up a MariaDB 11.0 database service and the Memos app linked to it.
Run docker-compose up -d to start the services in detached mode.
Memos will be available at http://localhost:5230.

The configurations are:

mysql service runs MySQL 8.0 with a database named memos-db.
memos service runs the latest Memos images, and links to the mysql/mariadb service.
MEMOS_DRIVER=mysql tells Memos to use the MySQL database driver.
MEMOS_DSN contains the database connection details.
The ~/.memos the directory is mounted for data persistence.

You can customize the MySQL password, database name, and other settings by updating the environment variables.

Kubernetes for Noobs

Kubernetes is an open-source system that helps with deploying, scaling, and managing containerized applications.

firstfinger · Anurag Vishwakarma

Configuring S3 Compatible Storage

Memos support integrating with S3-compatible object storage like Amazon S3 , Cloudflare R2 , DigitalOcean Spaces, etc

To use AWS S3/ Cloudflare’s R2 as object storage

Settings > Storage

Create a S3/Cloudflare R2 bucket
Get the API token with object read/write permissions
In Memos Admin Settings > Storage, create a new storage
Enter details like Name, Endpoint, Region, Access Key, Secret Key, Bucket name and Public URL (For Cloudflare R2 set Region = auto)
Save and select this storage

For Cloudflare R2 set Region = auto

With this setup, you can self-host the privacy-focused Memos note app using Docker Compose with a MySQL database, while integrating scalable S3 or R2 storage for persisting data.

13 Tips to Reduce Energy Costs on Your HomeLab Server

HomeLabs can be expensive when it comes to energy costs. It’s easy to accumulate multiple power-hungry servers, networking equipment, and computers.

firstfinger · Anurag Vishwakarma

How to Run Linux Docker Containers Natively on Mac with OrbStack?

Run Linux-based Docker containers natively on macOS with OrbStack’s lightning-fast performance, featherlight resource usage, and simplicity. Get the best Docker experience on Mac.

firstfinger · Anurag Vishwakarma

firstfinger

Why the OS Never Lets Your Process Touch Real Memory

The Problem With Raw Physical Memory

Virtual Memory

What is Paging?

How Linux Builds the Page Table

The CPU’s Role in MMU and CR3 Translation

Context Switching and CR3

What This Architecture Unlocks ?

What This Means When You Operate Linux Systems

Leaving Ghost for a Static Site

first, some credit

the problem it solves isn’t mine

running something for yourself vs for other people

i couldn’t write where i wanted

the theming i never enjoyed

choosing what came next

the stack

the migration tool

one post at a time, many posts at once

the layers

it checks its own work

where it actually got hard

keeping every old url working

how i publish now

what changed, in practice

what i gave up

the part i keep relearning

Running Hermes Agent on Your Own Box

1. Install

2. Setup wizard

3. Telegram bot

4. Run as a system service

5. Voice (Groq STT)

6. Web search (Tavily)

7. GitHub

8. Persona (SOUL.md)

9. Fallback model (Gemini)

10. MCP servers

11. Fix the auto-update password problem

12. Nightly auto-update cron

13. Validate

Notes

Manage the service

Fixing xterm-ghostty: unknown terminal type Over SSH

Why this happens

The trap: ssh-terminfo makes it worse

The actual fix

1. Disable ssh-terminfo in Ghostty config

2. Set TERM globally in ~/.ssh/config

Why not just push terminfo to every server?

Summary

Why Postgres is the last database you'll need ?

It is a relational database. That is the boring part.

A cache that you already have

A job queue, without the broker

Full-text search, properly indexed

Pub/sub without another daemon

JSONB, for when your schema is not ready

Extensions

Who actually runs on Postgres

OpenAI

Notion

Figma

Instagram

Others worth knowing about

The part nobody talks about - you own your data

Where you genuinely should stop

In simple words…

The Userspace Tax Behind Protocols - QUIC(UDP) vs TCP

The misconception

Understanding the protocol layers

The environment matters more than the protocol

Where the work actually happens

Path 1: gRPC over TCP

Path 2: Application protocol over QUIC over UDP

The kernel optimizations that QUIC structurally cannot use

TCP Segmentation Offload (TSO)

Generic Receive Offload (GRO)

Zero-copy I/O with sendfile()

The trap: `ssh-terminfo` makes it worse