DEV Community: FlatlinerAtheist | CLI-NERDS

SQLite in Production: A Practical Setup with Litestream Backups

FlatlinerAtheist | CLI-NERDS — Mon, 02 Nov 2026 12:10:13 +0000

SQLite often gets dismissed as a toy database, which surprises the many useful applications quietly running on it. For a small service with one application server, it can remove an entire database process, its network configuration, and a surprising amount of operational work.

The catch is not whether SQLite can store production data. It can. The catch is whether your access pattern fits and whether you can restore it after a bad day. Litestream helps with the second part by continuously replicating SQLite changes to object storage.

When SQLite is a sensible production choice

SQLite runs inside your application process and stores the database on local disk. Reads do not cross a network, and writes use ACID transactions. This is excellent for blogs, small SaaS tools, internal apps, and single-node self-hosted services.

It is less suitable when many application servers must write concurrently, you need horizontal write scaling, or clients require direct network access to the database. PostgreSQL remains the better general answer for those cases. Our MySQL vs PostgreSQL comparison covers the server-database side of that decision.

Choose SQLite because the architecture is genuinely small, not because avoiding PostgreSQL is a goal in itself.

Configure it like you mean it

Enable write-ahead logging and a busy timeout when your application opens the database:

PRAGMA journal_mode = WAL;
PRAGMA busy_timeout = 5000;
PRAGMA foreign_keys = ON;

WAL allows readers and a writer to work more comfortably together. A busy timeout tells SQLite to wait briefly when the database is locked instead of immediately failing. Foreign-key enforcement should be enabled per connection because SQLite does not assume you want it.

Keep the database on a local disk. A network filesystem with weak locking or unreliable flush behavior can corrupt the assumptions SQLite depends on. Also give the application one well-designed write path; throwing dozens of competing writers at a single file is not a scalability strategy.

Back up uploads and other application data too. Replicating only the database cannot recover files stored beside it.

Add continuous replication with Litestream

Litestream watches SQLite's WAL and streams changes to an S3-compatible bucket or another supported destination. Install it using the official release instructions, create a private bucket, and give Litestream credentials limited to the backup location it needs.

Provide credentials through a protected service environment rather than writing them into your application repository. Then run replication as a system service:

litestream replicate /var/lib/myapp/app.db \
  s3://your-backup-bucket/myapp/app.db

The command stays running while it replicates. Under systemd or another supervisor, configure it to start with the application host and restart on failure. Monitor replication errors and object-storage access; a silently stopped backup process is just an expensive source of false confidence.

Keep retention for older snapshots where your storage setup supports it. Replication faithfully copies the current state, including a mistaken DELETE, so point-in-time recovery options matter.

Practice the restore before you need it

Stop the application or restore onto a separate test machine. Do not experiment on the only live database file.

litestream restore -o /var/lib/myapp-restored/app.db \
  s3://your-backup-bucket/myapp/app.db

Check the restored file and open it with the application:

sqlite3 /var/lib/myapp-restored/app.db 'PRAGMA integrity_check;'

Then verify real records, not just that a file appeared. A restore drill should include starting the app, signing in, and reading recent data.

Remember that continuous replication has a small recovery window: changes after the last successfully replicated update may be lost. Measure it instead of promising zero data loss.

Boring can be a feature

SQLite plus Litestream gives a single-node application a local database and an off-box recovery path without running a separate database cluster. That is a genuinely useful production architecture for the right workload.

Know the single-writer limits, keep backups off the machine, and rehearse recovery. If the application eventually needs multiple write nodes or heavy concurrent writes, migrate deliberately. Until then, one reliable file and a tested restore may be all the database infrastructure you need.

pgvector for Beginners: Add Semantic Search to PostgreSQL

FlatlinerAtheist | CLI-NERDS — Mon, 02 Nov 2026 12:09:53 +0000

You already have PostgreSQL, backups, and a team that knows how to operate them. Then a new feature asks for semantic search, and suddenly the architecture diagram grows a separate vector database. For many applications, that extra system is unnecessary. pgvector adds vector storage and similarity search to PostgreSQL itself.

That means embeddings can live beside the documents, users, and permissions they belong to — with normal transactions, joins, and backups.

What an embedding does

An embedding model turns text, an image, or another input into a list of numbers. Similar inputs tend to produce vectors that are close together in the model's mathematical space.

A keyword search for “database keeps running out of connections” might not match a paragraph about “connection pool exhaustion.” Semantic search can, because it compares meaning represented by embeddings rather than exact words.

The model matters. Store the model name with your data, use the same model for documents and queries, and expect to regenerate embeddings when changing models.

A tiny pgvector example

Use a PostgreSQL distribution with pgvector installed, or try the project's Docker image. Enable the extension once per database:

CREATE EXTENSION IF NOT EXISTS vector;

This table uses three dimensions so the example stays readable. Real models usually produce hundreds or thousands; the declared size must match your model.

CREATE TABLE documents (
    id bigserial PRIMARY KEY,
    content text NOT NULL,
    embedding vector(3) NOT NULL
);

INSERT INTO documents (content, embedding) VALUES
    ('Postgres connection pool exhausted', '[0.9,0.1,0.0]'),
    ('Configure a reverse proxy', '[0.0,0.8,0.2]'),
    ('Tune PostgreSQL connections', '[0.8,0.2,0.1]');

Find the nearest rows using cosine distance:

SELECT content,
       1 - (embedding <=> '[0.85,0.15,0.05]'::vector) AS similarity
FROM documents
ORDER BY embedding <=> '[0.85,0.15,0.05]'::vector
LIMIT 3;

The <=> operator returns cosine distance, so 1 - distance expresses similarity. pgvector also supports L2 distance and inner product; use the metric recommended for your embedding model.

In application code, pass the query embedding as a parameter. Do not build SQL by concatenating user input.

Add an index when exact search becomes slow

Without a vector index, PostgreSQL performs exact nearest-neighbor search. That gives perfect recall and can be completely reasonable for a small table.

As the data grows, an HNSW index can trade a little recall for faster approximate search:

CREATE INDEX documents_embedding_idx
ON documents
USING hnsw (embedding vector_cosine_ops);

The operator class must match the distance operator in your query. Check the plan and timing rather than assuming the index helps:

EXPLAIN (ANALYZE, BUFFERS)
SELECT content
FROM documents
ORDER BY embedding <=> '[0.85,0.15,0.05]'::vector
LIMIT 5;

Small tables may still prefer a sequential scan. On large production tables, build indexes concurrently and test recall against exact results. Our guide to debugging PostgreSQL queries with EXPLAIN explains how to read the plan.

Keep keywords in the picture

Semantic search is not automatically better at everything. Exact error codes, product names, and rare identifiers often work better with keyword search. PostgreSQL full-text search can cover that side, and you can combine keyword and vector rankings for hybrid search.

You also retain normal relational filters. A search can stay inside a tenant, workspace, or permission boundary without synchronizing access rules into another database. Design and test those filters carefully: approximate indexes and heavy filtering can interact in surprising ways.

When pgvector is a good fit

It is a strong default when PostgreSQL is already your primary database, your vector workload fits comfortably on it, and operational simplicity matters. It is especially useful for document search, recommendations, deduplication, and retrieval for AI features.

A dedicated vector engine may be justified by extreme scale, specialized indexing, or a workload your benchmarks show PostgreSQL cannot handle. Make that decision with real data, not because every AI demo includes another service.

Start with exact search, measure, and add HNSW when needed. You might discover that the simplest AI infrastructure improvement is using the database you already trust.

CrowdSec vs Fail2ban: Practical Brute-Force Protection for Your Server

FlatlinerAtheist | CLI-NERDS — Mon, 02 Nov 2026 12:09:32 +0000

Expose SSH or a website to the internet and the automated login attempts will find it. You do not need to read thousands of failed-password lines by hand, but you do need a sensible way to stop repetitive abuse. Fail2ban and CrowdSec both turn suspicious activity into firewall decisions.

They overlap, but they are not quite the same product.

Fail2ban: small, local, and predictable

Fail2ban watches logs, matches patterns called filters, and bans an address through a firewall action when a jail reaches its threshold. It has been doing that job for years, and for a single Linux server that is often exactly what you need.

On Debian or Ubuntu:

sudo apt update
sudo apt install fail2ban

Create /etc/fail2ban/jail.local instead of editing the packaged defaults:

[DEFAULT]
findtime = 10m
maxretry = 5
bantime = 1h

[sshd]
enabled = true

Restart it and inspect the jail:

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Adjust the backend only if your distribution does not read SSH logs correctly. Test from a system you control, and keep an active root or console session while changing firewall behavior so a bad rule cannot lock you out completely.

Fail2ban is easy to reason about: this log, this pattern, this threshold, this ban. It does not require a central account or a crowd to be useful.

CrowdSec: behavior detection plus shared intelligence

CrowdSec also parses logs and detects behavior locally. Its architecture separates the detection engine from bouncers, which enforce decisions in a firewall, reverse proxy, or another layer.

That split is useful when you want one place to detect abuse and another to block it. CrowdSec can also consume community intelligence about addresses exhibiting malicious behavior elsewhere, while sharing signals according to its configuration. Treat that as an additional data source, not as proof that every listed address attacked you personally.

Typical inspection commands are:

sudo cscli alerts list
sudo cscli decisions list
sudo cscli metrics

The metrics view is particularly important: it shows which log sources are being read and which parsers are working. Installing a security agent without confirming that it parses your actual logs creates comforting dashboards and very little protection.

Use the official installation documentation for your distribution, install the relevant collections for SSH or your web server, and add a firewall bouncer. Then generate a harmless test event or use CrowdSec's testing facilities rather than attacking your own public endpoint.

Which one should you choose?

Choose Fail2ban when:

You have one or a few servers.
SSH brute force and a small set of log patterns are the main concern.
You want minimal moving parts and fully local decisions.

Choose CrowdSec when:

You want a broader scenario ecosystem for web and service abuse.
Detection and enforcement need to happen in different places.
Community threat intelligence is valuable to your setup.

Running both against the same logs is possible, but it also creates overlapping bans and two systems to debug. For a small VPS, pick one and operate it well.

Neither tool fixes weak security

An IP ban is a reaction, not an authentication strategy. Disable SSH password login where practical, use keys, keep software updated, and restrict exposed ports. Our Fail2ban installation guide and SSH hardening guide cover those fundamentals.

Also watch false positives. A shared NAT address can represent many innocent users, and overly aggressive thresholds can ban your own office. Start with conservative rules, review alerts, and know how to unban an address.

For most home servers, Fail2ban remains a perfectly good answer. For richer web detection and distributed enforcement, CrowdSec earns its extra complexity. The best choice is the one whose logs, decisions, and recovery commands you actually understand.

Passkeys Explained: A Practical Move Beyond Passwords

FlatlinerAtheist | CLI-NERDS — Mon, 02 Nov 2026 12:09:11 +0000

Passwords have two problems that never really go away: people reuse them, and fake login pages are good at stealing them. Passkeys offer a different model. Instead of typing a shared secret into every website, your device proves it holds a private key that belongs to your account.

That sounds technical, but using one usually feels like unlocking your phone. The important changes happen underneath.

What a passkey actually is

When you create a passkey, your device generates a pair of cryptographic keys for that specific site:

The private key stays protected by your device or password manager.
The public key goes to the website.

At login, the site sends a challenge. Your device signs it with the private key, and the site verifies the signature with the public key. The private key is never sent to the site.

Your fingerprint, face, or device PIN unlocks access to the key locally. The website does not receive your fingerprint or face scan.

Why phishing works less well

A password can be typed into the wrong website. A passkey is bound to the site's origin, so a credential created for example.com is not used on exarnple.com, no matter how convincing the page looks.

This removes one of the most reliable tricks in account takeover. It also removes the password database's usual treasure: public keys stored by a service are not reusable login secrets.

Passkeys do not make malware harmless, protect an already-compromised session, or stop someone from tricking you into approving a different action. They solve a specific problem very well.

Synced passkeys and device-bound keys

Many passkeys synchronize through an ecosystem or password manager, making them available on your phone and laptop. Others remain bound to a hardware security key or particular device.

Synced passkeys are convenient and still use public-key cryptography. Device-bound credentials can be useful for stricter policies, but losing the device matters more. The right choice depends on the account and your recovery plan.

Before turning passkeys on for an important account:

Add them on more than one trusted device where the service supports it.
Keep a hardware security key or another independent recovery method if possible.
Store recovery codes somewhere safe and offline.
Test signing in on a second device before removing an old login method.

Losing every device should not mean losing your digital life.

What websites need to implement

Passkeys use the WebAuthn standard and platform authenticators. For developers, the browser API is only half the job. The server must generate unpredictable challenges, verify responses and origins, store credential public keys, and expire challenge state correctly.

Use a maintained WebAuthn library rather than writing signature verification yourself. Keep the existing account-recovery and session-security controls, require HTTPS, and give users a way to name and revoke credentials.

A sensible rollout offers passkeys alongside existing sign-in first. Watch successful registrations, sign-ins, and recovery requests before considering whether passwords can become optional. Users with older devices still need a workable path.

Do passkeys replace password managers?

Not exactly. Many password managers can create and sync passkeys, so the two increasingly work together. You may still have passwords for older sites, SSH keys, encrypted archives, and other secrets. A manager remains useful — and if you want to run one yourself, our Vaultwarden guide is a practical starting point.

Should you switch?

For accounts that offer passkeys, yes: they are usually easier to use and much harder to phish than a password alone. Start with your email, password manager, cloud accounts, and developer platforms, because those can unlock many other services.

Just do not confuse “no password” with “no recovery plan.” Add a passkey, add a backup path, and then enjoy typing fewer secrets into boxes.

Caddy vs Nginx: Choosing a Reverse Proxy You Can Actually Maintain

FlatlinerAtheist | CLI-NERDS — Mon, 02 Nov 2026 12:08:50 +0000

You have an app listening on port 3000, a domain pointed at your server, and one remaining job: put HTTPS in front of it. The two names you will see most often are Caddy and Nginx. Both are excellent reverse proxies. The better choice depends less on benchmark charts than on how you want to operate the server.

Caddy: HTTPS as the default

Caddy's standout feature is automatic HTTPS. Give it a public domain with correct DNS and reachable ports 80 and 443, and it obtains and renews certificates for you.

A complete reverse-proxy configuration can be this small:

blog.example.com

reverse_proxy 127.0.0.1:3000

Reload it with:

sudo caddy reload --config /etc/caddy/Caddyfile

That is the entire mental model: domain in, application behind it, certificate handled. Caddy also makes security-conscious defaults easy to keep because you are not maintaining a separate certificate bot and a pile of TLS boilerplate.

For a new VPS, a homelab dashboard, or a handful of small applications, this simplicity is a real operational advantage. Fewer lines mean fewer places to make a mistake at midnight.

Nginx: control and a huge ecosystem

Nginx needs a little more configuration, but it is everywhere. Most teams already have someone who understands it, and its modules, caching controls, load balancing, and documentation cover almost every edge case.

An equivalent site looks like this:

server {
    listen 80;
    server_name blog.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

You then add TLS and HTTP-to-HTTPS redirection, commonly with Certbot or another certificate automation tool. Our Nginx reverse proxy guide and Let's Encrypt renewal guide walk through those pieces.

Nginx is a natural choice when you need detailed caching rules, existing include files, specialized modules, or consistency with infrastructure your team already runs.

The comparison that matters

Configuration: Caddy is shorter for common reverse-proxy and static-site setups. Nginx exposes more of the machinery explicitly.

Certificates: Caddy automates HTTPS in its normal configuration path. Nginx usually pairs with a separate ACME client.

Familiarity: Nginx has an enormous installed base and years of examples. Caddy's documentation and Caddyfile are friendly, but unusual requirements may push you toward its JSON configuration or plugins.

Performance: either can serve a typical blog or application without being the bottleneck. Your app, database, TLS termination pattern, caching, and server size usually matter more. Benchmark your own workload before rewriting a working proxy for a theoretical gain.

Operations: Caddy reduces routine certificate work. Nginx rewards teams that want precise control and already have proven configuration management.

A safe migration path

Do not replace a healthy production proxy on a Friday because a comparison article told you to. Test the new configuration on a separate hostname or VM first.

For either proxy:

Point a test DNS record at the server and wait for it to resolve publicly.
Allow only the required web ports through the firewall.
Check proxy headers so the application sees the real scheme and client address.
Verify certificate renewal, not just the first certificate issuance.
Test uploads, long requests, WebSockets if used, and redirect behavior.
Move production only after a rollback path is clear.

My practical recommendation

Choose Caddy for a new, straightforward self-hosted service when automatic HTTPS and a short configuration are the priority. Choose Nginx when existing expertise, advanced routing, or a mature configuration already makes it the easier system to maintain.

The best proxy is not the one with the loudest benchmark. It is the one you can configure correctly, renew automatically, and troubleshoot without dread.

DNS over HTTPS Explained: What It Protects and What It Doesn't

FlatlinerAtheist | CLI-NERDS — Mon, 02 Nov 2026 12:08:29 +0000

Every time you visit a website, your device usually asks DNS for its IP address first. Traditional DNS sends that question without encryption, so the network carrying it can often see or tamper with the request. DNS over HTTPS (DoH) fixes that transport problem by placing DNS inside an HTTPS connection.

It is a useful privacy upgrade, but it is not an invisibility cloak. Understanding what it does — and what it does not — helps you choose a sensible setup.

What changes with DoH

Without DoH, a typical lookup travels over UDP or TCP port 53. With DoH, the client sends the DNS query to a compatible resolver over HTTPS, normally on port 443.

That protects the query from casual inspection and modification on the path between you and the resolver. Public Wi-Fi operators and intermediate routers no longer get the same easy view of those DNS requests.

Your chosen resolver still receives the queries. Your device still connects to the destination IP afterward. DoH shifts trust; it does not eliminate it.

DoH, DoT, and ordinary DNS

DNS over TLS (DoT) solves a similar transport problem using a dedicated TLS service, usually on port 853. DoH blends into HTTPS traffic and can be easier to deploy through restrictive networks. Neither is automatically “more anonymous.”

The useful comparison is:

Plain DNS: simple and widely supported, but unencrypted between client and resolver.
DoT: encrypted DNS with a distinct port and identity.
DoH: encrypted DNS carried through HTTPS, often configured in browsers and operating systems.

A local resolver such as Unbound or Pi-hole can still provide filtering and caching while forwarding upstream over an encrypted protocol. That gives you central control without sending every device's queries in the clear to an outside resolver.

Turn it on without breaking your network

The easiest place to test is a browser that supports encrypted DNS. Choose a resolver you trust, enable its secure-DNS option, and visit that provider's test page to confirm the browser is using it.

Then consider the rest of the system. Browser-only DoH does not automatically protect lookups made by other applications. Operating-system support provides broader coverage, but availability and behavior differ across platforms.

On a home network, decide who should control DNS:

If you rely on Pi-hole or AdGuard Home for filtering, do not let every device silently bypass it with different DoH settings.
If you manage children's devices or a workplace network, document the approved resolvers rather than discovering unexpected policies later.
If an application has its own DNS setting, remember that changing the router alone may not change that application's behavior.

For a refresher on the records behind the lookup, see our DNS records guide.

The privacy claims to ignore

DoH does not hide all website metadata. The destination IP remains visible, and the TLS handshake can reveal the hostname unless additional protections such as Encrypted Client Hello apply. A resolver can also observe query patterns even when the transport is encrypted.

DoH is not a VPN. It does not route the rest of your traffic through another network, change your public IP, or make an unsafe website safe.

It also cannot guarantee integrity all the way to an authoritative server. It protects the client-to-resolver leg; DNSSEC addresses a different problem by allowing DNS responses to be validated cryptographically.

Should you use it?

For a laptop on untrusted Wi-Fi, encrypted DNS is a sensible default. Choose a resolver with a clear privacy policy and good reliability, then verify that it works with your filtering and local hostnames.

For a homelab, central DNS plus encrypted upstream forwarding is often cleaner than a different browser setting on every device. For a business, make it a deliberate policy rather than an accidental mix of browser defaults.

The win is straightforward: fewer people on the network path can watch or alter your lookups. Just do not mistake one encrypted hop for complete privacy.

Build Your Own Media Server with Jellyfin and Docker

FlatlinerAtheist | CLI-NERDS — Mon, 02 Nov 2026 12:08:09 +0000

Streaming subscriptions are convenient until a film disappears, a show moves to another service, or you realize your own media collection is sitting on a hard drive doing nothing. Jellyfin is a free, open-source media server that lets you stream that collection to your browser, TV, phone, and other clients — without an account at a media company.

It is also a good first self-hosting project: useful immediately, easy to run in Docker, and forgiving enough to learn on.

Before installing: organize the media

Jellyfin can fetch artwork and metadata, but it needs to identify what it is looking at. A simple structure prevents hours of mismatched titles:

/srv/media/
├── Movies/
│   └── Example Film (2024)/
│       └── Example Film (2024).mkv
└── Shows/
    └── Example Show/
        └── Season 01/
            └── Example Show - S01E01.mkv

Use your real titles, of course. Keep films and shows in separate libraries. Read-only media mounts are a sensible default: Jellyfin needs to read your collection, not reorganize or delete it.

Run Jellyfin with Docker Compose

Create a compose.yaml:

services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    container_name: jellyfin
    user: 1000:1000
    restart: unless-stopped
    volumes:
      - /srv/jellyfin/config:/config
      - /srv/jellyfin/cache:/cache
      - /srv/media:/media:ro
    ports:
      - "8096:8096"

Create the writable directories, make sure UID/GID 1000 owns them, then start the service:

sudo mkdir -p /srv/jellyfin/{config,cache}
sudo chown -R 1000:1000 /srv/jellyfin
docker compose up -d

Open http://server-ip:8096. Create the administrator account, add libraries pointing to /media/Movies and /media/Shows, and let the initial scan finish.

For a long-lived installation, replace latest with a release you have tested, and upgrade deliberately rather than pulling random updates every night.

Direct play first, transcoding second

The smoothest playback happens when the client supports the file directly. Transcoding converts video in real time when it does not, and high-resolution software transcoding can overwhelm an otherwise capable little server.

If you have a supported Intel or AMD GPU, hardware acceleration can help. On Linux, that commonly means passing the render device into the container:

    devices:
      - /dev/dri:/dev/dri

Add that only if /dev/dri exists, then enable the appropriate acceleration method in Jellyfin's playback settings. The exact driver and permissions vary by hardware. Check the server dashboard's transcoding logs if playback still maxes out the CPU.

For remote viewing, a modest upload speed matters more than a powerful processor. Lower the client's streaming bitrate instead of expecting your home connection to perform miracles.

Make the library pleasant to use

Install the official Jellyfin client for your TV or streaming device where one is available, and test direct playback with a representative file before importing everything. A phone browser is useful for setup, but TV clients have different codec and subtitle support.

After the first scan, check a handful of titles for incorrect matches. Fix folder names or use the library's identify function rather than editing dozens of metadata fields manually. Keep extras and different editions separated clearly so the scanner does not merge them into a confusing entry.

Schedule library scans and metadata refreshes for a quiet time if the server runs on a small disk or low-power CPU. Also watch the config partition's free space: transcoding cache and logs should not be allowed to fill it. A full system disk can make an otherwise healthy media server look broken.

Keep it private and recoverable

Do not forward port 8096 to the internet just because remote access sounds useful. A private overlay such as Tailscale is a cleaner default for personal viewing.

Back up /srv/jellyfin/config as well as any custom metadata and artwork you care about. Your media files need their own backup too — a server disk is not a backup. The 3-2-1 backup strategy is a good model.

Finally, keep Jellyfin updated, use separate accounts for viewers, and leave remote administration disabled unless you need it. The goal is a boring media appliance: press play, watch your stuff, and spend your weekend enjoying the library instead of maintaining it.

Tailscale for Homelabs: Access Your Servers Without Port Forwarding

FlatlinerAtheist | CLI-NERDS — Mon, 02 Nov 2026 12:07:48 +0000

You finally have Jellyfin, Nextcloud, and a dashboard running at home. Then you leave the house and realize none of it is reachable. The usual answer is port forwarding, but exposing every self-hosted admin panel to the internet creates a bigger problem than it solves.

Tailscale gives your devices a private network built on WireGuard. Your phone, laptop, and home server can talk to each other without opening inbound ports on your router, even behind carrier-grade NAT.

What Tailscale actually changes

Each device joins your private tailnet and receives a stable private IP address. Traffic between devices is encrypted. Tailscale's coordination service helps devices find one another and exchange keys; in many cases, the data then travels directly between them.

This is different from publishing a service on the web. By default, only devices and users allowed into your tailnet can reach it.

Connect your first server

On a Debian or Ubuntu server, the official installer is the quickest start:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale ip -4

The second command prints a login URL. Open it, authenticate, and approve the machine. Install the Tailscale app on your laptop or phone and sign in to the same tailnet.

Now test the private address from another connected device:

ping 100.x.y.z
ssh your-user@100.x.y.z

Replace the placeholder with the address returned by tailscale ip -4. You can now reach services using http://100.x.y.z:8096 or enable MagicDNS in the admin console and use the machine name instead.

Share a web app without exposing it publicly

If Jellyfin listens on port 8096, Tailscale Serve can provide a tailnet-only HTTPS URL:

sudo tailscale serve --bg 8096
tailscale serve status

Use the HTTPS address shown in the output from a connected device. To remove it later:

sudo tailscale serve --bg off

Serve is for your private tailnet. Tailscale Funnel is the separate feature that can expose a service to the public internet — don't enable it just to share an admin dashboard with yourself.

Make the setup safer than a flat home network

A private network is not automatically a zero-trust network. Do these things next:

Use individual accounts instead of sharing one login across the whole household.
Restrict access with ACLs or grants. A media player does not need SSH access to every server.
Keep normal SSH hardening in place if you run tailscale ssh; tailnet access is another layer, not a reason to forget the operating system. Our SSH hardening guide covers the basics.
Review connected machines and remove old phones or decommissioned servers.
Keep key expiry enabled for personal devices. Use properly scoped auth keys for unattended machines instead of disabling every safeguard.

When a device cannot connect

Start with tailscale status on both machines. Confirm they are logged into the intended tailnet, online, and not using an expired key. Then check that the service is actually listening on the server's Tailscale interface or all interfaces; an application bound only to 127.0.0.1 will not answer connections to its 100.x.y.z address.

Next, check the host firewall and the tailnet access policy. A working WireGuard tunnel cannot make a closed application port open, and an access rule may intentionally block one user or device. Change one layer at a time so you know which setting fixed the problem.

If direct peer-to-peer connectivity fails on a restrictive network, Tailscale may relay traffic through a DERP server. That is slower but still encrypted end to end. It is a connectivity fallback, not a reason to start forwarding ports again.

Where it fits — and where it doesn't

Tailscale is excellent for remote administration, private dashboards, and letting family reach a media server without teaching them VPN configuration. It can also connect cloud VMs and home machines without building a fragile chain of port forwards.

It does not replace backups, application passwords, or software updates. It also relies on Tailscale's coordination infrastructure unless you run a compatible self-hosted control plane such as Headscale. If you want every component under your control and enjoy operating network infrastructure, plain WireGuard may be a better fit.

For most homelabs, though, this is the sensible first step: close the forwarded ports, connect your devices privately, and expose public services only when they genuinely need to be public.

OpenTelemetry for Beginners: Traces, Metrics, and Your First Setup

FlatlinerAtheist | CLI-NERDS — Mon, 02 Nov 2026 12:07:27 +0000

"Something is slow" is the least actionable sentence in operations. Is it the app? The database? The network between them? OpenTelemetry (OTel) is how you stop guessing: a vendor-neutral standard for collecting traces, metrics, and logs from your applications — so you can see exactly where time and errors go.

It has become the default instrumentation layer for new projects, and for good reason: you instrument once and send data to Jaeger, Grafana Tempo, Prometheus, Datadog, or whatever backend you choose. No vendor lock-in at the SDK level.

The three signals, in plain English

Traces — the path of a single request through your system: which services it touched and how long each step took. This is what answers "slow where?"
Metrics — numbers over time: request rate, error rate, latency percentiles, memory. This is what dashboards and alerts are made of.
Logs — the events you already know, but correlated with traces so you can jump from "this slow request" to its exact log lines.

You don't need all three on day one. Start with traces — they deliver the biggest "oh, that's the problem" moments.

The architecture in 30 seconds

Your app uses an OTel SDK (or auto-instrumentation) to produce telemetry. It exports to the OpenTelemetry Collector — a small agent that receives, batches, and forwards data to your backend. The Collector is the key piece: it keeps your app config trivial and your backend choices flexible.

App (SDK) → OTel Collector → Jaeger / Grafana / Prometheus / vendor

A minimal working setup with Docker

Run Jaeger (an all-in-one trace backend with a UI) and the Collector:

services:
  otel-collector:
    image: otel/opentelemetry-collector:latest
    command: ["--config=/etc/otelcol/config.yaml"]
    volumes:
      - ./otelcol-config.yaml:/etc/otelcol/config.yaml
    ports:
      - "4318:4318"   # OTLP HTTP receiver

  jaeger:
    image: jaegertracing/all-in-one:latest
    environment:
      COLLECTOR_OTLP_ENABLED: "true"
    ports:
      - "16686:16686" # Jaeger UI

The Collector config (otelcol-config.yaml) receives OTLP and exports to Jaeger:

receivers:
  otlp:
    protocols:
      http:
exporters:
  otlp:
    endpoint: jaeger:4317
    tls:
      insecure: true
service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp]

Instrument a Node.js app

Auto-instrumentation covers HTTP, Express, and many libraries out of the box:

npm install @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node

// tracing.js — import this BEFORE anything else
const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');

const sdk = new NodeSDK({
  instrumentations: [getNodeAutoInstrumentations()],
});
sdk.start();

Point the exporter at the Collector (default is OTLP HTTP on localhost:4318), restart the app, generate some traffic, and open http://localhost:16686. Your requests appear as traces: every HTTP call, every DB query, with durations. That slow endpoint now shows you exactly which hop eats the time.

Python, Go, Java, and .NET have equivalent auto-instrumentation packages — same pattern, same backend.

What to do with it

Find your slowest endpoint in the trace list, open a trace, look at the longest span. That's your optimization target, with proof.
Add custom spans around your own expensive operations (image processing, report generation) so they show up too.
Add metrics later: the same SDKs expose latency and error-rate metrics for dashboards and alerts.

Keep the telemetry bill under control

Tracing every request forever can create more data than you can afford to store, especially once several services are instrumented. Start with a small service and learn what a useful trace looks like. Then configure sampling appropriate to your traffic: enough successful requests to understand normal behavior, while preserving errors and slow outliers where your backend supports it.

Be careful with span attributes and metric labels. Values such as user IDs, full URLs with unique identifiers, or request IDs create high-cardinality data that is expensive to index. Never put passwords, authorization headers, session tokens, or personal request payloads into telemetry just because the instrumentation makes it easy.

The Collector is also part of your production system. Monitor its queue, dropped data, memory use, and exporter errors. If it cannot reach the backend, your application should keep serving users rather than becoming a casualty of the observability pipeline.

The practical takeaway

OpenTelemetry isn't a monitoring product — it's the plumbing that makes any monitoring product useful without locking you in. Start with one service, one Collector, and Jaeger. The first time you watch a slow request break down hop by hop, you'll wonder how you ever debugged with logs alone.

GitOps with ArgoCD: A Practical Beginner's Guide for Kubernetes

FlatlinerAtheist | CLI-NERDS — Mon, 02 Nov 2026 12:07:06 +0000

"What's running in production right now?" If the honest answer is "whatever someone last applied with kubectl," you have a configuration drift problem waiting to happen. GitOps fixes it with one rule: the desired state of your cluster lives in Git, and an agent makes the cluster match it. ArgoCD is the most popular agent for the job.

Here's how the model works and how to set it up for real.

The idea in one paragraph

You stop running kubectl apply by hand. Instead, your manifests (or Helm charts, or Kustomize overlays) live in a Git repository. ArgoCD watches both the repo and the cluster, shows you when they differ, and syncs them — automatically or at the click of a button. Every production change becomes a pull request, with history, review, and an instant rollback via git revert.

Install ArgoCD on your cluster

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Wait for the pods to come up, then get the admin password and expose the UI:

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath='{.data.password}' | base64 -d

kubectl port-forward svc/argocd-server -n argocd 8080:443

Open https://localhost:8080, log in as admin with that password, and change it immediately. For a permanent setup, front it with an ingress and TLS — our Kubernetes ingress guide covers that part.

Point it at a repository

The fastest way to learn is a small app repo of your own: a folder with deployment.yaml and service.yaml for something trivial (an Nginx deployment works fine).

Create an Application in the UI — or as YAML, which is more in the spirit of GitOps:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/yourname/gitops-demo.git
    targetRevision: main
    path: manifests
  destination:
    server: https://kubernetes.default.svc
    namespace: demo
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

automated means ArgoCD syncs on every commit, prune removes resources deleted from Git, and selfHeal reverts manual changes made directly in the cluster — that's the drift-killer.

Apply it with kubectl apply -f application.yaml and watch the UI: within a minute, your app appears, syncs, and goes green.

The moment it clicks

Edit the replica count in Git, commit, push. ArgoCD notices and scales the deployment. Then — the important test — run kubectl scale by hand to a different number and watch selfHeal snap it back to Git's value. That's the whole value proposition in one demo: production can never silently differ from the repo.

Practical advice from the field

One repo per team or per app, with folders per environment (env/staging, env/production) rather than branches per environment. Branches diverge; folders just diff.
Don't auto-sync everything on day one. Start with manual sync on production so a bad commit requires a human click; automate staging first.
Secrets don't go in Git. Use Sealed Secrets, External Secrets Operator, or your cloud's secret store. Our ConfigMaps and Secrets guide covers the options.
Rollbacks are git revert + sync, not archaeology. Keep commits small and you'll love this on your worst day.

A safe first week with ArgoCD

Start with one non-critical application and leave automatic pruning off until you understand its behavior. Pruning is useful, but deleting a manifest in Git also gives ArgoCD permission to delete the corresponding cluster resource. That is exactly what you want eventually, and a painful surprise when a path or sync option is wrong.

Watch the application's Health and Sync states separately. “Synced” means the manifests match Git; it does not prove every pod is healthy. A deployment can match the repository perfectly and still crash because its image, configuration, or database is wrong.

Keep the initial admin credentials out of scripts, configure proper user access, and back up any Git repository settings that are not themselves declared elsewhere. Once the basic workflow is reliable, add staging automation, then production approvals, and only then broader pruning and self-healing.

Is it worth it for small setups?

For a single toy cluster, ArgoCD can feel like overhead. But the moment you have more than one environment or more than one person deploying, GitOps stops being ceremony and starts being the only sane way to answer "who changed what, when, and how do we undo it."

Wayland vs X11 in 2026: What's Better, What Breaks, Who Should Wait

FlatlinerAtheist | CLI-NERDS — Mon, 02 Nov 2026 12:06:46 +0000

For thirty years, Linux desktops ran on X11. Today every major distro has moved to Wayland — Fedora and Ubuntu default to it, and X11 is officially in maintenance mode. But the internet is full of contradictory advice: Wayland is the future, Wayland broke my setup, just use X11, X11 is dead.

Here's the honest picture in 2026, including who should still avoid Wayland.

Why the change happened at all

X11 was designed in 1987 for a world of dumb terminals. Its core model lets any application snoop on any other application's input and pixels — keyloggers are trivial by design. It also predates modern GPUs, mixed-DPI monitors, and touchpads, so those features were bolted on over decades.

Wayland rebuilds the model: the compositor (GNOME's Mutter, KDE's KWin, Sway) owns the display, and applications get only their own pixels and events. Better security isolation, smoother frame timing, proper per-monitor scaling.

What actually got better

Mixed-DPI setups — a 4K laptop next to a 1080p monitor just works, with independent scaling per display. On X11 this was a minefield of blurry apps.
Tearing and latency — Wayland's frame presentation is synchronized; video and scrolling look visibly smoother on most hardware.
Security — an app can't silently record your keystrokes or screen anymore. Screen sharing and remote desktop now go through explicit portals that ask permission.
Touchpad gestures — proper three/four-finger gestures instead of X11's hacky workarounds.

What still breaks

Screen sharing/recording — works, but through portals (PipeWire + xdg-desktop-portal). If your app is old, sharing may show a black screen until you run it with the right flags (usually --ozone-platform=wayland on Electron apps, or XWayland fallback).
NVIDIA drivers — the long-standing pain point. It's much better with recent proprietary drivers (explicit sync landed), but older cards and odd setups can still glitch. AMD and Intel are the safe choices.
Global hotkeys and automation tools — apps like xdotool or global key listeners don't work across apps anymore by design. Desktop-specific replacements exist (KDE/GNOME shortcuts, ydotool for lower-level needs).
Some remote desktop flows — RDP into a Wayland session is smoother than it was, but the "log into a running graphical session" use case still trips people up. Our XRDP guide covers the working setup.

XWayland: the compatibility layer

Most X11 apps run fine under Wayland via XWayland — a compatibility server that translates the old protocol. That's why the transition has been mostly painless: your old apps still launch, they just don't get the new security and DPI benefits.

Quick check of what's running natively:

xlsclients        # lists apps running through XWayland
echo $XDG_SESSION_TYPE   # "wayland" or "x11" — which session you're in

A sensible compatibility check

Before changing your daily machine, test a live USB or a second user session on the same hardware. Open a video call and share both a window and the full screen. Try your screenshot tool, password manager autotype, remote-desktop client, and any unusual global shortcuts. These small workflows are where a smooth demo can turn into a frustrating workday.

If one application misbehaves, check whether it is running natively or through XWayland before blaming the whole desktop. A native build may fix scaling while an X11 fallback may temporarily fix screen capture. Keep the distribution's packages and the desktop portal services updated, and avoid copying random flags into every launcher as a permanent solution.

For a production machine, make the session choice at the login screen rather than replacing lots of packages. Both sessions can often coexist, giving you an easy fallback while you test.

Should you switch?

Switch if: you're on GNOME or KDE with AMD/Intel graphics, use a laptop (especially mixed-DPI), or just want the smoothest experience. For most people in 2026, Wayland is simply better and there's no reason to stay on X11.

Stay on X11 (for now) if: you rely on niche X11-only tools, have an older NVIDIA card with a fragile driver situation, or run a highly customized tiling setup that you haven't ported to a Wayland compositor like Sway or Hyprland.

The pragmatic answer for most people: stop choosing. Modern distros already made the choice, XWayland covers the stragglers, and the only thing you need to do is check the two or three apps that matter to you before your next upgrade.

Immutable Linux Distros Explained: Silverblue, NixOS, and Why They Matter

FlatlinerAtheist | CLI-NERDS — Mon, 02 Nov 2026 12:06:25 +0000

Every Linux user knows the failure mode: an upgrade touches one library too many, and suddenly the system that worked yesterday won't boot today. Immutable distros attack that problem at the root — the operating system is read-only, updates arrive as complete images, and rolling back is a reboot, not a rescue mission.

Once a niche idea, this model has gone mainstream: Fedora's Atomic editions (Silverblue, Kinoite), openSUSE's MicroOS, and NixOS all bet on it. Here's what it actually means and whether you should care.

What "immutable" really means

Your root filesystem is mounted read-only. You can't apt install into the base system because there is no base system to mutate — the OS is a versioned image. Apps arrive via Flatpak, containers, or toolbox environments that sit on top of the untouched base.

Upgrades replace the whole image: the new version stages alongside the current one, you reboot into it, and if anything breaks you reboot into the previous image. No half-applied updates, no dependency hell, no "my system is 60% upgraded."

The main options in 2026

Fedora Silverblue / Kinoite — the gentle on-ramp. Full Fedora underneath (Silverblue = GNOME, Kinoite = KDE), Flatpak for apps, rpm-ostree for system images. If you already know Fedora, the learning curve is mostly Flatpak and the toolbox command.

NixOS — the other end of the spectrum. Your entire system is declared in a single configuration.nix file: packages, users, services, kernel options. Rebuilds are atomic and every previous generation is bootable. It's the most powerful model and the steepest learning curve — you're learning a new language, not just a new distro.

openSUSE MicroOS — transactional updates with Btrfs snapshots, strong in server and edge deployments. Less desktop-polished than Fedora's offering but very solid.

A day in the life

On a traditional distro you install apps into the system. On Silverblue the workflow looks different:

flatpak install flathub org.mozilla.firefox   # desktop apps: Flatpak
toolbox create dev                              # a mutable Fedora container
toolbox enter dev
sudo dnf install gcc vim                        # dev tools inside the container

System-level packages you truly need on the host get layered with rpm-ostree install htop (which creates a new image and needs a reboot). On NixOS you instead add the package to configuration.nix and run sudo nixos-rebuild switch — the system converges to the declared state.

Who this is actually for

Great fit: laptops you depend on daily (a bad update can never brick your morning), homelab servers you want reproducible, and anyone who has ever thought "I wish I could just rebuild this machine from a file."

Poor fit: heavy kernel-module tinkerers, people who constantly install random .deb/.rpm packages from the internet, and workflows that demand writing all over the host filesystem. You can force these, but you'll fight the design instead of enjoying it.

Updates, rollbacks, and backups

Atomic updates are not the same as automatic backups. The image can protect your operating system from a half-finished upgrade, but it cannot recover documents you deleted or a disk that failed. Keep a separate backup routine for /home and any application data.

On an rpm-ostree system, inspect the available deployments with rpm-ostree status. If the newest deployment has a problem, sudo rpm-ostree rollback selects the previous one for the next boot. On NixOS, previous generations remain available from the boot menu. Test that rollback path before you depend on it, and read the update notes for major releases.

Also remember that “immutable” does not mean the whole machine is frozen. Persistent directories such as /etc, /var, and your home directory still change. NixOS takes a declarative approach rather than simply making every root filesystem read-only, but the practical goal is similar: reproducible system state and safer transitions between versions.

The honest trade-off

You give up the casual flexibility of "just install it into the system." In return you get an OS that is nearly unbreakable, trivially reproducible, and boring in the best way. For a growing number of people — especially after one too many upgrade disasters — that trade is an easy yes.

If you're curious, try Silverblue in a VM for a week. If the Flatpak + toolbox workflow clicks, you'll understand why immutable desktops stopped being a niche experiment.