DEV Community: John

How Many People Fit in a Self-Hosted Hubs Room? Dialog SFU Bandwidth and CPU Costs Explained

John — Fri, 07 Aug 2026 09:11:34 +0000

A single self-hosted Hubs server on a 4 vCPU, 8 GB VPS comfortably carries one room of roughly 15 to 25 participants with audio and avatars, and drops to single digits once most of them switch cameras on. The binding constraint is almost never Reticulum, the Elixir state server, which handles position and object sync at very low cost per user. It is Dialog, the mediasoup based SFU, which must decrypt, route and re encrypt every audio and video stream, and whose outbound bandwidth grows with the square of the participant count. Plan your capacity against Dialog's egress and CPU first, and treat everything else as secondary.

TL;DR by reader profile:

Two person startup replacing a paid meeting room, for example a design studio doing weekly client walkthroughs: one small VPS is enough, because a 4 person audio first room needs a fraction of a single core and well under 10 Mbit/s of egress.
Community organiser running open public rooms, for example a monthly meetup with 30 drop in visitors: budget for a dedicated Dialog host and cap video, because unrestricted cameras in a 30 person room push egress into hundreds of Mbit/s.
Educator running parallel classrooms, for example six seminar rooms of 12 students each: scale by adding Dialog instances rather than by growing one machine, since mediasoup workers are single threaded and bind to one core each.
Enterprise team behind a corporate firewall, for example a distributed engineering group on locked down laptops: provision TURN capacity explicitly, because relayed peers double the traffic path and can quietly triple your bandwidth bill.
Hobbyist on a home server, for example a NAS in a cupboard on domestic fibre: check upload speed before anything else, because a typical asymmetric connection saturates its uplink at around 8 to 12 video participants.
Event host planning a one off launch, for example 100 attendees in a showcase space: shard into multiple rooms or use audio only broadcast patterns, since a single Hubs room is not designed as a webinar stage.

The central tradeoff is simple: every extra participant you allow with video multiplies Dialog's forwarding work and your egress bill, while every restriction you impose on cameras, resolution or room size buys back capacity you can spend on more concurrent rooms.

What is the realistic concurrent user limit for one self-hosted Hubs server?
Which Hubs component actually breaks first under load, Reticulum or Dialog?
How does Dialog's SFU model differ from mesh and MCU, and why does it matter here?
How much bandwidth does each Hubs participant consume, upstream and downstream?
Why does room bandwidth grow quadratically, and where does the curve become unaffordable?
How much CPU does a mediasoup worker use per audio stream and per video stream?
What server specification do you need for 10, 25 and 50 concurrent participants?
How much does Reticulum cost per user for position, rotation and object sync?
When does TURN relay kick in, and what does it add to your bandwidth bill?
How do simulcast, bitrate caps and audio only rooms change the maths?

What is the realistic concurrent user limit for one self-hosted Hubs server?

Start from the room, not the server. A Hubs room is a single Reticulum channel plus a single Dialog routing context, so the numbers that matter are per room before they are per machine. On a 4 vCPU, 8 GB Linux host running the full Community Edition stack, plan around these ceilings.

Room style	Realistic ceiling on 4 vCPU, 8 GB	What stops you first
Audio only, avatars moving	Roughly 25 to 30 participants	Dialog egress, then mediasoup worker CPU
Audio plus a few shared cameras	Roughly 15 to 20 participants	Outbound bandwidth on the host uplink
Everyone on camera	Single digits, often 6 to 8	Quadratic forwarding load in Dialog
Audio plus screen share at 1080p	Roughly 12 to 15 participants	Sustained high bitrate of the shared track
Several parallel small rooms	Limited by core count, not room count	One mediasoup worker binds to one core

Treat those as planning defaults, not guarantees. Your scene complexity, bitrate caps and network path move them substantially, and the later sections quantify each factor.

Where you run the stack sets the hard limit on the uplink figure. A VPS gives you symmetric bandwidth and a public IP. A home server or NAS gives you cheap storage but usually an asymmetric uplink. Yundera is a managed Personal Cloud Server, built on CasaOS, that runs self-hosted apps as Docker containers on a server dedicated to the user. Whichever you pick, measure the uplink with iperf3 before you size a room, because Dialog cannot forward what the link will not carry.

Which Hubs component actually breaks first under load, Reticulum or Dialog?

Dialog breaks first, almost every time. The two services fail in completely different ways, and knowing which symptom belongs to which process saves hours of misdirected tuning.

Reticulum scales the way Elixir services do: it is a Phoenix application on the BEAM virtual machine, and each participant is a lightweight process handling position, rotation and object state over a WebSocket. Thousands of these coexist on one core. You will see memory grow gently and CPU stay flat.
Dialog scales the way media servers do: it is built on mediasoup, and each worker process is single threaded and pinned to one core. When that core hits 100 percent, every stream it routes degrades at once, regardless of how idle the other cores look.
The failure signatures are distinct: a saturated Dialog produces choppy audio, frozen video tiles and rising round trip time while avatars keep moving smoothly. A struggling Reticulum produces the opposite, teleporting avatars and stale object positions while voices stay clear.
PostgreSQL rarely participates: Reticulum writes room metadata, accounts and scene records, not per frame state, so database load stays roughly constant as a room fills.
The host uplink often beats both: on a 1 Gbit/s link, sustained video forwarding can exhaust bandwidth while both processes still report headroom, which reads as network failure rather than server failure.

Diagnose with top -H -p $(pgrep -f mediasoup) to see per thread CPU on Dialog workers, then compare against the BEAM scheduler load. If one thread sits at 100 percent and the rest idle, you have found your ceiling.

How does Dialog's SFU model differ from mesh and MCU, and why does it matter here?

Dialog is a selective forwarding unit built on mediasoup. It receives one upstream from each participant and forwards copies to everyone else without decoding or re encoding the video. That single design choice explains most of the capacity numbers in this article.

Architecture	What the server does	Cost at 10 participants with video
Mesh, peer to peer	Nothing, clients connect directly to each other	Each client uploads 9 copies and downloads 9, clients die first
SFU without simulcast, plain forwarding	Copies each incoming stream to every other peer	Each client uploads 1 and downloads 9, server egress is 90 stream copies
SFU with simulcast, Dialog's normal mode	Picks a suitable quality layer per receiver	Same stream count, lower total bitrate, no transcoding CPU
MCU, server side mixing	Decodes all streams, composites one, re encodes	Each client uploads 1 and downloads 1, server CPU cost is severe
Audio only SFU	Forwards Opus tracks, applies no video work	Trivial CPU, bandwidth measured in tens of kbit/s per stream

The practical consequence is that Dialog trades CPU for bandwidth. It never transcodes, so a mediasoup worker stays cheap in processor terms compared to an MCU like Jitsi Videobridge running in mixing mode. What it cannot escape is the copy count. Ten senders in one room mean 90 outbound stream copies leaving your network interface, and 20 senders mean 380.

That is why you size a Hubs deployment by egress capacity and worker count rather than by raw CPU. It also means adding a faster processor rarely raises your ceiling.

How much bandwidth does each Hubs participant consume, upstream and downstream?

Bandwidth in a Hubs room comes from four separate streams, and only one of them is expensive. Measure each one before you multiply.

Voice, Opus over SRTP: a single microphone track runs in the 24 to 40 kbit/s range at typical WebRTC settings, plus roughly 10 percent packet overhead. Thirty people talking is still under 1.5 Mbit/s of unique source material.
Webcam video, VP8 or H.264 simulcast: Dialog normally publishes several spatial layers, commonly around 150 kbit/s at 320x180, 500 kbit/s at 640x360 and 1.2 to 1.5 Mbit/s at 1280x720. Each receiver pulls the layer their connection and tile size justify, so downstream per stream varies widely.
Screen share at 1080p: treat this as the heaviest single track in the room, typically 2 to 3 Mbit/s sustained for detailed content, and higher during rapid motion. One presenter sharing to 20 viewers costs more egress than 20 voice tracks combined.
Avatar and object state over Reticulum: position, rotation and interaction messages travel on a WebSocket separate from the media path, measured in single digit kbit/s per user. This is noise against the media figures.
Scene and asset downloads: a GLB scene, textures and audio files transfer once per join, so a 40 MB scene costs 40 MB per visitor at join time, not continuously.

Upstream per participant is simple: one voice track, optionally one camera, optionally one screen share. Downstream is where the count multiplies. Open chrome://webrtc-internals during a live room and read bytesSent and bytesReceived per transport to confirm your own numbers rather than trusting defaults.

Why does room bandwidth grow quadratically, and where does the curve become unaffordable?

The arithmetic is unforgiving. With n people sending video, each of the other n minus 1 receives a copy, so Dialog emits n times n minus 1 stream copies. Doubling a room quadruples its egress.

Five senders at 500 kbit/s each: 20 outbound copies, roughly 10 Mbit/s of egress. Any connection handles this.
Ten senders at the same bitrate: 90 copies, roughly 45 Mbit/s. Still comfortable on a symmetric 100 Mbit/s link, already impossible on most domestic uplinks.
Twenty senders: 380 copies, roughly 190 Mbit/s sustained. This is where a shared VPS network allowance starts to matter more than CPU.
Thirty senders: 870 copies, roughly 435 Mbit/s. You are now consuming close to half a gigabit for one room.
Fifty senders: 2,450 copies, over 1.2 Gbit/s. A single 1 Gbit/s port cannot carry it, whatever the server specification says.

Convert that to metered cost before committing. Sustained 100 Mbit/s of egress transfers about 45 GB per hour, so a weekly two hour session at twenty senders moves several hundred gigabytes per month. Providers that meter egress will notice.

The practical break point sits between 15 and 20 simultaneous video senders on a 1 Gbit/s host. Below it, you tune. Above it, you change the room design.

Where you host decides which side of that line you sit on. A self managed VPS with a symmetric gigabit port, a home server or NAS on asymmetric fibre, and Yundera, a managed Personal Cloud Server built on CasaOS that runs self-hosted apps as Docker containers on a server dedicated to the user, each present a different uplink profile you should confirm before sizing rooms.

How much CPU does a mediasoup worker use per audio stream and per video stream?

Dialog never decodes media, so the CPU cost is packet handling, not pixel work. What a worker actually spends its cycles on is SRTP decryption of the incoming packet, per consumer bookkeeping, then SRTP encryption of each outgoing copy. Cost tracks packets per second, not bitrate alone.

Audio is cheap because packet rates are low: Opus at the standard 20 ms frame size produces 50 packets per second per stream. Forwarding one voice track to 29 listeners means 1,450 encryptions per second, which a single core absorbs without noticing.
Video is expensive because packets are many: a 1.2 Mbit/s stream at a 1,200 byte payload runs at roughly 125 packets per second. The same 29 receivers turn that into 3,625 encryptions per second for one sender, and each additional sender adds another block.
Simulcast multiplies incoming work, not outgoing: the publisher sends several spatial layers, so the worker decrypts all of them but still forwards only the layer each consumer selected. Ingest cost rises modestly, egress cost does not.
Retransmissions add unpredictable load: NACK and PLI handling from lossy clients forces the worker to resend packets and request keyframes, and a handful of bad connections can cost more than a dozen clean ones.
Worker count is your only horizontal lever on one box: mediasoup starts one worker process per detected CPU core by default, each single threaded, and a room is pinned to a single worker.

Watch it live with pidstat -u -p $(pgrep -d, -f mediasoup) 1. When one worker crosses roughly 80 percent of a core, stop adding video senders to rooms it owns.

What server specification do you need for 10, 25 and 50 concurrent participants?

Size three things separately: cores for Dialog workers, RAM for Reticulum and PostgreSQL, and uplink for egress. The uplink is usually what you have to buy deliberately.

Target load	Specification to plan for	The binding constraint
4 to 6 people, one test room, audio first	2 vCPU, 4 GB RAM, 100 Mbit/s symmetric, 40 GB disk	Nothing, this runs the whole Community Edition stack on one host
10 concurrent, mixed audio and occasional video	4 vCPU, 8 GB RAM, 1 Gbit/s port	RAM, once PostgreSQL, Reticulum and the asset hosts share a box
25 concurrent, audio led with a few cameras	8 vCPU, 16 GB RAM, 1 Gbit/s port, metered egress checked	Sustained egress, not processor headroom
50 concurrent, video restricted	Dialog on its own 8 vCPU host, Reticulum and PostgreSQL on a second 4 vCPU host	Worker to core pinning, plus port capacity
50 plus, or several parallel rooms	Multiple Dialog instances, one per host, rooms assigned across them	Horizontal scaling, since a room cannot span workers

Allow 2 GB of RAM for PostgreSQL before tuning shared_buffers, and keep 20 GB of disk free for scene assets and uploads, which grow quietly.

Hosting choices split along the same lines: a self managed VPS gives you the symmetric port and root access to tune kernel networking, a home server or NAS gives you storage but rarely the uplink, and Yundera is a managed Personal Cloud Server built on CasaOS where apps are installed from an app store in one click rather than assembled from compose files by hand. Confirm the egress allowance in writing before you commit to a 25 person room.

How much does Reticulum cost per user for position, rotation and object sync?

Reticulum's cost per user is small enough that it rarely appears in capacity planning, but it is not zero, and it also fans out quadratically. The difference is payload size.

Per user memory on the BEAM is measured in kilobytes: each participant is an Erlang process holding channel state, so a 30 person room adds megabytes, not gigabytes. Reticulum's baseline footprint dominates, and that baseline is roughly constant.
Update payloads are tiny: an avatar transform is a handful of floats for position, rotation and a few tracked bones. Even at 10 to 20 updates per second, one sender produces low tens of kilobits per second of unique data.
The fan out still squares: with 30 people in a room, every update is copied 29 times. Assume 15 updates per second at 50 bytes and the room generates roughly 650 kB/s of broadcast traffic in total, which is under 6 Mbit/s. That is one twentieth of what the same room costs in video.
Object and media pins hit PostgreSQL, movement does not: spawning, moving and pinning an object writes a row, so a room where people constantly pin content produces steady database writes while ordinary walking around produces none.
Join and leave events are the spiky part: each join triggers presence updates to every client plus scene metadata queries, so 30 people arriving in the same 60 seconds costs more than the following hour.

Verify on your own instance by attaching to the running node and reading scheduler utilisation with :observer.start() or recon:scheduler_usage/1. If Reticulum is your bottleneck, you have an unusual room, not a typical one.

When does TURN relay kick in, and what does it add to your bandwidth bill?

Most Hubs clients connect straight to Dialog over UDP, because an SFU is already a public endpoint and needs no peer to peer hole punching. Relay only appears when the client side network refuses that path.

Symmetric NAT and strict firewalls force it: corporate networks that permit outbound 443 only will block Dialog's UDP media range outright, and the ICE negotiation falls back rather than failing.
ICE over TCP is the cheaper first fallback: mediasoup can accept TCP candidates on the same host, which keeps media on your Dialog server and adds latency and head of line blocking instead of a second machine and a second bandwidth charge.
coturn is the real TURN option: it listens on 3478 for UDP and TCP and 5349 for TLS, with a media port range set by min-port and max-port in /etc/turnserver.conf. Use static-auth-secret with time limited credentials rather than long lived users.
Relayed traffic is counted twice: every byte enters the TURN server and leaves it again, so a relayed participant pulling 2 Mbit/s costs 4 Mbit/s of measured transfer on that host, on top of the identical traffic Dialog already sent.
A small relay share is a large bill: in a 20 person video room, moving just 4 participants onto TURN adds their entire downstream a second time, which is a double digit percentage increase on total egress for a fifth of the audience.

Test before you need it with turnutils_uclient -T -u user -w secret your.turn.host. If you skip TURN entirely, accept that some corporate and mobile users will join with avatars visible and no audio at all.

How do simulcast, bitrate caps and audio only rooms change the maths?

These three levers move your ceiling further than any hardware upgrade. Each one attacks the copy count or the bitrate per copy. Take the same 20 person room and compare.

Configuration	What actually changes	Room egress at 20 participants
Everyone on camera at 640x360, 500 kbit/s	Nothing restricted, 380 outbound copies	Roughly 190 Mbit/s
Bitrate capped to 320x180, 150 kbit/s	Same 380 copies, each one smaller	Roughly 57 Mbit/s
Simulcast selecting low layers for distant avatars	Receivers pull the layer their tile size justifies	Between the two figures above, typically nearer the lower
Camera rights limited to 4 speakers	Copies fall to 4 senders times 19 receivers, 76 total	Roughly 38 Mbit/s
Audio only, avatars and screen share off	380 Opus copies at about 32 kbit/s	Roughly 12 Mbit/s

Three practical notes. Simulcast is the default worth keeping, because it costs the publisher extra upstream but saves every receiver downstream, and it degrades gracefully when one participant's connection collapses. Bitrate caps belong in Dialog's mediasoup settings rather than in client code, since anything enforced client side can be bypassed by a browser flag.

Restricting camera rights is the blunt instrument that works. Hubs room settings let you decide who may share video, and moving from open cameras to four presenters cuts egress by 80 percent in the table above without touching resolution at all.

Audio only is not a fallback, it is a valid room design. A 30 person social space with spatial audio, avatars and a good scene stays under 20 Mbit/s and runs on hardware that would collapse instantly with cameras enabled.

Duplicati on Backblaze B2 vs Backblaze Personal Backup: where the yearly cost actually crosses over

John — Fri, 07 Aug 2026 09:05:07 +0000

Duplicati backing up to Backblaze B2 costs less per year than a Backblaze Personal Backup subscription only below a dataset size you can calculate in one line, and that line is the whole decision. Personal Backup charges a flat annual fee per computer for unlimited data, so its cost curve is horizontal. B2 charges per gigabyte stored per month plus API calls and egress above the free allowance, so the Duplicati bill starts near zero and rises in a straight line. Divide the annual subscription fee by twelve times the B2 per gigabyte monthly rate, and you get the crossover in gigabytes: below it Duplicati wins every year, above it the subscription wins and keeps winning harder as you add data.

TL;DR

The 400 GB laptop owner, one MacBook holding documents, photos and a code folder: run Duplicati to B2, because a few hundred gigabytes billed per gigabyte per month sits far under any flat annual fee, and Duplicati compresses and deduplicates before you are billed.
The 6 TB media keeper with a film and music library on external drives: stay on Personal Backup, because unlimited flat pricing per computer is unbeatable at that volume and B2 charges for every terabyte forever.
The two person household with three laptops totalling 1.5 TB: run Duplicati into one B2 bucket, because the subscription is licensed per computer while a single bucket and three Duplicati jobs cover all of them under one bill.
The homelab operator with a NAS, a Proxmox host and two Linux VMs: Duplicati is the only option of the two, because Personal Backup is a Windows and macOS desktop product that excludes network shares and server operating systems.
The person who has never restored a file and wants zero maintenance: stay subscribed, because Duplicati's real price includes your own hours on local database rebuilds, retention tuning, verification runs and failure monitoring.
The person restoring large amounts often, for example a video editor pulling back 500 GB projects: model the egress before you switch, because Personal Backup restores are included while B2 bills downloads once you pass the free egress allowance.

The central tradeoff is a flat fee that ignores how much data you own against a metered bill that rewards you for owning less of it, with the difference paid in your own attention.

What does Duplicati plus Backblaze B2 actually cost you per year?
What does a Backblaze Personal Backup subscription actually cost per year?
At what dataset size do the two cost curves cross?
Deduplication, compression and the number B2 really bills you for
How much do restores cost, and how often will you actually restore?
How does retention depth change the arithmetic?
Tuning Duplicati remote volume size, upload threads and API call classes
Multiple computers, NAS shares and the per computer licence
What each product simply refuses to back up
Where should you run Duplicati, and what does the host add to the bill?

What does Duplicati plus Backblaze B2 actually cost you per year?

Duplicati itself is free and open source, so every euro or dollar on your annual bill comes from B2 and from your own hardware. The bill has four moving parts, and only one of them is the obvious one.

Storage per gigabyte per month: B2 bills the average bytes stored across the month, so your annual cost is roughly your stored size multiplied by the published per gigabyte rate multiplied by twelve. This is the dominant term for almost everyone.
Stored size, not source size: Duplicati 2 deduplicates at a default block size of 100 KB and compresses before upload, so a 500 GB source folder rarely becomes 500 GB in the bucket. Documents and code shrink hard, video and photos barely move.
Transaction calls: B2 splits API calls into Class A, Class B and Class C, with Class A calls such as uploads free and the listing and download classes billed per thousand calls. Duplicati's default remote volume size of 50 MB means a 500 GB backup lands as roughly 10,000 objects, which keeps call counts modest but not zero.
Egress on restore: B2 includes a free download allowance tied to your average stored data, and bills per gigabyte beyond it. Routine backups download nothing, so this term is zero in most years and spikes only when you restore.
Version retention: every kept version of a changed file is extra stored bytes, billed monthly like everything else.

Add those four, and you have a number that scales with what you actually own.

What does a Backblaze Personal Backup subscription actually cost per year?

Personal Backup is a flat fee per computer, billed monthly, yearly or on a two year term, with the longer terms carrying a lower effective annual rate. Unlimited means unlimited: 200 GB and 20 TB on the same machine cost the same. The complications are not in the headline price.

The licence covers one computer, not one household: three laptops means three subscriptions, and the annual cost triples while the amount of data protected is irrelevant to the bill.
Version history defaults to 30 days: deleted or changed files fall out of the backup after 30 days unless you pay for an extended version history add on, sold as a one year option and a forever option.
Forever version history is not flat: the forever tier adds a per gigabyte per month charge for data older than one year, which reintroduces exactly the metered pricing model you left B2 to avoid.
External drives count, network drives do not: USB attached disks are included at no extra cost, but a NAS share, a mapped network drive or a Linux server cannot be backed up at all, so protecting them means a second product on top.
Attached drives must be reconnected every 30 days: disconnect an external disk for longer and its backed up data is purged from the account, which is a silent cost if you rotate archive drives.
Restores are included: web download and restore by mail both come with the plan, with the mailed drive refunded on return.

The predictable number on the invoice is the product's main feature.

At what dataset size do the two cost curves cross?

Work it out yourself in one line. Take the annual Personal Backup fee, divide it by twelve, then divide that by the current B2 per gigabyte monthly rate. The result is the crossover in gigabytes stored, and both numbers are published on Backblaze's own pricing pages, so the calculation stays correct as rates change. Call that crossover point C.

Bytes stored in B2	Duplicati annual cost versus one subscription	What it means for you
0.25 x C	About 25 percent	Duplicati is clearly cheaper, and the gap is large enough to absorb restores
0.5 x C	About 50 percent	Duplicati is cheaper, with room for retention growth before parity
1 x C	Parity	Choose on features, not on price, because the invoices match
2 x C	About 200 percent	The subscription is cheaper and the gap widens every month you add data
4 x C	About 400 percent	Only non cost reasons justify Duplicati at this volume

Two adjustments move C in your favour. First, C scales linearly with the number of machines: three computers on Personal Backup means three fees, so your effective crossover is 3 x C for a single B2 bucket holding all three. Second, C applies to stored bytes, not source bytes, so Duplicati compression can put a 700 GB source folder comfortably under a 500 GB crossover.

One adjustment moves it against you: unlimited retention on B2 grows stored bytes forever, while the flat fee never notices.

Deduplication, compression and the number B2 really bills you for

Your source folder size is not your invoice. Duplicati hashes every block with SHA-256, stores each unique block once, packs blocks into archive volumes and compresses them before upload. Four things decide how far that gets you.

File type dominates the ratio: text, code, spreadsheets, mailboxes and virtual disk images compress and deduplicate heavily. JPEG, MP4, MP3 and existing ZIP archives are already compressed, so expect close to no reduction. Duplicati ships a default_compressed_extensions.txt list and skips compressing those types rather than burning CPU for nothing.
Deduplication is per backup job, not per bucket: two jobs covering the same 40 GB photo folder store those blocks twice and you pay twice. Consolidating overlapping folders into one job is free money.
Deleted data stays billable until compaction runs: when retention removes an old version, its blocks remain inside archive volumes that still contain live blocks. Duplicati only rewrites a volume once wasted space passes the compact threshold, 25 percent by default, so stored bytes lag behind logical deletions.
Encryption adds a small constant, not a percentage: AES-256 output is roughly the size of its compressed input plus per volume header overhead, so encryption costs you almost nothing on the bill.
The dashboard tells you the truth: the job's reported backend size, not the source size, is the number to feed into the crossover calculation from the previous section.

Measure once with a real backup before committing. A 1 TB documents heavy dataset and a 1 TB video library produce completely different B2 bills.

How much do restores cost, and how often will you actually restore?

Most people restore a handful of files a year and a full dataset once a decade, if ever. That matters because B2 includes a free download allowance of three times your average monthly stored data, so a household sized restore usually lands inside it.

A single full restore is normally free: pulling back everything you store is 1x your stored bytes against a 3x allowance, so you would need to restore your entire backup three times in one month before egress charges start.
Small restores cost more than you expect in bytes: Duplicati downloads whole archive volumes, so recovering one 2 MB document can pull a 50 MB volume. The cash impact is negligible, the wait is not.
Restoring without the local database is the slow path: direct restore first downloads the dlist and dindex files to rebuild an index of what is where, which on a large backup with many versions can take hours before a single file lands.
Class B download transactions are billed per call: thousands of volume fetches during a big restore add a small line item alongside egress, another reason larger remote volume sizes suit archival datasets.
Personal Backup charges nothing for either route: web download restores are included, and the restore by mail USB drive is refunded when you return it, so the subscription genuinely removes restore cost from the equation.

Budget the shape, not a scary number: routine restores are effectively free on both, and only repeated bulk pulls of your whole dataset make B2 egress a real line on the invoice.

How does retention depth change the arithmetic?

Comparing a 30 day subscription against an unlimited history Duplicati job is not a fair comparison. Match the retention first, then compare the invoices.

Retention setting	Effect on your bill	Where it applies
Keep all versions, the Duplicati default	Stored bytes grow with every change forever, so the B2 line rises even if your source folder never grows	Duplicati
`--keep-time=30D`	Roughly matches the standard subscription window, keeping stored bytes close to your live dataset size	Duplicati
`--retention-policy=1W:1D,4W:1W,12M:1M`	Thins older versions to one per week then one per month, buying a year of history for a fraction of the bytes	Duplicati
30 day version history, the plan default	No extra charge, and anything deleted more than 30 days ago is gone	Personal Backup
One year extended version history	A fixed add on fee per computer per year, still flat regardless of data volume	Personal Backup
Forever version history	Flat fee plus a per gigabyte monthly charge on data older than one year, so the metered model returns	Personal Backup

The practical consequence is that deep retention narrows the gap. If you want a year of history, the subscription add on is a fixed number per computer, while Duplicati's smart retention adds real bytes to a metered bill. If you want a decade of history, Duplicati's thinned policy competes well against a forever tier that meters everything over twelve months old.

Set retention before you measure stored size, or your crossover calculation is based on a number that will keep climbing.

Tuning Duplicati remote volume size, upload threads and API call classes

Defaults are tuned for a 50 GB laptop, not a 2 TB archive. Four settings change your bill, your backup window and your restore speed, and they pull against each other.

--dblock-size, default 50 MB: raising it to 200 MB or 500 MB cuts object count and the listing calls that go with it by the same factor. The cost is restore granularity, since recovering one small file downloads one whole volume.
--blocksize, default 100 KB: this one is fixed at job creation and cannot be changed later without starting over. A 2 TB dataset at 100 KB implies roughly 20 million block records in the local SQLite database, which is what makes repair and rebuild operations crawl. Raising it to 1 MB or larger for multi terabyte jobs trades a little deduplication for a database that stays usable.
--asynchronous-concurrent-upload-limit, default 4: more parallel uploads fill a fast link, but each in flight volume needs temporary disk space, and B2 counts each upload as a Class A call, which is not billed.
--number-of-retries, default 5, with --retry-delay: raising both rides out transient B2 errors instead of failing a job at 90 percent and re uploading later.

The class split is what makes B2 forgiving here: uploads and deletes are Class A and free, downloads are Class B, and listing is Class C with a published daily free allowance. Duplicati lists the bucket on every run, so shrinking object count with a larger volume size keeps you comfortably inside it.

Multiple computers, NAS shares and the per computer licence

This is where the flat fee stops being flat. Every extra machine multiplies a subscription while adding only its own gigabytes to a B2 bucket, so a four device household is a completely different calculation from a single laptop.

One bucket serves every machine: give each host its own Duplicati job and its own --prefix value, for example laptop-anna/ and nas-media/, so their archive volumes stay separated inside a single bucket and a single bill.
Issue one restricted application key per host: B2 application keys can be scoped to one bucket and one name prefix, so a compromised laptop key cannot read or delete another machine's backup. The master key stays out of every configuration file.
A central job over SMB shares deduplicates across machines: point one Duplicati instance at mounted network shares and shared files are stored once. The catch is that a laptop out of the house at 02:00 is simply not backed up that night.
Per machine agents catch laptops, at a cost: Duplicati runs on Windows, macOS, Linux and in Docker, so each device can back itself up whenever it has a connection, but identical files on two machines are billed twice.
Servers and NAS boxes have no subscription path at all: a Synology volume, a Proxmox host or a Linux VPS cannot be enrolled in a desktop plan, so mixed estates end up paying for two products anyway.

Count your machines before you compare prices. Three subscriptions against one metered bucket moves the crossover point three times further out.

What each product simply refuses to back up

Both tools have hard exclusions, and neither warns you loudly about them. Check this list against what you actually care about before comparing invoices.

Data	Backblaze Personal Backup	Duplicati
Operating system files, applications, temporary files	Excluded by default, since the product protects user data rather than a bootable image	Included if you select the path, though it is not a bare metal image either
Virtual disk images such as `.vmdk`, `.vhd` and `.iso`	Excluded by default through the client's exclusion rules, editable in settings	Included, and they deduplicate well between versions
Network shares and NAS volumes	Not supported at all	Supported through any mounted path, including SMB and NFS mounts
Linux hosts and servers	No client exists	First class, including headless Docker deployments
Open or locked files	Handled by the client's own snapshot logic	Requires `--snapshot-policy=on` to use VSS on Windows or LVM on Linux
Live databases	Files are copied as found, with no consistency guarantee	Same, unless you dump first with `--run-script-before`

Two practical consequences follow. If your important data includes VM images or a NAS share, the subscription's unlimited pricing never applies to it, so the comparison collapses before cost enters the picture. If your important data is a laptop's documents and photos, both cover it fully, and you are back to arguing about gigabytes.

Also check the client's maximum file size setting before trusting it with 80 GB video projects, because a size cap silently skips files rather than failing the backup.

Where should you run Duplicati, and what does the host add to the bill?

Duplicati has to run somewhere that can read your files, stay awake on schedule and hold a local SQLite database. That host is the hidden line item the subscription does not have.

On the machine being backed up: the simplest option, with the web interface on port 8200 and no extra hardware cost. The catch is that a sleeping laptop runs no backup, so set a schedule that matches when the lid is actually open.
On a NAS via Docker: one container backs up every share, which suits the central job pattern. Budget the local database on fast storage, because rebuilds on a spinning disk are painfully slow.
On a mini PC or home server: a low power box running 24/7 adds electricity and a machine to maintain, but it backs up network shares on a fixed schedule without depending on anyone's laptop.
On a VPS or a managed personal server: useful when the data already lives off site, for example a web application's files and database dumps. Yundera is a managed Personal Cloud Server, built on CasaOS, that runs self-hosted apps as Docker containers on a server dedicated to the user, and it sits alongside a self managed VPS, a home server or a NAS as one place to run the container.

One rule applies to every choice: a remote host can only back up data it can reach. Running Duplicati off site does nothing for the photos on a laptop unless those photos already sync somewhere the container can read.

OpenClaw vs Subscription AI Assistants: Real Token Costs, Capability Gaps and the Usage Level Where Self-Hosting Wins

John — Fri, 07 Aug 2026 08:10:14 +0000

OpenClaw wins on cost only at the two extremes of usage: very light use, where a metered token bill stays far below a flat monthly seat fee, and heavy automated use, where a subscription would throttle you long before your work is done. In the middle band, where you send a few dozen messages a day to a frontier model, a flat subscription is usually the cheaper line item, and OpenClaw earns its place on capability and data control instead of price. What OpenClaw actually buys you is a resident agent with shell access, file access, indefinite memory and a heartbeat that acts without being prompted, none of which a chat subscription offers at any tier. Treat the server as the small cost and the model tokens as the variable that decides everything.

TL;DR by reader profile

The light personal user, for example someone sending 10 to 20 messages a day and cancelling a 20 USD per month plan: run OpenClaw against a mid tier API model, because at that volume metered tokens plus a small VPS usually land under the flat fee.
The steady daily user, for example a knowledge worker with long threads and large pasted documents: keep the subscription and add OpenClaw only for automation, because long context replays are what make metered billing overtake a flat fee.
The automation builder, for example someone replacing scheduled Zapier or Make scenarios: move to OpenClaw, because the heartbeat and tool access do work a chat subscription cannot perform at any price.
The privacy driven self-hoster, for example someone who wants files and memory to stay on their own disk: run OpenClaw with a local model through Ollama, and accept slower responses and weaker reasoning as the price of zero prompt egress.
The developer with an existing homelab, for example someone already running a 4 vCPU and 8 GB server: adopt OpenClaw early, because your marginal hosting cost is close to zero and only tokens are new spend.
The non technical subscriber, for example someone who wants an assistant and not a system to maintain: stay subscribed, because OpenClaw adds credential handling, model routing, permission scoping and update duty to your week.

The central tradeoff is simple: a subscription gives you a predictable bill and no maintenance, while OpenClaw gives you capability and data control in exchange for a bill that moves with your usage and a system you now own.

What does OpenClaw actually do, and what does it replace?
Flat subscription fees versus metered tokens: two different cost shapes
What drives an OpenClaw token bill: context, memory and the heartbeat
How much server does OpenClaw need, and what does that cost to run?
How much does OpenClaw cost per month at light, steady and heavy usage?
At what monthly usage does self-hosting OpenClaw actually win?
Can local models through Ollama cut the OpenClaw token bill to zero?
What does OpenClaw do that a subscription assistant cannot?
What do you give up when you cancel the subscription?
Which of your data leaves the server when OpenClaw calls a hosted model?
What does OpenClaw cost over three years, including your own time?
Where should you run OpenClaw: home server, VPS, NAS or managed Personal Cloud Server?

What does OpenClaw actually do, and what does it replace?

OpenClaw is an open source AI agent you run on your own hardware, previously known as Clawdbot and Moltbot. It connects to messaging apps you already use, including WhatsApp, Telegram and Discord, and it brings its own model keys rather than shipping a model. You point it at Anthropic's Claude, OpenAI's GPT models or a local model served through Ollama, and you pay for whatever that model charges per token.

The distinction that matters for cost is that OpenClaw is an agent, not a chat window. It executes rather than answers.

File and shell access: OpenClaw reads and writes files on the machine it runs on and can execute terminal commands, so it acts on your actual working directory rather than on pasted excerpts.
Persistent memory: it retains preferences, ongoing projects and personal detail indefinitely in local storage, instead of losing state when a chat thread ends.
The heartbeat: OpenClaw wakes on its own schedule to check calendars, watch repositories and message you first, which is work no chat subscription performs.
Messaging bridges: the interface is Telegram or WhatsApp, so the assistant lives beside your other conversations rather than in a separate tab.

That combination means OpenClaw replaces two purchases at once. It replaces the flat assistant subscription, typically 20 USD per month at the entry tier for the mainstream products. It also replaces part of an automation subscription such as Zapier or Make, because scheduled, self triggered tasks are native behaviour here. Judge the bill against both, not just the chat plan you are cancelling.

Flat subscription fees versus metered tokens: two different cost shapes

A subscription and an OpenClaw deployment do not just differ in price. They differ in the shape of the curve, and that shape decides who wins at your volume.

A subscription is a step function. You pay the same 20 USD per month at the entry tier whether you send 5 messages or 500, until you hit a usage cap and either wait for a reset window or jump to the next tier. OpenClaw is a straight line through the origin. Zero messages costs you only the server. Every message after that adds its own token charge, and nothing resets at midnight.

Cost dimension	Flat subscription	OpenClaw with metered API
Cost at zero usage	Full monthly fee, billed regardless	Server only, no model spend
Cost at heavy usage	Capped by tier, then throttled	Rises linearly with no ceiling
Predictability	Exact figure known in advance	Varies month to month with workload
Rate limits	Enforced per plan tier	Bounded by provider account limits
Cost of a second user	Usually a second seat fee	Extra tokens only, one server
Idle automation	Not offered on chat plans	Heartbeat runs bill even when you sleep

Two consequences follow. First, the flat plan protects you from your own worst month, while OpenClaw exposes you to it. Second, OpenClaw charges you for activity you never initiated, because a scheduled check that finds nothing still consumed input tokens. Budget for the floor your automation creates before you budget for your conversations.

What drives an OpenClaw token bill: context, memory and the heartbeat

Your bill is not driven by how much you type. It is driven by how much the agent has to re-read before it answers you. Output tokens are the smaller half of the invoice for most personal deployments, because a 40 word reply is cheap and the 8,000 token context that produced it is not.

Context replay on every turn: each message resends the conversation so far, so turn 20 of a thread costs far more than turn 2, and one long session can cost more than fifty short ones.
Memory injection: the indefinite memory that makes OpenClaw useful is loaded into the prompt as text, so a memory store that grows all year quietly raises the floor price of every single request you make.
Tool call round trips: one instruction can become three or four model calls, because reading a file, running a command and interpreting the result are separate turns, each carrying the full context again.
Heartbeat wake-ups: scheduled checks bill input tokens even when the answer is nothing happened, so a 15 minute interval creates 96 paid calls per day before you say a word.
Model tier selection: a top tier reasoning model can cost several times a mid tier one per million tokens, and OpenClaw lets you route to either, so tier choice moves the bill more than message count does.

Two levers matter most. Lengthen the heartbeat interval from 15 minutes to 60 and you remove roughly three quarters of that idle spend. Prune memory and start fresh threads, and you cut the per turn floor for everything else.

How much server does OpenClaw need, and what does that cost to run?

The hardware side of this comparison is the boring side, and that is the point. OpenClaw's documentation recommends 2 vCPUs and 4 GB of RAM for development and testing, and 4 vCPUs, 8 GB of RAM and at least 20 GB of SSD storage for production use. Those are modest numbers. The agent spends most of its life idle, waiting on a heartbeat or on a reply from a remote model API, so CPU load is bursty and low.

Small VPS: a 4 vCPU and 8 GB instance from a mainstream provider covers the production baseline, and this is a fixed monthly line item you can quote exactly before you start.
Existing home server or NAS: if you already run a machine 24/7, your marginal cost is the electricity for a workload that is idle most hours, which makes tokens your only genuinely new spend.
Managed Personal Cloud Server: Yundera is a managed Personal Cloud Server, built on CasaOS, that runs self-hosted apps as Docker containers on a server dedicated to the user, which is a third option beside a self-managed VPS and hardware you own.
Storage growth: the 20 GB floor covers the install, but persistent memory, logs and any files the agent touches grow steadily, so watch the volume rather than assuming the baseline holds all year.

Budget the server as a flat number and stop thinking about it. On almost every deployment described in this article, hosting is the smaller half of the bill and model tokens are the half that actually varies.

How much does OpenClaw cost per month at light, steady and heavy usage?

There is no single answer, because your bill is a fixed server fee plus a token figure that you set by behaviour. What you can do is model the three profiles honestly, in token volume rather than invented currency, then multiply by whatever your chosen model charges per million tokens on the day you sign up.

Assume the production baseline of 4 vCPUs and 8 GB in all three cases, so the server line is identical and only the model spend moves.

Usage profile	Monthly workload	What dominates the bill
Light	10 to 20 short messages a day, heartbeat at 60 minutes, memory pruned	Server fee, with token spend a minority of the total
Steady	50 to 100 messages a day, long threads, documents pasted in	Context replay, which grows faster than message count
Heavy	Continuous automation, heartbeat at 15 minutes, multi step tool chains	Tool call round trips, at three or four model calls per instruction
Local only	Any volume, model served by Ollama on your own hardware	Electricity and RAM, with no per token charge at all

Two rules make the arithmetic tractable. First, multiply your daily message count by your average context length, not by your typing length, because the context is what you actually pay for. Second, add the heartbeat separately: at a 15 minute interval that is 96 calls a day, or roughly 2,880 a month, each carrying your memory payload whether or not anything happened.

Price those two numbers against your provider's published rate and you have your real figure.

At what monthly usage does self-hosting OpenClaw actually win?

The break-even is not one number, it is two crossing points, and most people sit between them.

Below roughly 20 short messages a day: OpenClaw usually wins on price, because a metered bill at that volume is a fraction of a flat 20 USD entry tier, and your only guaranteed cost is the server. Cancel with confidence.
Between 20 and 100 messages a day on a frontier model: the subscription usually wins, because context replay compounds and you are paying full rate for exactly the conversational usage that a flat plan was designed to absorb. This is the widest band and the one people miscalculate.
Above the plan's throttle point: OpenClaw wins again, not because tokens got cheaper but because the subscription stops serving you and the metered account does not. If you regularly hit reset windows, the comparison is no longer price against price.
Any automation at all: OpenClaw wins by default, because there is no subscription tier that runs a 15 minute heartbeat against your calendar and repositories on your behalf.
When the hardware is already paid for: the crossing point moves in OpenClaw's favour, since the fixed side of the equation collapses. This applies to a home server, a NAS, an existing VPS or a managed Personal Cloud Server such as Yundera.

Work it out this way: divide your server cost by your model's blended per million token rate to get your monthly token allowance at break-even, then compare that allowance to the volume you modelled earlier. If your projected usage is under it, self-hosting is cheaper. If it is well over, you are buying capability, not savings.

Can local models through Ollama cut the OpenClaw token bill to zero?

Yes, and that is the wrong way to think about it. Ollama removes the per token charge entirely, then hands you three replacement costs: hardware, latency and capability. OpenClaw supports local models as a first class option, so the plumbing is not the problem. The economics of the machine underneath it are.

Hardware moves from optional to mandatory: the 4 vCPU and 8 GB production baseline is sized for an agent that calls a remote API, not one that runs inference locally, so useful local models push you into far more RAM and usually a GPU.
The cost becomes capital, not subscription: you pay once for the hardware and then only for electricity, which flips the comparison from a monthly line item to an amortisation question over 24 or 36 months.
Capability drops at the reasoning end: local models handle summarising, routing and short replies acceptably, while multi step tool chains and long context planning are where the gap against a frontier model shows most.
Latency becomes visible: a remote API answers in seconds regardless of your hardware, while a local model on modest hardware makes the heartbeat and every tool round trip noticeably slower.
Prompt egress goes to zero: nothing leaves your machine, which is the one benefit no amount of API spend can buy back.

The pragmatic setup is hybrid. Route the heartbeat and routine classification to a local model, because that is high volume, low difficulty work that was inflating your bill, and reserve a hosted frontier model for the requests that genuinely need reasoning. That combination usually cuts spend more than going fully local does.

What does OpenClaw do that a subscription assistant cannot?

The capability gap is not about answer quality. On the same underlying model, a hosted chat product and OpenClaw produce comparable text. The gap is about what happens between messages, and about who decides the rules.

Act without being asked: the heartbeat gives OpenClaw permission to start work, so it can check a repository at 07:00 and message you the result, while a chat product only ever responds to a prompt you typed.
Reach the real filesystem: OpenClaw operates on the directory it runs in, so it edits your actual files and runs commands against them rather than working from a copy you pasted into a box.
Route per task, not per plan: you choose Claude for one job, a GPT model for another and Ollama for the heartbeat, and you can change that routing in an afternoon, whereas a subscription binds you to one vendor's model lineup.
Retain state indefinitely: memory persists on your disk with no thread limit and no retention window imposed from outside, so context from eight months ago is still available.
Ignore the reset clock: there is no plan tier that pauses you at a usage cap, so a long automated run finishes instead of stopping partway.
Live where your messages already are: the assistant answers inside Telegram, WhatsApp or Discord, which means household members and mobile use come free rather than requiring extra seats.

None of that is free. Every item on this list is also an item on the risk list, because an agent that can run commands, keep everything you say and act at 03:00 without supervision is exactly as consequential as it sounds.

What do you give up when you cancel the subscription?

Honest accounting means listing the losses, and they are real. A subscription is not only a model behind a login. It is a bundle of features that other teams built, tested and support, and OpenClaw hands most of that work back to you.

The polished client: you lose native mobile and desktop apps, voice input, document upload widgets and image generation surfaces, and you get a Telegram or WhatsApp thread instead.
The predictable bill: you lose the guarantee that a runaway month cannot happen, because nothing between your agent and the provider stops a misconfigured loop from spending until you notice.
Someone else's uptime: you become the operator, so container restarts, expired API keys, provider outages and OS updates are now yours to handle at whatever hour they occur.
Vendor side safety rails: account level abuse handling, content filtering and rate limiting were doing quiet work, and an agent with shell access and no supervisor is a different risk profile.
Integrated extras: features bundled into the 20 USD tier, from web browsing surfaces to connectors, become things you configure and maintain individually.

Add the time cost explicitly. The first week is genuine setup work: provisioning the server, pairing a messaging channel, scoping tool permissions, setting the heartbeat interval and testing what the agent is allowed to touch. After that, budget an hour or two a month for updates and key rotation. If that hour is worth more to you than the price difference you calculated earlier, the subscription is the rational choice and no amount of capability changes that.

Which of your data leaves the server when OpenClaw calls a hosted model?

Self-hosting the agent is not the same as self-hosting the inference. If OpenClaw is routed to Claude or a GPT model, the prompt goes to that provider exactly as it would from a subscription client. What changes is that you control which bytes get put into the prompt in the first place.

Data category	Stays on your server	Sent to the provider
Files and directories	The files themselves, at rest on your disk	Any excerpt the agent reads into context
Persistent memory	The full store, held locally	Whatever slice is injected into a given request
Message history	Complete archive, retained as long as you choose	The replayed context window for each turn
Command output	Logs and results on the machine	Any output fed back for interpretation
Metadata	Nothing, if you host it yourself	Timing, volume and account identity per call

Two consequences follow. First, your provider sees a stream shaped by your automation, not just your typing, so a chatty heartbeat leaks more operational detail than a human ever would. Second, the storage side of the privacy question genuinely is resolved by self-hosting: the memory store, the file tree and the transcripts sit on hardware you chose, whether that is a home server, a NAS, a VPS or a managed Personal Cloud Server such as Yundera, and no multi-tenant service holds a copy.

If prompt egress itself is the concern rather than storage, only local inference answers it. Everything else is scope reduction, which is worth doing but is not the same thing.

What does OpenClaw cost over three years, including your own time?

Three years is the right window, because it is long enough for hardware to amortise and for token prices to move. Build the total from five components rather than one monthly figure, and price your labour at whatever your hour is genuinely worth.

Server cost, 36 months: multiply your monthly hosting figure by 36. This is the only component you can quote precisely on day one, and on a 4 vCPU and 8 GB baseline it is usually the smallest variable in the model.
Token spend, 36 months: take your modelled monthly volume and multiply, then apply a downward adjustment. Per token prices at a given capability tier have trended down, so holding today's rate flat for three years overstates the total.
Setup labour, one time: the first week is real work. Count 6 to 12 hours across provisioning, channel pairing, permission scoping and testing, then price it.
Maintenance labour, recurring: at 1 to 2 hours a month, that is 36 to 72 hours over three years for updates, key rotation and incident handling. This line frequently exceeds every cash cost in the model.
Migration risk: budget one rebuild. Something breaks, a provider changes an interface, or you move hosts, and that is another day of your time.

Then compute the comparison honestly: 36 months of a 20 USD subscription is 720 USD per seat, with zero labour hours attached. If your OpenClaw total lands near that, the deciding factor was never money. It was capability and data control, and you should say so out loud when you choose.

Where should you run OpenClaw: home server, VPS, NAS or managed Personal Cloud Server?

The agent is small, so this decision is about reachability and operating burden, not horsepower. OpenClaw needs to be online when the heartbeat fires and reachable from your phone when you message it, which is where most home deployments get complicated.

Hosting option	What it demands from you	Main constraint
Home server	OS updates, backups, remote access setup	Residential connections and dynamic IPs make inbound reachability the hard part
NAS with Docker	Container management on an appliance	Often fewer than 4 usable vCPUs once existing services are running
Self-managed VPS	Full sysadmin duty, firewall and TLS	Predictable cost and uptime, but every layer is yours to patch
Managed Personal Cloud Server	App installation and configuration only	Less low level control than a bare VPS

Yundera is one option in that last row, alongside self-managed alternatives. Apps are installed from an app store in one click rather than assembled from compose files by hand, and each app is reachable on a public HTTPS subdomain via NSL.SH mesh routing, so no static IP, no port forwarding and no manual TLS certificate setup are required.

Two practical points decide most cases. First, if the machine sleeps or the connection drops, the heartbeat silently stops and you lose the capability you left the subscription for, which rules out laptops and anything on a flaky link. Second, whatever you choose, back up the memory store and configuration, because after twelve months that directory holds the accumulated context that makes the agent worth running at all.

Disclosure: this article is published by Yundera, a managed Personal Cloud Server for running self-hosted apps. It is mentioned above as one option among several.

When DokuWiki Is the Wrong Replacement for Notion or Confluence Cloud: The Gaps No Plugin Closes

John — Fri, 07 Aug 2026 07:48:19 +0000

DokuWiki replaces the part of Notion and Confluence Cloud that stores and serves written pages, and it does that job well on a flat file store with no database. It does not replace simultaneous multi cursor editing, database views with filters and rollups, native comment threads with mentions, or first party mobile apps, and three of those gaps have no plugin that closes them properly. Everything else you want back arrives as a community plugin that you then patch, test and carry across every future upgrade yourself. If your team's daily work happens inside a shared page during a call, or inside a filtered board view, stay on your paid plan.

TL;DR by reader profile

Solo consultant with a reference library (one writer, roughly 400 pages of notes and client docs): switch, because you never hit the locking model, and the full text index plus namespace ACLs cover everything you were paying a seat for.
Five person engineering team that already lives in pull requests (backend squad, docs reviewed alongside code): switch, because plain text pages in a versioned directory match how you already work, and you can accept the editor being one person at a time.
Twelve person marketing or ops team running trackers in Notion databases (content calendar, campaign status, filtered by owner and date): stay, because the struct plugin gives you typed fields and aggregation, not the relations, rollups and multiple saved views your calendar depends on.
Distributed team that co writes in one page during a video call (a weekly planning doc touched by six people at once): stay, because DokuWiki takes an exclusive page lock and the second editor is told to wait or fork the content.
Regulated company with an SSO mandate and joiner and leaver automation (60 staff, identity managed in Entra ID or Okta): stay unless you accept manual account lifecycle, because OAuth login is a community plugin and SCIM provisioning has no DokuWiki equivalent at all.
Association, school or club with a small budget and mostly stable reference content (handbooks, procedures, meeting minutes): switch, because your content is exactly the shape DokuWiki was built for and your collaboration is asynchronous anyway.

The real tradeoff: you exchange a per seat bill and a vendor's feature roadmap for zero licence cost and a permanent maintenance duty on every plugin that stands in for a feature you used to rent.

Can two people edit the same DokuWiki page at the same time?
Is there a real WYSIWYG editor for DokuWiki, and what does it cost you in markup?
What replaces Notion database views, relations and rollups in DokuWiki?
How granular are DokuWiki ACLs next to Confluence page restrictions?
Are there official DokuWiki mobile apps, and what do you actually use on a phone?
Can DokuWiki do SSO, and what happens to SCIM provisioning?
Where do comment threads, mentions and notifications end up?
Which paid features DokuWiki genuinely beats, and why that still matters

Can two people edit the same DokuWiki page at the same time?

No. DokuWiki takes an exclusive lock on a page the moment you open the editor, and the second person is refused entry until that lock expires or the first person saves. There is no operational transformation layer, no CRDT, no shared cursors. This is the single largest behavioural difference from Notion and Confluence Cloud, and no plugin in the repository fixes it, because the storage model writes one whole text file per page.

The lock timeout is 15 minutes by default: the locktime setting in conf/local.php holds 900 seconds, and the lock file sits in data/locks/ named after the page ID.

The lock refreshes while you type: DokuWiki sends a keepalive from the edit form, so a colleague reading the "is currently being edited" message has no reliable estimate of when the page frees up.

Draft recovery is per user, not shared: unsaved text lands in data/cache/ as a draft tied to your session, so a crashed browser loses nothing, but nobody else sees your work in progress.

Section editing is the real workaround: DokuWiki locks per page, so splitting a long document into several pages under one namespace lets two people work in parallel on adjacent content.

The Edittable and Wrap plugins do not change this: they alter markup, not concurrency, and both still require the page level lock.

Teams that treat the wiki as an asynchronous record barely notice. Teams that open one planning page during a stand up and expect six people to type into it will hit the wall on day one.

Is there a real WYSIWYG editor for DokuWiki, and what does it cost you in markup?

Sort of. The stock editor is a plain textarea with a button toolbar, and the markup is DokuWiki syntax, not Markdown: headings are ====== Title ======, bold is **bold**, italic is //italic//. A true WYSIWYG surface exists as the community plugin ckgedit, which drops a CKEditor instance over that textarea. It works, and it is the reason most former Confluence users can be onboarded at all, but the conversion runs both ways and the return trip is where you pay.

Editing option	What you get	What it costs you
Stock toolbar editor	Raw syntax, section edit links, zero conversion risk	Every writer learns a markup dialect that transfers nowhere else
`ckgedit` plugin	Rich text buttons, table handling, drag and drop of images	Round tripping can rewrite or strip syntax from other plugins, so complex pages need a raw pass afterwards
Markdown syntax plugins	Familiar `#` and `-` for developers	Two dialects now coexist in one wiki, and search or find and replace has to cover both
Paste from Notion or Confluence	Fastest way to move a single page	Nested toggles, callouts and column layouts arrive as flattened paragraphs

Two practical thresholds matter. First, any page carrying plugin calls such as {{page>...}} or struct fields deserves editing in raw mode only. Second, decide before rollout, because mixing editors across 300 pages leaves you with inconsistent whitespace and heading levels that nobody wants to normalise later.

Notion and Confluence give you one editor with one behaviour. DokuWiki gives you two, and you own the seam between them.

What replaces Notion database views, relations and rollups in DokuWiki?

The struct plugin, and it gets you about two thirds of the way. It attaches typed fields to pages through named schemas, stores them in SQLite via the sqlite plugin dependency, and renders aggregations with syntax such as {{struct table>projects}}. The older data plugin does something similar with ---- dataentry ---- blocks. Both are real tools. Neither is a database product.

Typed fields work properly: text, date, decimal, dropdown, user and page reference types all validate on save, so a status column stays a controlled vocabulary rather than free text.

Relations exist, in one direction only: the Page and Lookup field types point one page at another, and you can list what points back, but there is no rollup that sums or counts a related set into a parent field the way a Notion rollup does.

Views are markup, not saved objects: each filtered list is a wiki page containing an aggregation block, so changing a filter means editing a page. Nobody gets a personal view, and there is no per user sort state.

Board, calendar and timeline layouts are not included: struct renders tables and lists. If your team plans in a kanban column or a month grid, that presentation layer is missing, and dragging a card between columns does not exist.

Forms need a second plugin: bureaucracy builds the entry form that creates a page from a template, so a simple request tracker is a two plugin arrangement before you write any content.

Reference tables migrate cleanly. Anything your team actually manipulates as a board does not.

How granular are DokuWiki ACLs next to Confluence page restrictions?

Granular enough on the read and write axis, and clumsy on the organisational axis. DokuWiki ships an ACL manager in the admin area that writes plain rules to conf/acl.auth.php. Every rule maps a page or namespace to a user or a group and one of six permission levels: none (0), read (1), edit (2), create (4), upload (8) and delete (16). The most specific matching rule wins, and a user rule overrides a group rule.

Namespaces carry the model, not pages: you can write a rule for a single page, but the design assumes hr:* and hr:salaries style trees, so your permission scheme has to be encoded in your page naming before you migrate.

Only admins can change access: in Confluence any editor restricts their own page from the page menu. In DokuWiki that self service does not exist, so every access request becomes a ticket for whoever holds the admin account.

Moving a page moves its permissions: renaming hr:draft:review into a public namespace silently changes who can read it, which makes the move plugin a permissions tool as much as a housekeeping one.

Media inherits from the namespace it sits in: an image uploaded into a restricted namespace stays restricted, but the same file linked from a public page is served from its original path, so upload location decides exposure.

Read denial is total: a page you cannot read does not appear in search results, in the index, or in recent changes, with no "restricted content exists here" hint.

Three groups and a clean tree work well. Forty ad hoc exceptions do not.

Are there official DokuWiki mobile apps, and what do you actually use on a phone?

There are none. DokuWiki has no first party iOS or Android client, and it never has. What you get instead is a responsive default template that reflows to a phone screen, plus a remote API that third party clients can talk to. For reading, this is fine. For the workflows people actually do on a phone, capturing a note in a lift or clearing comments on a commute, it is a visible downgrade from a paid Notion or Confluence seat.

The browser is the client: the bundled template collapses the sidebar and sizes text sensibly, and templates such as bootstrap3 or mikio improve it further, but you are still typing wiki syntax into a textarea with a phone keyboard.

There is no offline mode: every page view is a request to your server. Lose signal on a train and the wiki is gone, where the Confluence and Notion apps keep recently opened pages cached locally.

There are no push notifications: DokuWiki's change alerts arrive by email subscription, so a phone gets them in a mail app, not as a badge on a wiki icon.

Third party clients exist but depend on the API: you must enable the remote option in conf/local.php, and optionally restrict it with remoteuser, before any external app can authenticate and post.

Photo capture is a file upload, not an inline action: the media manager accepts a camera file through the standard browser picker, then you paste the resulting {{:image.jpg}} syntax by hand.

Add the site to your home screen and accept it is a website. Anyone expecting parity with an app store client will be disappointed.

Can DokuWiki do SSO, and what happens to SCIM provisioning?

Single sign on: yes, through plugins or a proxy. Automated provisioning: no, and there is no equivalent to build on. This is the pairing that decides the question for most companies with an identity team, because the login half looks solved in a demo and the lifecycle half only hurts three months later when a leaver still has an account.

Directory authentication is the mature path: the bundled authad and authldap backends bind to Active Directory or LDAP, read group membership at login, and feed those groups straight into your ACL rules, so disabling an account in the directory blocks the next sign in.

OAuth and OpenID Connect arrive as plugins: the community oauth plugin plus a per provider service plugin covers Google, GitHub, Keycloak and generic OIDC endpoints, and it creates the local user record on first successful login.

SAML is usually solved outside DokuWiki: put an authenticating reverse proxy such as Authelia, Authentik or oauth2-proxy in front, then let DokuWiki trust the forwarded user header, which keeps the wiki ignorant of the protocol entirely.

SCIM does not exist here: no endpoint, no plugin, no group push. Joiners, leavers and group changes are either mirrored by your LDAP backend or performed by hand in the user manager.

Local accounts linger by default: the plain backend keeps entries in conf/users.auth.php until an admin removes them, and an active session survives until the cookie expires, so a deprovisioned employee is not necessarily locked out that minute.

If your compliance evidence includes automated deprovisioning reports, DokuWiki cannot produce them.

Where do comment threads, mentions and notifications end up?

Split across three mechanisms, none of them native to a page. DokuWiki has no comment system at all in the core. What it has is a subscription engine for change notifications, and a community plugin that bolts a comment box onto the bottom of pages. Inline comments anchored to a selected sentence, the feature Confluence reviewers live in, have no equivalent anywhere in the ecosystem.

Comments come from the discussion plugin: it renders a form under the page, supports replies one level deep, and offers moderation so posts wait for approval. Threads are per page, never per paragraph.

Comment data lives outside the page file: posts are stored in the metadata directory alongside the page, not inside the .txt source, so a page export carries the content and leaves the conversation behind.

There is no resolve workflow: a Confluence thread can be marked resolved and collapsed. Here a handled comment stays visible until someone deletes it, which pushes teams back to email or chat for review cycles.

Mentions do not notify anyone: typing a colleague's name creates text. The core subscription system is the only delivery path, and it is opt in per user.

Subscriptions are per page or per namespace, in three modes: every change, digest, or list. Digest and list batches are dispatched by lib/exe/taskrunner.php, which fires on ordinary page requests, so a quiet wiki delivers its summaries late.

The practical result: your review conversations move to Slack, Teams or email, and the wiki keeps only the outcome.

Which paid features DokuWiki genuinely beats, and why that still matters

Not every comparison runs one way. On four points DokuWiki is not merely cheaper, it is structurally better than what a hosted plan can offer, and those points are exactly why teams tolerate the gaps in the previous sections.

Capability	What DokuWiki does	Why it matters
Content storage	Every page is a UTF-8 file at `data/pages/<namespace>/<page>.txt`	You can `grep -r`, script bulk edits, or put the tree in Git with no export step and no API rate limit
Revision history	Old versions are gzipped into `data/attic` with a Unix timestamp in the filename	History survives independently of the application, so a broken install still leaves readable text
Backup and restore	Copy `data/`, `conf/` and `lib/plugins/` with rsync	A full restore is a directory copy onto a fresh install, with no database dump, no schema migration, no vendor ticket
User count	Accounts and page count carry no licence cost	Adding a contractor for two weeks is a line in a file, not a change to your billing tier

Longevity is the underrated one: DokuWiki has shipped on the same flat file model for years, and syntax written a decade ago still renders. Hosted editors change their block model on their own schedule, and your archive changes with it.

The absence of a database is the second: no PostgreSQL to patch, no connection pool to tune, no migration window. On a small server, the runtime is PHP and a filesystem.

If your content is meant to outlive the tool holding it, this column of the ledger carries real weight.

Netdata Cloud vs a Self Hosted Parent Node: The Real Three Year Cost for a Home Server

John — Fri, 07 Aug 2026 07:35:22 +0000

If you run Netdata on one to three machines at home, the local agent dashboard on port 19999 plus the free Netdata Cloud tier covers almost everything you need, and a paid plan rarely earns its keep across three years. Pay only when you need durable multi node views, alert routing that reaches other people, and role based access you can revoke. Self hosting a Netdata parent node is the cheapest route to long retention and one dashboard for every child node, and the price is one always on machine plus a weekend of setup. Bolting Prometheus and Grafana onto Netdata is the most expensive option measured in hours, and it only pays back if you already run that stack for something else.

TL;DR by reader profile:

Solo dev with one box (Marco, one mini PC running 14 containers): stay on the local agent and the free tier, because a single node needs no aggregation layer and the agent already stores its own history.
Solo dev with four to six nodes (Priya, a NAS, two VPS and a spare laptop): build a self hosted parent node, since streaming gives you one dashboard and one retention policy without a per node bill.
Dev who checks metrics from a phone while away (Tomas, on call for his own side project): use the free Cloud tier or a WireGuard tunnel home, because remote reachability is the one thing a local only setup genuinely lacks.
Dev already running Prometheus and Grafana (Ines, with existing dashboards and recording rules): keep Netdata as a collector and export to your existing stack rather than paying twice for storage and dashboards.
Dev sharing nodes with other people (Sam, two contractors with root on the same servers): a paid plan is the cleanest answer, since roles, invitations and revocation are exactly what self hosting makes you build by hand.
Dev with hard data residency rules (Lena, contract work under a strict client policy): parent node only, because it keeps every metric and every alert inside machines you control.

The tradeoff is straightforward: Netdata Cloud sells you remote access, retention and permissions as a subscription, and a parent node buys you the same three things with your own hardware, your own tunnel and your own maintenance hours.

What does Netdata Cloud actually add on top of the agent you already run?
What does the free tier stop giving you?
How much does Netdata Cloud really cost over three years?
What does a self hosted Netdata parent node cost over the same three years?
How do you size a parent node for a home server's metric volume?
How much bandwidth does streaming from child to parent actually use?
How do the dbengine tiers change your retention bill on a parent node?
What does bolting Prometheus and Grafana onto Netdata cost you in hours and hardware?
Which setup gives you alerts that actually reach you, and what do notifications cost?

What does Netdata Cloud actually add on top of the agent you already run?

The agent is not a thin client. Every collector, every chart, every health alarm and the entire time series database run on the machine itself, and http://localhost:19999 serves the full dashboard whether Cloud is connected or not. Netdata Cloud does not collect your metrics a second time. It adds a control plane on top of agents that already work.

A single view across nodes: Cloud stitches your connected agents into one interface, so a chart can span four machines instead of forcing you to open four browser tabs on four addresses.

Reachability without a tunnel: the agent opens an outbound connection to Cloud, so you get remote access without exposing port 19999, forwarding a port on your router, or standing up WireGuard or Tailscale yourself.

Identity and permissions: Cloud is where accounts, invitations, Spaces, Rooms and role assignments live. A standalone agent has no user model at all, so anyone who reaches the port sees everything.

Centralised alert state: the agent evaluates health entities locally and can send notifications by itself, but Cloud aggregates active alerts from every node and routes them through integrations configured once for the whole Space.

Fleet metadata and history: node inventory, which agents are online, and alert history that outlives the individual agent's database.

The distinction matters for cost. If you disconnect Cloud tomorrow, collection, retention and local alarms keep running unchanged. What you lose is the aggregation layer, and that layer is exactly what a self hosted parent node also provides.

What does the free tier stop giving you?

Start with what it does not touch. The free Community tier places no cap on collection frequency, no cap on the metrics the agent gathers, and no cap on how long your own machine retains them. Retention is decided by netdata.conf and your disk, not by your plan. The limits sit in the control plane instead.

Advanced notification integrations: email and basic delivery are available without paying, while the routed integrations most teams want, PagerDuty and Opsgenie among them, sit on paid plans. The agent itself can still fire notifications directly through health_alarm_notify.conf, which is the free workaround.

Granular roles: free Spaces give you a small set of role options. Fine grained separation, the kind you need when a contractor should read dashboards but never silence an alarm, is a paid feature.

Extended alert and event history in Cloud: the window Cloud keeps for alert transitions and audit events is shorter on the free tier. Your agent keeps its own health log regardless, so this is convenience, not data loss.

Support commitments: community support versus a contractual response time is a real difference, and it is worth close to nothing when the only person on call is you.

Two things to check before you budget. Plan boundaries move, so read the current pricing page rather than a blog post, this one included. And every paid capability above is a permissions or routing feature, not a monitoring feature. Nothing you pay for makes the agent see more. That single observation is what makes the three year arithmetic in the next section lean the way it does.

How much does Netdata Cloud really cost over three years?

Netdata Cloud paid plans bill per node per month, so your three year total is not one number, it is a multiplication. Thirty six months times your node count times the plan rate, plus whatever your node count does over that period. Rates change, so pull the current figure from the pricing page and run the arithmetic yourself. The shape of the bill matters more than today's rate, because the shape is what makes it grow.

Cost driver	How it scales	Effect on a 36 month total
Node count	Linear, and a node is any claimed agent	Six nodes cost six times one node, every month, forever
Container hosts	One Docker host is one node, not one per container	Cheap if you consolidate, expensive if you spread services across boxes
Ephemeral nodes	Test VMs and rebuilt machines can each claim a slot	Silent creep, so prune stale nodes in the Space regularly
Billing period	Annual commitment usually beats month to month	Locks the rate for twelve months and removes one variable
Plan tier	Step function, not linear	Adding one contractor who needs a restricted role can move the whole Space up a tier

Two habits keep the total honest. Run netdata claim deliberately rather than baking a claiming token into every image you build, otherwise a rebuild loop quietly adds billable nodes. And decide your node count for year three, not year one, because a home lab that starts at two machines rarely stays at two. That growth curve is precisely what a parent node absorbs for free.

What does a self hosted Netdata parent node cost over the same three years?

A parent node is a normal Netdata agent that accepts streamed metrics from children. There is no licence, no node count and no billing period. The costs are real, they are just paid in hardware, watts and hours instead of invoices.

Hardware, if you need any: if you already keep a NAS or a mini PC running all day, the marginal cost is close to zero and you skip this line entirely. If you buy a box for the job, divide the purchase price by 36 months to get the monthly figure you actually compare against a subscription.

Electricity, which is the only truly recurring cost: measure idle draw with a plug meter, then multiply watts by 8,760 hours per year, by three years, by your tariff per kWh. A parent aggregating a handful of children sits near idle most of the time, so the delta over a machine you already run is small.

Disk for retention: the parent stores every child's history in its own dbengine files, so its storage footprint is roughly the sum of the fleet. Sizing that properly is section seven's job.

Setup hours, paid once: generate an API key with uuidgen, configure stream.conf on the parent and on each child, open the streaming port between them, verify the children appear. Budget an evening for the first one and minutes for each additional child.

Ongoing maintenance: package updates, an occasional config migration, and watching that children reconnect after reboots.

That is the whole bill. Notice that node count appears nowhere in it, which is the structural difference from a per node subscription.

How do you size a parent node for a home server's metric volume?

Do not guess the fleet total. Measure one child, then multiply. Query http://localhost:19999/api/v1/info on a typical machine and read back how many charts and dimensions it actually collects. A quiet VPS and a Docker host running 20 containers differ by an order of magnitude, because every container, every network interface and every mounted filesystem adds dimensions.

CPU on the parent scales with ingested dimensions, not with node count: four small children can be lighter than one busy container host. Streaming ingestion itself is cheap, since the parent is storing points rather than running collectors.

Machine learning is the biggest optional CPU cost: the parent can train anomaly models for streamed children as well as itself. If the parent is a low power box, set enabled = no under the [ml] section of netdata.conf on the parent and leave detection running on the children instead.

RAM follows tier0 caching: the dbengine holds recent pages in memory before flushing them to disk, so memory use tracks the total dimension count across the fleet. Give the parent headroom rather than trimming it to the exact working set.

Disk wants sustained small writes, not raw capacity: the dbengine flushes continuously. An SSD, even a modest one, behaves far better here than a spinning disk shared with media files.

Start with two children, then watch the parent monitor itself: Netdata ships a Netdata Monitoring section that charts its own CPU, memory and dbengine behaviour. Add the rest of the fleet only once that section looks flat.

Size for your year three node count, then stop. Over provisioning a parent is the one place this setup starts costing subscription money.

How much bandwidth does streaming from child to parent actually use?

The honest answer is that you must measure it, but you can predict its shape precisely. A child sends one value per dimension per collection interval, continuously, over a single persistent TCP connection. Bandwidth is therefore dimensions multiplied by frequency, and nothing else. A quiet node with few dimensions produces a trickle. A Docker host with hundreds of container dimensions at one second resolution produces a steady, measurable stream.

Compression is on by default and does most of the work: the streaming protocol compresses the connection, configured under the [stream] section of stream.conf. Leave it enabled. Metric streams are highly repetitive, so they compress well.

Collection frequency is the single biggest lever: raising update every from 1 to 2 in netdata.conf on a child roughly halves what it sends. You lose per second granularity on that node, which for a backup NAS matters far less than for a database host.

Reconnection triggers replication, not a silent gap: when a child comes back after downtime, it backfills the missing window to the parent. Expect a burst well above the steady rate, proportional to how long the link was down.

Trimming collectors trims the stream permanently: disabling collectors you never look at removes their dimensions from both the parent's disk and the wire.

Measure it where it counts: watch the network interface chart on the child, or run iftop against the parent's address, and read the real number for your fleet.

This only becomes a cost line if a child lives on a metered connection or a VPS with an egress allowance. On a LAN, it is free.

How do the dbengine tiers change your retention bill on a parent node?

Netdata does not store one copy of your history. The dbengine writes three tiers, each downsampling the one before it, and each with its own retention setting in the [db] section of netdata.conf. This is why a parent holding months of data for six children stays manageable. The arithmetic per dimension per day makes the point immediately.

Tier	Default granularity	Points per dimension per day, and what it buys
Tier 0	1 second	86,400 points: the forensic detail you want for the last incident, and the overwhelming majority of your disk usage
Tier 1	1 minute	1,440 points: sixty times cheaper, still fine for spotting a memory leak developing over a week
Tier 2	1 hour	24 points: effectively free, and the right resolution for capacity planning across months
All three combined	Mixed	The parent serves whichever tier matches the zoom level of the chart you are viewing

The tuning move is obvious once you see the ratio. Shorten tier 0 retention and lengthen tiers 1 and 2. Keeping seven days of per second data plus a year of hourly data costs a fraction of keeping per second data for a year, and you will almost never zoom to one second resolution on something that happened in March.

Set retention per tier by size, by time, or by both, and the dbengine enforces whichever limit it hits first. Setting a size cap is the safer habit on a home server, because it guarantees Netdata cannot fill the disk that everything else depends on.

What does bolting Prometheus and Grafana onto Netdata cost you in hours and hardware?

Netdata exposes /api/v1/allmetrics?format=prometheus on port 19999, so wiring it into Prometheus is a scrape target in prometheus.yml and nothing more. The integration is easy. The stack around it is what costs.

You now run three services instead of one: Prometheus, Grafana, and in practice Alertmanager, since Grafana alerting or Alertmanager is what turns a query into a notification. Each has its own config, its own upgrade cadence and its own breaking changes to read about.

You store everything twice: the agent keeps its dbengine tiers and Prometheus keeps its own TSDB, on the same disk if this is one home server. Prometheus defaults to 15 days retention, so budget capacity for both databases rather than assuming the scrape replaces local storage.

You lose per second resolution unless you fight for it: Prometheus commonly runs a 15 second scrape_interval. Dropping that to 1 second across a Netdata export multiplies series volume hard, which is exactly the cardinality problem the tiered dbengine was designed to avoid.

You rebuild dashboards by hand: Netdata auto generates charts for every collector it finds. Grafana gives you a blank canvas. That is a genuine advantage if you want a curated view, and a genuine cost measured in evenings if you just wanted the charts you already had.

You rewrite alerts in a second language: health entities on the agent become PromQL rules plus routing config, maintained separately.

The verdict is conditional. If Prometheus already runs for other services, exporting Netdata into it is sensible and nearly free. If it does not, this is the most expensive of the three options and the only one where the recurring cost is your attention.

Which setup gives you alerts that actually reach you, and what do notifications cost?

Every option evaluates alarms the same way, because health entities run on the agent regardless of what sits above it. The difference is what happens when the alerting machine is the machine that failed. A single agent watching only itself cannot tell you it lost power. That blind spot, not feature lists, should drive this decision.

A lone agent covers threshold alerts and nothing else: it fires on high disk usage or a stopped service, and it goes silent on the failure mode you most want to hear about.

A parent node closes the gap for children: it evaluates alarms on streamed data and notices when a child stops reporting, so a dead VPS produces an alert instead of silence. You configure delivery once on the parent rather than on every node.

Netdata Cloud closes the same gap from outside your network: the outbound connection means Cloud sees a node go unreachable even if your whole house loses power, which a parent sitting in that house cannot do.

Free delivery channels do most of the work: Discord, Slack, Telegram and ntfy all accept webhooks directly from the agent, cost nothing, and reach your phone. Reload after editing with netdatacli reload-health.

Paid channels are the real notification cost: SMS through a provider bills per message, and a PagerDuty seat can exceed what you spend on monitoring itself.

The pragmatic setup for one person is two independent paths. Let Netdata alert on thresholds, then run a separate reachability check from somewhere else entirely, a free tier uptime service or an Uptime Kuma instance on different hardware. Redundant alerting costs nothing and catches the failure a single system structurally cannot.

Navidrome duplicate albums, split discs and missing art: the tagging and mount anti-patterns that break a 50k library

John — Fri, 07 Aug 2026 07:19:38 +0000

Navidrome is not guessing at your library, and it is not corrupting it. It builds albums from the tags inside your files, then keys every album and track to a persistent ID derived from those tags, so a duplicate album means two groups of files disagree about ALBUMARTIST, album name, release date or MusicBrainz ID. Split discs, "Various Artists" fragmentation and missing covers come from the same root cause, one layer down: inconsistent tags, or a filesystem that reports different modification times and paths on every mount. Fix the tags and stabilise the mount, and the scanner stops being the problem.

TL;DR by reader profile

Solo developer with a 50,000 track library on a home NAS, mounted over SMB: move the music onto a local disk or a stable NFS export before touching tags, because mtime drift makes every scan a full scan and hides whether your tag fixes worked.
Anyone whose library came from mixed sources over ten years, ripped CDs plus purchased downloads plus old downloads: run MusicBrainz Picard over the worst offenders first, since missing ALBUMARTIST and inconsistent album titles cause the large majority of duplicate album reports.
Beets user who already has a tidy, scripted library: keep beets as the source of truth and point Navidrome at its output read only, because two tools writing tags to the same files is how you get half-updated albums.
Docker Compose user running Navidrome next to Jellyfin, Plex or Lidarr on the same folder: decide which application owns tag writes and cover files, since competing artwork conventions are the usual reason embedded art stops showing.
Anyone running from a laptop, an external USB drive or a rclone mount: disable the watcher and use a scheduled scan, because filesystem notification events do not cross most network and FUSE mounts reliably.
Anyone about to "just delete the database and rescan": export playlists and back up navidrome.db first, because a rebuild recovers metadata but not play counts, ratings or starred items unless the identity tags are stable.

The central tradeoff is this: strict, MusicBrainz backed tags give you a library that survives rescans and server moves, but they cost hours of upfront cleanup that a loose folder based collection never asks for until the day it breaks.

Why does Navidrome show the same album twice after a scan?
How Navidrome decides what an album is: persistent IDs and the grouping tags
Why missing ALBUMARTIST breaks more than any other single tag
Do you need MusicBrainz IDs in Navidrome, and what actually breaks without them?
Why does one album split into CD1 and CD2 in the interface?
Compilations, Various Artists and soundtracks: four ways they fragment
Why is cover art missing when the file clearly has an embedded image?
Why does Navidrome rescan the whole library on an SMB or NFS mount?
Symlinks, bind mounts and container paths: the anti-patterns that hide half a library

Why does Navidrome show the same album twice after a scan?

Because two sets of files disagree about at least one grouping tag, and Navidrome trusts the tags rather than the folder. It never merges albums by directory name. If ten tracks say ALBUMARTIST=Radiohead and the other two say Radiohead with a trailing space, you get two albums, both named the same, sitting side by side in the interface.

The disagreements that produce duplicates:

Album title variants: one track tagged OK Computer and another OK Computer (Remastered) are two different releases as far as the scanner is concerned, and the interface offers no visual hint that only the suffix differs.
Partial ALBUMARTIST coverage: if a tag editor wrote ALBUMARTIST on eight of twelve tracks, the untagged four fall back to their own ARTIST value, so a guest vocalist on track 9 becomes an album of one.
Mixed MusicBrainz IDs: files carrying MUSICBRAINZ_ALBUMID are keyed by that ID, while files without it are keyed by artist plus title plus release data, so a half tagged album cannot group with itself.
Release date and version drift: a differing DATE, ORIGINALDATE or release version field separates two otherwise identical halves of the same rip.
Invisible characters: trailing whitespace, curly versus straight apostrophes and non breaking spaces compare as different strings, which is why the two entries look identical on screen.

Check one before guessing. Run ffprobe -show_entries format_tags -v quiet yourfile.flac on a track from each duplicate and compare the output line by line. In most cases the answer is visible within 30 seconds.

How Navidrome decides what an album is: persistent IDs and the grouping tags

Every album and every track gets a persistent ID, computed by hashing a configurable expression made of tag values. Two files that produce the same album PID are the same album. Two files that do not, are not. That is the whole rule, and once you can read the expression, duplicate reports stop being mysterious.

The mechanics you need to know:

The expression lives in configuration: PID.Album and PID.Track in navidrome.toml, or ND_PID_ALBUM and ND_PID_TRACK as environment variables in your Compose file, so you can inspect and change the grouping rule without touching a single audio file.
A comma concatenates, a pipe falls back: musicbrainz_albumid|albumartistid,album,albumversion,releasedate means "use the MusicBrainz album ID if present, otherwise build a key from album artist, album title, version and release date".
The first non empty field wins: this is why a library with MusicBrainz IDs on 60 percent of files behaves as two libraries under one roof, with two different keying strategies running in parallel.
Track PIDs hang off album PIDs: the default track expression falls back to the album ID plus disc number, track number and title, so an unstable album PID makes every track ID unstable too.
Changing the expression is not free: new PIDs mean new rows, and play counts, ratings and starred flags are attached to the old IDs.

Practical consequence: prefer fixing tags over rewriting ND_PID_ALBUM. Loosening the expression to hide a duplicate also merges genuinely distinct releases, such as a 1997 pressing and its 2017 remaster.

Why missing ALBUMARTIST breaks more than any other single tag

Because it is the only tag that tells Navidrome who owns the album, and when it is absent the scanner falls back to the per track ARTIST value. On a solo record that fallback is harmless. On anything with a featured guest, a duet, a remixer or an orchestra credit, it shatters one album into several one track albums, each filed under a different artist in the sidebar.

The tag has a different name in every container, which is exactly why editors write it inconsistently: TPE2 in ID3v2 for MP3, ALBUMARTIST as a Vorbis comment in FLAC and Ogg, and aART in MP4 for AAC and ALAC files.

File situation	What Navidrome shows	Underlying reason
ALBUMARTIST on all 12 tracks	1 album, 12 tracks	Every file produces the same album PID
ALBUMARTIST on 10 of 12 tracks	1 album plus 2 strays	The 2 untagged files key off their own ARTIST
No ALBUMARTIST, 4 guest features	5 albums, same cover	Each distinct ARTIST value becomes its own key
No ALBUMARTIST on an 18 track compilation	Up to 18 albums	Every track has a different performer
ALBUMARTIST with a trailing space on 1 file	2 albums, identical names	String comparison is exact, whitespace included

Fix it in bulk rather than by hand. In MusicBrainz Picard, matched releases write album artist automatically. In Kid3 or Mp3tag, select a folder and set the field once for every file in it. The rule that survives contact with a real library: ARTIST describes the performance, ALBUMARTIST describes the shelf it sits on, and it must be identical across every file in the album.

Do you need MusicBrainz IDs in Navidrome, and what actually breaks without them?

No. A library with clean, consistent text tags works fine. What you cannot do is mix the two approaches inside one album, because the pipe fallback in the album PID expression means tagged files key off a 36 character UUID and untagged files key off artist plus title plus date. Half a release with MUSICBRAINZ_ALBUMID is the single most reliable way to manufacture a duplicate that no amount of retyping the album name will fix.

What the IDs buy you once coverage is complete:

Immunity to text edits: rename an album from Vol. 1 to Volume 1 and the grouping survives, because the key is the UUID and not the string you just changed.
Artist disambiguation: three different bands called Nirvana get three MUSICBRAINZ_ARTISTID values, so they stop collapsing into one crowded artist page.
Correct external lookups: artist images, biographies and ListenBrainz submissions resolve against a canonical entity rather than a fuzzy name match.
Reliable re tagging later: with IDs embedded, beet mbsync or a Picard reload updates metadata from upstream without you re matching anything by hand.
A stable identity across servers: move the library to a new machine, rebuild the database, and the albums come back grouped the same way.

The cost is real. Matching a large collection in Picard is manual work on anything ambiguous: bootlegs, live recordings, regional pressings and unofficial releases often have several candidate releases, or none. A pragmatic split is to tag the 20 percent of albums you actually play, leave the rest on text tags, and never mix within one album folder.

Why does one album split into CD1 and CD2 in the interface?

The folder layout is not the problem. Navidrome will happily assemble a 2 disc, 24 track release from Album/CD1 and Album/CD2, because it groups by tags and ignores directory structure. The split happens when the ripper baked the disc number into the album title, or left the disc tag empty.

The four causes, in the order you should check them:

Disc suffixes inside the ALBUM tag: files reading The Wall (Disc 1) and The Wall (Disc 2) produce two different album keys, and the sidebar shows two covers with almost identical names. Strip the suffix so both discs carry the exact string The Wall.
Missing DISCNUMBER: the tag is DISCNUMBER in FLAC and Ogg, TPOS in ID3v2 and the disk atom in MP4. Without it, disc 2 track 1 and disc 1 track 1 both claim position 1, so the album lists two tracks numbered 1 and the play order goes wrong.
Release version or date drift between discs: if one folder was tagged in a later session with a different DATE or release version, the grouping expression sees two releases even though the album titles match.
Per disc MusicBrainz IDs: some releases are modelled as separate media within one release, and a mismatched MUSICBRAINZ_ALBUMID on one folder keeps the halves apart permanently.

The bulk fix is a regular expression action in Mp3tag or Kid3 over the parent folder: move the trailing (Disc N) or CDN out of the album field and into the disc number field. Then set DISCTOTAL to 2 on all 24 files so the interface labels the discs correctly.

Compilations, Various Artists and soundtracks: four ways they fragment

A 40 track compilation is the worst case for a tag driven scanner: every track has a different performer, so anything less than perfectly consistent album level tags produces dozens of one track albums. Four distinct failures account for nearly all of it.

The compilation flag is missing: the tag is COMPILATION=1 as a Vorbis comment, TCMP in ID3v2 and the cpil atom in MP4. Set it on every file of the release. Without it, nothing marks the album as a multi artist release, and the scanner has only the per track artist to work from.
Various Artists is spelled four different ways: Various, Various Artists, VA and V/A are four separate album artists and therefore four separate albums. Pick the exact string Various Artists, which is what MusicBrainz Picard writes, and apply it to all 40 files without exception.
Per track ALBUMARTIST was written by a helpful editor: some tools copy ARTIST into ALBUMARTIST when the field is blank, so track 7 becomes an album by that one performer. This is silent, and it happens to files you never opened in the editor yourself.
Soundtracks credited to the composer on some tracks only: a film score with 6 licensed songs mixed into 30 cues ends up half credited to the composer and half to the featured bands, splitting one release into two or more.

Verify the whole folder in one pass rather than spot checking. Run ffprobe -show_entries format_tags -v quiet over each file and confirm that album artist, album title and compilation flag are byte identical across all of them.

Why is cover art missing when the file clearly has an embedded image?

Because Navidrome looks for artwork in a configured order, and stops at the first hit. That order is set by CoverArtPriority, or ND_COVERARTPRIORITY in your Compose file, and the default puts embedded art first, then cover.*, folder.* and front.* files in the album directory. If a stale, low resolution folder.jpg outranks your new embedded image under a modified priority string, the old picture wins and nothing looks broken in the logs.

The causes worth checking, in order of how often they turn out to be the real one:

The cache folder is not writable: Navidrome resizes artwork and stores it under the cache directory. If the container runs as UID 1000 and the volume is owned by root, extraction silently produces nothing. Run ls -ln on the cache path and confirm the owner matches the user in your Compose file.
Art is embedded in one track only: the album cover comes from the files themselves, so tagging track 1 and leaving the other 11 bare gives inconsistent results in track level views.
Filename case and spelling: Folder.jpg, AlbumArt.jpg and cover.jpeg are not the same as the patterns in your priority list. Standardise on lowercase cover.jpg in every album directory.
The image is not a format the extractor handles: WebP and progressive or CMYK JPEG files embedded by a third party tool are common failures. Re embed as a baseline JPEG or PNG.
The browser cached the placeholder: after fixing tags, hard reload the page before concluding the fix failed.

Change one variable at a time, then rescan a single album folder rather than the whole library.

Why does Navidrome rescan the whole library on an SMB or NFS mount?

A quick scan compares each directory's modification time against the timestamp of the last scan. Anything newer gets re read. Network filesystems break that comparison in two ways: they report modification times with different precision or a different timezone offset than the local disk, and they can change the reported value on remount. When every folder looks newer than the last scan, every folder is rescanned, and a 50,000 track library never gets a fast pass.

Mount type	mtime stability across remounts	Practical consequence
Local ext4 or XFS	Stable to the nanosecond	Quick scans stay quick, watcher works
NFSv4 with synced clocks	Stable if server and client run NTP	Reliable, watcher events unreliable
SMB3 via cifs	Depends on mount options and server	Frequent full rescans, timestamp drift
rclone or other FUSE mount	Often synthesised or coarse	Repeated full rescans, high latency per file

Diagnose it before changing anything. Run stat -c '%y %n' /music/SomeAlbum from inside the container, unmount and remount the share, then run the identical command again. If the two values differ, the mount is the cause and no amount of tag editing will help.

The fixes that hold, in order of preference:

Move the library to a local disk: the only option that removes the class of problem entirely.
Pin the SMB mount options: set vers=3.0 and keep noserverino out of your fstab line, since it also destabilises inode numbers.
Run NTP on both ends: a clock skew of a few seconds, or a 3600 second daylight saving shift, is enough to invalidate the comparison.
Schedule scans instead of fighting the watcher: covered next, but the mount is the thing to fix first.

Symlinks, bind mounts and container paths: the anti-patterns that hide half a library

Navidrome can only index what it can see and read from inside its own namespace. In Docker that namespace is whatever you bind mounted, so a path that works perfectly in your host shell can be empty, dangling or unreadable to the process doing the scanning. The symptom is not an error. It is an album count that is 8,000 tracks short of what you expected.

Symlinks that resolve outside the bind mount: if /mnt/music/rock is a link to /mnt/tank/rock on the host and you only mounted /mnt/music, the container sees a broken link. Mount the real target as well, or replace the symlink with a second bind mount in your Compose file.
Directories the container user cannot traverse: a folder with mode 700 owned by root is invisible to a process running as UID 1000, and the scan skips it without stopping. Verify with docker exec -u 1000 navidrome ls /music/Artist rather than trusting your own shell.
The data folder living inside the music folder: if navidrome.db and the cache sit under the scanned tree, the scanner walks its own working files. Keep music at /music and state at /data, as two separate volumes.
Renaming the mount point between deployments: switching from /music to /media/music changes every stored path, so the next scan re imports the entire library even though not one audio file changed.
Folders you never wanted indexed: drop a .ndignore file into a directory to exclude it and its children, which is the clean way to skip incoming downloads or a lossless archive.

WordPress Sitewide Outages: Which Misconfigurations Actually Cause Them, Ranked by Frequency and Recovery Time

John — Fri, 07 Aug 2026 04:35:34 +0000

Most WordPress outages are not attacks. Four causes account for the overwhelming majority: a plugin or theme update that throws a PHP fatal error, a PHP resource limit set below what the installed plugin set needs, a database that stops answering because MySQL hit a limit or the disk filled, and a wp-config or site URL value edited to something the server cannot serve from. Each has a different recovery path, and the fastest one is almost never wp-admin, because wp-admin is usually down with the rest of the site. Rank them by mean recovery time instead of frequency and the ordering inverts: the most common failure is the cheapest to undo, while the rarest, InnoDB corruption on a full disk, is the one that ends in a restore from backup.

TL;DR by reader profile:

Family running one shared site (Marta hosts the household blog, a shared photo gallery and a recipe page on a small VPS): put DISALLOW_FILE_EDIT and automatic plugin updates under manual control, and keep WP-CLI installed, because the single most likely outage is a well meaning family member updating a plugin from a phone and having no way back in.
Volunteer admin for a community group (Ade maintains the sports club site nobody else touches): budget for a documented restore drill twice a year rather than more monitoring, because your real risk is not detection speed, it is discovering the backup was never tested.
Freelancer hosting several client installs on one box (Jonas runs six WordPress sites behind one nginx instance): set per site PHP-FPM pool limits and separate MySQL users, because a single runaway site otherwise takes the other five down with it.
Small store owner on WooCommerce (Priya sells stock she has to reconcile daily): raise WP_MEMORY_LIMIT, move cron off WP-Cron and monitor MySQL connections, because commerce plugin sets fail on resource ceilings long before content sites do.
Homelab self-hoster running WordPress in Docker (Tomas keeps the whole stack in one compose file): treat volume mapping and file ownership as the primary failure surface, because container rebuilds are what silently discard uploads and reset permissions.

The tradeoff is blunt: every guard that stops a bad change from taking the site down, staging environments, file edit locks, pinned plugin versions and manual updates, costs you friction on every ordinary edit you make.

Which WordPress misconfigurations actually cause a full sitewide outage?
The main failure modes ranked by frequency, blast radius and mean recovery time
Why does a plugin or theme update end in a white screen of death?
PHP memory_limit, max_execution_time and OPcache: the settings that fail first
What does "Error establishing a database connection" mean in each of its cases?
MySQL connection limits, InnoDB corruption and the full disk that causes both
How does a wrong WP_HOME or WP_SITEURL value lock you out of wp-admin?
Permalinks, .htaccess and nginx rewrites: the disagreement that 404s every page
Do file ownership and permission mistakes really take a site offline?
WP-Cron misconfiguration: the silent damage that becomes a visible outage
How do caching layers and a misconfigured object cache serve blank or stale pages?

Which WordPress misconfigurations actually cause a full sitewide outage?

A sitewide outage means every visitor sees an error page and you cannot reach /wp-admin either. That narrow definition rules out most of what people worry about. Slow queries, a broken contact form and a mangled theme layout are all bad, but they leave the site reachable. Only a short list of misconfigurations take the whole thing down at once.

PHP fatal errors from plugin or theme code: an activated plugin calling a function that no longer exists halts execution before any output, so both the front end and the admin die in the same request. This is the single most common cause.
Resource ceilings set below what the site needs: a PHP memory_limit of 128M against a plugin set that needs more, or a max_execution_time of 30 seconds against an import job, turns a normal page load into a fatal.
The database refusing connections: wrong credentials in wp-config.php, MySQL exceeding max_connections, or the disk hitting 100 percent all produce the same "Error establishing a database connection" page with no admin access.
Wrong site address values: WP_HOME and WP_SITEURL pointing at a hostname or scheme the server does not answer on redirects every request into a loop, including the login page you need to fix it.
Web server rewrite rules that stop matching: a deleted .htaccess on Apache or a missing try_files directive on nginx returns 404 for every URL except the homepage.
File ownership drift after a rebuild or restore: files owned by root instead of www-data make PHP unable to read what it must include.

Everything else degrades the site. These six stop it.

The main failure modes ranked by frequency, blast radius and mean recovery time

Rank the six causes and a pattern appears: frequency and recovery cost run in opposite directions. What breaks constantly is what you can undo with one command. What almost never breaks is what forces a restore.

Failure mode	Frequency and blast radius	What recovery actually costs
Plugin or theme fatal error	Most frequent. Blast radius is total but confined to one install, and the trigger is always a change you made	Lowest. `wp plugin deactivate --all` over SSH, or renaming the folder in `wp-content/plugins`, restores the site in the time it takes to log in
PHP resource ceiling hit	Frequent on plugin heavy sites, intermittent rather than constant, so it looks like a slowness problem first	Low once diagnosed, but diagnosis dominates. Raising `WP_MEMORY_LIMIT` in `wp-config.php` is one line, finding the right line takes the log
Site URL or redirect loop	Occasional, usually right after a domain, HTTPS or migration change. Blast radius includes the login page	Low with shell access, high without. `wp option update home` fixes it, the trap is having no way in except the admin you just broke
Rewrite rules stopped matching	Occasional, often after a server config change rather than a WordPress change	Low. Regenerate with `wp rewrite flush` or restore the `.htaccess` block
File ownership or permission drift	Occasional, spikes after container rebuilds and restores	Medium. One `chown -R` command, but the wrong one breaks it further
Database unreachable or corrupt	Rarest by a wide margin	Highest by a wide margin. Credentials are minutes, a corrupt InnoDB tablespace means restoring from backup

Note the asymmetry: the modes you meet weekly are cheap, the one you meet yearly is the one your backups exist for.

Why does a plugin or theme update end in a white screen of death?

A white screen is not an error state of its own. It is a PHP fatal error with display_errors set to Off, which is the correct production setting. PHP stops mid request, sends nothing, and the browser renders the empty response as a blank page. The information you need exists, it is just in the log rather than on screen.

A PHP version the new code does not support: an update written against PHP 8.2 running on PHP 7.4 hits syntax it cannot parse, and a parse error kills the request before any plugin loads. This is why an update can break a site that was untouched for a year.
Two plugins declaring the same function or class: PHP throws a fatal on redeclaration. The plugin you updated is often not the one at fault, it just loaded second.
A removed hook or function the theme still calls: the theme calls something the updated plugin deleted, so the front end dies while /wp-admin sometimes survives, because admin loads a different template path.
The update itself interrupted mid write: a PHP timeout during the unzip step leaves half the new files and half the old ones in wp-content/plugins, a state no version of the plugin was ever tested in.
Memory exhausted during the update routine: database migration code in the plugin activation hook is far heavier than a normal page load.

Turn on WP_DEBUG_LOG in wp-config.php and read wp-content/debug.log. WordPress 5.2 and later also email the address in admin_email a recovery mode link that loads the admin with the offending plugin paused.

PHP memory_limit, max_execution_time and OPcache: the settings that fail first

WordPress core is light. Your plugin set is not. Resource ceilings fail in a specific order, and knowing that order saves you from raising the wrong one.

memory_limit in php.ini: the production default shipped with PHP is 128M. A content site never approaches it. WooCommerce, a page builder and a backup plugin loaded together on the same request can, and the result is Allowed memory size of X bytes exhausted in the error log rather than a useful message on screen.
WP_MEMORY_LIMIT in wp-config.php: WordPress defaults this to 40M for single site and 64M for multisite, and raises it to WP_MAX_MEMORY_LIMIT, 256M by default, only inside the admin. It can raise the limit toward the php.ini value, it cannot exceed a hard limit set by your host, so setting it to 512M on a 128M box changes nothing.
max_execution_time: 30 seconds by default under PHP-FPM. Imports, backup archiving and image regeneration all exceed it on real datasets, and the request dies halfway through, leaving partial data behind.
upload_max_filesize and post_max_size: 2M and 8M by default. These do not take the site down, they silently break media uploads and theme installs, which people misdiagnose as a permissions fault.
OPcache serving stale bytecode: with opcache.validate_timestamps on, PHP rechecks files every opcache.revalidate_freq seconds, 2 by default. Turn validation off for performance and a deploy leaves old cached files mixed with new ones on disk, which produces fatals until you run opcache_reset() or restart PHP-FPM.

What does "Error establishing a database connection" mean in each of its cases?

WordPress prints one message for at least four unrelated faults. The message tells you nothing. The MySQL error code behind it tells you everything, and you get it by connecting manually from the same host: mysql -u wp_user -p -h 127.0.0.1 wp_db.

Error 1045, access denied: the credentials in wp-config.php no longer match the grant in MySQL. Common after restoring a database dump onto a new server, where the tables came over but the user did not. Recreate the grant, do not edit the site.
Error 2002, cannot connect through socket: DB_HOST is set to localhost, which makes the MySQL client use a Unix socket rather than TCP. If MySQL listens on TCP only, or lives in another container, this fails while 127.0.0.1 or the container name works. In Docker Compose, DB_HOST must be the database service name, not localhost.
Error 1049, unknown database: DB_NAME points at a database that does not exist, usually because a migration script created it with a different prefix or the import silently failed partway.
MySQL is not running at all: connection refused rather than denied. Check the service before touching any WordPress file, because nothing in wp-config.php can fix a stopped daemon.
The database answers but tables are unreadable: WordPress shows the same page and sometimes offers a repair link. That link only works after you add define('WP_ALLOW_REPAIR', true); to wp-config.php, and you must remove it afterwards, because /wp-admin/maint/repair.php is reachable without logging in while that constant is set.

MySQL connection limits, InnoDB corruption and the full disk that causes both

These three failures look separate and are usually the same incident at different stages. A disk fills, MySQL cannot write, connections pile up waiting, and what started as a slow page ends with a tablespace that will not open.

Error 1040, too many connections: MySQL and MariaDB both default max_connections to 151. Every PHP-FPM worker holds one connection while it runs a query, so if pm.max_children across your pools exceeds that number, a traffic spike exhausts the pool and every later request fails. Check SHOW GLOBAL STATUS LIKE 'Max_used_connections'; before raising anything, because the real fix is usually fewer slow queries, not more connections.
The disk at 100 percent: binary logs, InnoDB temporary files and unrotated error logs fill a volume quietly. MySQL then refuses all writes, WordPress cannot save a post or a session, and cron jobs fail silently. Run df -h first on every database incident, before you read a single log line.
A bloated wp_options table: expired transients and rows with autoload set to yes are loaded on every single request. A few hundred kilobytes of autoloaded data turns into real memory pressure per worker, which multiplies across concurrent requests.
InnoDB corruption after an unclean stop: the server refuses to start and the error log names a page. mysqlcheck --repair does not help here, it only repairs MyISAM tables. The recovery path is starting with innodb_force_recovery set to 1, dumping with mysqldump, then reimporting into a clean instance.

Note the ordering: only the last of these needs a backup, and only the last is unrecoverable without one.

How does a wrong WP_HOME or WP_SITEURL value lock you out of wp-admin?

WordPress stores its own address twice, in the home and siteurl rows of wp_options, and every page it builds is constructed from those values. Get them wrong and WordPress does not fail, it faithfully redirects you to the address you told it to use. That address is the one that does not work, including for the login page you need in order to correct it.

Constants silently win over the database: WP_HOME and WP_SITEURL in wp-config.php override the stored options and grey out both fields in Settings then General. People change the database values, see no effect, and conclude the site is broken.
A scheme mismatch behind a reverse proxy: the proxy terminates TLS and forwards plain HTTP, so PHP never sets $_SERVER['HTTPS']. WordPress sees an insecure request for an https:// site address and redirects to itself forever. Browsers give up after roughly 20 hops and show ERR_TOO_MANY_REDIRECTS.
The www and bare hostname disagreeing: setting siteurl to https://www.example.com while the certificate or DNS only answers on example.com produces the same loop, with a TLS warning in front of it.
Cookie domain mismatch: login appears to succeed, then bounces straight back to the login form. The auth cookie was written for a host you are not browsing. COOKIE_DOMAIN in wp-config.php is the lever.

Fix it from the shell, not the browser: wp option update home 'https://example.com' --skip-plugins --skip-themes, then the same for siteurl. Content containing hardcoded old URLs needs wp search-replace, which handles serialized data that a raw SQL UPDATE would corrupt.

Permalinks, .htaccess and nginx rewrites: the disagreement that 404s every page

The signature of this failure is unmistakable: the homepage loads perfectly, every other URL returns 404, and the admin either works or throws you back to the dashboard. The homepage survives because it resolves to index.php through the default directory index. Everything else depends on a rewrite rule that has stopped applying.

AllowOverride None in the Apache vhost: Apache reads .htaccess only where the directory block permits it. Set this to None and your .htaccess becomes an inert text file. The rules are present, correct and completely ignored, which is why comparing file contents against a working site tells you nothing.
mod_rewrite not loaded: on a fresh Debian or Ubuntu Apache install the module is off until you run a2enmod rewrite and reload. WordPress writes the rules regardless and reports no problem.
The WordPress block overwritten: the rules live between the # BEGIN WordPress and # END WordPress markers. Security plugins, caching plugins and hand edits all write to the same file, and a plugin that rewrites its own block sometimes truncates that one.
nginx never reads .htaccess at all: it has no such mechanism. The site depends entirely on try_files $uri $uri/ /index.php?$args; in the server block, so migrating an Apache site to nginx without porting that line 404s every post immediately.
Stale rewrite rules in the database: the rewrite_rules option holds the compiled ruleset. Change the permalink structure to /%postname%/ without flushing and the stored rules no longer match.

Visiting Settings then Permalinks and saving regenerates them. From the shell, wp rewrite flush --hard does the same and also rewrites the .htaccess block.

Do file ownership and permission mistakes really take a site offline?

Yes, but the outage looks different from a PHP fatal. You get 403 Forbidden or a 500 from the web server rather than a white page, and it happens after a restore, a container rebuild or a hasty chown, never on its own. The tell is that nothing in wp-content/debug.log explains it, because PHP was never reached.

Path	Correct state	What a wrong state does
Directories under the web root	`755`, owned by the PHP user, `www-data` on Debian and Ubuntu	Remove the execute bit and Apache or nginx returns 403 for every URL, including the homepage. This is a genuine sitewide outage
PHP files such as `index.php`	`644`, readable by the web server	Files owned by `root` after an unpacked backup are unreadable, so the server 500s on include
`wp-config.php`	`640` or `600`, ideally not group readable	Too tight and PHP cannot read its own credentials, which surfaces as a database connection failure you will misdiagnose
`wp-content/uploads`	Writable by the PHP user	Media uploads fail with a vague error, plugin and core updates fall back to prompting for FTP credentials
The whole tree set to `777`	Never correct	The site keeps working, which is the problem. Any other account on the host can rewrite your PHP

Two specifics worth committing to memory. If WordPress asks for FTP details during an update, PHP cannot write to its own directory, and define('FS_METHOD', 'direct'); in wp-config.php only helps once ownership is actually correct. In Docker, set the container user to match the bind mount owner rather than chowning the volume to root.

WP-Cron misconfiguration: the silent damage that becomes a visible outage

WP-Cron is not cron. There is no scheduler. WordPress checks the due list on page load and fires a loopback HTTP request to wp-cron.php to run whatever is overdue. Every failure mode follows from that one design fact, and none of them announce themselves until something else breaks.

A low traffic site never runs its jobs: no visitors means no page loads means no cron. Scheduled backups, transient cleanup and security scans simply do not happen. You discover this when you need the backup that was never taken.
A busy site runs it too often: each qualifying request can spawn another wp-cron.php call. Under traffic these stack against your PHP-FPM worker pool, and once workers are exhausted the site returns 502 to real visitors. This is the case where cron causes the visible outage directly.
The loopback request cannot reach itself: HTTP basic auth on staging, a firewall that blocks the server calling its own public hostname, or a container whose DNS resolves the domain to an address it cannot route, all break the call silently. WordPress logs nothing useful.
The cron option grows without bound: the schedule lives in a single autoloaded row in wp_options. Plugins that queue per item jobs, Action Scheduler backlogs in particular, inflate that row so it is unserialized on every request.
Overlapping runs: WP_CRON_LOCK_TIMEOUT defaults to 60 seconds, so a job that takes longer than that can start again before the first finishes.

The fix is the same everywhere: define('DISABLE_WP_CRON', true); in wp-config.php, then a system crontab entry running wp cron event run --due-now every 5 minutes. Audit the backlog with wp cron event list.

How do caching layers and a misconfigured object cache serve blank or stale pages?

Caching does not usually cause an outage. It extends one. A cache in front of a broken site keeps serving the broken response after you have fixed the underlying fault, which is why people spend an hour debugging a problem that stopped existing 40 minutes ago.

The 500 page gets cached: an nginx fastcgi_cache or a CDN that caches error responses will hold that 500 for the full TTL. Fix the fatal, purge nothing, and every visitor still sees the error. Always confirm what you are looking at is fresh, with a cache busting query string or a direct request to the origin.
WP_CACHE set without the drop-in present: page cache plugins add define('WP_CACHE', true); to wp-config.php and install wp-content/advanced-cache.php. Delete the plugin folder by hand and the constant remains, pointing at a file that is gone.
Two object cache drop-ins fighting: only one wp-content/object-cache.php can exist. Install a second caching plugin and it overwrites the first, so the site now talks to a backend that was never configured.
Redis unreachable with no graceful fallback: some drop-ins throw a fatal rather than falling back to the database, which turns a restarted Redis container into a white screen across the whole site.
Redis evicting or refusing writes: with maxmemory-policy set to noeviction, a full instance returns OOM errors on writes instead of discarding old keys. allkeys-lru is the safer choice for a WordPress object cache.
Logged in pages served to everyone: if the cache does not exclude the wordpress_logged_in_ cookie, one user's admin bar, cart or session leaks to anonymous visitors.

What a Malicious Ollama Model Can Actually Do to Your Host, and How to Sandbox /api/pull

John — Fri, 07 Aug 2026 03:14:46 +0000

A malicious Ollama model is not a virus you double click, but it is untrusted input handed to a C parser, a template engine and your filesystem in one request. The realistic damage from a hostile /api/pull is disk exhaustion, VRAM starvation, blob writes under ~/.ollama/models, a poisoned chat template that silently rewrites every prompt, and memory corruption in the GGUF loader if the file is crafted for it. None of that requires a vulnerability in your app code, only an Ollama daemon that trusts whoever can reach port 11434 and whichever registry a tag points at. Bind the daemon to localhost, pin models by SHA256 digest, run the container as a non root user with a read only root filesystem and a capped model volume, and the entire class collapses to a bad model that answers badly.

TL;DR by reader profile:

Solo developer running Ollama on a laptop, for example a contractor testing llama3.1:8b locally: leave OLLAMA_HOST at 127.0.0.1:11434 and pin digests, because your only real exposure is pulling a model whose tag moved under you.
Two person startup running Ollama on one rented GPU box, for example a founder pair serving an internal assistant: run it in Docker as UID 1000 with --read-only, --cap-drop ALL and a sized model volume, because a single unbounded pull can fill the disk that also holds your Postgres data.
Team fronting Ollama with Open WebUI or Continue, for example five engineers sharing one workstation: put model management behind the proxy and block /api/pull, /api/create, /api/push and /api/delete for normal users, because chat access and registry access are not the same privilege.
Anyone building agents or RAG on Ollama, for example a support bot with tool calling: treat the Modelfile TEMPLATE and SYSTEM blocks as attacker controlled text, because a poisoned template reaches the model before your prompt does.
Consultancies holding client data, for example a two person shop under an NDA: keep model pulls on a staging host, mirror approved blobs internally, and never let the inference container make outbound calls, because a model that can reach the internet is an exfiltration path with a GPU attached.

The central tradeoff is that every layer you add between Ollama and the host, non root users, read only mounts, seccomp filters and offline registries, also removes the one click convenience that made you choose Ollama over a served runtime in the first place.

What can a malicious model actually do to an Ollama host?
Where does Ollama put model blobs, and what does /api/pull write to disk?
Is a GGUF file data or code?
What can a Modelfile do that a bare weights file cannot?
Which Ollama endpoints mutate state, and who can reach them?
How do you pin a model by digest instead of trusting a moving tag?
Container hardening: non root user, read only rootfs and dropped capabilities
Seccomp, device passthrough and the GPU exception to every sandbox rule
How do you cap disk and VRAM so one pull cannot starve the host?
What should an Ollama container be allowed to reach on the network?

What can a malicious model actually do to an Ollama host?

Start with the honest bound: a GGUF file is not a shell script, and Ollama does not execute it. The damage comes from what the daemon does around the weights, and from the fact that /api/pull is a write operation with no signature check.

Fill the disk: a pull streams blobs into ~/.ollama/models/blobs with no default size ceiling, so a crafted manifest pointing at a 400 GB blob will keep writing until the filesystem is full, taking down anything else sharing that volume.

Starve the GPU: loading a model with an inflated context length or a large layer count reserves VRAM at load time, and with OLLAMA_MAX_LOADED_MODELS above 1 a few pulls plus a few /api/generate calls can pin every byte of a 24 GB card.

Rewrite every prompt: the TEMPLATE and SYSTEM directives travel with the model, so a hostile publisher controls the text wrapped around your user input on every single request, including instructions to your tool calling layer.

Corrupt loader memory: GGUF headers, tensor counts and metadata key value pairs are parsed in C before any inference happens, and a malformed field is untrusted input reaching a memory unsafe parser running with whatever privileges the daemon has.

Persist under a familiar name: /api/create can register a model called llama3.1:8b locally that points at attacker chosen weights, so ollama list looks normal while every request goes somewhere else.

The severity of all five depends entirely on one question, answered in the next section: what does the daemon actually write, and as which user.

Where does Ollama put model blobs, and what does /api/pull write to disk?

Ollama keeps everything under one root, $OLLAMA_MODELS, which defaults to ~/.ollama/models for a user install and /usr/share/ollama/.ollama/models when the Linux service runs as the ollama system user. In the official Docker image it is /root/.ollama, which is why so many compose files mount a volume there and quietly grant the daemon root ownership of every byte it writes.

Inside that root there are exactly two directories, and knowing which is which decides where your quota and your read only mount go.

blobs/: flat content addressed storage, one file per layer, named sha256-<64 hex characters>. Weights, adapters and the license text all land here, and a single 8B model at Q4 quantisation typically writes one blob of several gigabytes plus four or five tiny ones.

manifests/: a nested path mirroring the registry, for example manifests/registry.ollama.ai/library/llama3.1/8b, holding a JSON document that lists the digests a tag resolves to. Delete a manifest and the blobs stay, which is how disks fill after people believe they cleaned up.

Write path during a pull: the daemon fetches the manifest first, then each missing blob to a -partial file, verifies the digest, and renames it into place. A resumed pull reuses the partial, so an interrupted 20 GB download still occupies 20 GB.

Everything else in $HOME/.ollama: id_ed25519 and id_ed25519.pub, the keypair identifying this host to the registry, plus history for the CLI. That private key sits beside the blobs, which matters once you decide who owns the volume.

Is a GGUF file data or code?

Data, and that distinction matters less than people assume. GGUF is a binary container: a magic string GGUF, a version integer, tensor and metadata counts, a key value metadata block, then the tensor data. There is no bytecode section and no entry point, so nothing in the file gets jumped to. The comparison people reach for is the right one: this is not a pickle file. PyTorch .bin and .pt checkpoints deserialise Python objects and can execute on load, which is exactly why safetensors and GGUF exist.

The risk is that a container format still has to be parsed, and the parser is llama.cpp's C and C++ code running inside the Ollama daemon.

Attacker controlled counts: the header declares how many tensors and metadata entries follow, and those integers drive allocations and loops before any of the actual content is validated.

Attacker controlled offsets: each tensor carries an offset and dimensions, so a file can claim a tensor extends past the end of the mapped region.

Attacker controlled strings: metadata keys and string values are length prefixed, and length prefixed strings in C are the oldest bug class there is.

Memory mapping by default: Ollama maps weights rather than copying them, so a malformed structure is read straight from a file the attacker wrote.

Bugs get fixed, then reappear: llama.cpp GGUF parsing has had a steady stream of out of bounds and integer overflow fixes, which is evidence the surface is real, not that it is now clean.

Treat GGUF as untrusted input to a memory unsafe parser. That framing, not malware scanning, is what justifies the container boundaries in the later sections.

What can a Modelfile do that a bare weights file cannot?

A Modelfile is the part people forget to review, because it looks like configuration rather than payload. It ships inside the model when you pull a tag, and /api/create accepts one over HTTP. It cannot spawn a process, but it controls everything that surrounds the weights at runtime.

Directive	Legitimate use	What a hostile publisher gets
`FROM`	Points at the base weights or another local model	Redirects a familiar name to blobs you never inspected
`TEMPLATE`	Formats chat turns with Go template syntax	Wraps, reorders or drops your messages and tool definitions on every request
`SYSTEM`	Sets a default persona	Injects standing instructions your application never sent and cannot see in its own logs
`PARAMETER`	Tunes `temperature`, `num_ctx`, `stop`	Sets `num_ctx` high enough to reserve far more VRAM than the model needs, or strips stop tokens
`ADAPTER`	Applies a LoRA on top of the base	Attaches behaviour changing weights that never appear in the base model's reputation
`MESSAGE`	Seeds few shot examples	Preloads fake conversation history that steers the first real answer

Two habits close most of this. Run ollama show --modelfile <name> after every pull and read the TEMPLATE and SYSTEM blocks before the model serves traffic, because a diff against the upstream template takes under a minute. Then treat PARAMETER num_ctx as a resource declaration, not a preference: it is the single field that turns a model listing into a memory allocation request, which is why the next sections cap it at the daemon level rather than trusting what arrived in the file.

Which Ollama endpoints mutate state, and who can reach them?

Ollama has no user model. There are no accounts, no API keys and no roles, so the answer to "who can reach them" is exactly "anyone who can open a TCP connection to port 11434". The default bind is 127.0.0.1:11434, and setting OLLAMA_HOST=0.0.0.0 to reach the box from a laptop is the single change that converts every endpoint below into a public one.

POST /api/pull: downloads a manifest and its blobs from any registry the tag names, writing to disk and consuming bandwidth, with no confirmation step.

POST /api/create: registers a new model from a Modelfile supplied in the request body, which is how an attacker binds a trusted looking name to weights or a template of their choosing.

POST /api/blobs/:digest: uploads a raw blob directly into the store, so the attacker does not even need a reachable registry.

DELETE /api/delete: removes a model. One request destroys a 40 GB download and the next request to your app fails with a model not found error.

POST /api/push: uploads a local model to a registry, signed with the id_ed25519 key sitting next to your blobs.

POST /api/generate and /api/chat: read only for the filesystem, but they load models into VRAM and run inference, which is the resource abuse path.

The practical rule is that chat access and model management are separate privileges, and Ollama does not separate them for you. Your reverse proxy has to: allow /api/chat, /api/tags and the /v1 compatibility routes, and return 403 for the five write endpoints above.

How do you pin a model by digest instead of trusting a moving tag?

Ollama has no pull name@sha256:... syntax, so you cannot ask the daemon to pin for you. Tags like llama3.1:8b are pointers that the publisher can repoint at any time, and a later ollama pull will happily replace your blobs with different weights under the same name. Pinning is therefore something you enforce around Ollama, not inside it.

Record the manifest after the first pull: read manifests/registry.ollama.ai/library/llama3.1/8b, a small JSON file listing every layer digest, and commit a copy to the repository that deploys the service. This is your reference.

Check the short ID on every host: ollama list prints an ID column holding the first 12 hex characters of the manifest digest. Two machines showing different IDs for the same tag means the tag moved between the two pulls.

Fail the deploy on drift: in CI, diff the live manifest against the committed one and exit non zero on mismatch. A blob rename is enough to catch, because blob filenames are sha256-<digest> and any weight change produces a different filename.

Freeze the store instead of re pulling: once verified, mount the model directory read only and never run ollama pull in production. Pull on a staging host, verify, then copy the blobs and manifests trees across.

Mirror internally if you run more than two hosts: serve the verified blobs from your own object storage or an internal registry, so the production daemon never resolves a public tag at all.

The cost is honest: you lose one command updates and take on a small manifest review each time you deliberately upgrade.

Container hardening: non root user, read only rootfs and dropped capabilities

The official ollama/ollama image runs as root with HOME=/root/.ollama, so the default compose file most people copy gives a network reachable daemon root ownership of the volume holding your blobs and the id_ed25519 key. Fixing that is four flags and one chown.

Setting	Default image behaviour	Hardened value
Process user	root, UID 0	`user: "1000:1000"` after `chown -R 1000:1000` on the volume, plus `HOME=/home/ollama` and `OLLAMA_MODELS=/models`
Root filesystem	Writable, so a parser bug can drop files anywhere in the container	`read_only: true` with `tmpfs: /tmp:size=512m,noexec` for runner extraction
Capabilities	Full default Docker set, including `CAP_CHOWN` and `CAP_NET_RAW`	`cap_drop: [ALL]`, adding none back, because inference needs no capability
Privilege escalation	setuid binaries can still raise privileges	`security_opt: [no-new-privileges:true]`
Model store	Bind mount, writable, often the host home directory	Named volume mounted at `/models`, writable only while you pull, `:ro` in production

Two details catch people out. First, the model directory must be writable during a pull and can be read only afterwards, so run pulls with a separate one shot container that mounts the same volume read write, then keep the serving container on :ro. Second, no-new-privileges and cap_drop: ALL do not affect throughput at all, because llama.cpp needs no elevated syscall to read a mapped file and talk to a device node.

What this buys you is narrow but real: a GGUF parser bug now executes as UID 1000 inside a container with no capabilities and nowhere writable except /tmp and the model volume.

Seccomp, device passthrough and the GPU exception to every sandbox rule

Docker's default seccomp profile already blocks around 44 syscalls, including mount, ptrace and the kernel module calls, and Ollama needs none of them. Keep the default and resist the two pieces of advice that circulate whenever a CUDA container misbehaves: --privileged and --security-opt seccomp=unconfined. Neither is required for inference, and both undo the previous section entirely.

Pass through specific GPUs, not all of them: --gpus '"device=0"' or the compose device_ids: ["0"] limits the container to one card, so a second GPU stays available for anything else on the box.

Know which device nodes appear: the NVIDIA container toolkit injects /dev/nvidiactl, /dev/nvidia-uvm and /dev/nvidia0. ROCm needs /dev/kfd and /dev/dri, and /dev/kfd is the broader grant of the two.

Accept the hole you just opened: those nodes are ioctl interfaces straight into a closed source kernel driver. Seccomp filters syscall numbers, not ioctl arguments, so the driver surface stays reachable from inside the container no matter how many capabilities you dropped.

Do not expect VRAM isolation from Docker: separation between processes sharing a card is enforced by the GPU driver, not by the container runtime, which is why the disk and VRAM limits in the next section matter more here than any Linux security module.

Skip user namespace remapping if it fights the toolkit: userns-remap and GPU passthrough interact badly on some driver versions. A plain UID 1000 container with cap_drop: ALL is the pragmatic stopping point.

The honest summary: containerising Ollama contains the filesystem well and the GPU barely. Treat the card as shared, hostile territory and budget it explicitly.

How do you cap disk and VRAM so one pull cannot starve the host?

Both limits have to live outside Ollama, because the daemon will happily accept whatever the manifest and the request ask for.

Give the model store its own filesystem: a dedicated LVM volume, a ZFS dataset with quota=200G, or an XFS project quota on the mount point. A --storage-opt size= on the container only works on overlay2 over XFS, so the separate volume is the portable answer. When the quota is hit the pull fails and Postgres on the root disk keeps running, which is the entire point.

Alert on the partial files, not the total: a growing sha256-<digest>-partial file in blobs/ is an in flight download, and comparing its size against your quota tells you about a hostile pull minutes before the disk fills.

Load one model at a time: OLLAMA_MAX_LOADED_MODELS=1 and OLLAMA_NUM_PARALLEL=1 mean a single resident model and a single concurrent request, so VRAM use becomes predictable instead of a function of how many distinct model names someone sends.

Unload aggressively: OLLAMA_KEEP_ALIVE=30s instead of the 5 minute default frees the card between bursts. For a two person team hitting the assistant a few times an hour, the reload cost is a few seconds and the card is free the rest of the time.

Override the context length yourself: OLLAMA_CONTEXT_LENGTH sets the default window at the daemon, which neutralises a PARAMETER num_ctx shipped inside someone else's Modelfile. Cap the request queue too, OLLAMA_MAX_QUEUE defaults to 512 pending requests.

Add mem_limit and cpus on the container so CPU offload cannot swap the host to death either.

What should an Ollama container be allowed to reach on the network?

Nothing, in steady state. A serving daemon needs inbound requests from your proxy and no outbound access at all. Egress is only required while pulling, and pulling is a deliberate, occasional act.

Publish to loopback, never to the host's public interface: write 127.0.0.1:11434:11434 in the ports mapping. A bare 11434:11434 binds every interface, and Docker inserts its rules ahead of ufw, so a firewall you believe is blocking the port is not blocking it.

Prefer no published port at all: put Ollama and its proxy on the same user defined bridge network and let the proxy reach http://ollama:11434 by container name. The daemon then has no host port, and OLLAMA_HOST=0.0.0.0 is safe inside that network because the network is the boundary.

Mark the inference network internal: true: a Compose network with that flag gets no route to the outside, so the container cannot resolve or contact any registry. Attach the pull container to a second, normal network only while you pull, then detach.

Allowlist one destination if you must keep egress: registry.ollama.ai on TCP 443 plus DNS. Everything else denied, because a model that can reach arbitrary hosts turns tool calling mistakes into exfiltration.

Leave OLLAMA_ORIGINS alone: it controls which browser origins may call the API, and setting it to * means any web page you visit can script requests against your local daemon, including the write endpoints. Name the specific origins your UI uses instead.

Test the result from another machine with curl -m 5 http://<host>:11434/api/tags. A connection timeout is the correct outcome, not a JSON model list.

When You Should Not Run Kubernetes, and What a Single Docker Compose Host Really Costs You

John — Thu, 06 Aug 2026 08:17:33 +0000

Do not run Kubernetes for a client project that fits on one server, has no autoscaling requirement, and is maintained by fewer than three people who touch infrastructure. A single Docker Compose host running behind a reverse proxy handles the majority of small agency workloads, and it costs you exactly two things: minutes of downtime during reboots, and a manual path back from hardware failure. Kubernetes does not remove those costs, it converts them into a control plane you now have to keep alive. Pick the failure mode you can actually staff.

TL;DR by reader profile:

Agency running 12 client sites on one provider (WordPress, Node APIs, a few static builds): one Compose host per client tier, because per client blast radius matters more to you than scheduling, and your real risk is a botched deploy, not capacity.
Two person team with one revenue critical app (SaaS, single Postgres, 24/7 traffic): Compose plus a warm standby and tested restores, because a second machine you can promote beats a cluster nobody on the team can debug at 3am.
Team of six with a genuine multi service platform (8 or more services, several deploys a day): Kubernetes starts paying for itself here, because rolling deploys, health gating and per service resource limits stop being manual work.
Contractor handing infrastructure back to the client at the end of the engagement: Compose, because a docker-compose.yml plus a README is a deliverable the client can actually run, and a cluster is a dependency on you.
Anyone under a contractual uptime commitment with penalties (SLA with credits attached): you need redundancy of some kind, and that is the one case where the orchestration question becomes a real engineering decision rather than a preference.
Solo developer hosting side projects and one paying client: Compose on a single host, because every hour spent on cluster maintenance is an hour not billed.

The central tradeoff: Kubernetes buys you automatic recovery and rolling deploys at the price of a permanent operational surface you must keep patched, while Compose buys you a system one person can hold in their head at the price of doing recovery yourself.

When should you not run Kubernetes?

When should you not run Kubernetes?

Skip Kubernetes when the cluster would exist to solve a problem you do not have yet. Four conditions, and if three of them describe your project, stop.

Your workload fits on one machine: the whole stack, application, database, cache and reverse proxy, runs inside the RAM and CPU of a single server you can afford. If you are not resource constrained, the scheduler has nothing to schedule.

Traffic is predictable: you know roughly what next Tuesday looks like because it looks like last Tuesday. Horizontal Pod Autoscaler is worth real money when load swings by an order of magnitude within an hour. It is worth nothing when your peak is 3x your trough and both fit on the same box.

Nobody on the team owns infrastructure full time: Kubernetes is a system that needs a person. Version skew between control plane and nodes, CNI upgrades, cert rotation, ingress controller changes and deprecated API versions all arrive whether or not anyone is assigned to them.

The client will eventually own this: you are building something you hand over. A cluster is a hiring requirement disguised as a deployment target.

Condition	Points to Compose	Points to Kubernetes
Capacity	Everything fits on one host	You are already sharding across machines
Traffic shape	Predictable, within 3x daily swing	Spiky, unpredictable, event driven
Team	Under 3 people touching infra	A named platform owner or team
Deploy frequency	A few times a week	Several times a day across services
Handover	Client inherits the stack	You operate it indefinitely
Uptime terms	Best effort, informal	Contractual SLA with penalties

The inverse is also true, and worth saying plainly so this does not read as a hit piece. If you run 8 or more services that deploy independently, if two teams need to ship without coordinating, or if your uptime commitment survives a single machine failing, Kubernetes is the correct answer and Compose will hurt you.

Immich vs Google Photos: Why Self-Hosting Your Photo Library Wins in 2026

John — Thu, 06 Aug 2026 06:31:57 +0000

Immich is the better choice if you own a machine that stays powered on and you care where your photos live. It gives you the parts of Google Photos people actually use every day, mobile auto backup, face grouping, map view, albums and shared links, without a storage meter that raises your bill as your library grows. Google Photos still wins on zero maintenance and on search that understands a sentence. If you are willing to spend one evening on setup and roughly an hour a quarter on updates, Immich replaces it.

TL;DR by reader profile:

Family archivist with 15 years of photos (Marta, two phones, one shared library): move to Immich on a small always on box, because a growing archive is exactly the case where a per gigabyte subscription compounds against you forever.
Photographer shooting RAW every weekend (Tomas, 40 megapixel bodies): Immich, because RAW files eat cloud tiers fast and you already keep a local working copy that you can point the server at.
Non technical user with one phone and no home server (Elena, iPhone, no NAS): stay on Google Photos for now, because Immich needs someone to own updates, backups and remote access, and that someone would be you.
Privacy sensitive professional handling client images (lawyer, therapist, journalist): Immich on hardware you control, because the legal question is not whether the provider is trustworthy but who can be compelled to hand over the data.
Homelab owner already running Docker (Sam, existing NAS and reverse proxy): Immich, because the marginal cost is one compose stack on infrastructure you maintain anyway.
Small team or studio sharing a shoot library (five people, one archive): Immich with per user accounts and shared albums, because Google Photos was built for one person and gets awkward the moment several people need write access.

The central tradeoff: Google Photos sells you freedom from maintenance and pays for it with a recurring bill and a library you do not control, while Immich hands you control and a one time hardware cost and charges you in setup time, backup discipline and the responsibility for your own uptime.

What is Immich, and can it really replace Google Photos?

What is Immich, and can it really replace Google Photos?

Immich is an open source, self-hosted photo and video backup server. You install it on a machine you own, install the Immich app on your phone, and it uploads new photos in the background the way Google Photos does. It is licensed under AGPL-3.0, developed in the open on GitHub, and released on a fast cadence with frequent tagged versions. It is not a photo viewer bolted onto a file share. It is a full stack with its own database, machine learning container and mobile clients for Android and iOS.

The honest answer on replacement: yes for the daily loop, partially for search.

The daily loop is backup, browse, album, share. Immich covers all four. You get automatic background upload, a timeline grouped by date, albums, shared albums with other users on your server, public share links with optional passwords and expiry, a map view built from EXIF GPS data, face grouping into named people, and duplicate detection. Multi user support is built in, so each family member gets their own library on the same server.

Where it differs is the part Google spent a decade on: semantic search quality and the automatic memories and collages that surface old photos without you asking.

Capability	Google Photos	Immich
Automatic phone backup	Yes, first party OS integration	Yes, background service in the app
Face grouping and named people	Yes	Yes, runs locally on your server
Natural language search	Yes, strong	Yes, CLIP based, weaker on complex phrasing
Storage limit	Bound to your Google One tier	Bound to your disk
Who holds the data	Google	You
Maintenance owner	Google	You

Treat Immich as a replacement for the product, not a clone of the company. You give up an army of engineers tuning search ranking. You gain a library that cannot be reindexed, repriced or closed without your consent.

DEV Community: John

How Many People Fit in a Self-Hosted Hubs Room? Dialog SFU Bandwidth and CPU Costs Explained

Table of contents

What is the realistic concurrent user limit for one self-hosted Hubs server?

Which Hubs component actually breaks first under load, Reticulum or Dialog?

How does Dialog's SFU model differ from mesh and MCU, and why does it matter here?

How much bandwidth does each Hubs participant consume, upstream and downstream?

Why does room bandwidth grow quadratically, and where does the curve become unaffordable?

How much CPU does a mediasoup worker use per audio stream and per video stream?

What server specification do you need for 10, 25 and 50 concurrent participants?

How much does Reticulum cost per user for position, rotation and object sync?

When does TURN relay kick in, and what does it add to your bandwidth bill?

How do simulcast, bitrate caps and audio only rooms change the maths?

Duplicati on Backblaze B2 vs Backblaze Personal Backup: where the yearly cost actually crosses over

Table of contents

What does Duplicati plus Backblaze B2 actually cost you per year?

What does a Backblaze Personal Backup subscription actually cost per year?

At what dataset size do the two cost curves cross?

Deduplication, compression and the number B2 really bills you for

How much do restores cost, and how often will you actually restore?

How does retention depth change the arithmetic?

Tuning Duplicati remote volume size, upload threads and API call classes

Multiple computers, NAS shares and the per computer licence

What each product simply refuses to back up

Where should you run Duplicati, and what does the host add to the bill?

OpenClaw vs Subscription AI Assistants: Real Token Costs, Capability Gaps and the Usage Level Where Self-Hosting Wins

Table of contents

What does OpenClaw actually do, and what does it replace?

Flat subscription fees versus metered tokens: two different cost shapes

What drives an OpenClaw token bill: context, memory and the heartbeat

How much server does OpenClaw need, and what does that cost to run?

How much does OpenClaw cost per month at light, steady and heavy usage?

At what monthly usage does self-hosting OpenClaw actually win?

Can local models through Ollama cut the OpenClaw token bill to zero?

What does OpenClaw do that a subscription assistant cannot?

What do you give up when you cancel the subscription?

Which of your data leaves the server when OpenClaw calls a hosted model?

What does OpenClaw cost over three years, including your own time?

Where should you run OpenClaw: home server, VPS, NAS or managed Personal Cloud Server?

When DokuWiki Is the Wrong Replacement for Notion or Confluence Cloud: The Gaps No Plugin Closes

Table of contents

Can two people edit the same DokuWiki page at the same time?

Is there a real WYSIWYG editor for DokuWiki, and what does it cost you in markup?

What replaces Notion database views, relations and rollups in DokuWiki?

How granular are DokuWiki ACLs next to Confluence page restrictions?

Are there official DokuWiki mobile apps, and what do you actually use on a phone?

Can DokuWiki do SSO, and what happens to SCIM provisioning?

Where do comment threads, mentions and notifications end up?

Which paid features DokuWiki genuinely beats, and why that still matters

Netdata Cloud vs a Self Hosted Parent Node: The Real Three Year Cost for a Home Server

Table of contents

What does Netdata Cloud actually add on top of the agent you already run?

What does the free tier stop giving you?

How much does Netdata Cloud really cost over three years?

What does a self hosted Netdata parent node cost over the same three years?

How do you size a parent node for a home server's metric volume?

How much bandwidth does streaming from child to parent actually use?

How do the dbengine tiers change your retention bill on a parent node?

What does bolting Prometheus and Grafana onto Netdata cost you in hours and hardware?

Which setup gives you alerts that actually reach you, and what do notifications cost?

Navidrome duplicate albums, split discs and missing art: the tagging and mount anti-patterns that break a 50k library

Table of contents

Why does Navidrome show the same album twice after a scan?

How Navidrome decides what an album is: persistent IDs and the grouping tags

Why missing ALBUMARTIST breaks more than any other single tag

Do you need MusicBrainz IDs in Navidrome, and what actually breaks without them?

Why does one album split into CD1 and CD2 in the interface?

Compilations, Various Artists and soundtracks: four ways they fragment

Why is cover art missing when the file clearly has an embedded image?

Why does Navidrome rescan the whole library on an SMB or NFS mount?

Symlinks, bind mounts and container paths: the anti-patterns that hide half a library

WordPress Sitewide Outages: Which Misconfigurations Actually Cause Them, Ranked by Frequency and Recovery Time

Table of contents

Which WordPress misconfigurations actually cause a full sitewide outage?

The main failure modes ranked by frequency, blast radius and mean recovery time

Why does a plugin or theme update end in a white screen of death?

PHP memory_limit, max_execution_time and OPcache: the settings that fail first

What does "Error establishing a database connection" mean in each of its cases?

MySQL connection limits, InnoDB corruption and the full disk that causes both

How does a wrong WP_HOME or WP_SITEURL value lock you out of wp-admin?