DEV Community: John

Self-Hosted WordPress vs WordPress.com Business vs WP Engine and Kinsta: The Real 3-Year Cost for a Two-Person Startup

John — Thu, 17 Sep 2026 07:04:41 +0000

For most two-person startups, self-hosted WordPress has the lowest cash cost over three years. It only has the lowest total cost if one founder can spend a small, steady amount of time each month on updates, backups and security, and does not bill that time at a consultant's rate. WordPress.com Business and managed hosts such as WP Engine or Kinsta cost more in fees but take most of that maintenance work away. The deciding figures are not the hosting fees. They are the renewal price of premium plugins, the cost of an incident, and how much each founder's hour is worth.

TL;DR:

The technical founder with spare evenings (for example, a developer building a SaaS landing page and blog): self-host on a small VPS or a personal cloud server, because the hosting bill stays small and the maintenance is familiar work.
The non-technical pair selling a service (for example, two consultants who need a credible site and a contact form): use WordPress.com Business, because a fixed yearly fee costs less than learning server administration.
The WooCommerce shop with real revenue at stake (for example, a two-person direct-to-consumer brand): use a managed host like Kinsta or WP Engine, because staging, backups and support cost less than one bad outage during a sale.
The content-heavy startup expecting traffic spikes (for example, a media newsletter that gets shared widely): self-host behind a CDN or pick a managed plan with generous visit limits, because per-visit plan limits are where managed hosting costs rise.
The bootstrapped team planning to pivot (for example, founders still testing product-market fit): self-host with a lean free plugin stack, because leaving is cheap and nothing is locked into a plan tier.
The team handling customer data under strict rules (for example, a health or legal tech startup): self-host where you control the hosting location, because data location and access logs matter more than saving admin hours.

The central tradeoff is simple: self-hosting spends your time to save money, and managed WordPress spends money to save your time.

How much does WordPress really cost a two-person startup over 3 years?
What goes into the total cost beyond the hosting bill
What does self-hosting WordPress cost in year one, year two and year three?
How WordPress.com Business pricing and plan limits play out over three years
What do WP Engine and Kinsta charge once you hit visit and storage limits?
Premium plugins and themes: the renewal costs that grow each year
How many hours a month does self-hosted WordPress maintenance actually take?
Backups, staging and disaster recovery across the three options
Is self-hosted WordPress secure enough without a managed host's protection?
What happens to the cost when traffic grows or WooCommerce is added?
Where to run self-hosted WordPress: VPS, home server or personal cloud server
Data sovereignty and hosting location for a small WordPress site
How hard is it to switch between self-hosted and managed WordPress later?
Which option fits your startup: recommendations by profile

How much does WordPress really cost a two-person startup over 3 years?

WordPress itself costs nothing. The software is released under the GPLv2 licence, and you can download it from wordpress.org free of charge. The real cost is everything around it, and over 36 months those extra costs add up to far more than the first invoice suggests.

A fair comparison needs three kinds of cost. Cash is what goes on the card: hosting, domains, premium plugins and backup storage. Time is the hours a founder spends on updates, fixing things and restores. Risk is the expected cost of downtime, a hacked site or lost orders. Pricing pages only show the first kind. For a two-person team, the second and third often decide the answer.

Option	What the bill covers	What you still handle
Self-hosted on a VPS	Server, domain, any paid plugins, off-site backup storage	Server updates, WordPress updates, security, backups, restores
WordPress.com Business	Hosting, updates, backups, security for the platform	Plugin choices, content, anything a plan limit blocks
WP Engine	Managed hosting, staging, backups, support	Plugin licences, overage if you pass the visit limits
Kinsta	Managed hosting, staging, backups, CDN, support	Plugin licences, add-ons, moving to a higher tier as you grow

The pattern is the same across all four. Self-hosting has the smallest fixed bill and the largest time cost. Managed plans reverse that. Over three years, renewals and growth decide which side comes out ahead. Plugin renewals and plan upgrades happen every year, while the time you spend learning to run a server mostly happens in year one.

What goes into the total cost beyond the hosting bill

The hosting bill is the easy part to see. Most of the three-year total sits in smaller costs that only show up once the site is live. Each one is small on its own, but together they are what make a cheap-looking setup expensive.

Domain renewal: you pay it every year whatever you choose, and some registrars charge far more to renew than they did the first year.
TLS certificates: Let's Encrypt certificates are free but expire after 90 days, so a self-hosted setup needs automatic renewal that someone checks is working.
Transactional email: WordPress sends email through wp_mail(), which uses PHP mail by default and often lands in spam, so most teams add an SMTP plugin and a sending service such as Amazon SES or Mailgun.
Off-site backups: a backup kept on the same server does not protect you, so you need storage somewhere else, such as Backblaze B2 or an S3 bucket, plus a plugin like UpdraftPlus to send backups there.
CDN and DNS: Cloudflare's free plan covers many small sites, but image-heavy pages or WooCommerce checkouts can push you towards paid features.
Uptime monitoring: if nobody is watching, the first person to notice an outage is usually a customer.
Founder hours: every update, failed restore and plugin conflict costs time, and time is what a two-person team has least of.

Where you run the site changes which of these you manage yourself. A self-managed VPS, a home server and a NAS all leave TLS, networking and backups to you. 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. On that kind of setup, public HTTPS access comes with the subdomain, but email, off-site backups and plugin upkeep are still your job.

What does self-hosting WordPress cost in year one, year two and year three?

Self-hosting costs change shape over three years. Year one has most of the learning and setup work. Years two and three are cheaper in time, but plugin renewals and growing storage start to show up on the bill.

Cost line	Year one	Years two and three
Server	Small VPS, home server, NAS or a platform such as Yundera, often the smallest size that runs PHP and MySQL	Same size unless traffic or WooCommerce needs more memory
Setup time	Heaviest: web server, database, TLS, SMTP, backups, caching	Light: occasional rebuild or migration
Software upkeep	WordPress applies minor updates automatically, but a person must test the major releases that come out a few times a year	Same routine, plus PHP 8.x version upgrades that can break older plugins
Operating system	Choose an Ubuntu LTS release to get 5 years of standard support	Plan one OS upgrade if you started late in a release's life
Premium plugins	First-year prices, often discounted	Full renewal prices on every licence you kept
Backup storage	Small, a few snapshots	Grows with each upload and every retained copy
Incidents	Most likely, while the setup is still new	Less frequent, but each one takes longer if nobody has practised a restore

The mistake teams make is judging the whole cost on year one alone. In year one, self-hosting looks expensive in hours and cheap in cash. By year three, you spend far fewer hours, but the cash cost has quietly risen through plugin renewals and storage. That third year is the right number to hold up against a managed plan's renewal price, not the introductory one.

One routine keeps the time cost predictable. Set a fixed monthly maintenance window, put every update through a staging copy first, and run a timed test restore once a quarter.

How WordPress.com Business pricing and plan limits play out over three years

WordPress.com Business is the only WordPress.com plan most startups need to think about, because it is the first plan where you can install your own plugins and themes. That access is what makes it a real alternative to self-hosting. The three-year cost depends less on the price shown on the page and more on how you pay and what the plan does not include.

Billing term: monthly billing costs the most per month, while annual and multi-year terms cost less per month but require payment upfront. For a startup short on cash, paying for 36 months at once can be a hard call.
Introductory pricing: the first-term price is often discounted, and renewals charge the standard rate. Build your three-year total on the renewal price, not the checkout price.
Bundled domain: an annual plan includes a domain registration for the first year only. From year two, you pay the domain renewal separately.
Developer access: Business includes SFTP, SSH and database access, so a technical founder can still debug problems. You do not get root access to the server, so you cannot install system packages or tune PHP beyond what the platform lets you change.
Plugins you still pay for: the plan pays for hosting, not for premium plugin licences, so your SEO, forms and membership renewals cost the same as they would on a VPS.
Store features: a serious WooCommerce shop may push you onto a higher Commerce tier, which moves you into a different price band.

This plan works best as a fixed, predictable cost. It works worst when you need something the platform does not allow. That usually means leaving for Kinsta, WP Engine or a VPS, and paying for the migration on top.

What do WP Engine and Kinsta charge once you hit visit and storage limits?

WP Engine and Kinsta both sell plans in tiers. Each tier sets a limit on sites, visits and storage. The entry price is only an accurate guide to your three-year cost if the site stays inside those limits. Once you go over, you either pay overage fees or move up a tier, and the next tier is usually a big jump rather than a small step.

Limit	How it raises the bill	What to watch
Monthly visits	Overage fees on each block of extra visits, or a forced move to a higher tier	Both hosts count unique visitors over a 24-hour window, and bot traffic can count too
Storage	Paid add-on or higher tier once media and backups fill the quota	WooCommerce product images and uncompressed uploads grow fastest
Bandwidth or CDN usage	Charges or tier changes on plans that measure data transfer	Large downloads, video and podcast files served from the same site
Number of sites	A second site, such as a docs or app marketing site, can need a bigger plan	Staging copies usually do not count, but separate production sites do
Add-ons	Extra fees for features like extra backups, security add-ons or additional PHP workers	Features you enable once and then forget are billed every month

For a two-person startup, the danger is a success spike, not steady growth. A launch post that goes viral or a mention in a newsletter can push one month over the visit limit. On a self-hosted server behind Cloudflare, the same spike usually costs nothing extra as long as caching holds.

Before you commit to a year, look at the analytics from your current site. Estimate your visits in year three, including bots, and price the tier you will need then, not the tier you need today.

Premium plugins and themes: the renewal costs that grow each year

Premium plugins are the part of the WordPress budget people forget to check. They cost the same whether you self-host, use WordPress.com Business or pay Kinsta, so the hosting choice does not change this line. What does change is how many plugins you keep adding over three years. Most are sold as yearly licences, and each one renews on its own date.

Licence expiry is not a shutdown: plugins are GPL, so the code keeps running after the licence lapses, but updates and support stop. Running old code on a public site is a security debt that someone eventually has to pay.
Renewal versus first-year price: many vendors discount the first year, so your year-two cost for Gravity Forms, WP Rocket or Yoast SEO Premium can be higher than what you paid at checkout.
Site-count tiers: a single-site licence covers one production site. Adding a second site, such as a documentation site, can force every licence up to the multi-site tier at the same time.
Page builders and themes: Elementor Pro or a premium theme ties your layouts to that vendor, so dropping the licence later means rebuilding pages instead of simply cancelling.
WooCommerce extensions: subscriptions, bookings and payment gateway add-ons are often sold separately, and a shop can end up with more of these licences than every other plugin combined.
Free alternatives: Rank Math or Yoast free, Contact Form 7 and a well-configured server cache cover many needs at no licence cost, as long as you accept less vendor support.

Run wp plugin list once a quarter. For each paid plugin, write down its renewal date and what you would use instead. If nobody on the team can name a reason to keep a plugin, cancel it before it renews.

How many hours a month does self-hosted WordPress maintenance actually take?

Nobody can give you an honest single number, because the hours depend on your setup more than on WordPress. Instead, count the tasks and time each one yourself over your first three months. After that, the monthly total usually settles into a predictable routine with occasional spikes.

Core and plugin updates: running wp core update and wp plugin update --all takes minutes. Most of the time goes on testing checkout, forms and login on a staging copy before you push to production.
Server patching: apt upgrade and occasional reboots on a VPS, home server or NAS. The OS layer is less of your job on platforms that package WordPress as a Docker container, such as Yundera, although you still update the app itself.
Backup checks: a backup job that reports success is not proof. Export a test with wp db export, restore it somewhere else, and time the whole process.
Security review: look at failed logins, unknown admin users and file changes in wp-content. Each check is short, but it needs to happen on schedule.
Performance work: clear caches, compress images and look for slow queries when pages get sluggish. This work comes in bursts rather than every month.
Incident response: a plugin conflict, a full disk or an expired certificate. These are rare but take the longest, and they always happen at a bad time.

To turn hours into money, multiply the monthly hours by the value of a founder's hour. Use the rate that founder could bill clients, or the value of product work they are not doing. Add a buffer for incidents. Compare that figure with the difference between your hosting bill and a managed plan. In a two-person team, one founder usually ends up owning this work, so price it at their rate.

Backups, staging and disaster recovery across the three options

Backups only matter on the day you need to restore one, so compare the three options by what a restore actually involves. For WooCommerce, also ask how many orders you could lose between the last backup and the moment the site broke.

Recovery need	Self-hosted WordPress	WordPress.com Business, WP Engine, Kinsta
Daily backups	You set it up yourself with UpdraftPlus, a cron job or server snapshots	Included and automatic, with retention set by the plan
Off-site copy	Your job: follow the 3-2-1 rule with at least one copy on separate storage	Stored by the host, and you need an extra export if you want a copy outside the host
Staging site	Manual clone of files and database, plus search-and-replace for URLs with `wp search-replace`	One-click staging, then push to live when ready
Restore speed	Depends on how often you practise it and how big `wp-content/uploads` is	A button in the dashboard, usually quick for small sites
WooCommerce orders	A nightly backup can lose a full day of orders on restore	Same risk unless the plan offers more frequent backups
Full host failure	You rebuild on another server from your off-site copy	You wait for the provider, or restore elsewhere from your own export

Managed hosts are better at the everyday cases: you break something with an update and roll back in minutes. Self-hosting can be better at the rare disaster, but only if you have been keeping an independent copy of the database and wp-content. Many managed customers never make that copy, and they discover the gap when an account is suspended or a billing problem locks them out.

Whichever option you choose, keep wp-config.php settings, the latest database export and the uploads folder somewhere your hosting provider cannot reach. Test restoring from it twice a year.

Is self-hosted WordPress secure enough without a managed host's protection?

Yes, if you treat security as a routine rather than a product. Most WordPress compromises come through outdated plugins, weak admin passwords and abandoned themes, not through WordPress core. A managed host reduces some of that risk, but it cannot protect a site that runs a vulnerable plugin you chose to install.

Plugin auto-updates: since WordPress 5.5 you can switch on auto-updates for each plugin. Turn them on for low-risk plugins and keep manual, tested updates for WooCommerce and payment gateways.
Admin access: use unique passwords and two-factor authentication through a plugin such as WP 2FA or Wordfence. Keep administrator accounts to the two founders only.
Hardening in wp-config.php: set DISALLOW_FILE_EDIT to true so a stolen login cannot edit PHP files from the dashboard. Keep the database credentials out of any public repository.
Attack surface: block xmlrpc.php if nothing uses it, rate-limit wp-login.php with fail2ban or your firewall, and delete unused themes and plugins instead of just deactivating them.
Edge filtering: Cloudflare in front of the origin hides its IP and absorbs a lot of automated traffic. Its free plan includes basic protections, and managed rulesets need a paid tier.
Detection: file-integrity scans and alerts when a new admin account appears. Without them, a quiet compromise can sit unnoticed for months.

What managed hosts really add is people and speed. Kinsta and WP Engine run server-level firewalls, patch PHP for you, and some clean up malware if a site is infected. On a self-hosted server, cleanup is your job, and it is the most expensive hour in this whole cost model. Put a realistic incident allowance into your three-year budget rather than assuming it will not happen.

What happens to the cost when traffic grows or WooCommerce is added?

A brochure site with a blog is mostly static pages. A cache can serve those pages without running PHP, so extra traffic costs very little. WooCommerce changes that, because carts, checkouts and account pages are different for every visitor and cannot be served from a shared page cache.

Uncacheable pages: /cart/, /checkout/ and /my-account/ run PHP and query the database for every visitor. On a VPS that means more memory. On Kinsta or WP Engine it can mean more PHP workers or a higher tier.
Object caching: Redis cuts repeated database queries on dynamic pages. Self-hosted, it is one more service to run and keep an eye on. On managed plans, it is sometimes a paid add-on.
Order storage: WooCommerce 8.2 made High-Performance Order Storage the default for new stores. Older stores that still keep orders in wp_posts should migrate before order volume makes the database slow.
Scheduled tasks: the default wp-cron only runs when someone visits the site, which is unreliable for subscription renewals. Set DISABLE_WP_CRON and call wp cron event run --due-now from a real system cron instead.
Payment compliance: hosted payment fields from Stripe or PayPal keep card data off your server and usually put you in the simplest PCI DSS questionnaire, SAQ A. Collecting card numbers yourself makes compliance far more work.
Extension licences: shipping, tax and subscription plugins add renewal lines, often several at once.

The pattern over three years is clear. Traffic growth by itself barely moves a self-hosted budget, but it pushes managed plans up through visit limits. Adding WooCommerce raises the cost on both sides. For a store, the cost of downtime now includes lost sales, which makes paying for managed support easier to justify.

Where to run self-hosted WordPress: VPS, home server or personal cloud server

Once you decide to self-host, the next choice is where the server lives. That choice decides how much of the stack you manage below WordPress itself. It is the second-largest time factor after your plugin list.

Option	What you manage	Main tradeoff
VPS (Hetzner, DigitalOcean, OVHcloud)	OS, web server, PHP, database, TLS, firewall, backups	Full control and a public IP, but every layer of the stack is your job
Home server	Hardware, OS, networking, power, plus everything a VPS needs	Hardware you already own, but CGNAT, blocked ports 80 and 443, and slow home upload speeds can rule it out
NAS (Synology, QNAP)	Container or package setup, router forwarding, DNS, TLS	Convenient if you already own one, but a public store on the same box as company files mixes risks
Managed personal cloud server	WordPress, plugins, content, off-site backups	Dedicated server with one-click app installs and HTTPS handled, less control over the underlying system
Shared hosting	WordPress and plugins only	Low effort, but noisy neighbours and limited PHP settings

For the first four options, running WordPress in containers is the most portable approach. The official wordpress Docker image plus a mariadb container, with wp-content and the database on named volumes, can be moved between a VPS, a NAS and a dedicated server without reinstalling anything.

Pick based on who owns the pager. If one founder is comfortable with Linux, a VPS is the most flexible choice. If neither wants to manage networking and certificates, choose an option that handles those layers. Otherwise, the hours you save on hosting fees will go into troubleshooting DNS and TLS. A home server works for staging but is a risky place for a store that needs to stay online.

Data sovereignty and hosting location for a small WordPress site

Even a small WordPress site handles personal data: contact form entries, comment IP addresses in wp_comments, newsletter signups and, with WooCommerce, full names and addresses on every order. If you serve customers in the EU, the GDPR requires you to know where that data is stored and who can access it.

Advantages of controlling the hosting location:

Known jurisdiction: you choose the country the server runs in, instead of reading it from a provider's list of subprocessors.
Shorter processor chain: fewer companies to cover with a data processing agreement under GDPR Article 28.
Direct access to logs: web server and database logs stay under your control, and you can hand them over during an audit or a breach investigation.
Exit without permission: a full copy of the database and wp-content is always yours, whatever happens to a billing account.

Checklist before you pick a host:

Region choice: Kinsta and WP Engine let you choose a data centre region on their cloud providers. Check whether your WordPress.com plan gives you any say over location.
Third-party calls: Gravatar, remotely loaded Google Fonts and embedded analytics send visitor data elsewhere. A Munich court fined a site owner in 2022 for loading Google Fonts remotely, so host fonts locally.
Email path: order and form emails go through your SMTP provider, which becomes a processor too.
Backup location: an off-site bucket in another country moves the data just as much as the server does.
Retention: delete old form entries and inactive customer accounts on a schedule rather than keeping them forever.

Self-hosting does not make you compliant on its own. What it gives you is a shorter, clearer list of places your data goes, and a short list is easier to audit.

How hard is it to switch between self-hosted and managed WordPress later?

It is easier than with most platforms, because WordPress is the same software everywhere. A site is a database plus a wp-content folder, and a migration moves both. The difficulty comes from what each host adds on top of WordPress and from anything the site does while the move is in progress.

Migration tools: Duplicator, All-in-One WP Migration and Migrate Guru package the site into one archive. WP Engine and Kinsta also offer their own migration tools or assisted moves, which lowers the cost of moving onto them.
URLs and serialized data: if the domain or path changes, use wp search-replace rather than raw SQL. It handles serialized PHP arrays that a plain find-and-replace would corrupt.
Host-specific code: managed hosts add their own must-use plugins and caching layers in wp-content/mu-plugins. Remove them after moving out, or they will fail silently or conflict with your own cache.
DNS cutover: lower the DNS record TTL to 300 seconds a day before the move, so visitors reach the new server within minutes instead of hours.
WooCommerce orders: orders placed on the old server after the export are lost. Schedule a short maintenance window or freeze checkout during the final sync.
Email and integrations: SPF and DKIM records, payment webhooks and API keys stored in wp-config.php all need checking on the new host.

For a two-person startup, this means the first hosting decision is not permanent. A site with a few plugins can move in an afternoon. A store with years of orders and many extensions needs a staged rehearsal. The practical lesson for your three-year budget: avoid host-only features you cannot rebuild elsewhere, and leaving stays cheap.

Which option fits your startup: recommendations by profile

Use your team's skills, your revenue risk and your expected growth to choose. The hosting price alone should not decide it.

Profile	Recommendation	Main reason
Developer founder, marketing site and blog	Self-host on a VPS	Low cash cost, and the upkeep uses skills the founder already has
Two non-technical founders, service business	WordPress.com Business	Fixed yearly cost, no server work
WooCommerce store with daily orders	Kinsta or WP Engine	Staging, backups and support are worth more than one outage
Content site expecting viral spikes	Self-host behind Cloudflare	Traffic spikes do not trigger visit overages
EU startup collecting customer data	Self-host in a region you choose	A shorter list of data processors, and logs you control
Pre-product-market-fit team likely to pivot	Self-host with free plugins only	No yearly commitments to cancel
Agency-style team running several client sites	Managed multi-site plan	One dashboard and support contract across every site

Next steps:

If you self-host:

Deploy the wordpress and mariadb containers with named volumes.
Set up off-site backups and test one restore before launch.
Put a fixed monthly maintenance window in both founders' calendars.

If you choose WordPress.com Business:

Price the three-year total using renewal rates, not the introductory price.
Check that every plugin you need is allowed on the plan.
Schedule a regular full export stored outside WordPress.com.

If you choose Kinsta or WP Engine:

Estimate year-three visits, including bots, and pick that tier.
List every add-on and its monthly price.
Keep your own off-site copy of the database and wp-content.

Netdata Alerts in Week One: Which to Keep, Tune or Silence, and How to Route Them to Slack, Discord and ntfy

John — Tue, 15 Sep 2026 07:06:26 +0000

Keep Netdata's stock alerts for disk space, memory pressure, OOM kills and failed systemd units exactly as they ship. In the first week, raise the thresholds or lengthen the delays on the CPU, network error and TCP reset alerts, and silence the ones for hardware or services you don't run. Send CRITICAL alerts to ntfy so they reach a phone, and send WARNING alerts to a Slack or Discord channel that someone reads once a day. That leaves a small team with a handful of real alerts a week, not dozens.

TL;DR

Solo on-call founder with two VPS nodes, e.g. a SaaS API plus its database box: route CRITICAL to ntfy and WARNING to Discord, because one phone and one channel is all two people can realistically watch.
Team that already lives in Slack, e.g. a two-person agency using Slack with clients: use a private Slack channel for WARNING and ntfy for CRITICAL, because paging through the same app you chat in gets muted within days.
Docker-heavy single host, e.g. twelve containers on one mini PC: tune the per-container cgroup CPU and memory alerts first, because they produce most of the first-week noise on busy hosts.
Parent-child streaming setup, e.g. one parent collecting from four children: run health checks and notifications on the parent only, so one config decides what reaches you and each alert isn't sent several times.
Production database owner, e.g. a single PostgreSQL primary: keep the connection, disk and replication alerts at stock or tighter, because those failures cost data, not just uptime.
Staging or hobby node, e.g. a preview environment rebuilt weekly: set to: silent for most alerts on it and keep the dashboard, because alerts on a box you routinely destroy teach you to ignore alerts everywhere.

The central tradeoff is simple: every alert you silence is an outage you might hear about from a customer, and every alert you keep but ignore trains you to miss the one that matters.

Why do Netdata's stock alerts fire so often in the first week?
How Netdata's health configuration is structured on disk
Which stock alerts should you keep exactly as shipped?
Which alerts are worth tuning rather than deleting?
Which alerts can a small team silence outright?
How do you change thresholds, delays and hysteresis without losing them on upgrade?
Anomaly detection versus fixed thresholds for a two-person rotation
How do you send Netdata alerts to Slack, Discord and ntfy?
Splitting pages from notices with roles and severities

Why do Netdata's stock alerts fire so often in the first week?

Netdata ships with hundreds of alert definitions. They are written to be useful on any Linux machine, so they aren't tuned to yours. A new install turns on almost all of them at once, before you've seen what normal looks like on your hosts. Most first-week noise has a few predictable causes.

Auto-discovery attaches alerts to everything it finds: every collector that detects a service, disk, interface or container brings its own alerts. You never explicitly asked for any of them, so it isn't obvious where a notification comes from.
Templates multiply across instances: one definition that watches network interfaces runs separately against eth0, docker0 and every veth pair Docker creates. A host with twenty containers can raise the same warning many times over for traffic that is perfectly normal.
Thresholds assume a generic server: the stock 10min_cpu_usage alert warns when average CPU over ten minutes crosses 85% and goes critical above 95%. A small VPS that runs a nightly build or backup crosses that line on schedule, every night.
Internet-facing noise looks like failure: the TCP reset and dropped-packet alerts react to port scanners and bots hitting a public IP. On a box exposed to the internet, that is background activity, not a sign of trouble.
Short-lived containers churn state: containers that start, stop and get rebuilt during deploys make their per-container alerts appear, change state and get removed. Each transition can produce a notification.

None of this means the defaults are wrong. It means the first week is when you find out which alerts match how your hosts actually behave, and that is exactly what the next few sections sort through.

How Netdata's health configuration is structured on disk

Before you change any alert, you need to know which files Netdata reads and which files a package upgrade overwrites. The layout differs slightly between install types. On a native package install, stock files live under /usr/lib/netdata/conf.d/ and your changes go under /etc/netdata/. A static install from the kickstart script puts both trees under /opt/netdata/. In the official Docker image, only /etc/netdata is worth mounting as a volume.

Stock alert definitions: /usr/lib/netdata/conf.d/health.d/ holds one .conf file per area, for example cpu.conf, ram.conf, disks.conf and tcp_resets.conf. Upgrades replace these files, so any edit you make there disappears.
Your overrides: /etc/netdata/health.d/ is where your versions go. A file here with the same name as a stock file replaces that stock file completely. Netdata does not merge the two line by line, so copy the whole file before you edit it.
The edit-config helper: run sudo ./edit-config health.d/cpu.conf from inside /etc/netdata. It copies the stock file into place and opens it, so you never start from a blank file by accident.
Alarm versus template: each definition starts with either alarm:, which is tied to one specific chart, or template:, which applies to every chart of a context such as every disk or every container. Most stock noise comes from templates, because a single definition runs against every instance.
Notification settings: /etc/netdata/health_alarm_notify.conf holds webhooks, recipients and roles, apart from the alert logic.
The global switch: the [health] section of netdata.conf turns the health engine on or off for the whole node.

After editing, run netdatacli reload-health to apply the change without restarting the agent.

Which stock alerts should you keep exactly as shipped?

Keep an alert as shipped when the condition it catches ends in data loss, a crash, or a service that stays down until someone steps in. A small team can't afford to learn about these from a customer, and the stock thresholds already leave room before real damage. You can check the exact names on your nodes in the dashboard's Alerts tab or with curl localhost:19999/api/v1/alarms?all.

disk_space_usage and disk_inode_usage: a full filesystem breaks databases, log writers and Docker image pulls all at once. Running out of inodes produces the same "no space left" errors while df -h still shows free space, which is exactly why a separate alert for it is worth having.
oom_kill: this fires when the kernel has already killed a process to free memory. It is not a prediction, so every notification means something on the host just died.
ram_available: this looks at memory the system can actually reclaim, not raw usage. That makes it a better early warning than ram_in_use on hosts where the page cache fills RAM by design.
systemd_service_unit_failed_state: a unit that has crashed and hit its restart limit won't recover on its own. On a host without containers, this is often the only sign a background worker has stopped.
docker_container_unhealthy: this goes off only for containers you gave a HEALTHCHECK, so it is quiet by default and precise when it does fire.
postgres_total_connection_utilization: running out of connections looks like an application outage even though the database itself is healthy.

If one of these turns out noisy, look at the host before you blame the threshold. On a disk that sits at 88% for a week, the fix is cleanup or more storage, not a quieter alert.

Which alerts are worth tuning rather than deleting?

Tune an alert when the condition it tracks does matter, but the stock threshold or time window doesn't fit how your hosts behave. Delete an alert only when the condition never matters to you. The difference is simple: a CPU pegged at 100% for two hours is a real problem, while a CPU at 90% for twelve minutes during a nightly build is not. The fix is to change when the alert fires, not whether it exists.

Alert	Why it is noisy at stock settings	What to change
`10min_cpu_usage`	Scheduled builds, backups and image pulls push the average above the line every day	Widen the `lookup` window to 30 minutes, or add `delay: up 15m` so short spikes never notify
`cgroup_10min_cpu_usage`	Fires for each container, so one busy deploy produces several warnings	Keep CRITICAL, and match only the containers that serve users with a `chart labels` filter
`cgroup_ram_in_use`	Containers with tight memory limits sit near them by design, especially JVM and Node services	Raise the WARNING level for those services, and keep `oom_kill` as the hard signal
`10min_disk_backlog`	Backup and `docker system prune` runs queue I/O for minutes at a time	Lengthen the up delay so it fires only when the backlog lasts longer than your longest backup
`1m_ipv4_tcp_resets_sent`	Port scans against a public IP send resets all day	Keep it as a low-priority notice, never a page, and raise the threshold once you know the baseline
`inbound_packets_dropped_ratio`	Docker `veth` interfaces drop packets during container churn	Limit it to physical interfaces with a `chart labels` match on the device name

Before you change anything, write down the value each alert showed when it fired during the week. Set the new threshold from those notes, not from a guess.

Which alerts can a small team silence outright?

Silence an alert when no value it could reach would make you change anything. There are two ways to do it, and the difference matters. Setting to: silent in the definition keeps the alert running, so its state still shows on the dashboard, but nothing gets sent. Disabling it by name in the [health] section of netdata.conf stops it from being evaluated at all. For a small team, to: silent is usually the better choice, because you can still look back at the history after an incident.

1m_received_traffic_overflow and 1m_sent_traffic_overflow: these compare traffic to the interface's link speed. Virtual NICs on cloud VPS plans often report a speed that has nothing to do with your real bandwidth cap, so the percentage is meaningless.
load_average_1: one-minute load on a small VPS jumps with every cron job. 10min_cpu_usage, once tuned, already covers sustained saturation, so this adds noise without adding a signal.
system_clock_sync_state: on some virtual machines and inside certain container setups, the host or hypervisor manages time. The agent can report "unsynchronised" indefinitely while the clock is actually correct.
used_swap: if you set up swap or zram on purpose so a 2 GB box can absorb spikes, using swap is the plan, not a failure. oom_kill still catches the case where that plan runs out.
Web log redirect and bad-request ratios: on a public site, crawlers and vulnerability scanners generate 3xx and 4xx responses constantly. Your application's error tracking is a better place to catch real client errors.
Every alert on disposable staging nodes: match them with a host label and silence the lot, keeping only disk_space_usage, so a full disk doesn't block the next deploy.

Keep a short comment above each change explaining why you silenced it. Six months from now, that line is the only record anyone will have.

How do you change thresholds, delays and hysteresis without losing them on upgrade?

Copying a whole stock file into /etc/netdata/health.d/ works, but it freezes that file in time. When a later release fixes a stock definition in cpu.conf, your copy keeps the old version forever. A cleaner pattern is to leave stock files untouched, write your own definitions under new names, and turn off only the stock alerts you replaced.

Put overrides in one file: create something like /etc/netdata/health.d/local-overrides.conf and give each definition a new name, for example team_10min_cpu_usage. The name never matches a stock file, so upgrades can't shadow it or be shadowed by it.
Disable only the originals: in netdata.conf, set enabled alarms = !10min_cpu_usage !cgroup_ram_in_use * under [health]. The trailing * keeps every other stock alert active and upgradeable.
Widen the window with lookup: lookup: average -30m unaligned of user,system averages user and system CPU over 30 minutes, so a ten-minute spike can't push it over the line.
Add hysteresis inside warn: warn: $this > (($status >= $WARNING) ? (75) : (90)) raises at 90% but clears only below 75%. That stops an alert flapping around a single value.
Hold notifications with delay: delay: up 10m down 15m multiplier 1.5 max 1h waits ten minutes before telling you, waits fifteen before sending the all-clear, and stretches both delays when an alert keeps flipping, up to one hour.
Version the directory: keep /etc/netdata in a git repository. After each upgrade, diff the stock definitions you replaced against your own versions, so upstream fixes don't pass unnoticed.

Check a change by watching the renamed alert appear in api/v1/alarms?all before you trust it.

Anomaly detection versus fixed thresholds for a two-person rotation

Netdata trains small machine learning models for each metric, right on the agent, and marks every one-second sample as anomalous or normal. The result shows up as an anomaly rate. You can write an alert on it with a lookup that uses the anomaly-bit option, for example the average anomaly rate across a chart over the last 10 minutes. The question is whether that signal should ever wake someone up.

Aspect	Fixed thresholds	Anomaly rate alerts
What triggers it	A value crosses a number you picked, such as disk above 90%	A metric behaves unlike its own recent history
First-week behaviour	Noisy until tuned, but the noise is predictable	Unreliable while models are still training on only a few days of data
Catches well	Hard limits: full disks, exhausted connections, OOM kills	Unusual patterns with no obvious limit, such as a quiet API suddenly doing steady writes
Blind spot	Anything you didn't think to set a threshold for	Slow drift, because a disk filling 1% a day just becomes the new normal
Readable at 3 a.m.	Yes: "disk at 94%" tells you what to do	Rarely: "anomaly rate 40% on 12 charts" tells you to go and look
Resource cost	Negligible	Extra CPU on every node, which is why many parent-child setups turn off `[ml]` on children and let the parent train

For two people sharing on-call, page only on fixed thresholds. Send anomaly rate alerts, if you enable them, to the daily notice channel. Use them as a prompt to open the dashboard, not as proof something is broken. If an anomaly alert keeps pointing at a real problem, turn that into a fixed-threshold alert you can act on.

How do you send Netdata alerts to Slack, Discord and ntfy?

The agent sends notifications through alarm-notify.sh, and every setting it reads lives in health_alarm_notify.conf. Open it with sudo ./edit-config health_alarm_notify.conf from /etc/netdata. It is a long file, but each service needs only a switch, a destination and a default recipient.

Slack: create an incoming webhook for your workspace, then set SEND_SLACK="YES", paste the URL into SLACK_WEBHOOK_URL, and set DEFAULT_RECIPIENT_SLACK to a channel such as #ops-alerts. Each Slack webhook is tied to a single channel, so plan on one webhook for each channel you want to post to.
Discord: in the channel settings, create a webhook under Integrations. Set SEND_DISCORD="YES", put the URL in DISCORD_WEBHOOK_URL, and set DEFAULT_RECIPIENT_DISCORD to the channel name. Discord is often the free option for a small team that doesn't pay for Slack.
ntfy: set SEND_NTFY="YES" and put the full topic URL in DEFAULT_RECIPIENT_NTFY, for example https://ntfy.sh/ followed by your topic. On the public ntfy.sh server, anyone who knows a topic name can subscribe to it, so choose a long random name or run your own ntfy server and set NTFY_ACCESS_TOKEN.
Email as a fallback: SEND_EMAIL depends on a working sendmail on the host. Most small VPS setups don't have one configured, so turn it off rather than letting messages fail without anyone noticing.
Test before trusting: switch to the netdata user with sudo su -s /bin/bash netdata, then run /usr/libexec/netdata/plugins.d/alarm-notify.sh test. It sends a WARNING, a CRITICAL and a CLEAR to every destination you enabled.

If the test works from a terminal but real alerts never arrive, check that the netdata user can reach the internet through your firewall.

Splitting pages from notices with roles and severities

Every alert definition has a to: line naming a role, and most stock alerts use to: sysadmin. In health_alarm_notify.conf, each role maps to recipients for each service. Put those two ideas together and you get a two-tier setup: a short list of alerts that can wake a person up, and everything else collected for a daily look.

Role mappings: role_recipients_slack[sysadmin]="#ops-alerts" sends every sysadmin alert to that channel. Roles you don't map fall back to the DEFAULT_RECIPIENT_ value for each service, so a role you forgot to map still reaches someone.
The |critical modifier: add it to a recipient, as in role_recipients_ntfy[sysadmin]="https://ntfy.sh/<topic>|critical", and that destination receives only CRITICAL alerts and the CLEAR that follows. WARNING alerts still reach Slack or Discord, but they never buzz a phone.
A dedicated pager role: in your override file, set to: pager on the handful of alerts that justify waking someone, such as disk_space_usage, oom_kill and database connection exhaustion. Map pager to ntfy only, and a threshold edit elsewhere can never quietly add to the page list.
Keep a written record in chat: map pager to Slack or Discord as well as ntfy. The phone push gets attention, and the channel keeps a timestamped history both of you can scroll back through the next morning.
Per-person routing: with two people, give each their own ntfy topic and alternate which one sits in role_recipients_ntfy[pager] week by week. That is a simple on-call rotation without a paging SaaS.
Database and web roles: stock database alerts use roles like dba. Map them explicitly, or they fall through to your defaults and page you with the wrong priority.

Run alarm-notify.sh test "pager" after every mapping change.

rclone mount vs rclone bisync after Dropbox: the real latency, RAM and conflict numbers

John — Sat, 12 Sep 2026 07:06:51 +0000

Neither one alone reproduces the Dropbox desktop client, and the honest answer is that you run both. An rclone mount with --vfs-cache-mode full gives you a folder that looks complete in your file manager, but every first read of an uncached file costs a network round trip, and nothing is available offline until you have opened it. rclone bisync gives you genuine local copies with local disk latency and true offline access, at the cost of a scheduled run, a mandatory first --resync, and conflict files you have to resolve yourself. Split your data: bisync the working set you edit daily, mount the archive you only read.

TL;DR by reader profile

Solo dev with one laptop and a home server, 40 GB of code and notes: run bisync on a 5 minute timer for the working set, because local disk latency and offline access matter more than seeing every remote change instantly.
Photographer or media hoarder with 2 TB on object storage: run a single mount with --vfs-cache-mode full and a capped cache, because copying 2 TB to every device defeats the point of moving off the hosted plan.
Developer who builds inside the synced folder: never point a compiler, a node_modules tree or a Git repository at a mount, because per file stat and open calls turn a 20 second build into minutes.
Someone with two laptops and a phone editing the same files: bisync each laptop against the remote and expose the server folder over rclone serve webdav, because bisync is two way between exactly two ends, not a mesh.
Anyone on a metered or flaky connection: choose bisync with --check-access and a low --transfers value, because a mount reacts to a dropped link by returning I/O errors mid save.
Team of one who wants the sharing links back: accept that neither tool replaces them, and plan a second front end for public links rather than stretching rclone into the job.

The central tradeoff is simple: a mount buys you unlimited apparent capacity and pays for it in latency and fragility, while bisync buys you local speed and offline safety and pays for it in disk space, scheduling and conflict resolution.

What does an rclone mount actually replace when the Dropbox client is gone?
How does rclone bisync differ from a mount in day to day use?
Which VFS cache mode should you run: off, minimal, writes or full?
How much RAM and disk does an rclone mount really consume?
What latency do open, stat and write calls show against a local disk baseline?
How fast do remote changes appear, and what do dir-cache-time and poll-interval control?
How do you size the VFS cache without filling the disk?
Conflicts, renames and deletes: what bisync does and what the first resync costs
What breaks when the network drops or the provider rate limits you?
Running the mount under systemd and recovering it after a reboot
Where should the mount run: home server, NAS, VPS or managed Personal Cloud Server?
How do you reach the same folder from a phone or a second laptop?

What does an rclone mount actually replace when the Dropbox client is gone?

A mount replaces the appearance of the Dropbox folder, not its behaviour. rclone mount remote:files ~/Cloud --vfs-cache-mode full presents a FUSE filesystem where ls returns the full listing within milliseconds once the directory cache is warm, so your file manager, your editor's open dialog and find all behave normally. What changes is what happens underneath each file you touch.

Directory listings become remote metadata calls: the first ls on a cold directory hits the provider API, and rclone holds that listing for the --dir-cache-time window, which defaults to 5 minutes.

File contents arrive on demand: opening a 400 MB video streams it over the network rather than reading it from disk, and with --vfs-cache-mode full the bytes land in the cache directory only after that first read completes.

Writes go through a local staging file: in full or writes mode your application writes to the cache, the file closes, then rclone uploads it, so a save that returns instantly can still be in flight seconds later.

Offline access disappears by default: the Dropbox client kept every non selective file on disk, while a mount shows you names you cannot open when the link is down.

Selective sync has no equivalent: you approximate it with --exclude filters or a second mount, not with a checkbox.

The practical consequence is that a mount is excellent for an archive you read occasionally and poor for a directory you compile in. Treat it as a network drive with a good cache, which is what it is.

How does rclone bisync differ from a mount in day to day use?

Bisync is a scheduled job, not a filesystem. You run rclone bisync ~/Cloud remote:files from cron or a systemd timer, it compares both sides against a stored listing pair in ~/.cache/rclone/bisync/, and it copies the differences in both directions. Between runs, your local directory is an ordinary folder on an ordinary disk.

Behaviour	rclone mount	rclone bisync
Where files live	Cache directory, populated on first read	Full local copy of everything in scope
Offline access	Only what is already cached	Every file, always readable and writable
Change propagation	Within the `--dir-cache-time` window, 5 minutes by default	Only when the next scheduled run fires
Disk required	Whatever you cap the cache at	At least the size of the synced tree
Failure mode	I/O errors reaching the application mid operation	A run exits non zero and leaves both sides untouched
Conflicting edits	Last writer wins silently	Conflict files written to both sides

The scheduling interval is the knob that defines the experience. A 5 minute timer means a file you save on the server appears on the laptop within 5 minutes and a deletion propagates on the same clock. A 60 minute timer halves your API calls and doubles the window in which the two sides can diverge.

The other practical difference is scope. A mount covers a whole remote cheaply because it stores almost nothing. Bisync covers only what you are prepared to store twice, which is why the working set versus archive split is the decision that shapes everything else.

Which VFS cache mode should you run: off, minimal, writes or full?

There are four modes and only two of them are realistic for a folder you actually work in.

--vfs-cache-mode off: files are read and written straight through, and any application that opens a file for both reading and writing fails, which rules out most editors, SQLite databases and Office formats.

--vfs-cache-mode minimal: files opened read write are staged on disk, everything else streams, so vim saves work but a seek backwards in a large file still costs a fresh range request.

--vfs-cache-mode writes: all writes go to the cache first and uploads happen on close, while reads stream from the remote every time, which suits a machine with a small disk and an append heavy workload such as a log or backup target.

--vfs-cache-mode full: reads and writes both use the cache, sparse chunks are kept, and a second open of the same file costs local disk latency instead of a round trip, which is the only mode that feels remotely like the old desktop client.

Run full unless the disk under the mount cannot spare the space. That disk is the real constraint, so decide where the mount lives before you tune the flags: a home server with a spare SSD, a NAS, a self managed VPS with a small volume, or a managed host. 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, budget cache space on the same box that runs rclone mount, because the cache is local by definition and cannot be pushed onto the remote.

How much RAM and disk does an rclone mount really consume?

Memory use is not a single number, it is a formula with three terms you control.

A base process footprint: a single mount process with nothing open is small enough that it is not the term you should worry about, and you can confirm yours with ps -o rss= -C rclone.

Read buffers, one per open file: --buffer-size defaults to 16 MiB and is allocated per file handle in use, so ten files open simultaneously is on the order of 160 MiB of buffers before anything else. Set --buffer-size 0 on a small box and accept more round trips.

Cached directory metadata: rclone keeps listings in memory for the --dir-cache-time window, and the cost scales with the number of objects you have walked, not their size, so a find across 500,000 files is what turns a quiet mount into a hungry one.

Upload concurrency: --transfers defaults to 4, and each in flight upload of a large file holds chunk buffers whose size depends on the backend, which is why a bulk copy into the mount is the peak you should size for.

Disk is simpler and more dangerous. With --vfs-cache-mode full the cache directory, by default under ~/.cache/rclone/vfs/, grows to hold every file you have read or written until an eviction rule removes it. Read one 40 GB video and you have written 40 GB locally. Two limits matter: --vfs-cache-max-size caps total bytes, and --vfs-cache-max-age defaults to 1 hour and expires idle entries. Leave both unset and the cache is bounded only by the filesystem it sits on.

What latency do open, stat and write calls show against a local disk baseline?

Measure your own numbers rather than trusting anyone's table, because the dominant term is the round trip time between your server and the provider region. Get the baseline first with ping to the endpoint host, then run strace -c -f ls -l in a cold directory on the mount and the same command in a bisync folder. The difference you see is the entire argument of this article.

Cold stat on a mount: costs at least one round trip if the parent directory is not cached, which is why a single ls -l on 2,000 files can take seconds while the same command on local disk returns in milliseconds.

Warm stat on a mount: served from kernel attribute cache and rclone memory, where --attr-timeout defaults to 1s and controls how long the kernel trusts what it was told.

First open and read: one round trip plus transfer time for the requested range, so latency scales with file size on a streaming read and with RTT on a small file.

Second open in full mode: local disk latency, because the bytes are already in the cache directory.

write followed by close: the write returns at local speed, then close blocks until the upload starts, so a save of a 2 MB file feels instant and a save of a 2 GB file does not.

Small files are where mounts lose decisively. A tree of 10,000 source files under 4 KB each turns into 10,000 metadata operations, and no cache mode fixes the first pass. A bisync folder pays that cost once per run, in the background, with --checkers running them in parallel.

How fast do remote changes appear, and what do dir-cache-time and poll-interval control?

Two independent timers decide when a file written elsewhere shows up in your mount, and confusing them is the most common reason people think the mount is broken.

--dir-cache-time, default 5m0s: the maximum age of a cached directory listing. When it expires, the next access re-lists that directory from the remote. Raise it to 1000h and you cut metadata calls to almost nothing, at the price of never noticing outside changes on your own.

--poll-interval, default 1m0s: how often rclone asks the backend for a change feed and invalidates only the affected directories. This is the mechanism that makes a long --dir-cache-time safe.

Backend support is the catch: polling depends on the backend implementing change notification. Google Drive, Dropbox and OneDrive do. Plain S3, Backblaze B2 and SFTP do not, and on those the only thing that refreshes a listing is --dir-cache-time expiry.

Manual invalidation as the escape hatch: start the mount with --rc and run rclone rc vfs/refresh recursive=true or rclone rc vfs/forget dir=path/to/folder to force a re-list immediately.

The practical recipe for a polling capable backend is --dir-cache-time 1000h --poll-interval 15s, which gives you near instant propagation and almost no idle API traffic. On a non polling backend such as B2, keep --dir-cache-time between 1m and 5m if you need freshness, and accept the listing calls, or leave it long and drive refreshes from whatever process writes the files.

None of this applies to bisync, where propagation is exactly your timer interval and nothing else.

How do you size the VFS cache without filling the disk?

Start from the largest single file you will ever write, not from your total data. The cache must hold a complete copy of any file being written, so --vfs-cache-max-size is a target for eviction, not a hard ceiling: an in use or not yet uploaded file is never evicted, and the directory can exceed the cap while an upload is in flight.

Workload	Settings to start with	What you give up
Archive you mostly read, 500 GB SSD	`--vfs-cache-max-size 100G --vfs-cache-max-age 720h`	100 GB of disk permanently committed
Small VPS with a 40 GB volume	`--vfs-cache-max-size 8G --vfs-cache-max-age 24h`	Repeat reads of large files go back to the network
Write heavy target, backups or logs	`--vfs-cache-mode writes --vfs-cache-max-age 1h`	Every read is a fresh download
Laptop with limited space	`--vfs-cache-max-size 4G --vfs-cache-poll-interval 30s`	More frequent eviction churn on the disk
Large file editing, video or disk images	Cache at least 2x the biggest file	The cap is advisory during writes

Eviction is least recently used and runs on --vfs-cache-poll-interval, which defaults to 1m0s. --vfs-cache-max-age defaults to 1h0m0s, so out of the box a file you read this morning is gone by lunchtime. Put the cache somewhere you control with --cache-dir /var/cache/rclone rather than leaving it under ~/.cache, and alert on that path at 85 percent full. Also watch --vfs-write-back, default 5s, which is how long a closed file waits before upload starts.

Conflicts, renames and deletes: what bisync does and what the first resync costs

The first run is not optional and it is not symmetric. rclone bisync ~/Cloud remote:files --resync establishes the baseline listings that every later run compares against, and by default path1 wins for files that differ on both sides. Run it on a copy first, or with --dry-run, because a careless --resync is the one command in this article that can overwrite good data.

Conflicts are renamed, not merged: when both sides changed since the last run, the default --conflict-resolve none keeps both and appends ..path1 and ..path2 to the filenames, leaving you to pick. Set --conflict-resolve newer if you would rather it decide, and --conflict-loser delete if you do not want the loser kept.

Deletes propagate, with a brake: --max-delete defaults to 50, meaning a run aborts if more than 50 percent of files on either side would be deleted, which is what saves you when a drive fails to mount.

Renames cost a full transfer: a renamed directory is seen as deletions plus new files, so moving a 20 GB folder re-uploads 20 GB.

A failed run leaves a marker: bisync writes its listings under ~/.cache/rclone/bisync/ and refuses to continue after an abort until you either fix the cause or re-run with --resync, which is deliberate.

Access checks catch empty mounts: --check-access requires an RCLONE_TEST file present on both sides and aborts if one is missing.

Budget the resync as a one time full comparison of both trees. On 40 GB it is minutes. On 2 TB it is the reason you chose a mount instead.

What breaks when the network drops or the provider rate limits you?

A mount fails loudly inside your applications. Bisync fails quietly in a log file. That difference matters more than any throughput number.

The mount returns I/O errors to whatever is reading: a dropped link mid read surfaces as EIO, and an editor that was saving may leave a partial file. If the FUSE process itself dies you get "transport endpoint is not connected" until you run fusermount -uz ~/Cloud and remount.

Pending uploads survive in the cache: with --vfs-cache-mode full, files closed but not yet uploaded stay in the cache directory and retry, so a reboot before the upload completes is the real risk, not a brief outage.

Retry behaviour is tunable: --low-level-retries defaults to 10 and --retries to 3, while --timeout defaults to 5m0s and --contimeout to 1m0s. Lower the timeouts on a flaky link so failures surface in seconds rather than minutes.

Rate limits show up as 403 and 429 responses: Google Drive enforces a 750 GB per day upload cap per account, and hitting it stops uploads for the rest of the day regardless of your flags. Use --tpslimit 10 to stay under per second quotas, and check rclone mount --stats 30s output or the log for pacer messages.

Bisync stops rather than guesses: a run that cannot reach one side aborts with a non zero exit code and no changes, which is safe but silent, so wire the timer to alert on failure with OnFailure= in the systemd unit.

Neither tool queues work indefinitely for you. A mount buffers only what fits in its cache, and bisync simply waits for its next scheduled attempt.

Running the mount under systemd and recovering it after a reboot

A mount started from a shell dies with the shell. Write a unit file, /etc/systemd/system/rclone-mount.service, and treat the mount as infrastructure.

Wait for the network, not just for boot: set After=network-online.target and Wants=network-online.target, because a mount that starts before DNS resolves fails immediately and leaves an empty directory that applications will happily write into.

Use Type=notify: rclone signals systemd once the mount is actually ready, so dependent services do not start against a directory that is not mounted yet.

Always set an ExecStop: ExecStop=/bin/fusermount -uz /home/you/Cloud handles the stale endpoint case on restart, and pair it with Restart=on-failure and RestartSec=10 so a crash recovers without you.

Decide who can see the mount: by default only the user running rclone can read it, and exposing it to Docker containers or other accounts needs --allow-other, which requires user_allow_other in /etc/fuse.conf.

Run bisync from a timer, not cron: a .timer with OnUnitInactiveSec=5min will not overlap runs the way cron can, and OnFailure= gives you a place to hang an alert.

If you run the mount as your login user rather than root, enable loginctl enable-linger $USER or the unit stops when you log out. Where this box lives is your call: a home server, a NAS, a self managed VPS, or a managed host. 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. On any of them, verify recovery honestly by rebooting and then running findmnt /home/you/Cloud before you trust it with a working set.

Where should the mount run: home server, NAS, VPS or managed Personal Cloud Server?

Put the mount where the bandwidth and the cache disk are, then reach it from your laptop over the LAN or a tunnel. Mounting the same remote independently on four devices multiplies API calls and gives you four caches to keep warm.

Location	Best for	Main constraint
Home server with a spare SSD	Large caches and 24/7 bisync timers	Your upload link caps every write to the remote
NAS appliance	Reusing disks you already own	Vendor kernels may not load `fuse`, and package availability is limited
Self managed VPS	Fast symmetric bandwidth near the provider region	Small volumes force a low `--vfs-cache-max-size`, and egress may be billed
Managed Personal Cloud Server	One click app installs and public HTTPS without port forwarding	You work within the app store and container model
The laptop itself	A single device setup with no server	Cache and mount vanish when the lid closes

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, with each app reachable on a public HTTPS subdomain through NSL.SH mesh routing.

Two details decide more than the category. First, if rclone runs inside a container, a FUSE mount needs --device /dev/fuse and --cap-add SYS_ADMIN, and the mount is visible only inside that container unless you add --allow-other and a shared bind mount. Second, colocation matters: a VPS in the same region as your bucket turns a 100 ms round trip into single digit milliseconds, which is the single largest latency win available to you.

How do you reach the same folder from a phone or a second laptop?

Do not mount the remote a second time. Re-export the copy you already have on the server, and serve the bisync folder rather than the mount so you are not stacking one cache on top of another.

rclone serve webdav /srv/cloud --addr :8080 --user you --pass secret: the broadest client support, readable by Finder, Windows Explorer, and mobile apps on both platforms, at the cost of chatty per file requests over a slow link.

rclone serve sftp: better for large files and lossy connections, and it gives you an existing client on every laptop through sshfs or an SFTP capable file manager.

rclone serve s3: useful when the consumer is a backup tool or a script that already speaks the S3 API rather than a human with a file browser.

Samba on the same directory: the right answer when the second laptop is on the same LAN and you want native Finder or Explorer behaviour including proper file locking.

A second bisync pair on the other laptop: the only option that gives that machine genuine offline copies, and the reason to remember that bisync links exactly two endpoints, so three devices means each syncs to the remote, not to each other.

Two rules keep this safe. Never expose rclone serve directly to the internet on a plain HTTP port: put it behind a reverse proxy with TLS, or reach it over a WireGuard or Tailscale tunnel so the listener stays on a private interface. And pick one writer per file where you can, because WebDAV clients and bisync runs editing the same path within the same 5 minute window is exactly how you manufacture conflict files.

Should Ntfy Run on the Home Server It Is Meant to Warn You About? Where Alerts Fail and How to Avoid It

John — Thu, 10 Sep 2026 07:05:48 +0000

Yes, if Ntfy is your only way of getting alerts, it should not run only on the server it watches. A power cut, an ISP outage, a kernel panic or a dead Docker daemon takes down the thing that failed and the thing that would tell you, in the same moment. Self-hosting Ntfy on your home server is still fine for app-level messages such as "backup finished" or "cron job failed", because the host is alive to send them. For "my server is down" alerts, something outside that box has to notice the silence and send the message.

TL;DR

Single-box homelabber (one mini PC running Jellyfin, Nextcloud and Ntfy): keep the local Ntfy for job notifications and add an external heartbeat check, because a dead host cannot report its own death.
Privacy-first tinkerer who refuses third-party relays: run a second Ntfy instance on a small VPS or at another site, because being independent of other services only helps if the second instance fails separately.
Backup-and-cron notifier who only wants "job done" messages: self-host on the same server and switch to "alert me when the message does not arrive" logic, because a missing success message is the real signal.
iPhone user: sending critical alerts to ntfy.sh with an access-protected topic costs you little, because a self-hosted server already hands iOS push wake-ups to the ntfy.sh upstream relay.
Two-site owner (home server plus a NAS at a relative's house): have each site host the Ntfy that watches the other, because two homes rarely lose power and internet at the same time.
Freelancer hosting client sites from home: do not rely on a home-hosted Ntfy for uptime alerts at all, because clients will notice the outage before you do.

The core tradeoff is keeping your notification pipeline fully under your control versus having an alert path that survives the exact failure you need to hear about.

What actually goes silent when your home server goes down?
Which outages can a same-host Ntfy still report, and which can it never report?
How Ntfy's message cache and missed-message recovery behave during an outage
Why silence is the signal: dead man's switch patterns for Ntfy alerts
Is ntfy.sh reliable and private enough for critical home server alerts?
Is a second, off-site Ntfy instance worth the extra maintenance?
Where should the Ntfy instance that watches your home server run?
Does the phone side of Ntfy add its own failure points?
Wiring Uptime Kuma, Healthchecks and cron to Ntfy without a shared failure domain

What actually goes silent when your home server goes down?

If Ntfy runs on the box it watches, one failure can shut down three things at once: the Ntfy server, the tools that publish to it (Uptime Kuma, cron scripts, smartd, a UPS daemon) and the cache holding recent messages. How much you lose depends on how the server failed.

Power loss: every process stops at the same moment, so nothing gets a chance to send a last message. A UPS only helps if something like a NUT shutdown hook runs curl -d "on battery" ntfy.example.com/alerts before the battery runs out.
ISP or router outage: the server stays up and local publishing still works. Your phone on mobile data just can't reach Ntfy, so the messages wait until the connection is back.
Kernel panic or hard freeze: no userspace code runs, so no monitor on the host can notice the failure, let alone report it.
Docker daemon crash: the host still answers ping, but the Ntfy container and the Uptime Kuma container stop together. Running Ntfy as a systemd service from the official package instead of in Docker avoids this particular case.
Disk full: Ntfy's cache-file database, logs and your scripts' temp files all fail to write. You usually find out when things start behaving strangely, not from an alert.

None of this depends on the hardware. A home server, a NAS, a self-managed VPS or Yundera are each a single failure domain when they both run the monitored apps and send the alerts about them. 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. The rest of this article is about what to move off that one machine.

Which outages can a same-host Ntfy still report, and which can it never report?

Useful rule: a same-host Ntfy can report a failure only if the kernel, the network stack and Ntfy itself are still running. That covers more than you might expect, but not the failures that matter most.

Failure	Can a same-host Ntfy report it?	Why
One app container crashes	Yes	Uptime Kuma or a healthcheck script sees it and publishes locally
Backup or cron job exits non-zero	Yes	The script can call `curl` on its failure path before it exits
Disk usage passes 90%	Yes	A threshold check fires while there is still room to write
SMART warning from `smartd`	Yes	The disk is degraded, not dead yet
Disk at 100%	Unreliable	The cache database and the sending scripts may fail to write
Docker daemon crash	Only if Ntfy runs outside Docker	Containerised publishers and the containerised server stop together
ISP or router outage	Late	The message is published locally and reaches your phone only after the link comes back
Power loss or kernel panic	Never	Nothing is running to notice or publish

The pattern is clear. A same-host Ntfy is good at "something inside the server went wrong" and useless for "the server itself is gone". The first group is the everyday noise of a homelab, so local Ntfy still earns its place. The second group is the one you set up alerting for in the first place.

This does not change with the platform. A home server, a NAS, a self-managed VPS or Yundera all show the same split. When the bottom rows of the table happen, only an observer running somewhere else can tell you.

How Ntfy's message cache and missed-message recovery behave during an outage

Ntfy is built to cope with clients that disconnect. It stores messages on the server so a phone that was offline can catch up later. That design helps with some outages and does nothing for others, so it is worth knowing exactly how it works.

The cache is only as durable as its configuration: without cache-file set in server.yml, Ntfy keeps messages in memory only, so a container restart after a crash wipes everything that had not been delivered yet. Point it at a SQLite file on a persistent volume, such as /var/cache/ntfy/cache.db.
Messages expire after cache-duration: the default is 12 hours. If your ISP drops overnight and comes back 14 hours later, alerts from the start of the outage have already been deleted before your phone reconnects.
Clients catch up with since: the apps reconnect and ask for everything after the last message ID they saw. You can do the same by hand with curl "https://ntfy.example.com/alerts/json?poll=1&since=all" to check what the server actually holds.
Attachments have their own shorter clock: attachment-expiry-duration defaults to 3 hours, so a log file attached to an alert may already be gone while the text is still there.
Messages sent with X-Cache: no are never stored: that is handy for chatty status pings, but a phone that is offline when one arrives never gets it.
Failed publishes are not queued anywhere: when the server itself is unreachable, a plain curl from a remote script just fails. Unless you add --retry 5 or your own queue, the message is lost before the cache ever sees it.

The cache recovers messages that were delayed. It cannot recover messages that were never published.

Why silence is the signal: dead man's switch patterns for Ntfy alerts

A server that has lost power cannot send a message, so the alert has to come from something that notices the messages stopped. This is a dead man's switch: the server checks in on a schedule, and a watcher somewhere else alerts you when the check-ins stop. Ntfy has no built-in "alert me if no message arrives" feature, so the watcher is always a separate tool.

Hosted heartbeat checks: a crontab line like */5 * * * * curl -fsS -m 10 --retry 3 https://hc-ping.com/<uuid> pings Healthchecks.io every 5 minutes. When a ping is missed and the grace period runs out, Healthchecks sends an alert through its native Ntfy integration to whatever Ntfy server you point it at.
Uptime Kuma push monitors off-site: run Uptime Kuma somewhere other than home and add a monitor of type Push. Your server calls the push URL on a timer, and Kuma marks it down after one heartbeat interval with no call, then notifies you through its Ntfy provider.
Remote pull checks: the same off-site Kuma can probe a public URL or TCP port on your home server. Unlike a push heartbeat, this also catches the case where the server is fine but your ISP has dropped.
Grace periods sized to your maintenance: if a kernel update reboot takes 4 minutes, a 5-minute schedule with a 10-minute grace keeps routine reboots quiet and still alerts you in under a quarter of an hour.
Heartbeats from the end of the chain: put the ping at the end of the backup script, not in its own cron entry. That way it proves the job finished, not only that cron started.

The watcher's location decides everything. If it runs on the home server, it goes silent along with everything else.

Is ntfy.sh reliable and private enough for critical home server alerts?

The public instance at ntfy.sh runs the same open source server you would host yourself, on infrastructure that has nothing in common with your home. That alone makes it a strong candidate for the one alert that has to survive a power cut. The tradeoffs are about trust and limits, not features.

Topic names are the password on anonymous use: anyone who guesses homelab-alerts can read your messages or send you fake ones. A random topic such as hl-7f3k9q2xw8 makes guessing impractical. An account with access tokens, sent as Authorization: Bearer tk_..., closes the hole properly.
Message bodies are readable by the operator: Ntfy does not encrypt messages end to end, so whatever you send sits in plain text in ntfy.sh's cache until it expires. Keep hostnames, IP addresses and file paths out of alert text.
Anonymous use has rate limits: ntfy.sh caps daily messages and attachment sizes per visitor, and the paid ntfy Pro tiers raise those caps and add reserved topics. A heartbeat alert that fires only on failure stays far below any cap. A chatty Uptime Kuma pointed at it may not.
No uptime guarantee on the free service: the public instance is run by the project itself, and free use comes with no guarantee. For a backup alert path that is acceptable, because it only has to be up at the rare moment your home server is down.
The split design works best: send routine job notifications to your local Ntfy and send only "heartbeat missed" alerts from Healthchecks.io to ntfy.sh. That way ntfy.sh sees almost nothing about your systems, while the alert that matters travels outside your home.

For most homelabs, ntfy.sh is private enough for a single, carefully worded outage alert.

Is a second, off-site Ntfy instance worth the extra maintenance?

The Ntfy server is a single Go binary with modest resource needs, so compute is not the cost of a second instance. The cost is that you now run a public service, and a public service needs more care than a LAN-only container.

Task	Same-host Ntfy only	Adding an off-site instance
Access control	Often left open on the LAN	`auth-default-access: deny-all`, then `ntfy user add`, `ntfy access` and `ntfy token add` for every publisher
TLS and proxy	Optional behind the home router	Public HTTPS, `behind-proxy: true` and certificate renewal you have to keep an eye on
Upgrades	One `docker pull binwiederhier/ntfy`	Two instances to keep on the same release
Backups	`cache-file` if you care	`auth-file` as well, or every token has to be reissued after a rebuild
Watching the watcher	Not applicable	The VPS needs its own heartbeat, or it can fail silently for weeks
Phone setup	One server in the app	Subscriptions on two servers, with different topics and credentials
Monthly cost	Electricity you already pay	A small VPS fee, plus your time for patching the OS

The row that usually decides it is watching the watcher. An off-site instance that nobody checks gives you false confidence: the day your home server dies may be months after the VPS quietly ran out of disk.

A second instance makes sense in two cases. The first is when you refuse to let any third-party service carry your alerts. The second is when you already run a VPS for other things, so the patching and backups are already done. If the only reason is one "server down" message, a hosted heartbeat check sending to ntfy.sh gets you the same failure-domain separation with no new server to maintain.

Where should the Ntfy instance that watches your home server run?

Separate two roles before choosing a location. The watcher notices the silence, and the messenger delivers the alert. Both have to survive the failures they are meant to report, and each place you might put them covers a different set of failures.

The same home server: goes down with everything it watches. Keep it for job notifications and nothing that says "the server is down".
A second device on the same LAN: a Raspberry Pi running the arm64 Ntfy build outlives a kernel panic, a Docker crash or a full disk on the main box. It still dies in a power cut unless it has its own UPS, and during an ISP outage it cannot reach your phone either.
A NAS or Pi at a second site: a relative's house gives you separate power and a separate uplink. You depend on their router, their outages and your ability to fix things remotely.
A small self-managed VPS: separate power, network and hardware, at the cost of the public-service maintenance covered in the previous section.
ntfy.sh as the messenger: no maintenance and fully separate infrastructure, with the privacy and rate-limit tradeoffs already covered.
A hosted watcher with any messenger: Healthchecks.io spots the missed heartbeat on its own infrastructure, so even a same-LAN messenger only has to be reachable when it matters.

Before you pick a host, whether a self-managed VPS, a NAS at a friend's house or Yundera, ask three questions. Does it share a power circuit with the monitored machine? Does it share an internet uplink? Does it resolve its name through DNS running on that machine? One "yes" means that failure will silence your alerts again.

Does the phone side of Ntfy add its own failure points?

Getting the alert to the server is only half of the path. The other half is waking a phone that may be asleep, in a pocket, on battery saver or connected to a flaky mobile network, and each platform does that differently.

Client	How it gets woken	What else must be working
Android, Google Play build	Firebase for ntfy.sh topics, its own always-on connection for self-hosted servers	Battery optimisation exemption so Android does not kill the connection
Android, F-Droid build	Always its own connection, no Firebase at all	The same exemption, plus the ongoing foreground service notification
iOS app	Your server sends a poll request through `upstream-base-url: "https://ntfy.sh"`, Apple's push service wakes the app, and the app then fetches the message from your server	ntfy.sh, Apple's push service and your server, all at once
Web app in a browser	Web Push through the browser vendor's push service, once VAPID keys are configured	The browser's push infrastructure and an active subscription
Email forwarding	`X-Email` header, sent through the server's `smtp-sender-addr`	A working SMTP relay and a mailbox you actually check

The iOS row matters most here. If your self-hosted Ntfy is the messenger and ntfy.sh has a problem at the same moment, iPhone alerts show up late or only when you open the app. If your own server is the thing that is down, the app has nothing to fetch even when the wake-up does arrive.

Two cheap fixes cover most of the phone-side risk. Send outage alerts with X-Priority: 5 and allow that max-priority notification channel to override Do Not Disturb in Android settings. Then add a second delivery channel, such as email, for the heartbeat alert only.

Wiring Uptime Kuma, Healthchecks and cron to Ntfy without a shared failure domain

The goal is simple to state: every alert path ends at a messenger that does not share power, network or a Docker daemon with whatever raised the alert. In practice that means deliberately choosing the destination for each tool.

Cron jobs with a fallback URL: wrap your publish call as curl -fsS -m 5 -d "backup failed" http://ntfy.lan/jobs || curl -fsS -m 10 -d "backup failed" https://ntfy.sh/hl-7f3k9q2xw8. When the local container is down, the second call still gets the message out.
Local Uptime Kuma for container health: point its Ntfy notification at your local server with a dedicated health topic and credentials. It is the right tool for "Nextcloud returns 502", and it is fine if it dies along with the host.
Healthchecks.io for host death: in its Ntfy integration, set an off-site server URL and a separate outage topic, with the highest priority for down events and a low priority for recovery events.
A remote Uptime Kuma pointed away from home: the most common mistake is an off-site Kuma whose notification still targets ntfy.yourdomain.com at home. It detects the outage perfectly and then tries to report it to a server that is down.
A boot announcement: a systemd oneshot unit with After=network-online.target that runs ntfy publish outage "host rebooted" tells you that a short power cut happened, even when it ended inside the heartbeat grace period.
One topic per severity: keeping jobs, health and outage separate lets you mute routine noise on your phone without also muting the alert that matters.

Before trusting any path, write down the full chain for each alert: the tool, the host, the messenger, the phone. Any host that appears twice in the same chain is a shared failure domain.

Docmost Content In and Out: What Import, Storage and Handover Really Cost Over Three Years

John — Tue, 08 Sep 2026 07:06:41 +0000

The server bill is the small number. Over a three year client engagement, Docmost costs you far more in billable hours than in infrastructure: the Confluence and Notion imports land at partial fidelity and need human cleanup, the Postgres database and the attachment store grow on two different curves that you must budget separately, and the eventual export or handover is a project of its own rather than a button. Budget the migration in and the migration out as two priced deliverables, treat storage growth as a monthly line item, and the three year picture stops surprising you in month 30.

TL;DR by reader profile

The three person studio moving one client wiki (400 Confluence pages, one space, no SSO requirement): run Community Edition on a single small server and quote the import as fixed price consulting, because the cleanup hours dwarf every other cost in year one.
The fifteen person agency running one Docmost per client (eight active clients, separate databases): standardise one backup and restore runbook across every instance before you add client number three, because per instance operational drift is what turns eight servers into a full time job.
The agency migrating a client off Notion (nested pages, databases, embedded files): plan for a content model translation, not a file copy, because Notion databases have no direct Docmost equivalent and someone has to decide what each one becomes.
The agency that always hands over at project end (build the wiki, transfer it, walk away): write the export path into the statement of work on day one, because a handover priced after the fact is a handover you absorb at cost.
The agency with regulated or public sector clients (data residency clauses in the contract): keep attachments and Postgres in a jurisdiction you can name in writing, because retrofitting storage location after the content lands means a second full migration.
The agency evaluating Docmost against staying on Confluence (renewal in six months, no migration budget yet): price the exit from Confluence and the potential exit from Docmost together, because a one way saving is not a saving.

The central tradeoff: Docmost removes the per seat licence bill, and replaces it with hours you have to spend on import fidelity, storage growth and the eventual handover, so the question is whether your team bills those hours or eats them.

What does three years of Docmost content logistics actually cost?
How faithful is the Confluence import into Docmost?
How faithful is the Notion import into Docmost?
Post import cleanup: the line item agencies forget to quote
How fast does the Docmost Postgres database grow per space?
Redis, websockets and the real time collaboration layer
Local disk or S3 for Docmost attachments over three years?
What has to be in a Docmost backup for the restore to actually work?
Exporting client content out of Docmost when the engagement ends
Handover: transferring a running Docmost instance to the client

What does three years of Docmost content logistics actually cost?

Split the bill into four streams and price each one separately. The infrastructure stream is predictable and small. The human streams are neither.

Cost stream	When it hits	What drives the number
Content in	Month 1 to month 3	Page count, macro and database complexity in the Confluence or Notion source, plus the review pass someone has to do page by page
Running storage	Every month for 36 months	Postgres row growth from page versions and comments, plus attachment volume in local disk or S3 compatible object storage
Operations	Continuous, spiking at upgrades	Backup verification, restore drills, container updates, and the per instance multiplier if each client gets their own deployment
Content out	Final 60 days of the engagement	Export fidelity, attachment relinking, and the credential and DNS work in a handover

Two specifics change the shape of that table more than anything else. The first is edition: Community Edition is AGPL-3.0 and free of seat fees, so a ten client agency pays nothing in licence and everything in hours, while the paid self managed tier converts some of those hours into a per seat subscription with a minimum seat count. The second is instance topology. One Docmost per client means one pg_dump schedule, one restore test and one upgrade window per client, multiplied by however many clients you signed.

Agencies routinely quote the import and forget the other three streams. Over 36 months, the running storage and operations lines usually exceed the import you actually invoiced for.

How faithful is the Confluence import into Docmost?

Structure survives. Anything Confluence rendered dynamically does not.

Confluence stores pages as storage format XHTML full of macro tags in the ac: and ri: namespaces. Docmost stores pages in a ProseMirror based document model. The import is a translation between two different content models, so the failure cases are systematic rather than random. Expect these categories:

Body text, headings, tables and lists: these map cleanly and need no review, because both formats express them as ordinary block nodes.
Macros: expect losses on anything computed at render time, including page trees, include and excerpt macros, JIRA issue tables, status labels and multi column layouts. Each one becomes either static text, a stripped block or nothing.
Attachments and inline images: files come across, but every one carries a URL that pointed at a Confluence attachment path, so links need rewriting to Docmost attachment references before the page reads correctly.
Internal page links: links written against Confluence page IDs or space keys do not resolve in Docmost, and a wiki of 400 pages typically carries several hundred of them.
Page history and comments: treat version history as non transferable and plan to leave the Confluence instance readable for a defined period instead.
Permissions and users: space and page restrictions do not carry an equivalent, so access has to be rebuilt in Docmost spaces by hand.

Two import routes exist. The paid self managed tier ships a Confluence migration tool. On Community Edition you export each space, then feed the resulting HTML or Markdown files into Docmost's file import. The second route costs no licence and considerably more hours.

How faithful is the Notion import into Docmost?

Notion is the harder migration, because Notion is not only a wiki. Half of a typical client workspace is databases, and Docmost has pages and spaces, not databases.

Start from the export. A Notion workspace export as Markdown and CSV produces a zip where every page is a .md file whose filename carries a 32 character page ID appended to the title, nested pages become folders, and every database arrives as a flat .csv next to a folder of its row pages. Docmost imports Markdown and HTML files, so the raw material is compatible. The content model is where the hours go.

Plain pages and nested hierarchies: these translate well, since the folder structure maps onto Docmost's page tree with predictable parent and child relationships.
Databases, views and filters: no equivalent exists. Each one needs a decision: flatten to a static Markdown table, split into one page per row, or leave it behind in Notion.
Relations, rollups and formulas: these are computed properties and export as static values at best, so any client process that depended on a rollup number needs rebuilding elsewhere.
Toggles, callouts, synced blocks and embeds: toggles and callouts degrade to ordinary blocks or blockquotes, and synced blocks duplicate rather than stay linked.
Filenames and internal links: the appended page IDs pollute every page title and every internal link, so budget a scripted rename and link rewrite pass rather than manual editing.
Attachments: files land in per page folders with URL encoded names, and each reference has to be re-pointed at Docmost storage.

Quote a Notion migration as content redesign. Quoting it as a file conversion is how agencies lose money on week two.

Post import cleanup: the line item agencies forget to quote

The import finishes in an afternoon. The cleanup runs for weeks, and it is the part clients see.

Quote it by artefact count, not page count. Before you price the work, extract the numbers from the export itself: how many attachment references, how many internal links, how many macros or database blocks. A grep -c over the exported Markdown gives you a defensible estimate in minutes, and it stops you quoting a 400 page wiki as if all 400 pages were prose.

Cleanup task	Scriptable	What drives the hours
Rewriting internal links	Mostly, with a mapping table from old page ID to new Docmost page slug	Number of links, not number of pages, and whether the source used stable IDs or titles
Re-pointing attachments	Mostly, once the files are uploaded and the new paths are known	Attachment count and how many were embedded inline rather than listed
Replacing lost macros and databases	No	One judgement call per instance, since each needs a decision about what replaces it
Rebuilding the page tree and space split	Partly	How closely the source hierarchy matched how the client actually works
Rebuilding permissions and group membership	No	Number of users, groups and previously restricted areas
Client review and sign off	No	Client responsiveness, which you do not control

Two practical rules. Fix links and attachments with a script before anyone opens the wiki, because manual repair after users start editing means merge conflicts with live content. And put the review pass on the client's calendar with a deadline, since an open ended sign off is an open ended invoice you cannot send.

How fast does the Docmost Postgres database grow per space?

Slower than people expect, because attachments live outside it. Docmost keeps files on local disk or in S3 compatible storage, so the database holds text, structure and metadata only. That makes Postgres the cheap half of your storage bill and the expensive half of your backup window.

Measure rather than estimate. Two queries give you everything you need for a three year projection:

SELECT pg_size_pretty(pg_database_size('docmost'));: run it monthly, log the result, and you have a real growth curve for the client after 90 days instead of a guess.
SELECT relname, pg_size_pretty(pg_total_relation_size(relid)) FROM pg_catalog.pg_statio_user_tables ORDER BY pg_total_relation_size(relid) DESC LIMIT 10;: this tells you which table is actually growing, which is rarely the one people assume.

The drivers, in the order they usually matter:

Page content and its editing state: each page stores structured document content plus collaborative editing state, so an actively edited page occupies more than its rendered word count suggests.
Page history: every saved version is a stored row. A wiki with 40 heavily revised policy pages can hold more history than content.
Full text search indexes: search indexes add a meaningful fraction on top of the base tables, and they grow with content volume rather than with usage.
Comments, mentions and activity records: high traffic client spaces accumulate these steadily even when page count is flat.

The practical consequence: a documentation wiki that would fit in a few hundred megabytes of Markdown becomes a database you must dump, transfer and restore as a single consistent unit.

Redis, websockets and the real time collaboration layer

Docmost needs Redis as well as Postgres. It is configured through REDIS_URL in the environment file and ships as a second service in the standard Docker Compose stack. Understanding what it holds decides two cost questions: how much RAM each client instance needs, and what you can safely leave out of the backup set.

Redis holds transient state, not documents: caching, background job queues and coordination for the collaborative editing layer live there, while the durable page content sits in Postgres. Treat Redis as rebuildable and exclude it from your backup and restore runbook.
The RAM floor is per instance, not per user: one Docmost per client means one Node process, one Postgres and one Redis for each of them. Eight clients is 24 containers, and the idle baseline of that stack, not peak editing load, sets the server you have to rent for 36 months.
Websockets need proxy configuration: real time editing runs over a websocket connection, so any reverse proxy in front of Docmost must pass Upgrade and Connection headers and tolerate long lived connections. Get this wrong and the symptom is edits that vanish on refresh, which clients report as data loss.
Concurrent editors drive connections, not storage: cost scales with how many people have a page open at once, which for agency client wikis is usually a handful, not the whole seat count.
Version pinning matters at upgrade time: pin the Redis and Postgres image tags in your compose file rather than tracking latest, so an unattended pull cannot change the database major version underneath a client instance.

Local disk or S3 for Docmost attachments over three years?

Docmost picks this with one environment variable: STORAGE_DRIVER=local or STORAGE_DRIVER=s3, with the S3 path taking AWS_S3_BUCKET, AWS_S3_REGION and AWS_S3_ENDPOINT, which means any S3 compatible service such as MinIO, Backblaze B2 or Cloudflare R2 works, not only AWS.

Dimension	Local disk volume	S3 compatible object storage
Monthly cost shape	Bundled into the server you already rent, until the disk fills and you resize the whole machine	Metered per GB stored, plus request charges, so it grows smoothly with content
Backup workflow	Attachments are in the same snapshot as everything else, one artefact to restore	Two systems to keep consistent, since the bucket and the database are backed up separately
Growth ceiling	Hard, set by the volume size, and hit without warning when a client uploads a video	Effectively none within an agency workload
Multi client isolation	One directory per instance, trivially separable	One bucket or prefix per client, with per client keys if you want real separation
Exit and handover	Copy a directory, no egress fee	Bucket to bucket copy, and egress charges apply when the data leaves the provider

The decision usually turns on the last row. Local disk keeps the exit cheap and the backup simple, which suits a wiki you expect to hand over. Object storage keeps the growth curve predictable and the server small, which suits instances you will run for the full 36 months.

Whichever you pick, set it before the import. Switching drivers later means moving every file and rewriting every attachment reference, which is the cleanup pass you already paid for once.

What has to be in a Docmost backup for the restore to actually work?

A database dump alone restores a wiki with no files, no working logins and no working configuration. Five artefacts make a restorable set, and the last two are the ones people discover are missing at the worst moment.

The Postgres dump: take it in custom format with pg_dump -Fc -U docmost docmost > docmost.dump rather than plain SQL, because custom format restores in parallel and lets you list contents before restoring. A dump taken while the container runs is fine, since Postgres gives you a consistent snapshot.
The attachment store: the mapped storage volume if you run STORAGE_DRIVER=local, or a versioned copy of the bucket if you run S3. Files and database must come from close enough in time that no page references an attachment that does not exist yet.
The .env file: this holds APP_SECRET, the database URL and the storage configuration. Restore a database with a different APP_SECRET and every session token signed with the old value stops validating, so users are forced back through login and any integration using an issued token breaks.
The compose file with pinned image tags: the version of Docmost that produced the dump is the version that can read it. Restoring a dump into a newer image and hoping the migrations run cleanly is not a recovery plan, it is a second incident.
What to leave out: Redis, container logs and any build cache. Including them inflates every transfer for no recovery value.

Store the set as one dated archive per client. Three files in three places is how partial restores happen.

Exporting client content out of Docmost when the engagement ends

Docmost exports pages and whole spaces to Markdown or HTML, delivered as a zip with attachments included. That covers the contractual obligation to return the content. It does not cover everything the client thinks they are getting, so agree the definition of the deliverable before the final invoice.

Run a sample export first, on one real space: unpack the zip and check exactly which artefacts appear before you promise anything, because what leaves the system is the only fidelity statement worth putting in writing.
Expect content, not context: page bodies and structure travel well in Markdown. Comments, page history, permissions, group membership and user accounts are not part of a content export, so if the client needs those, the deliverable is a database dump instead of a zip.
Check attachment paths in the unpacked zip: confirm that image and file links resolve to the bundled folders rather than to URLs on your server, since links pointing at an instance you are about to decommission are a broken archive with a working preview.
Decide the target format early: Markdown imports cleanly into Obsidian, a Git repository or another Docmost instance. HTML suits an archive that must render without tooling. Exporting to one and converting later costs a second pass.
Budget by space, not by wiki: export, unpack, verify and repackage is a repeatable unit of work per space, so eight client spaces is eight cycles even though the command is the same each time.

Write the export format, the excluded artefacts and the delivery medium into the statement of work at signature. Negotiating scope during an offboarding is a losing position.

Handover: transferring a running Docmost instance to the client

Two shapes exist, and they cost very differently. Transferring the server itself means an account and billing change with no data movement. Rebuilding on the client's own infrastructure means a restore, a DNS cutover and a credential rotation, which is a half day of focused work per instance plus the scheduling overhead of getting the client's IT contact in the same window.

Agree where it lands before you quote: the client may want it on a VPS they rent, on an office server or NAS, or on a managed Personal Cloud Server such as Yundera. 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. Each target implies different work for you, so pin it down at signature rather than at offboarding.
Rebuild, then restore, in that order: bring up the stack with the pinned image tags first, confirm it starts clean, then load the content with pg_restore -d docmost docmost.dump and copy the attachment store. Restoring into a stack that has never booted hides two failures behind one symptom.
Lower DNS TTL to 300 seconds a day ahead: cutover then takes minutes instead of hours, and rollback stays available if the new host misbehaves.
Rotate everything on the way out: database password, APP_SECRET, S3 keys and your own admin account. Your credentials should not survive the engagement.
Hand over a written runbook: backup command, restore command, upgrade procedure and the pinned versions. Without it, you are the unpaid support line for the next two years.

Plex Server Sizing: Quick Sync, Discrete GPU or Raw CPU for 3, 5 and 10 Simultaneous Transcodes

John — Sat, 05 Sep 2026 07:06:31 +0000

For almost every household leaving a streaming subscription behind, a modern Intel CPU with an integrated Quick Sync engine and a Plex Pass is the correct answer, and a discrete GPU is money you do not need to spend. Quick Sync handles multiple concurrent 1080p transcodes on a chip that idles at single digit watts, which matters far more than peak throughput on a box that runs 24 hours a day. Raw CPU transcoding only makes sense if you refuse to pay for Plex Pass, because hardware acceleration is a Plex Pass feature, and Plex's own published guidance of roughly 2000 PassMark points per 1080p transcode and roughly 17000 per 4K transcode shows how quickly software encoding runs out of headroom. A discrete NVIDIA card earns its place in exactly one scenario: heavy simultaneous 4K HDR tone mapping for many remote viewers at once.

TL;DR by reader profile:

The two viewer household (Maya, watching at home while her sister streams from abroad): a low power Intel mini PC with Quick Sync, because two 1080p transcodes barely register on the iGPU and the box costs less to run than the subscription it replaces.
The five stream family (Tom, three kids on tablets plus two remote relatives): a current generation Intel desktop CPU with Quick Sync, an SSD for the transcode directory and 16 GB of RAM, because five concurrent 1080p sessions are comfortably inside one iGPU's budget.
The ten stream sharer (Priya, sharing her library with a wide circle of friends): a Quick Sync host plus either a second server or a discrete NVIDIA card, because concurrent session limits and upload bandwidth bite before the encoder does.
The 4K HDR remux collector (Daniel, direct playing to an Apple TV but transcoding for everyone else): budget for tone mapping specifically, because HDR to SDR conversion is the single most expensive operation Plex performs per stream.
The no Plex Pass holdout (Sam, unwilling to add another recurring charge): buy CPU by PassMark score and plan your library around direct play, because software encoding is the only path open to you.
The existing NAS owner (Elena, already running a two bay unit): check whether your NAS CPU has Quick Sync at all before buying anything, because many ARM based units cannot transcode 1080p reliably even once.

The central tradeoff is this: Quick Sync gives you many cheap, low power streams at good but not perfect quality, while a discrete GPU or a large CPU gives you fewer, more expensive streams that survive the hardest 4K HDR and subtitle cases without falling over.

Why does Plex transcode at all, and how do you stop it?
What does "3, 5 or 10 simultaneous streams" actually mean?
How much CPU do you need for software only transcoding?
How many streams can an Intel Quick Sync iGPU handle?
When does a discrete GPU beat Quick Sync, and where do AMD and Apple Silicon land?
What 4K HDR tone mapping does to your hardware budget
Subtitles: the setting that turns a hardware transcode back into CPU work
How much RAM and what scratch disk does the Plex transcoder need?
How much upload bandwidth do 3, 5 and 10 remote streams need?
What Plex Pass unlocks, and why it changes the hardware maths
Three reference builds sized for 3, 5 and 10 concurrent transcodes

Why does Plex transcode at all, and how do you stop it?

Plex transcodes when the client cannot play the file as it is stored. The server decodes the original video and re encodes it into something the client accepts, and that work is what your hardware budget pays for. Every stream you can push back into direct play costs you nothing but disk reads and bandwidth, so the cheapest transcoding hardware is the transcode you never run.

Four things trigger it, and each has a different fix:

Unsupported codec or container: a Chromecast or a smart TV that cannot decode HEVC or AV1 forces a full video transcode. Storing a second H.264 copy of your most watched titles removes it entirely.
Bandwidth limits set on the client: the Plex app defaults to a quality cap on remote playback, and a 1080p stream capped at 4 Mbps will be re encoded even though the file itself would play. Setting the client to Maximum in Settings, Video Quality, and enabling "Allow direct play" on the server stops it.
Audio the client cannot handle: TrueHD or DTS HD MA on a device expecting stereo AAC triggers an audio only transcode. That path costs a fraction of a video transcode and is usually not worth engineering around.
Subtitles that must be burned into the picture: image based formats such as PGS and VOBSUB cannot be passed through, so the video is re encoded. Text based SRT is handed to the client untouched.

The distinction Plex draws in the Dashboard matters. "Direct Play" means untouched, "Direct Stream" means the container is rewrapped but the video is not re encoded, and "Transcode" is the expensive case. Read that label before you buy anything.

What does "3, 5 or 10 simultaneous streams" actually mean?

A stream count on its own tells you almost nothing. Ten people watching 1080p H.264 files on Apple TVs is a smaller load than two people watching 4K HDV remuxes on old smart TVs. Before you size anything, translate your household into transcode units.

Count what your library and your viewers actually produce:

Concurrent viewers, not total accounts: a library shared with 30 friends might never exceed 4 sessions at once. Open the Plex Dashboard, leave it running for a fortnight, and use the observed peak rather than the account count.
Transcodes, not sessions: if 7 of your 10 sessions direct play, you are sizing for 3 transcodes. This single distinction moves you from a desktop CPU with a discrete card down to a mini PC.
Resolution of each transcode: Plex's published guidance puts a 1080p transcode at roughly 2000 PassMark points and a 4K transcode at roughly 17000, so one 4K session is worth about eight 1080p sessions in software.
Tone mapping and subtitle burn in per stream: these are per stream multipliers, not fixed overheads, so a household with 5 transcodes where 2 need burned in PGS subtitles is meaningfully heavier than 5 clean ones.
Peak overlap window: most households peak for 2 to 3 hours in the evening. Sizing for the 90th percentile of that window rather than the absolute maximum saves real money.

Write the result as a sentence: "peak 5 sessions, of which 3 transcode, 1 of them 4K HDR". That sentence, not the headline number, is what you buy hardware against for the rest of this article.

How much CPU do you need for software only transcoding?

Without Plex Pass, every transcode runs on the CPU, and the sizing rule is arithmetic rather than judgement. Plex publishes PassMark guidance per stream, you look up your candidate chip on cpubenchmark.net, and you divide. Headroom matters because the score is a whole chip figure and your server is also reading disks, scanning the library and running the operating system, so aim to use no more than 70 percent of the total.

Workload per stream	Plex published PassMark guidance	What that means when you shop
720p transcode	Around 1500 points	A modern dual core handles two of these and little else
1080p transcode	Around 2000 points	3 concurrent streams need roughly 6000 points of usable score
4K transcode	Around 17000 points	One stream demands more than most mainstream desktop CPUs deliver in total
5 mixed 1080p streams	Around 10000 points plus overhead	Realistically a 6 core or 8 core desktop chip, not a mini PC
10 concurrent 1080p streams	Around 20000 points plus overhead	Server or high core count workstation territory

Two practical consequences follow. First, 4K software transcoding is effectively off the table: a single stream at roughly 17000 points costs more silicon than five 1080p streams, which is why 4K libraries are built around direct play or hardware acceleration. Second, software encoding scales by core count rather than clock speed, so an older 12 core Xeon can beat a newer quad core for this one job while drawing far more power for every other hour of the day.

How many streams can an Intel Quick Sync iGPU handle?

More than most households will ever ask of it. Quick Sync is a fixed function media engine, so a 1080p transcode consumes engine time rather than CPU cores, and the same job that pins several software threads shows up as a few percent of CPU load. Intel does not publish a Plex specific stream ceiling, and Plex does not either, so treat the engine as your bottleneck and verify with your own Dashboard rather than trusting a forum number.

What actually determines the answer:

Generation, not CPU tier: an i3 and an i7 from the same generation usually carry the same media engine, so paying for more cores buys you nothing for transcoding. Buy the newest generation you can, not the fastest chip in an old one.
Codec support by generation: 7th generation added HEVC Main10 decode, 11th generation added AV1 decode, and 12th generation and later Arc based engines added AV1 encode. A file your engine cannot decode falls back to the CPU silently.
The F suffix trap: Intel CPUs ending in F, such as an i5 14400F, ship with no integrated graphics at all. This is the single most common way people buy a Plex server that cannot hardware transcode.
BIOS and container plumbing: the iGPU is often disabled when a discrete card is installed, and in Docker you must pass the device through explicitly with --device /dev/dri/renderD128. Check with ls /dev/dri before blaming Plex.
No artificial session cap: unlike consumer NVIDIA drivers, Quick Sync imposes no vendor limit on concurrent encode sessions, so you scale until quality or engine time degrades.

When does a discrete GPU beat Quick Sync, and where do AMD and Apple Silicon land?

A discrete card wins in one narrow case: many simultaneous 4K HDR transcodes, where tone mapping and high resolution decode saturate a single integrated media engine. Below that threshold you are buying idle wattage and a PCIe slot you did not need.

NVIDIA, and the session cap you must check: consumer GeForce drivers have historically capped the number of concurrent NVENC encode sessions, with the cap raised across driver generations. Quadro and RTX professional cards carry no such limit, and community driver patches exist for GeForce cards, so confirm the current cap for your exact card before assuming ten streams will run.
AMD Radeon, the least travelled path: Plex supports AMF acceleration, but the tooling, driver behaviour and tone mapping results are less consistently reported than Intel or NVIDIA. Choose it only if you already own the card.
Apple Silicon and VideoToolbox: a Mac mini running Plex Media Server with Plex Pass hardware transcodes through VideoToolbox and idles very low, which makes it a credible small server if you accept macOS as your host operating system.
Where the server itself lives: the acceleration path available to you is decided by the host, whether that is a NAS, a self built home server, a rented VPS or a managed platform. 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 those options rather than replacing the sizing question.
Both engines at once: Plex uses one acceleration path per server, so an iGPU plus a card does not add their capacities together.

What 4K HDR tone mapping does to your hardware budget

Tone mapping is the most expensive per stream operation Plex performs. Converting a 4K HDR10 file to SDR for a client that cannot display high dynamic range means decoding 4K, remapping the colour volume frame by frame, scaling and then encoding. Skip this step and the same file is merely a 4K transcode. Include it and your per stream cost rises sharply, which is why one 4K HDR viewer can dictate a build that five 1080p viewers never would.

It is a Plex Pass feature with a switch: find it in Settings, Transcoder, "Enable HDR tone mapping". Turning it off does not save you money, it just produces washed out, grey looking video on SDR clients.
Generation decides whether it is accelerated: older integrated engines fall back to slower paths for the tone mapping stage even when decode and encode are accelerated, so an eighth generation part and a twelfth generation part are not interchangeable for this workload.
Dolby Vision is the sharp edge: Profile 5 files carry no HDR10 base layer, so transcoding them for a non Dolby Vision client commonly yields the well known green or purple cast. Profile 7 and Profile 8 files with an HDR10 base layer behave predictably.
The cheapest fix is storage, not silicon: keeping a 1080p SDR H.264 copy beside the 4K HDR original removes the operation entirely for every client that would have triggered it.
Host choice does not remove it: a NAS, a home server, a VPS or Yundera all face the same per stream cost, because tone mapping is decided by the file and the client, not the location.

Subtitles: the setting that turns a hardware transcode back into CPU work

You can own the right iGPU, transcode 1080p all evening, and still watch one session collapse because of a subtitle track. Image based subtitles cannot be sent to the client as text, so Plex composites them into the picture, and that burn in step is frequently handled outside the fixed function encoder. The result is a session that shows as hardware accelerated in the Dashboard while CPU load climbs anyway.

Know which formats force it: PGS from Blu-ray sources and VOBSUB from DVD sources are bitmap tracks and always burn in. Styled ASS and SSA tracks often burn in too, because their positioning and effects cannot survive being passed as plain text.
SRT is the format that costs nothing: a plain text track is handed to the client and rendered there, so the video can direct play untouched. A sidecar file named Movie.2019.en.srt beside the video is the simplest way to get one.
Set the client policy deliberately: in Settings, Player, the "Burn Subtitles" option accepts Never, Only image formats and Always. Leaving it on Always converts every text track into an expensive transcode for no benefit.
Convert once instead of burning nightly: running your PGS tracks through OCR in a tool such as Subtitle Edit produces SRT files that serve every future playback. One conversion replaces hundreds of transcodes.
Forced tracks are the hidden repeat offender: files with forced foreign dialogue subtitles trigger burn in on titles you assumed were direct playing, so audit your most watched foreign language content first.

Budget one extra transcode unit for every stream that burns subtitles, then work to eliminate them.

How much RAM and what scratch disk does the Plex transcoder need?

RAM is rarely the constraint. Plex Media Server itself is modest, and a transcode holds working buffers rather than the whole file, so the memory question is really about how much you can spare for a RAM backed scratch directory. The scratch disk is where careless builds get punished, because every transcoding session writes segment files continuously for as long as someone is watching.

Start at 8 GB and choose 16 GB if you use tmpfs: 8 GB runs a small server comfortably, and the second 8 GB exists so you can hand several gigabytes to a RAM disk without starving the operating system's file cache.
Move the transcode directory off the media array: set Settings, Transcoder, "Transcoder temporary directory" to an SSD path or to /dev/shm on Linux. Leaving it on a spinning array makes disks seek between reading source files and writing segments while other users are browsing.
Understand what the buffer setting costs you: "Transcoder default throttle buffer" defaults to 60 seconds, so each session writes roughly a minute of encoded video ahead of the viewer. Multiply that by your peak transcode count to size the directory.
Watch SSD endurance, not just speed: transcoding is a sustained write workload on a drive that is otherwise idle, which is a real argument for tmpfs on a machine with spare RAM.
Put the library database on an SSD regardless: com.plexapp.plugins.library.db drives every browse, scan and search, and it is the difference between a client that loads instantly and one that stalls on the home screen.

Size RAM for the scratch directory you intend to use, then stop.

How much upload bandwidth do 3, 5 and 10 remote streams need?

Transcoding capacity is worthless if your upstream cannot carry the result. Remote playback is limited by your upload speed, and most domestic connections are asymmetric, so a household with 500 Mbps down might have 40 Mbps up. Size against Plex's own quality presets, which are the bitrates your viewers will actually select, and add roughly 20 percent of headroom for protocol overhead and anything else using the line.

Concurrent remote streams	Upload required at the 1080p 8 Mbps preset	Practical note
3 streams	Around 24 Mbps plus overhead, so 30 Mbps	Within reach of most fibre and some cable uploads
5 streams	Around 40 Mbps plus overhead, so 48 Mbps	Rules out most VDSL and older cable connections
10 streams	Around 80 Mbps plus overhead, so 96 Mbps	Symmetric fibre or a hosted server territory
3 streams at the 20 Mbps 1080p preset	Around 60 Mbps plus overhead, so 72 Mbps	Quality preset matters more than stream count
1 stream of an untranscoded 4K remux	Frequently 50 Mbps or more, depending on the file	Direct play saves CPU and spends bandwidth instead

Two controls keep this predictable. Settings, Server, Remote Access carries a "Limit remote stream bitrate" option that caps what any single remote viewer can pull, which protects the connection at the cost of forcing more transcodes. Separately, if direct connection fails and sessions fall back to Plex Relay, throughput is capped at 1 Mbps, or 2 Mbps with Plex Pass, which is why a working port forward or reverse proxy matters more than any encoder.

What Plex Pass unlocks, and why it changes the hardware maths

Hardware transcoding is a Plex Pass feature. That single fact reframes the whole build, because the choice is not "iGPU or CPU", it is "pay for a subscription and buy a small machine" against "pay nothing recurring and buy a large one". For a reader who has just cancelled a streaming service, the second option often costs more in the first year and far more in electricity across three.

Hardware accelerated encode and decode: without a Pass, Plex ignores Quick Sync, NVENC and VideoToolbox entirely, no matter what silicon you installed.
Subscription shape, not a single price: Plex Pass is sold as a monthly plan, an annual plan and a one time lifetime purchase, so the comparison against a bigger CPU is a three year total, not a monthly line item.
Server side background work: intro and credit detection, chapter thumbnails and loudness analysis run as scheduled tasks on your server. They consume CPU outside playback hours, which is an argument for keeping some general purpose headroom even on a Quick Sync build.
Mobile downloads change your peak: synced offline copies are transcoded once, at full speed rather than in real time, so a single sync job can briefly load the machine harder than three live streams.
The Pass follows the account, not the machine: you can move your server between a NAS, a self built box, a VPS or Yundera without repurchasing, so the hardware decision stays reversible.

Decide the Pass question first. Every sizing number in this article changes depending on the answer.

Three reference builds sized for 3, 5 and 10 concurrent transcodes

These three builds assume Plex Pass, 1080p transcodes with SDR sources, and the scratch directory already moved off the media array. Adjust upward if your peak sentence from earlier includes 4K HDR or burned in subtitles.

Target load	Core hardware	Why this is the cut off
3 concurrent 1080p transcodes	Intel N100 or N305 mini PC, 16 GB RAM, 500 GB NVMe for the database and scratch	A twelfth generation media engine covers this load while the whole machine draws less power than a single desktop GPU at idle
5 concurrent 1080p transcodes	Intel Core i3 or i5 desktop of a recent generation, non F model, 16 GB RAM, separate NVMe	Same engine class in a chassis with room for drives and a 3.5 inch bay backplane
10 concurrent 1080p transcodes	Recent Intel Core i5 or i7, non F model, 32 GB RAM, NVMe scratch, symmetric fibre upstream	Bandwidth and library database contention arrive before the encoder saturates
3 concurrent 4K HDR transcodes	Recent Intel Core i5 with Arc based graphics, or an NVIDIA RTX card in a tower	Tone mapping at 4K is the workload that justifies discrete silicon
No Plex Pass, any count	High core count desktop or used workstation CPU, sized by PassMark	Software encoding scales by cores, so the chassis, cooling and power bill all grow

Two notes apply to every row. Buy the storage array separately from the compute decision, because drives do not affect transcoding. And validate with intel_gpu_top or the Plex Dashboard under real load before adding hardware you assumed you needed.

Migrating to Hubs Community Edition: what survives the move, and what you rebuild by hand

John — Thu, 03 Sep 2026 07:07:11 +0000

Your files survive the move to Hubs Community Edition. Your rooms do not. Scene GLBs, avatar GLBs and uploaded media are portable binary assets that carry across cleanly, but the database rows that turn those assets into a working room, the short room IDs, the permalinks, the accounts, the per room permissions and the moderation settings are all Reticulum state that a fresh deployment generates from scratch. Plan the migration as an asset transfer plus a manual rebuild of everything that was a link, a login or a setting.

TL;DR by reader profile

Agency hosting client spaces (a five person studio running 12 branded client showcases): migrate the scenes, rebuild the rooms, and budget for reissuing every client facing URL, because the old links are the single largest source of post migration support tickets.
Education team (a university department with 40 seminar rooms and one shared campus scene): migrate the handful of scenes that matter and re-create rooms per term, since most seminar rooms were disposable and rebuilding them is faster than reconstructing their state.
Events company (a three person team that spins up a venue scene per event): migrate scene sources and avatars, then invest the saved time in the Dialog SFU and TURN setup, because live audio quality decides whether the event works at all.
Solo creator or community organiser (one person running a monthly meetup room): expect a single evening of work, mostly re-uploading avatars and re-creating one room, and accept that your bookmarked room link is gone for good.
Enterprise or public sector team (an internal comms group with retention obligations): treat the migration as a new system build with its own data map, because self hosting moves recordings, uploads and access logs onto infrastructure you now have to account for.

The tradeoff is simple: binary assets move almost for free, while identity, links and configuration cost you manual work that scales with the number of rooms you kept, not the number of gigabytes you stored.

What survives the move to Hubs Community Edition, and what does not?
How Reticulum stores rooms, scenes, avatars and media
Do your existing room links still work after the move?
Which parts of a Spoke scene transfer, and which need republishing?
Custom avatars: what carries over and what you re-upload
Uploaded files, orphaned assets and the storage directory
Accounts, permissions and moderation settings you rebuild by hand
Which third party integrations stop working until you supply your own keys?
How long does a 50 room migration take, and how do you verify it?
Where do you run Hubs Community Edition, and what does the stack need?

What survives the move to Hubs Community Edition, and what does not?

Split your inventory into two piles before you touch anything. Binary assets survive because they are just files on disk: a published Spoke scene is a glTF 2.0 binary, a custom avatar is a .glb with a small set of texture overrides, and an uploaded image, PDF or video is the original file plus a generated thumbnail. Everything else is Reticulum state, which means rows in a Postgres database that a new deployment creates fresh and never inherits.

Item	What survives the move	What you rebuild by hand
Published scenes	The scene GLB and its textures, byte for byte	The scene entry, its listing, its thumbnail and its owner
Spoke projects	The project source and any assets you exported	The project entry in the editor, plus a republish per scene
Custom avatars	The base GLB and override maps	The avatar record, its name and its assignment to an account
Room media	The uploaded originals in the storage directory	The link between each file and the room it was pinned in
Rooms	Nothing automatic	Room name, scene binding, occupancy limit, permissions, pinned objects
Accounts and links	Nothing automatic	Every account, every role, and every short room ID in a shared URL

The practical consequence is that migration effort tracks your room count, not your storage size. Twelve rooms sharing one 80 MB scene is a longer job than one room referencing 4 GB of uploads, because the 4 GB copies in a single rsync and the twelve rooms do not.

How Reticulum stores rooms, scenes, avatars and media

Reticulum, the Elixir backend behind Hubs, splits your world into two stores that fail independently. Postgres holds the meaning, and a storage directory on disk holds the bytes. A migration that copies one without the other produces either empty rooms or unreachable files, so map both before you plan anything.

Rooms live entirely in Postgres: a hub row carries the short room ID used in the URL, the display name, the maximum occupancy, the member permissions bitfield and the binding to a scene. Nothing about a room exists as a file you can copy.
Scenes and avatars are rows that point at files: the scene or avatar record holds the name, description, attribution and its own short ID, then references the GLB and thumbnail through file records. Copy the GLB without the row and Hubs has no way to list it.
Uploaded media are owned file records: each upload gets an ID, a content type and an access key that the delivery URL must present, so the raw file on disk is not addressable unless the matching row exists in the database.
Storage separates temporary from permanent: files dropped into a room start in an expiring area and are promoted to permanent storage when someone pins them, which is why unpinned uploads disappear from a copy taken later.
Pinned objects are room state, not files: position, rotation, scale and the object reference sit in their own rows, so a pinned image restores as a floating object only if both the file and that row survive.

Take pg_dump and rsync of the storage path together, from the same moment.

Do your existing room links still work after the move?

No. A Hubs room URL is a hostname plus a short room ID plus a decorative slug, and only the first two parts matter. The slug is ignored on resolution, which is why renaming a room never broke its link, but the hostname is now yours and the short ID is regenerated by your own Reticulum instance. Every link you ever pasted into a calendar invite, a client deck or a printed programme resolves to nothing you control.

The hostname is unrecoverable: you cannot issue a 301 redirect from a domain you never owned, so any bookmark pointing at the old service is dead and no DNS change on your side fixes it.
Short IDs are generated, not carried: creating a room on your instance produces a new ID, so the same scene republished twice gives you two different room addresses with identical content.
You can force the ID if you insert it: seeding the hub row with a chosen short ID makes the path component match the old link exactly, which turns a broken URL into one that only needs the domain swapped.
Six digit entry codes are per deployment: the short code flow people used to jump from a headset browser into a room only knows about rooms in your database, so every previously shared code is invalid.
Embeds break silently: an iframe embedded in a client site keeps rendering its container and fails inside, so nobody reports it until a meeting starts.

Budget one communication task per audience, not per room. Twelve client rooms usually means three emails, not twelve.

Which parts of a Spoke scene transfer, and which need republishing?

Treat the published scene and the editable project as two separate things, because only one of them is self contained. The published output is a GLB carrying Hubs specific behaviour in the MOZ_hubs_components glTF extension, so spawn points, waypoints, audio zones, mirrors and the generated navmesh all travel inside the file. The project is a JSON document full of absolute URLs, and those URLs pointed at an asset host that no longer answers.

The published GLB renders immediately: drop it into your own instance, bind a room to it, and geometry, materials, baked lighting settings, collision and navigation behave exactly as before, with no re-authoring.
The project file opens with holes: your .spoke project references every imported model, texture, image and audio clip by URL, so reopening it in your own Spoke gives you a scene tree with unresolved assets rather than a working edit.
Third party imports are the worst offenders: anything pulled in from Sketchfab or a media search result was referenced rather than embedded, so those nodes need re-importing one by one against your own configured providers.
Scene metadata does not ride along: name, description, attribution credits and the scene thumbnail are database fields, so a transferred GLB appears as an untitled entry until you set them.
Republishing regenerates derived data: a fresh publish rebuilds the navmesh and the thumbnail, which is why a scene you can only supply as a GLB stays frozen at its last published state.

Migrate GLBs for continuity, and re-import projects only for the 2 or 3 scenes you still expect to edit.

Custom avatars: what carries over and what you re-upload

Avatars split the same way scenes do, and the derived ones cause the trouble. A fully custom avatar is a single GLB you can copy anywhere. A derived avatar is not a model at all: it is a reference to a parent avatar plus texture overrides, typically a base map, an emissive map, a normal map and an ORM map. Move the child without the parent and it resolves to nothing.

Standalone avatar GLBs transfer intact: rig, skin weights, blend shapes and materials all survive, so a bespoke client mascot loads on your instance the moment you re-upload it and give it a name.
Derived avatars need their parent first: upload the base avatar, then the overrides, in that order, or the child record points at a parent ID your database has never seen.
The default avatar set is not your data: the stock avatars ship with the client and a fresh deployment starts with its own listings, so any curated in house set has to be re-created as avatar listings in the admin panel.
Nobody keeps their selection: avatar choice is stored against an account, and since accounts do not migrate, every returning user lands on a default avatar and picks again on first entry.
Ready Player Me links keep working: avatars pulled in by URL are fetched at use time rather than stored as your records, so that path survives the move untouched.

For a team of 20 with one branded avatar each, expect the uploads to take under an hour and the re-selection support requests to trickle in for a fortnight.

Uploaded files, orphaned assets and the storage directory

Open the storage directory and you will find no filenames. Files are written under opaque identifiers with no extension, so a 4 MB blob could be a client logo, a PDF or a thumbnail, and only the matching database row tells you which. This is why a partial migration is so hard to debug: the disk looks healthy, the rooms look empty, and nothing in the file tree explains the gap.

Reconcile counts before you trust the copy: run find /storage -type f | wc -l on both sides and compare it with the number of file rows in Postgres, because a mismatch found now is a five minute fix and a mismatch found later is an archaeology project.
Orphans come in two directions: files with no row are dead weight you can delete, while rows with no file are worse, since Hubs renders the object placeholder and then fails to load it in front of a client.
Derivatives inflate your storage estimate: every image carries a generated thumbnail alongside the original, so the directory size is not the sum of what people uploaded and copying only the originals leaves visible gaps in room listings.
Large video is served as it was uploaded: without a transcoding step in your stack, a 500 MB source file is what every visitor streams, so audit the biggest 20 files before you size bandwidth.
Permissions travel with the copy: use rsync -a and keep ownership consistent with the user your Reticulum container runs as, or uploads succeed and reads fail.

Copy files first, restore the database second, then verify one room per scene.

Accounts, permissions and moderation settings you rebuild by hand

There is one piece of good news here: Hubs never stored passwords. Login is a magic link sent to an email address, so nobody needs a reset campaign and you are not migrating credentials. What you are migrating is the absence of everything else, because an account row carries the identity, the admin flag and the ownership of every scene and avatar that person created.

Every account starts again: a returning user enters the same email address on your domain and receives a brand new account, with no history, no owned scenes and no saved avatar.
Ownership does not follow the asset: a scene you re-upload as an admin is owned by the admin account, so the designer who built it can no longer edit or republish it without you reassigning the record.
The first admin comes from configuration, not the database: your deployment nominates an admin email before anyone logs in, and that is the only account that can reach the admin panel to promote the next one.
Room permissions are per room defaults you set again: the toggles governing who may pin objects, spawn media, draw, share a camera or fly are stored on the hub row, so a locked down client showcase reverts to the default permissive setup unless you reapply it.
Moderation state is gone: closed rooms, kicked users and any ban you applied were tied to identities on the old deployment and have no meaning against new account IDs.

For 20 users across 12 rooms, the account side is self service and costs you nothing, while the permission side is roughly 12 short admin tasks.

Which third party integrations stop working until you supply your own keys?

The hosted service quietly held API credentials on your behalf. Your deployment holds none, so several features that felt native to Hubs become inert until you register for accounts and add keys to your configuration. One of them is not optional: without working outbound email, nobody can log in at all, because the magic link never arrives.

Integration	State on a fresh deployment	What it needs from you
Magic link login	Broken, blocks all sign in	SMTP credentials or a transactional mail provider, plus SPF and DKIM records
Sketchfab import	Search returns nothing	A Sketchfab API token in your Reticulum configuration
GIF and image search	Empty results panel	A key per provider, one for GIFs and one for image search
Video links from streaming sites	Paste works, playback varies	A resolver service reachable from your instance, checked per site
Discord room binding	Absent	The separate Hubs Discord bot deployed with its own bot token
Third party media embeds	Blocked by the browser	A working CORS proxy host, included in your content security policy

Two consequences matter for a migration plan. First, test the email path before you announce anything, because every other check depends on being able to sign in. Second, audit your existing scenes for objects that came from a search panel, since those nodes will render as broken references until the matching provider key is in place. A scene with 30 imported models can hide 3 or 4 of these, and they only surface once someone walks up to them.

How long does a 50 room migration take, and how do you verify it?

Do not estimate the whole job. Time one room end to end, then multiply, because the per room work is almost perfectly repetitive. Create the room, bind the scene, set the permissions, re-pin the objects, capture the new URL. If that loop takes you 4 minutes, 50 rooms is a little over 3 hours of clicking, and the asset copy underneath it happens once regardless of room count.

Front load the one time work: the file copy, the database restore, the email configuration and the provider keys are a single block of effort, and none of it repeats when you add the fiftieth room.
Batch by scene, not by room: rooms sharing one scene need that scene republished once, so ordering your list by scene turns 50 tasks into as few as 8 or 10 real pieces of work.
Verify with two browser windows: join the same room twice on different profiles, confirm you hear yourself on the second connection, and confirm both avatars move, which tests the SFU and the state channel together.
Watch the network panel on entry: a room that looks correct can still be firing failed requests for pinned media, so treat anything other than zero failed asset loads as unfinished.
Test one room on an actual headset: desktop entry passes long before the headset path does, and problems here are usually certificate or host related rather than anything to do with your migrated content.

Reserve a quarter of your total budget for the last 3 rooms. The stragglers are always the ones with imported models and pinned video.

Where do you run Hubs Community Edition, and what does the stack need?

Hubs is not one container. A working deployment runs the Reticulum backend, the web client, Spoke, the Dialog SFU that carries voice and video, a TURN server for clients behind restrictive networks, Postgres and a storage volume. That shape drives the hosting decision more than CPU or RAM does, because real time media has requirements a typical web app never raises.

You need several hostnames, not one: the app, the asset host, the media server and the CORS proxy each answer on their own name, all on HTTPS, and your content security policy has to list them consistently or the client blocks its own assets.
UDP is the hard requirement: WebRTC media flows over a UDP port range to the SFU, and any host that only exposes TCP 443 forces every participant onto TURN relaying, which changes your bandwidth profile completely.
TURN is not optional in practice: corporate networks routinely block direct paths, so plan for a relay listening on the standard 3478 and 5349 ports even if your own testing never touches it.
Postgres and storage are the state: everything else can be recreated from images, so your backup job only has to cover the database and the storage directory.
Your options span the usual ground: a self managed VPS, a home server, a NAS or a managed personal 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.

Choose the host on its networking behaviour first. A machine that cannot pass UDP will run every meeting through a relay.

Ollama Has No API Authentication: How To Properly Gate Port 11434

John — Tue, 01 Sep 2026 07:06:06 +0000

Ollama has no username, no password and no API key. Anything that can reach TCP port 11434 can list your models, run inference on your GPU, pull a 40 GB model onto your disk and delete every model you have, with a single curl command and no credential. The fix is not a setting inside Ollama, because there is not one: you keep the default bind on 127.0.0.1, and if you genuinely need remote access you put a bearer token proxy, an SSH tunnel or a mesh VPN in front of it. Everything else in this article is choosing which of those three, and proving you got it right.

TL;DR by reader profile:

The single laptop user (Maya, a writer running llama3.2 on a MacBook for offline drafting): keep the default 127.0.0.1 bind and never touch OLLAMA_HOST, because nothing outside the laptop has any reason to reach the API.
The home GPU box owner (Tom, one desktop with an RTX card in the study, phone and tablet elsewhere in the house): use a mesh VPN such as Tailscale or WireGuard, because it gives you remote access without any port ever being open to the network or the router.
The laptop plus workstation developer (Priya, coding on a thin laptop against a beefy machine two rooms away): use an SSH tunnel, because it needs zero changes on the Ollama side and dies the moment you close the terminal.
The self-hoster running a web chat UI (Ben, Open WebUI on a rented VPS with a public domain): terminate HTTPS at a reverse proxy that checks a bearer token, and never publish 11434 itself, because the browser tier and the model tier need separate trust.
The small team sharing one model server (a six person studio pooling one GPU): use a proxy with per user tokens and rate limits, or mutual TLS, because you need to revoke one person without rotating everyone.
Anyone who already set OLLAMA_HOST=0.0.0.0 (following a blog post to make a client work): stop and audit before hardening, because an exposed endpoint may already have models on disk that you did not pull.

The real tradeoff is this: every method that makes a new client easy to connect also widens the set of machines that can reach your models, and you cannot optimise both at once.

What is actually listening on port 11434 when Ollama runs?
What can somebody do with an unauthenticated Ollama API?
Is binding to 127.0.0.1 enough, and when does that guarantee break?
How do I check right now whether my Ollama is reachable from outside?
How do I set OLLAMA_HOST correctly on Linux, macOS and Windows?
Does OLLAMA_ORIGINS stop a website from talking to my local models?
Firewall rules or bind address: which layer should you rely on?
How do I put a bearer token in front of Ollama with a reverse proxy?
When is mutual TLS worth the extra work?
SSH tunnels and mesh VPNs: reaching Ollama without opening a port
How much latency does a proxy add to streamed tokens?

What is actually listening on port 11434 when Ollama runs?

When you install Ollama, you get two things: a command line client and a long running HTTP server. The server is the part that matters here. It listens on TCP port 11434 and speaks plain HTTP, not HTTPS, and it answers every request it receives without asking who sent it.

A REST API, not a chat program: the ollama run llama3.2 command you type is a thin client that talks to the same HTTP endpoint any other machine would use, so anything curl can send, a stranger can send.
A background service that starts itself: on Linux it is usually a systemd unit called ollama.service, on macOS it is the menu bar app, and on Windows it is a tray process, which means the port is open long after you close the terminal you launched it from.
Full lifecycle control, not just inference: the API covers listing, pulling, creating, copying and deleting models, so it is an administrative interface as much as a generation interface.
Direct access to your model directory: models live under ~/.ollama/models on Linux and macOS, and the API can add to or remove from that directory without touching the shell.
No credential layer of any kind: there is no login, no API key setting and no per client identity, so the only access control you have is which network interfaces the port is bound to.

Where that port lives depends on where you run Ollama: a laptop, a home server, a NAS, a rented VPS, or a 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.

What can somebody do with an unauthenticated Ollama API?

Treat reachability as full control. There is no read only mode, so anyone who can open a socket to the port holds the same powers you do from your own shell.

Inventory your models: a single curl http://your-host:11434/api/tags returns every model name, size and digest on the machine, which tells an intruder both what you use the box for and how much disk you have committed.
Run inference on your hardware for free: POST /api/generate and POST /api/chat execute on your GPU and your electricity bill, with no rate limit and no quota, and an abuser can point a public chat frontend at your endpoint and let strangers use it.
Fill your disk on demand: POST /api/pull downloads any model from the registry, and large models run to tens of gigabytes each, so a loop of pull requests is a straightforward way to exhaust storage until the host stops working.
Delete everything you have downloaded: DELETE /api/delete removes a model with one request and no confirmation prompt, so hours of downloads disappear without a trace in any interface you normally watch.
Read what you are currently doing: GET /api/ps lists models loaded in memory right now, which leaks activity patterns even when no prompt content is exposed.
Create custom models on your machine: POST /api/create builds a new model entry from a Modelfile, including a system prompt of the attacker's choosing, so a client of yours can be silently served a modified model under a familiar name.

None of this requires an exploit or an unpatched version. It is the documented API behaving exactly as designed.

Is binding to 127.0.0.1 enough, and when does that guarantee break?

Yes, with one condition: a process bound to 127.0.0.1 is unreachable from any other machine, because the kernel refuses packets arriving on a physical interface for a loopback address. No firewall rule is doing that work. The bind itself is the boundary. The problem is how many ordinary situations quietly move the bind somewhere else.

You set OLLAMA_HOST to make one client work: the usual advice for connecting a phone, a second laptop or a container is OLLAMA_HOST=0.0.0.0:11434, which replaces a boundary that was airtight with none at all, on every interface at once including any public one.
Loopback is per machine, not per user: every local account, every browser extension and every background process on that host can reach 127.0.0.1:11434, so on a shared workstation the bind protects you from the network and from nobody else.
Windows Subsystem for Linux crosses the line: WSL2 runs on its own virtual network, so a server bound to loopback inside WSL and a server bound to loopback on Windows are two different boundaries, and people usually resolve the confusion by binding wide.
A VPN or mesh interface is still an interface: if you bind to 0.0.0.0 expecting only your VPN subnet to reach it, the same socket answers on Ethernet and Wi Fi too.
IPv6 has its own loopback: binding to 127.0.0.1 does not cover ::1, and binding to [::] covers far more than you probably intend.

The rule to keep: change the bind only when you have already decided what will check the requests.

How do I check right now whether my Ollama is reachable from outside?

Do this before you change anything. Five minutes of checking tells you whether you are hardening a closed door or cleaning up after an open one.

Look at the bind address on the host itself: run ss -tlnp | grep 11434 on Linux, lsof -nP -i :11434 on macOS, or netstat -ano | findstr 11434 on Windows, and read the left hand address, because 127.0.0.1:11434 is safe and 0.0.0.0:11434 or [::]:11434 means every interface is answering.
Test from a second device on the same network: from a phone or another laptop, run curl -m 5 http://192.168.1.50:11434/api/tags with your machine's local IP, and a JSON model list coming back proves the LAN can reach it.
Test from outside your network: turn Wi Fi off on your phone so it uses mobile data, then try the same request against your public IP, because that is the only test that distinguishes a LAN exposure from an internet exposure.
Check the router for a forwarding rule: open the port forwarding or virtual server page and look for anything sending 11434 inward, since a rule added months ago for a different purpose can survive a router reboot and a firmware update.
Audit the model directory for things you did not pull: list ~/.ollama/models and compare it against what you remember downloading, because an unfamiliar model or a sudden jump in disk usage is the clearest sign someone else has been using the API.

Write the results down. You will repeat this test after every change in the sections that follow.

How do I set OLLAMA_HOST correctly on Linux, macOS and Windows?

The variable has to reach the background service, not your terminal. Exporting OLLAMA_HOST in a shell changes where the client looks, not where the server listens, which is the single most common reason a change appears to do nothing.

Platform	Where the value belongs	What makes it take effect
Linux with systemd	`sudo systemctl edit ollama.service`, then add `Environment="OLLAMA_HOST=127.0.0.1:11434"` under a `[Service]` block	`sudo systemctl daemon-reload` followed by `sudo systemctl restart ollama`
macOS desktop app	`launchctl setenv OLLAMA_HOST "127.0.0.1:11434"` so the value is visible to apps launched by the session	Quit Ollama from the menu bar and start it again, since the running process keeps its old environment
Windows	User environment variables in the System Properties dialog, one entry named `OLLAMA_HOST`	Exit the tray icon completely, then relaunch, because a minimised process is still the old one
Docker container	An `-e OLLAMA_HOST=...` flag or an `environment:` entry, paired with a publish flag such as `-p 127.0.0.1:11434:11434`	Recreate the container, since environment variables are fixed at creation

After any of these, repeat the two device test from the previous section rather than trusting the config file. The value is only correct if a request from another machine now fails.

Where you run the server decides which row applies to you: a laptop and a self managed VPS use the platform rows, while a NAS, a home server running containers and a managed Personal Cloud Server such as Yundera all use the Docker row, because apps there run as Docker containers on a server dedicated to the user.

Does OLLAMA_ORIGINS stop a website from talking to my local models?

Partly, and only inside a browser. OLLAMA_ORIGINS sets which web origins get an Access-Control-Allow-Origin header back. That is a rule the browser enforces on the page, not a rule the server enforces on the request. Understand the difference before you rely on it.

It does block the ordinary case: a random site you visit cannot script a POST to http://localhost:11434/api/chat, because a JSON content type triggers a preflight OPTIONS request first, and a rejected preflight means the real request is never sent.
It does not block anything outside a browser: curl, Python, a mobile app and a script on another machine ignore CORS entirely, so an origin allowlist has zero effect on the exposure risks covered earlier.
Simple requests still leave your machine: a plain GET to /api/tags needs no preflight, so the browser sends it and only blocks the page from reading the answer, which is a weaker guarantee than most people assume.
The default is deliberately local: Ollama already permits origins such as http://localhost and http://127.0.0.1 on any port, plus browser extension origins, which is why a locally served web UI works with no configuration at all.
Setting it to * removes the only browser side check you had: the wildcard is the standard fix suggested when a self hosted frontend on a different host cannot connect, and it lets every page in every tab you open reach the API.

If a remote frontend needs access, name its exact origin, for example OLLAMA_ORIGINS=https://chat.example.com, rather than opening it to everything.

Firewall rules or bind address: which layer should you rely on?

Rely on the bind address as the primary control and treat the firewall as the backstop. A bind is a property of the socket, so it cannot be bypassed by a rule someone forgets to reapply. A firewall is a separate ruleset that has to be correct, loaded and evaluated before the traffic reaches the port.

Layer	What it genuinely stops	Where it lets you down
Bind address (`OLLAMA_HOST=127.0.0.1:11434`)	Every packet from every other machine, on every interface, with no ruleset to maintain	Nothing on the local host, and it is one environment variable away from being undone
Host firewall (`sudo ufw deny 11434/tcp`, or Windows Defender Firewall)	Remote access even when the service is bound to `0.0.0.0`, and it survives an accidental config change	Docker published ports write their own forwarding rules, so a container can be reachable while `ufw status` looks correct
Router or cloud provider firewall	Inbound traffic from the internet, including scans that find port 11434 within hours of exposure	Nothing on your LAN, so every other device in the house or office still has full API access
Bind plus host firewall together	Both the remote path and a future misconfiguration of either one	Neither layer identifies who is calling, so a permitted machine still has unlimited control

Set the bind first, add the deny rule second, then repeat the external test. If your provider gives you a network level firewall, close 11434 there as well and leave it closed permanently.

How do I put a bearer token in front of Ollama with a reverse proxy?

The pattern is always the same: Ollama stays bound to 127.0.0.1, a proxy on the same host owns the public port, and the proxy rejects anything without the right Authorization header. Ollama itself is never modified, and it never learns that authentication exists.

Generate a token with real entropy: openssl rand -hex 32 gives you 64 hexadecimal characters, which is far beyond guessable, and it costs nothing compared with a memorable passphrase that a dictionary attack will find.
Make the proxy compare, then forward: in Caddy this is a matcher on header Authorization "Bearer <token>" followed by reverse_proxy 127.0.0.1:11434, and in nginx it is an if test on $http_authorization returning 401 before the proxy_pass line.
Terminate TLS at the proxy: a bearer token over plain HTTP is readable by anything between the client and the server, so Caddy's automatic certificates or a certbot managed nginx config are part of the control, not an optional extra.
Turn off response buffering: nginx needs proxy_buffering off; and a long proxy_read_timeout, otherwise streamed tokens arrive in one block at the end and a slow generation looks like a hung request.
Add a rate limit while you are there: capping requests per IP turns a leaked token into a nuisance instead of unlimited free access to your GPU.
Check your clients can send headers first: Open WebUI and most OpenAI compatible tools have a field for an API key, while the ollama command line client sets only a host URL, so CLI users need a tunnel rather than a token.

Test with a deliberately wrong token and confirm you get a 401.

When is mutual TLS worth the extra work?

Mutual TLS means the proxy in front of Ollama demands a client certificate before it forwards anything. A bearer token proves knowledge of a string. A client certificate proves possession of a private key that never travels over the wire. That is a real upgrade, and it costs you setup time on every device you own.

It is worth it when you have several fixed devices: issue one certificate per machine from your own certificate authority, and you can revoke the stolen laptop alone instead of rotating a shared token and reconfiguring everything else.
It is worth it when the endpoint must stay on the public internet: an unauthenticated scanner gets a TLS handshake failure rather than an HTTP 401, so your endpoint never confirms that anything is listening behind it.
It is worth it when tokens keep leaking into places you cannot audit: shell history, container environment variables and editor config files all hold plain strings, while a private key can live in the operating system keystore.
It is not worth it for a single user on a single laptop: the loopback bind already gives you a stronger boundary than certificates would, with no expiry to manage.
It is not worth it when your clients cannot present certificates: many mobile apps and some desktop LLM frontends have no field for a client key, so you would end up running a token path beside the certificate path and inheriting the weaker of the two.

The practical cost is renewal. Certificates expire, commonly at 365 days, and a forgotten renewal takes every client offline at once with an error message that looks nothing like an authentication problem.

SSH tunnels and mesh VPNs: reaching Ollama without opening a port

Both approaches leave the bind on 127.0.0.1 and move the network problem somewhere that already has authentication. Nothing about Ollama changes, and port 11434 stays closed to the world in both cases.

The SSH tunnel is the fastest to set up: ssh -N -L 11434:127.0.0.1:11434 user@gpu-box makes the remote API appear on your own loopback, so the ollama command line client, Open WebUI and every default CORS origin work unchanged with no token anywhere.
The tunnel inherits SSH's authentication: key based login means no new secret to manage, and closing the terminal closes the access, which is exactly what you want for occasional use and exactly what you do not want for a service that must stay up.
A mesh VPN suits always on access: Tailscale or plain WireGuard give the host a private address, in Tailscale's case inside the 100.64.0.0/10 range, reachable only by devices you have enrolled.
The mesh handles the network problems for you: it negotiates through NAT over UDP, WireGuard on port 51820 by default and Tailscale on 41641, so there is no router rule to add and no public IP requirement.
Access control moves to the mesh, not the API: every enrolled device gets unrestricted use of the model server unless you write ACLs, so treat enrolment as the sensitive act and remove old phones and laptops when you stop using them.
Phones and tablets are where the tunnel loses: mobile SSH forwarding is awkward, while a VPN client on the phone makes the endpoint reachable from the sofa with no configuration in the app itself.

How much latency does a proxy add to streamed tokens?

Less than people fear, and in the wrong place. Token generation is bounded by your GPU or CPU, while a local proxy hop is a copy across loopback. What actually ruins the experience is buffering and connection setup, not throughput. Measure it on your own hardware with curl -N -w "%{time_starttransfer}" and compare the direct call against the gated one.

Path to the API	Where the extra delay comes from	What keeps it small
Direct to 127.0.0.1:11434	Nothing beyond model load and generation, so this is your baseline number	Keep a model resident so the first request does not pay the load cost again
Local reverse proxy with a bearer token	One extra loopback hop plus a TLS handshake on each new connection	Enable HTTP keep alive and reuse connections instead of opening one per request
SSH tunnel to another machine	The round trip to that machine, plus SSH encryption on every chunk of the stream	Run it over a wired LAN where possible, since the network round trip dominates everything else
Mesh VPN across the internet	The full path to the remote host, and a relay hop if a direct connection cannot be negotiated	Confirm the connection is direct rather than relayed, because relayed traffic takes a longer route

The number that matters to a reader is time to first token, not tokens per second. Streaming hides steady state overhead well. It hides nothing about a slow start. If a gated setup feels sluggish, check buffering and connection reuse before you blame the encryption.

Immich Sizing Guide: What a 20,000 Photo Google Takeout Import Really Costs in Disk, RAM and Hours

John — Sat, 29 Aug 2026 07:05:56 +0000

Budget roughly 1.35 to 1.6 times your raw photo size on disk, 6 GB of RAM for the full stack with machine learning enabled, 4 CPU cores, and a full weekend of background processing before a 20,000 item library is fully searchable. The import itself is the fast part. Thumbnail generation, video transcoding and machine learning jobs are what actually keep the server busy, and three settings decided in the first hour, the storage template, the machine learning model, and the transcoding policy, are the ones that force a full re-run of every job if you change your mind in month two.

TL;DR by reader profile:

The phone-only archivist, one iPhone and 20,000 photos with almost no video: 2 CPU cores, 4 GB RAM and 1.4x your library size is enough, because thumbnails dominate and transcoding barely runs.
The family with a decade of camcorder video, 20,000 items where 3,000 are clips: go to 4 cores and 8 GB RAM before you import, because video transcoding is the single job that will run for days on weak hardware.
The RAW shooter with a Lightroom folder tree, 20,000 files averaging 25 MB: use an external library in read-only mode rather than uploading, so Immich never becomes the only copy of your originals.
The privacy-first switcher leaving Google Photos this week: set the storage template and the machine learning model before the first upload, then never touch them again, because both settings rewrite work already done.
The low-power host, a Raspberry Pi 5 or an N100 mini PC: disable the smart search model on day one and run facial recognition only, or accept that machine learning jobs will still be queued a week later.
The person who just wants it working tonight: import with default settings, leave transcoding on the optimal policy, and treat the first 72 hours as unattended processing time rather than a broken install.

The central tradeoff is that every setting which makes Immich feel fast and searchable later, larger machine learning models, generated previews, transcoded video, costs you disk and hours of CPU during the first week, and changing your mind afterwards means paying that cost a second time.

How much disk space does Immich actually need for 20,000 photos?
Why is the Immich database and thumbnail folder bigger than you expected?
How much RAM does Immich need, and what happens when it runs out?
How many CPU cores does the first import really use?
How long does a 20,000 item Google Takeout import take from start to searchable?
Should you upload into Immich or point it at an external library?
What does the Google Takeout format break, and how do you fix it before importing?
Which storage template should you set before the first upload?
Which machine learning model should you choose on day one?
What should the video transcoding policy be, and what does it cost you?
Where should you actually run Immich: NAS, mini PC, home server or hosted?
Which day-one settings force a full re-run if you change them later?

How much disk space does Immich actually need for 20,000 photos?

Start from the size of your Google Takeout, not the photo count. A 20,000 item library from a modern phone is usually somewhere between 60 GB and 120 GB of originals, because a 12 megapixel HEIC frame lands near 2 MB while a single 4K clip can pass 400 MB. Immich stores your originals untouched, then adds derived files on top.

The multiplier you should plan for is 1.35x to 1.6x the original size, split across four directories under UPLOAD_LOCATION:

upload/ and library/, the originals: 100 percent of your Takeout size, byte for byte, because Immich never recompresses the file you gave it.
thumbs/, the previews: typically 15 to 25 percent on a photo heavy library, since every asset gets a small thumbnail plus a larger preview image used by the timeline and the detail view.
encoded-video/, the transcodes: zero if you have no video, but easily 50 to 100 percent of your video bytes again when the default policy re-encodes clips your browser cannot play natively.
The Postgres volume, metadata and machine learning vectors: small in absolute terms, usually a few hundred megabytes at this scale, but it grows with embeddings and faces rather than with file size.

Practical floor: if your Takeout unzips to 90 GB, provision 200 GB and do not let the filesystem cross 80 percent during import. Running du -sh on each subdirectory after the first 1,000 assets gives you a real multiplier for your own library, which beats any generic estimate.

Why is the Immich database and thumbnail folder bigger than you expected?

Because Immich does not generate one thumbnail per photo. It generates a small WebP tile for the timeline grid and a much larger preview used whenever you open an asset, and that second file is the one that surprises people. A 2 MB HEIC original can produce a preview of several hundred kilobytes, so the ratio between a phone photo and its derivatives is far worse than it is for a 25 MB RAW file, where the same preview is a rounding error.

Four things inflate these directories beyond a naive estimate:

Preview resolution is a setting, not a constant: the preview size configured in Administration, Settings, Image Settings applies to every asset, so raising it after import means every existing preview is regenerated and the old ones replaced.
Motion photos count twice: an iPhone Live Photo or a Samsung motion shot arrives as a still plus a short video, and Immich stores and processes both, which quietly turns 20,000 selected items into more than 20,000 stored assets.
Postgres carries vectors, not just rows: smart search stores an embedding per asset and facial recognition stores one per detected face, so a library with many group photos grows the database faster than a library of landscapes.
Deleted assets linger for 30 days: the trash retention default keeps originals and derivatives on disk until the period expires, so disk usage during a messy first week reflects your mistakes as well as your library.

Check the real split with du -sh thumbs encoded-video inside UPLOAD_LOCATION before you conclude anything about total size.

How much RAM does Immich need, and what happens when it runs out?

Plan for 6 GB of system RAM for the full stack with machine learning enabled, and 4 GB if you disable smart search. The four containers are not equal: the server and Postgres are steady and modest, Redis is tiny, and immich-machine-learning is the one that spikes, because it loads a model into memory the first time a job needs it and holds it there.

What failure looks like is the part nobody warns you about. The kernel OOM killer does not stop Immich politely. It kills the machine learning container mid job, the job returns to the queue, the container restarts, reloads the model, and fails again on the same asset. You get a silent loop that burns CPU for hours and never advances the counter.

Three signals tell you this is happening:

docker compose ps shows a restart count climbing: the machine learning container sits at 5 or 10 restarts while the server container sits at 0.
The job queue stalls at the same number: smart search stays frozen while thumbnail generation keeps moving, because only one container is dying.
dmesg | grep -i oom prints kill lines: this is the definitive check, and it names the process that was terminated.

The fix is either more RAM, a smaller model, or fewer concurrent machine learning jobs, set to 1 in the job settings.

Hosting choice matters here because you cannot add RAM to a box that has none free. A NAS with 4 GB shared with other services, a self-managed VPS, a mini PC and a managed option are all viable starting points. 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.

How many CPU cores does the first import really use?

All of them, unless you tell Immich otherwise. Immich runs background work as named job queues, and each queue has its own concurrency setting in Administration, Settings, Job Settings. The defaults are tuned for a machine that is doing nothing else, so on a 4 core box the first import will pin every core for hours and make the web interface feel sluggish while you are still uploading.

The queues do not weigh the same:

Thumbnail Generation: the heaviest sustained consumer during a bulk import, because it decodes every original and writes two derivatives, and it scales almost linearly with the concurrency value you set.
Video Transcoding: the one queue you should keep at concurrency 1, since FFmpeg already uses multiple threads internally and running two transcodes at once mostly makes both slower.
Smart Search and Face Detection: CPU bound unless you have a supported GPU, and these are the queues that decide whether your library is searchable on day three or day seven.
Metadata Extraction: cheap per asset, fast to complete, and rarely the bottleneck at 20,000 items.

Four cores is a workable floor. Two cores works but roughly doubles your wall clock time, and a shared vCPU with a burst credit balance will collapse to baseline speed partway through and stay there.

Watch it live with docker stats, which shows per container CPU percentage. If immich-server sits near your core count times 100 percent for hours, that is normal during first import, not a fault. Lower Thumbnail Generation concurrency to 2 if you need the machine responsive for anything else.

How long does a 20,000 item Google Takeout import take from start to searchable?

Think in phases, not in one number. The upload finishes long before the library is usable, and the gap between those two moments is where people assume something is broken.

Phase	What is happening	Typical shape on 4 cores
Upload via `immich-go` or the CLI	Files transferred, metadata read, duplicates skipped	Minutes to a few hours, limited by disk or LAN speed
Metadata extraction	Dates, GPS, camera fields written to Postgres	Completes soon after upload, rarely the bottleneck
Thumbnail generation	Two derivatives written per asset	Several hours, and the timeline stays gappy until it ends
Video transcoding	Non compatible clips re-encoded by FFmpeg	Hours to days, entirely driven by how much video you have
Smart search and face detection	Embeddings and faces computed per asset	The long tail, often the last queue still running

A photo heavy library with under 500 short clips is usually fully processed inside 24 hours on 4 cores. Add 3,000 camcorder clips and the same library can take a long weekend, because transcoding runs at concurrency 1 by design.

Two practical points. First, upload speed and processing speed are independent: immich-go can finish at 2 a.m. while the job queues still have 18,000 items pending. Second, the Jobs page in the admin panel shows an active and a waiting count per queue, and the waiting count falling is the only honest progress bar you have.

Do not judge the install until every queue reads zero. Search results, people grouping and the map view are all incomplete before that point, and re-running them costs the same hours again.

Should you upload into Immich or point it at an external library?

Upload if Immich is becoming your primary photo home. Use an external library if you already have a folder tree you edit with other tools and want to keep owning.

The two paths differ in who controls the files on disk:

Uploaded assets live under UPLOAD_LOCATION and obey the storage template: Immich decides the folder layout and filename, moves files when you change the template, and treats deletion in the app as deletion on disk after the trash period.
External libraries are read only by design: you register a path such as /mnt/photos in the container, Immich indexes what it finds, generates thumbnails into its own directories, and never writes to or renames your originals.
External libraries need a rescan to notice changes: new files added by Lightroom, Syncthing or a NAS share appear after a scan job runs, either on the configured interval or when you trigger it manually, which is not the instant behaviour uploads give you.
Mobile backup always uploads: the phone app has no concept of an external path, so a mixed setup is normal, historic archive as an external library and new phone photos as uploads.
Duplicate risk is real if you do both with the same files: importing a Takeout with immich-go and also mounting that same folder externally gives you every asset twice, counted twice in storage reporting.

For a 20,000 file RAW archive averaging 25 MB, the external route is the safer first week choice: your originals stay where your backup script already finds them, and a mistake in Immich cannot rename or move 500 GB of files.

What does the Google Takeout format break, and how do you fix it before importing?

Takeout does not hand you a photo library. It hands you archives of files whose metadata has been moved out of the images and into JSON sidecars, and if you import them naively your entire timeline collapses onto the import date.

Dates and GPS live in sidecar JSON, not in the file: each media file gets a companion .json holding photoTakenTime and location, and Immich's plain upload path does not merge them, which is why so many first imports show 20,000 photos all dated today.
Sidecar filenames do not reliably match their media: Google truncates long names and appends counters like IMG_1234(1).jpg, so naive pairing by filename fails on a meaningful slice of any large export.
Edited copies arrive alongside originals: a file plus its -edited variant are two assets, which inflates your item count above what Google Photos showed you.
Albums are folders, not metadata: album membership is expressed by directory layout and an album JSON, so a plain folder upload gives you every photo and zero albums.
Live Photos are split: the still and the paired video land as separate files that need rejoining, not as one asset.

The fix is tooling, not manual cleanup. immich-go was written for exactly this: it reads the sidecars, rebuilds dates, recreates albums and pairs motion photos, and it can consume the Takeout zip files directly without you unzipping 100 GB first.

Import a single archive as a test run of a few hundred assets, confirm the timeline dates look correct, then delete those assets and run the full set. Discovering a date problem after 20,000 items means redoing all of it.

Which storage template should you set before the first upload?

Decide this before a single asset lands, because the template controls the on disk path of every uploaded file, and changing it later triggers a Storage Migration job that physically moves all 20,000 files.

Templates are built from variables such as {{y}}, {{MM}}, {{filename}} and {{ext}}, set in Administration, Settings, Storage Template. Four sane choices:

Template	Resulting path shape	Best for
Disabled, the default	Random directory and asset id under the user folder	People who will never touch the files outside Immich
`{{y}}/{{MM}}/{{filename}}`	`2019/07/IMG_1234.jpg`	Anyone who wants a browsable archive that survives Immich
`{{y}}/{{y}}-{{MM}}-{{dd}}/{{filename}}`	`2019/2019-07-14/IMG_1234.jpg`	Event heavy libraries where one day equals one shoot
`{{album}}/{{filename}}`	`Corsica 2019/IMG_1234.jpg`	Album driven workflows, with the caveat that assets in no album fall back

The default is genuinely defensible. Random paths never collide and never break when you rename an album. The argument against it is portability: if Immich is your only index, a corrupted database leaves you with a directory of meaningless filenames.

Two hazards. Filename collisions inside the same folder get a numeric suffix, so {{y}}/{{filename}} on a phone that resets its counter will produce IMG_0001_1.jpg. And the template applies to uploaded assets only, never to external libraries, which keep their original paths untouched.

Pick a year and month layout unless you have a specific reason not to. It is readable, it sorts, and it means a plain file browser can still make sense of your archive years from now.

Which machine learning model should you choose on day one?

This is the setting with the harshest change penalty. Smart search stores one embedding per asset, and embeddings from different models are not interchangeable, so switching models invalidates all 20,000 of them and forces a full re-run of the Smart Search queue.

The choice lives in Administration, Settings, Machine Learning Settings, and the models are pulled from the Immich Hugging Face collection on first use.

The default CLIP model: shipped because it fits modest hardware, and on a 4 core box with no GPU it is the only option that finishes a 20,000 item library in hours rather than days.
Larger visual models: better at abstract queries like "birthday cake" or "snow on a mountain", at the cost of more RAM in the machine learning container and a longer queue, which is exactly the combination that triggers the OOM loop on a 4 GB host.
Multilingual models: the only way to search in a language other than English, noticeably heavier than their English only equivalents, and worth choosing on day one if your household does not think in English.
Facial recognition is separate: it runs its own detection and recognition models with their own concurrency, so you can keep faces enabled while leaving smart search off entirely.
Off is a valid answer: on a Raspberry Pi 5 or an N100, disabling smart search turns a week of queued jobs into a library that is fully browsable by date and album tonight.

Test with 200 assets before committing. Search for three things you would realistically look for, judge the results, then import the rest. Making that judgement after the full import costs you the entire queue again.

What should the video transcoding policy be, and what does it cost you?

Leave it on the default optimal policy unless you have a specific reason not to, then understand exactly what that policy is doing to your disk and your weekend.

Transcode policy	What it re-encodes	What it costs you
Don't transcode	Nothing	Zero extra disk, but clips your browser cannot decode simply will not play
Videos not in an accepted format	Only unsupported codecs and containers	The cheapest useful option, ideal for phone footage that is already H.264 in MP4
Videos higher than target resolution or not in an accepted format	The above, plus anything above the target resolution, 720p by default	The default, and the reason a 4K library balloons in processing time
All videos	Every clip regardless of source	Doubles your video storage and can run for days on 3,000 items

Three things decide the real cost. The target resolution, because raising it to 1080p produces larger transcodes but keeps quality your phone actually shot. The constant rate factor, where the default of 23 trades size against fidelity. And hardware acceleration, which is the difference between hours and days: Immich supports NVENC, QSV, VAAPI and RKMPP, enabled by adding hwaccel.transcoding.yml to your compose command and selecting the matching API in the settings.

The trap is that the original is always kept. Transcodes are additional files in encoded-video/, never replacements, so an aggressive policy costs storage on top of your originals rather than saving any.

If your video is mostly modern phone footage, switching to "videos not in an accepted format" before the first import can remove most of the transcoding queue entirely.

Where should you actually run Immich: NAS, mini PC, home server or hosted?

The hardware question is really a question about video and about who fixes it at 11 p.m. when the phone app stops backing up.

A consumer NAS, Synology or QNAP class: attractive because the disks are already there, but many models ship 2 GB or 4 GB of RAM shared with the NAS operating system, and their Celeron and ARM CPUs turn the transcoding queue into a multi day job. Check for a container station and free RAM before assuming it will work.
A mini PC, N100 or similar: the sweet spot for a first Immich server. Four cores, upgradable RAM, low idle draw, and Intel Quick Sync on board, which is the single change that collapses video processing time.
An old desktop or a home server: the most CPU per euro you will ever get, and the right answer if you already own one. The costs are electricity, noise and the fact that your library now depends on a machine with no redundancy.
A VPS or a managed personal server: removes the hardware problem and the port forwarding problem, and moves the storage question into a monthly bill, since 200 GB of block storage is a different line item than a 4 TB disk you buy once. 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, and each app is reachable on a public HTTPS subdomain via NSL.SH mesh routing.

Whatever you pick, the deciding number is free RAM, not disk. Disk you can add later. A 4 GB ceiling shared with three other containers is what actually stops a 20,000 item import.

Which day-one settings force a full re-run if you change them later?

Some Immich settings are free to change at any time. Five are not, and the difference is whether the change invalidates work already written to disk. On a 20,000 item library, each of these costs you the same hours you spent during the first import.

Setting	What changing it later triggers	Safe default for week one
Storage template	A Storage Migration job that moves every uploaded file on disk	Set it before the first upload, then leave it
Smart search model	All existing embeddings discarded, full Smart Search queue re-run	Pick the model you can afford to run, test on 200 assets
Preview and thumbnail size	Thumbnail Generation re-runs for every asset, old derivatives replaced	Accept the default unless you view photos on a 4K display
Transcode policy or target resolution	Every clip matching the new rule is re-encoded from the original	Decide by looking at what codecs your clips actually use
Facial recognition model	Face detection and recognition re-run, and people you named can need reassigning	Enable it once and do not switch models casually

Two settings that look scary and are not: UPLOAD_LOCATION can be moved if you move the directory and keep the structure intact, and job concurrency can be raised or lowered mid import with no penalty at all.

The practical rule is simple. Anything that changes how a derived file is generated forces regeneration of every derived file. Anything that changes scheduling or naming of the running system does not.

Write your five choices down before you import. Reviewing them takes 15 minutes. Discovering one was wrong in month two costs you another weekend of queued jobs.

ConvertX Hardware Requirements: How Much CPU, RAM and Disk Before Conversions Start Failing

John — Thu, 27 Aug 2026 07:06:17 +0000

ConvertX will install and run on a 1 vCPU, 1 GB virtual machine, and it will convert a 2 MB PNG to WebP in a second. That box will also kill a 4K video conversion, a 300 MB PDF and a large EPUB rebuild, usually with no visible error at all. The honest hardware floor for general use is 2 vCPU and 4 GB of RAM with 3 times your largest file free on disk, and the floor for routine video work is 4 vCPU and 8 GB. If your real workload is long video transcodes or 500 MB office documents, and you have no appetite for reading container logs, a hosted converter will fail less than a small self-hosted instance.

TL;DR by reader profile:

The occasional image converter, for example someone flattening HEIC holiday photos to JPEG once a month: self-host ConvertX on the smallest tier you have, because single image jobs finish in seconds and memory pressure never builds.
The document and ebook person, for example a researcher pushing DOCX and EPUB through Pandoc and Calibre weekly: self-host on 2 vCPU and 4 GB, because LibreOffice and Calibre are single threaded and want headroom rather than cores.
The video converter, for example a parent re-encoding phone clips to H.264 for a TV: budget 4 vCPU, 8 GB and a large scratch volume, or accept conversions measured in hours.
The privacy-driven user with sensitive files, for example someone converting bank statements and medical scans: self-host even on modest hardware, because the failure mode is a slow job, not a document sitting on a third party server.
The shared household or small team instance, for example five people with one link: treat concurrency as the real constraint, because two overlapping jobs on 4 GB will OOM before either one finishes.
The reader with no sysadmin appetite at all, for example someone who cannot read docker logs and does not want to: use a hosted converter for anything over 100 MB, because silent failure with no diagnosis is worse than a public upload you understand.

The central tradeoff is this: ConvertX moves your files off other people's servers, but it also moves every timeout, memory limit and disk exhaustion onto a machine you now have to size correctly yourself.

What happens inside ConvertX when you press Convert
What are the real hardware floors for ConvertX, tier by tier
The upload path: where large files die before ConvertX ever sees them
How do you tell an OOM kill from a timeout in ConvertX
Why does a ConvertX job finish with no output and no error
Scratch disk: the hidden multiplier on every ConvertX conversion
Concurrency in ConvertX: what breaks when two jobs overlap
Video and FFmpeg in ConvertX: the workload that decides your tier
Images and ImageMagick in ConvertX: pixel maths, memory limits and policy files
Documents, ebooks and LibreOffice in ConvertX: slow, single threaded, quietly fragile

What happens inside ConvertX when you press Convert

ConvertX is not one converter. It is a Bun web application that receives your upload, writes it to disk, then shells out to whichever command line tool handles that format pair. Understanding that chain is the whole hardware question, because the web layer costs almost nothing and the child process costs everything.

The upload lands on disk first: your file is written into the container's data volume before any conversion starts, so a 500 MB video occupies 500 MB before a single frame is encoded.
A converter binary is selected by format pair: FFmpeg for audio and video, ImageMagick and libvips for raster images, Inkscape and resvg for vectors, Calibre for ebooks, Pandoc and LibreOffice for documents, Assimp for 3D meshes. Each has its own memory behaviour and none of them know about the others.
The job runs as a child process, not inside the web server: ConvertX waits for that process to exit. If the kernel kills it, ConvertX sees a dead process, not an explanation.
The output is written beside the input: peak disk usage is input plus output plus whatever temporary files the tool creates, which for LibreOffice and Calibre is substantial.
Results persist until cleanup runs: AUTO_DELETE_EVERY_N_HOURS defaults to 24, so a day of conversions accumulates on the volume before anything is reclaimed.

The practical consequence: ConvertX itself idles at a few hundred megabytes. Your 8 GB requirement is not ConvertX, it is FFmpeg encoding 4K, or ImageMagick decompressing a 200 megapixel TIFF into an uncompressed pixel buffer. Size the box for the worst binary you will ever invoke, not for the web interface.

What are the real hardware floors for ConvertX, tier by tier

Pick your tier from the heaviest format you actually convert, not from the average one. The table below maps common hardware to what genuinely completes and what starts failing.

Tier	Completes reliably	Starts failing at
1 vCPU, 1 GB RAM	Single images under 20 megapixels, PDF to text, small Markdown and DOCX via Pandoc, audio transcodes	Any video over roughly 2 minutes, LibreOffice on large spreadsheets, two concurrent jobs of any kind
2 vCPU, 4 GB RAM	Batches of 20 photos, EPUB and MOBI via Calibre, 1080p clips under 5 minutes, most office documents	4K video, TIFF files over 100 megapixels, three or more overlapping users
4 vCPU, 8 GB RAM	1080p video at usable speed, 4K short clips, large PDF rasterisation, 2 to 3 concurrent jobs	Long 4K transcodes measured in hours, batch video, sustained multi user load
8 vCPU, 16 GB RAM	Feature length video, large batch image work, several simultaneous users	Little in practice, the constraint becomes disk throughput and patience

Disk matters as much as RAM. Reserve at least 3 times the size of your largest file, and remember that with AUTO_DELETE_EVERY_N_HOURS at its default of 24, a day of jobs stays resident.

Where that hardware lives is a separate decision. A self managed VPS, an always on home server, a NAS running Docker and a managed option all reach the same floors. 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 choose, the tier table above is what decides whether a conversion finishes.

The upload path: where large files die before ConvertX ever sees them

Half of the "ConvertX is broken" reports are not ConvertX at all. The file never reached the container. Every layer between your browser and port 3000 has its own size ceiling, and most of them reject silently or with a generic 413.

Nginx caps uploads at 1 MB by default: client_max_body_size starts at 1m. Until you raise it, anything larger returns 413 Request Entity Too Large and ConvertX logs nothing, because no request arrived. Set it to a value above your largest file, or to 0 to disable the check.
Cloudflare's free proxy caps request bodies at 100 MB: if your domain is proxied through Cloudflare on a free plan, a 400 MB video cannot reach your server regardless of your own configuration. Grey clouding the record or using a direct hostname is the only fix.
Proxy read timeouts kill slow uploads: nginx defaults proxy_read_timeout to 60 seconds. A large file over a slow home uplink can exceed that before the body finishes.
Your upstream bandwidth is the real limit at home: a 10 Mbit upload link moves roughly 1.25 MB per second, so a 500 MB file takes over 6 minutes of held connection before conversion even begins.
Caddy and Traefik behave differently: Caddy applies no default body limit, so people migrating from nginx often see the ceiling vanish without understanding why.

Where you run the instance changes which of these you have to configure. A self managed VPS means editing the proxy yourself, a NAS exposes its own reverse proxy settings, and on Yundera each app is reachable on a public HTTPS subdomain via NSL.SH mesh routing. Test with a file at your true maximum size before trusting any of it.

How do you tell an OOM kill from a timeout in ConvertX

These two produce almost identical symptoms in the browser: a job that never completes. They need opposite fixes. More RAM does nothing for a timeout, and a longer timeout does nothing for an OOM kill. Diagnose before you resize.

Signal	Points to an OOM kill	Points to a timeout
Exit status in `docker logs convertx`	Process terminated by signal 9, container exit code 137	Process still running, or killed cleanly after a fixed interval
`docker inspect --format '{{.State.OOMKilled}}' convertx`	Returns `true` after the container itself dies	Returns `false`, the container is healthy
Host kernel log via `dmesg -T`	Contains "Out of memory: Killed process" naming ffmpeg, soffice or convert	Contains nothing at all
Browser behaviour	Connection stays open, then the job vanishes from progress	504 Gateway Timeout from the reverse proxy while the job continues server side
`docker stats` during the job	Memory climbs to the limit then the row disappears	Memory sits flat, CPU pegged at 100 percent on one core

The pattern worth memorising: an OOM kill is sudden and leaves kernel evidence, a timeout is patient and leaves the converter alive. A frequent surprise is a job that hits both, where FFmpeg keeps encoding for 40 minutes after the proxy already returned 504, so the output file appears later with no matching entry in your browser.

Add swap before you upgrade the tier. On a 4 GB box, 2 GB of swap turns some ImageMagick kills into slow but successful conversions. It will not save a 4K transcode, and a job that swaps heavily for 20 minutes is usually a signal that the tier is wrong rather than the configuration.

Why does a ConvertX job finish with no output and no error

This is the failure mode that drives people back to hosted converters. The job appears in the history, the status does not scream at you, and the download is either missing or a 0 byte file. ConvertX only knows what the child process told it, and command line converters lie about success constantly.

The converter exited 0 but wrote nothing: LibreOffice is the worst offender here. It returns success after refusing to convert a document it could not parse, so ConvertX records a finished job pointing at an empty file.
A stale LibreOffice profile lock: if a previous conversion was killed mid run, the leftover profile directory blocks the next invocation. The fix is restarting the container, which is why the same document fails five times then works after docker restart convertx.
Missing fonts or unsupported subfeatures: a DOCX with an embedded font, or a PDF using a CJK typeface the container lacks, converts to a page of blank boxes rather than an error.
The output was cleaned up before you fetched it: with AUTO_DELETE_EVERY_N_HOURS at 24, a job you started last night and downloaded this evening can be gone.
Disk filled mid write: the converter writes a partial file, then fails on the final flush. You get a truncated result and a job marked done.

Your only reliable diagnostic is docker logs convertx, ideally with --tail 200 right after the failure. If reading container logs to work out why a PDF came back blank sounds like a bad evening, that is a legitimate reason to keep a hosted converter for anything important.

Scratch disk: the hidden multiplier on every ConvertX conversion

RAM gets the attention, disk causes the outages. ConvertX needs room for the input, the output and whatever intermediate the converter invents along the way, all at the same moment. That peak is routinely 5 to 10 times the size of the file you uploaded.

Rasterising a PDF is arithmetic, not magic: one A4 page at 300 DPI in RGB is about 3508 by 2480 pixels, roughly 26 MB uncompressed. A 100 page document becomes around 2.6 GB of intermediate data before anything is written as PNG or JPEG.
Uncompressed video intermediates are enormous: a single 1080p RGB frame is 1920 by 1080 by 3 bytes, about 6.2 MB. At 25 frames per second that is 155 MB of scratch per second of footage if a lossless intermediate is produced.
Calibre and LibreOffice unpack before they convert: an EPUB or DOCX is a zip archive, and the expanded working directory plus embedded images can dwarf the original file.
Everything accumulates in the same volume: uploads, outputs and mydb.sqlite share /app/data. If you did not mount a named volume, all of it lands on the container layer and fills the host root partition instead.
Retention multiplies the total: at the default 24 hour cleanup, a day of 20 conversions averaging 200 MB in and 150 MB out holds roughly 7 GB before anything is reclaimed.

Check with df -h on the host and docker system df for volume usage, not by guessing from your upload sizes. A full disk produces truncated outputs rather than clean errors, so a 20 GB volume on a video oriented instance is a floor, not a comfortable allocation.

Concurrency in ConvertX: what breaks when two jobs overlap

ConvertX has no job queue that serialises heavy work. A batch upload of 12 files, or two people clicking Convert at the same moment, means multiple converter processes competing for the same cores and the same memory ceiling. This is the single most common reason a box that felt adequate suddenly fails.

FFmpeg claims every core by default: with no explicit -threads value it scales to all available CPUs. On 4 vCPU, two simultaneous encodes request 8 threads across 4 cores, so both run at roughly half speed plus context switching overhead, and neither finishes when you expect.
ImageMagick multiplies memory, not just time: each process holds its own pixel buffer. Two 100 megapixel TIFF conversions on a 4 GB box are not one job twice, they are two independent allocations racing the same limit.
LibreOffice does not like company: two soffice invocations contending for the same user profile directory produce one success and one job that returns nothing usable.
SQLite serialises writes: mydb.sqlite handles job records fine at household scale, but it is a single writer database, not something to plan a 20 user instance around.
The web interface stays responsive while everything else starves: Bun keeps serving pages, so the instance looks healthy while conversions crawl. Health checks tell you nothing here.

The practical control is Docker resource limits. Setting cpus: "3.0" and mem_limit: 6g on a 4 vCPU, 8 GB host leaves the operating system breathing room and makes the failure predictable rather than random. If your instance serves more than three people who convert video, plan for one job at a time and tell them so.

Video and FFmpeg in ConvertX: the workload that decides your tier

If you never convert video, ignore most of the hardware advice in this article and run ConvertX on whatever you have. If you do, video alone sets your tier, because encoding is the only workload here that saturates every core for a sustained period.

Source material	On 2 vCPU, 4 GB	On 4 vCPU, 8 GB
Audio only, MP3 to FLAC or WAV	Completes in seconds, no real load	Identical, the tier is irrelevant
1080p H.264 clip under 5 minutes	Completes, slower than realtime, tolerable	Completes comfortably, cores are the binding constraint
1080p H.264 to H.265	Encoding runs far slower than the equivalent x264 job, expect to leave it running	Usable, still the slowest common conversion
4K to 1080p, 10 minutes or longer	Frequently exceeds proxy patience and sometimes memory	Completes, but plan for an unattended run
Feature length or batch video	Not a realistic workload	Marginal, this is where you want 8 vCPU

Three facts explain the whole table. A 4K frame carries 8.3 million pixels against 2.1 million at 1080p, so the same encoder does roughly four times the work per frame. The x264 preset ladder from ultrafast to veryslow spans an enormous speed range at similar quality targets, and ConvertX exposes this through the FFMPEG_ARGS environment variable, so setting -preset veryfast is the cheapest tier upgrade available. Finally, the container has no GPU acceleration unless you explicitly pass a device through, so everything runs on the CPU.

Set FFMPEG_ARGS before you buy more vCPU. A preset change costs nothing and often moves a job from abandoned to finished.

Images and ImageMagick in ConvertX: pixel maths, memory limits and policy files

Image conversion looks harmless because the files are small. The decoded buffer is what matters, and that number has nothing to do with the size on disk. A 12 MB JPEG and a 12 MB PNG can consume wildly different amounts of RAM.

Work out the buffer, not the file size: ImageMagick is normally built at Q16, meaning 2 bytes per channel. RGBA at 16 bits is 8 bytes per pixel, so a 100 megapixel scan needs roughly 800 MB of memory before any processing begins. That alone explains most failures on a 1 GB box.
The pixel cache silently falls back to disk: when the memory limit is reached, ImageMagick starts using a disk backed cache rather than failing. The job still completes, hundreds of times slower, which is why one photo occasionally takes 20 minutes while its neighbours take 2 seconds.
policy.xml can refuse the conversion outright: Debian based images ship with the PDF, PS and EPS coders disabled. The giveaway in the logs is "attempt to perform an operation not allowed by the security policy". That is a policy decision, not a hardware problem, and adding RAM will never fix it.
The same file has a cheap path and an expensive one: ConvertX also bundles libvips, which streams in tiles rather than loading the full image. Where both can handle a format pair, the vips route uses a fraction of the memory.
Batches compound the buffer, not the file count: 20 photos at 24 megapixels is not 20 small jobs, it is repeated 400 MB allocations.

Check a suspicious file with identify -verbose before blaming the tier.

Documents, ebooks and LibreOffice in ConvertX: slow, single threaded, quietly fragile

Document conversion is the workload people assume is trivial and then cannot explain. It rarely triggers an OOM kill on 4 GB. It just takes far longer than the file size suggests, and it does not get faster when you add cores.

Which binary handles the job decides everything: Pandoc converting DOCX to Markdown or HTML is a text transformation that finishes almost immediately on any tier. The same DOCX to PDF goes through LibreOffice or XeLaTeX, which is a completely different order of cost.
LibreOffice pays a cold start on every single job: each conversion launches soffice in headless mode, which means loading an entire office suite before the first page is laid out. That fixed overhead dominates on small documents, so a 40 KB letter and a 4 MB report can take a similar time.
Layout is single threaded: repagination, table reflow and font metrics run on one core. A 4 vCPU box converts a large spreadsheet no faster than a 1 vCPU box, which is why upgrading the tier for document work is usually wasted money.
LaTeX routes run multiple passes: XeLaTeX processes a document two or three times to resolve the table of contents and cross references, so the wall clock is a multiple of one pass, not one pass.
Calibre scales with embedded images, not page count: a 600 page text only EPUB converts easily, while a 90 page illustrated PDF to EPUB decodes every image and needs far more headroom.

The useful move is choosing your target format deliberately. If HTML or Markdown will do, you avoid LibreOffice and LaTeX entirely and turn a minutes long job into a seconds long one.

Why Your Self-Hosted Stirling-PDF Container OOMs, Hangs or Returns a Broken PDF: 15 Anti-Patterns and Their Fixes

John — Tue, 25 Aug 2026 07:06:47 +0000

Stirling-PDF is not an unstable application. Almost every crash, hang and quietly mangled output traces back to one of fifteen decisions you made outside the app: an unbounded container, the wrong image variant, a reverse proxy that gives up after 60 seconds, or an OCR call with no language pack behind it. The Java process inside the container claims a default heap of 25 percent of visible RAM, office conversions serialise through a single background LibreOffice process, and every job writes scratch files to disk before it returns a single byte. Correct those four assumptions and most of the remaining catalogue stops happening.

TL;DR by profile:

The weekend homelab tinkerer (one N100 mini PC, roughly ten PDFs a week, merge and split only): run the ultra-lite image with a hard 1 GB container limit, because you never touch the two subsystems that consume memory.
The scan hoarder (a decade of paper, 40,000 pages, OCR every one of them): run the full image, mount a real tessdata volume with your languages, and process in batches of 50 pages or fewer, because OCR cost scales with page count and DPI, not file count.
The automation builder (an n8n or cron job calling the Stirling-PDF API unattended): add your own queue and set explicit timeouts on both sides, because the app accepts every concurrent request you throw at it and holds each one in memory.
The small team sharing one instance (four people behind a VPN, mixed office conversions): budget for LibreOffice serialisation and raise proxy timeouts before you raise CPU, because your bottleneck is a single conversion process, not cores.
The NAS owner (a box already running twenty other containers): set the memory limit and the temp volume first, because an unbounded Stirling-PDF job is the container most likely to evict your other services.

The central tradeoff is headroom against completion: every limit that stops Stirling-PDF from taking down its host also stops some legitimate large job from ever finishing.

What is actually failing when Stirling-PDF dies, and how do you confirm it in two minutes?
Anti-pattern 1 and 2: no container memory limit, and no JVM heap ceiling inside it
Anti-pattern 3 and 4: running the wrong image variant, then calling a tool it does not contain
Where does Stirling-PDF write its temporary files, and why does that fill your disk?
Why does OCR hang, fail outright, or return a file with no selectable text?
Anti-pattern 9 and 10: treating office conversion as fast, parallel and font-independent
Why does a large upload fail before Stirling-PDF ever sees the file?
Anti-pattern 12: reverse proxy timeouts shorter than the job you just started
Anti-pattern 13: compression and repair settings that return a valid file with wrong content
Anti-pattern 14: volume permissions, custom fonts and language packs mounted incorrectly

What is actually failing when Stirling-PDF dies, and how do you confirm it in two minutes?

Three different failures get reported as "Stirling-PDF crashed", and they need opposite fixes. Run docker inspect stirling-pdf --format '{{.State.ExitCode}}' and docker logs --tail 200 stirling-pdf before you change anything. The exit code alone separates two of the three cases.

Exit code 137, container killed by the host: the kernel OOM killer reclaimed the process because the container exceeded its cgroup memory limit, or the host ran out of RAM entirely. The application log ends mid-sentence with no stack trace, which is the giveaway. Confirm it with dmesg -T | grep -i oom on the host or docker inspect reporting OOMKilled: true.
A java.lang.OutOfMemoryError: Java heap space stack trace, container still running: the JVM hit its own heap ceiling while the container still had free memory. The web UI usually stays reachable and only that one job fails. This is the fix nobody applies, because the container looks healthy.
No error at all, the request just never returns: the job is running, but something between your browser and the app gave up first. A 504 after roughly 60 seconds points at the reverse proxy, not at Stirling-PDF.
HTTP 200 with a file that opens but is wrong: text vanished, fonts substituted, images blurred to unreadable. Nothing in the log marks this as an error, because from the application's point of view it succeeded.

The first two are memory problems, the third is a timeout problem, and the fourth is a settings problem. Diagnosing the wrong one costs you a weekend.

Anti-pattern 1 and 2: no container memory limit, and no JVM heap ceiling inside it

Docker applies no memory limit by default. A container-aware JVM with no -Xmx claims a maximum heap of 25 percent of the memory it can see, which is the host's total RAM when you set no limit. Both defaults are wrong for this workload, and they fail in opposite directions.

Configuration	What the JVM sees	What breaks
No `mem_limit`, no heap setting	25 percent of host RAM as max heap, on 8 GB that is 2 GB	The host runs out of RAM before the container does, and your other services get evicted first
`mem_limit: 2g`, no heap setting	512 MB max heap, calculated from the limit	`OutOfMemoryError` on a job the machine could easily have handled
`mem_limit: 2g`, heap raised to 1.5 GB	1.5 GB heap, 512 MB left for everything else	Exit 137 the moment a native helper process starts, because Ghostscript and Tesseract live outside the heap
`mem_limit: 4g`, heap capped at 2 GB	2 GB heap, 2 GB for native processes and page cache	Nothing, for a single-user instance

The subtlety that catches people out: capping the Java heap does not cap the container. LibreOffice, Ghostscript, Tesseract and qpdf are separate native processes. Their memory counts against the cgroup limit but never against -Xmx.

Set both, and leave the native processes at least as much room as the heap. Add JAVA_TOOL_OPTIONS=-XX:MaxRAMPercentage=50 rather than a fixed -Xmx, so the ratio survives a change to the container limit. Then watch docker stats stirling-pdf during your largest real job instead of guessing.

Anti-pattern 3 and 4: running the wrong image variant, then calling a tool it does not contain

Stirling-PDF ships as more than one image, and they are not interchangeable. Pulling latest because it sounds current, or ultra-lite because it sounds efficient, decides which of the 50 plus tools actually work at runtime. The UI still shows every button either way, which is why this fails so confusingly.

stirlingtools/stirling-pdf:latest-ultra-lite: core PDF manipulation only, so merge, split, rotate, reorder and metadata edits. No OCR, no LibreOffice, no Python. It is the right choice if you genuinely never convert or OCR, and the wrong choice the first time you try.
stirlingtools/stirling-pdf:latest: the standard build, with OCR and office conversion included. This is the default answer for most self-hosters, and the variant the rest of this article assumes.
stirlingtools/stirling-pdf:latest-fat: everything preinstalled, including the ebook and advanced HTML tooling that the standard image otherwise fetches at container start when you set INSTALL_BOOK_AND_ADVANCED_HTML_OPS=true. It trades disk for a container that starts ready and needs no outbound network on boot.
The tool you call but did not install: the request reaches the backend, the underlying binary is absent, and you get a generic failure rather than "this image cannot do that". Confirm with docker exec stirling-pdf which soffice tesseract before blaming your configuration.

Where you run it changes how much this bites. On a self-managed VPS, a home server or a NAS you pick the tag yourself in a compose file. 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, so the variant arrives already chosen by the packaged app. Either way, verify which binaries exist before you design a workflow around them.

Where does Stirling-PDF write its temporary files, and why does that fill your disk?

Every non-trivial operation is a file-on-disk pipeline, not an in-memory transform. The container writes scratch files under /tmp/stirling-pdf, hands them to Ghostscript, Tesseract or LibreOffice, and only then streams a result back to your browser. If you never mounted anything at that path, all of it lands on the container's writable overlay layer, on the same filesystem as your Docker root.

The multiplication nobody budgets for: an OCR pass rasterises every page, writes the image set, writes an intermediate PDF, then writes the output. Peak disk use is several times the input size, and it happens before you see any progress at all.
Failed jobs do not always clean up: a container killed at exit 137, or a request abandoned when you closed the tab, leaves its scratch files behind. Check with docker exec stirling-pdf du -sh /tmp/stirling-pdf after a week of real use.
The overlay layer is the worst possible target: it is slow, it counts against your Docker storage pool, and it disappears on docker compose down, taking any recoverable partial output with it.
Two fixes, different tradeoffs: mount a tmpfs sized at 1 GB or 2 GB for speed, accepting that a job larger than the tmpfs fails outright, or bind mount a real directory for capacity, accepting slower rasterisation on spinning disks.
Cleanup is configurable: the temp file management block in /configs/settings.yml controls the cleanup interval, the maximum age of scratch files and whether a sweep runs at startup. Set it once rather than adding a cron job.

This matters more on constrained storage than on a roomy VPS, whether that is a NAS volume, a home server SSD or a Yundera instance.

Why does OCR hang, fail outright, or return a file with no selectable text?

OCR is the most expensive thing this application does, and it is driven by option combinations most people pick at random. Three failures dominate: no language data present, the wrong OCR mode for the input, and a page count the container cannot chew through before something upstream gives up.

Language data comes first. Run docker exec stirling-pdf tesseract --list-langs. If your language is missing, OCR fails or produces nonsense, and mounting a volume at /usr/share/tessdata with the traineddata files you need is the fix, not a setting change.

OCR option	What it actually does	Where it bites
Force OCR	Rasterises every page, then layers recognised text over the image	Destroys existing vector text and searchable layers, and inflates output size on documents that were already digital
Skip text	Leaves pages that already contain a text layer untouched	Returns a file with no new selectable text on mixed documents, which reads as a silent failure
Clean and deskew preprocessing	Runs image correction before recognition	Adds a full extra image pass per page, so processing time rises on exactly the large scans you were already struggling with
Sidecar output	Writes recognised text to a separate file alongside the PDF	Doubles the scratch files per job, which matters if your temp mount is a small tmpfs

Cost scales with pages and resolution, not with file count. A 400 page scan at 600 DPI is a fundamentally different job from 40 pages at 200 DPI, even at similar file sizes. Batch large documents into chunks of 50 pages or fewer, run them one at a time, and treat any OCR job over a few minutes as something that needs a raised timeout rather than a retry.

Anti-pattern 9 and 10: treating office conversion as fast, parallel and font-independent

Converting DOCX, XLSX or PPTX to PDF does not happen in Java. Stirling-PDF hands the file to a headless LibreOffice process inside the container. That single detail explains both of this section's anti-patterns.

The first conversion after a container start is the slow one: the headless soffice process has to initialise before it can do any work. Measure your second conversion, not your first, or you will size the machine against a number you will never see again.
Conversions serialise, so more cores do not help: requests queue behind one conversion backend. Two users submitting large presentations at the same time do not each get half the speed, the second one waits. If office conversion is your bottleneck, raise your reverse proxy timeout before you add vCPUs.
A wedged soffice process blocks everything behind it: one malformed document can leave the backend stuck, and every later conversion times out while the rest of the application stays perfectly healthy. Check with docker exec stirling-pdf ps aux | grep soffice, and restart the container rather than debugging the document.
Missing fonts corrupt layout silently: the container ships a limited font set. A document written in Calibri or Cambria gets substituted glyphs, so line breaks move, tables overflow and page counts change. The output is a valid PDF that does not match the original, and nothing in the log calls this an error.
Fix fonts by mounting them, not by hoping: bind mount your TTF files into a directory under /usr/share/fonts, then confirm with docker exec stirling-pdf fc-list | wc -l. Carlito and Caladea are the metric-compatible stand-ins for Calibri and Cambria, and Liberation Sans covers Arial.

Why does a large upload fail before Stirling-PDF ever sees the file?

A 413 error, or a progress bar that reaches 100 percent and then dies, is almost never the application. Every layer between your browser and the container can refuse a body, and each one has a different default. The container logs stay empty, which is the clue: if Stirling-PDF had rejected the file, it would have said so.

Layer	Default body limit	What you see
nginx or nginx proxy manager	`client_max_body_size` defaults to 1 MB	HTTP 413 within seconds, no entry in the Stirling-PDF log at all
Caddy or Traefik	No request body limit by default	Nothing, these two are rarely the culprit unless you added a buffering middleware yourself
Apache httpd	`LimitRequestBody` defaults to unlimited	Nothing, unless a distribution config or a hardening guide set it for you
Cloudflare proxied hostname	100 MB per request on the free plan	HTTP 413 from Cloudflare's edge, with a Cloudflare branded error page rather than your own
Stirling-PDF itself	A multipart upload limit in `/configs/settings.yml`	A clean application-level rejection that does appear in the log

Diagnose it by bypassing the chain. Send the same file directly to the container port with curl -F "fileInput=@big.pdf" http://localhost:8080/... from the host. If that works and the browser does not, the problem is in front of the app, and no amount of container tuning will fix it.

Raise the limits in order, from the outermost layer inward, and raise them to the same value. A proxy that accepts 500 MB in front of an app that accepts 50 MB just moves the failure one hop later, after the user has already spent the upload time.

Anti-pattern 12: reverse proxy timeouts shorter than the job you just started

A 504 after roughly a minute, on a job you know takes longer, is a proxy default and nothing else. The container never stopped working. It is still rasterising pages while your browser shows an error page.

nginx gives up after 60 seconds: proxy_read_timeout and proxy_send_timeout both default to 60s, which is shorter than almost any real OCR or large office conversion. Raise them to 300s or 600s in the location block for Stirling-PDF, not globally.
Cloudflare cuts the origin off at 100 seconds: a proxied hostname on the free plan returns error 524 when the origin has not responded in time, and you cannot raise that on the free plan. Long jobs behind an orange cloud need a different path to the app, such as a VPN or a direct hostname.
Caddy and Traefik do not impose a short default here: if you use either and still see a timeout, look at the client, at Cloudflare, or at an explicit middleware you configured yourself.
The retry is what actually kills the container: the abandoned job keeps running and keeps its memory. Clicking the button again starts a second copy of the same work, so peak memory doubles, and the container that was surviving one job gets killed at exit 137 running two. This is why "it broke worse when I tried again" is such a common report.
A timeout is not a substitute for batching: raising the ceiling to 600s makes a long job possible, but a job that needs 600 seconds should be split. Confirm the real duration by timing it against the container port directly, with the proxy out of the picture, before you decide which number to set.

Anti-pattern 13: compression and repair settings that return a valid file with wrong content

This is the failure class with no error message. The request returns 200, the PDF opens, and the damage only surfaces weeks later when someone needs the original. Compression, flattening, repair and sanitisation all rewrite the document structure, and several of them discard data by design.

Aggressive compression downsamples images, permanently: the optimisation levels run from light restructuring to heavy image resampling. On a scanned invoice, a high level can drop resolution below the point where the text is legible, and there is no undo. Test one representative document at each level before you apply anything to a batch.
Targeting an output size lets the tool decide how much to destroy: asking for a specific final size hands the algorithm permission to resample as far as it needs to. Set a level you have tested instead of a size you hope for.
Flattening converts form fields into static content: an interactive form becomes a picture of a form. Entered data is preserved visually, but the fields are gone, and any workflow that reads field values downstream stops working.
Repair rewrites the file structure and can drop what it does not understand: bookmarks, annotations, attachments and tagging are the usual casualties. Repair is for files that genuinely fail to open, not a routine step.
Any rewrite invalidates a digital signature: compress, repair, flatten, sanitise or even a metadata edit breaks the cryptographic seal. If a document is signed, it leaves the pipeline untouched.
Verify instead of trusting the 200: compare page counts and extracted text between input and output with pdfinfo and pdftotext from poppler-utils, and run qpdf --check output.pdf. Keep the original file until that comparison passes.

Anti-pattern 14: volume permissions, custom fonts and language packs mounted incorrectly

Two mount mistakes account for most of the "I followed the guide and it still does not work" reports. Both look correct in the compose file.

Mounting an empty host directory over a populated container path hides what was already there: bind mount an empty folder at /usr/share/tessdata and the traineddata files shipped in the image vanish, including English. OCR that worked before your fix stops working after it. Copy the existing contents out first with docker cp stirling-pdf:/usr/share/tessdata ./tessdata, then mount that directory back.
The same trap applies to fonts: mounting your font collection at /usr/share/fonts replaces the container's entire font tree. Mount a subdirectory such as /usr/share/fonts/truetype/custom so the bundled families survive alongside yours.
Docker creates missing bind mount sources as root: if the host path does not exist when the container starts, Docker makes it owned by root:root. An app running under a non-root user then fails to write, and configuration changes made in the UI silently do not persist across a restart.
Check the identity before you chase the permission: run docker exec stirling-pdf id to see which UID the process actually uses, then docker exec stirling-pdf ls -ln /configs to compare it against the ownership of the mounted directory. The numbers either match or they do not, and that answers the question in five seconds.
Set PUID and PGID to your own account, not to 0: running as root to make a permission error go away leaves every file the app writes owned by root on your host, which becomes your problem the first time you try to back up or move the data directory.

Hubs Community Edition backup and restore: what npm run backup captures, what it misses, and how long recovery takes

John — Sat, 22 Aug 2026 07:06:26 +0000

The bundled scripts in Hubs Community Edition back up two things: the PostgreSQL database and the Reticulum file store that holds uploaded GLB scenes, avatars, thumbnails and room media. They do not back up your hcce.yaml, your TLS material, your DNS records, your Kubernetes cluster or your object storage credentials, and if you point Hubs at an external database instead of the bundled Postgres pod, the scripts fall back to backing up the Reticulum files only. That means npm run restore-backup is not a disaster recovery plan on its own: it is the last step of one, and everything before it is a rebuild you have to be able to perform from your own notes. Plan for a restore that is a fresh install plus a data load, and time it once so you know the real number instead of a hoped-for one.

TL;DR by reader profile:

Small agency hosting client worlds (a four person studio running six separate client instances): keep the scripts, but wrap them in per instance archives with your hcce.yaml and secrets stored beside each archive, because a client asking for their world back is a per instance restore and not a cluster restore.
Solo operator running one instance (a single lecturer hosting seminar rooms on one VPS): the built in backup plus a nightly filesystem snapshot of the node is enough, because your recovery target is the whole box and not a selective extraction.
Team using an external managed Postgres (a studio on a hosted database with automated point in time recovery): treat the two halves separately, because the scripts stop covering the database the moment it leaves the bundled pod and your restore must line up two independent timelines.
Team with heavy scene libraries (a studio with hundreds of client uploaded GLB files): budget your restore window from file store size and disk throughput, because the database restores quickly and the assets dominate the clock.
Team facing a domain or host migration (a move to a new provider or a new client domain): rehearse the restore on a scratch host first, because room URLs, the Reticulum host configuration and certificate issuance all have to be corrected before anyone can join a room.

The central tradeoff: the built in scripts are simple and cover the data that actually matters, but they assume you can rebuild the surrounding installation by hand, so the effort you save at backup time is effort you pay back, under pressure, at restore time.

What does npm run backup actually capture in Hubs Community Edition?
What does the Hubs backup script silently miss?
Where does Hubs store rooms, avatars and uploaded GLB scenes on disk?
How long does a full Hubs restore actually take?
How do you run npm run restore-backup without breaking existing room URLs?
Should you back up the Hubs Postgres database separately from the Reticulum file store?
What changes when you run Hubs against an external database instead of the bundled pgsql pod?
Which Hubs secrets, certificates and configuration files must be saved outside the backup archive?
How much disk space does a year of Hubs backups need?
Snapshots, scripts or object storage: which backup strategy fits a Hubs instance?
How do you test a Hubs restore before you actually need it?
What breaks when you restore Hubs onto a different domain or a different host?

What does npm run backup actually capture in Hubs Community Edition?

Run npm run backup from your Hubs Community Edition checkout and you get a single timestamped archive, named in the data_backup_1234567890123 pattern, containing two payloads and nothing else.

The PostgreSQL database, dumped from the bundled pgsql pod: this is the record of every room, its title, its permissions, its owner account, its scene assignment and the metadata rows that point at uploaded files. Lose it and your GLB files still exist on disk but no longer belong to any room.
The Reticulum file store: the uploaded assets themselves, meaning GLB scenes exported from Spoke, custom avatars, room thumbnails, images, audio and video that people dropped into rooms. This is the part that grows without limit and dominates the archive size.
Nothing about your cluster or your configuration: hcce.yaml, your Kubernetes state, your certificates and your DNS live outside the archive and are your responsibility to version elsewhere.
Nothing about the state of the services at the moment of the dump: the archive is a data snapshot, not a running system image, so a restore always lands on a freshly installed instance.

The matching command is npm run restore-backup data_backup_1234567890123, and calling npm run restore-backup with no argument restores the most recent archive it finds. Where the instance runs shapes the rest of the plan: a self managed VPS, a home server, a NAS and Yundera are all viable homes for the surrounding stack. 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, the archive stays the same two payloads.

What does the Hubs backup script silently miss?

The word to notice is silently. The script does not warn you about the gaps, it simply finishes, prints a path and leaves you feeling covered. Six things are outside it.

Your hcce.yaml: this file carries your domain, your admin email, your subdomain layout and the deployment options that make the instance yours. Restore the data onto a default configuration and you get a working Hubs that is not your Hubs.
Secrets and keys: the Reticulum secret key base, the Perms keypair used to sign room join tokens, the cookie signing salt and any OAuth or email credentials. Regenerating the Perms keypair invalidates tokens that clients already hold, so sessions and pending invites break.
TLS certificates and the cert-manager state: a fresh install reissues through Let's Encrypt, which means the restore is gated on DNS pointing at the new host and on rate limits, not on your archive.
The k3s cluster itself: node configuration, storage class, persistent volume definitions and any manual kubectl edits you made months ago and forgot.
External object storage and CDN configuration: if you moved uploads off local disk, the bucket credentials and the bucket contents are not in the archive at all.
Email, TURN and third party settings: SMTP relay credentials and Coturn configuration decide whether people can receive invites and connect through restrictive networks.

Test the gap cheaply. Run npm run backup, extract the archive to a scratch directory and list what came out. Everything you expected but cannot find is now an item on a second backup job, ideally a git repository holding hcce.yaml and an encrypted secrets file.

Where does Hubs store rooms, avatars and uploaded GLB scenes on disk?

Two places, and knowing which is which decides what you can recover selectively later.

PostgreSQL holds the structure, not the bytes: the Reticulum schema carries tables such as hubs for rooms, accounts for identities, scenes and avatars for published assets, and owned_files for every upload. A row in owned_files records the owner, the content type and the identifier, while the actual file sits elsewhere.
The Reticulum storage volume holds the bytes: GLB scenes exported from Spoke, avatar GLBs, room thumbnails, images, PDFs, audio and video are written into a fanned out directory tree, each upload stored as a data file paired with a small metadata file. The names are identifiers, not human readable titles, which is why a file only means something when the database row that points at it survives too.
Derived media is cached, not authored: image resizing and video transcoding produce output that can be regenerated, so it is worth excluding from a tight recovery target and rebuilding after the fact.
The volume is a Kubernetes persistent volume claim: run kubectl get pvc in your Hubs namespace to see the claim and its size, and kubectl exec into the Reticulum pod to measure the tree with du -sh before you plan any window.

Where that volume physically lives depends on the host you chose, whether a self managed VPS, a home server, a NAS or Yundera. The split matters because the database is small and fast to move, while the storage volume is the part that grows every time a client uploads a scene.

How long does a full Hubs restore actually take?

Nobody can hand you a single number, because the archive is dominated by whatever your clients uploaded. What you can do is decompose the clock into five stages, measure each once on your own hardware, and turn the total into a promise you can actually keep.

Restore stage	What dominates the clock	How to shorten it
Provision the host and install k3s	Provider provisioning time plus package downloads	Keep a prebuilt image or a scripted node setup instead of typing it fresh
Deploy Hubs from `hcce.yaml`	Container image pulls for Reticulum, Dialog, the client and Postgres	Pre pull images on the standby host, or host them in a local registry
Issue TLS and point DNS	DNS propagation plus Let's Encrypt issuance, both outside your control	Lower the record TTL before a planned migration, not during an incident
Load the database dump	Row count in `hubs`, `accounts` and `owned_files`, usually the smallest stage	Nothing needed, this is rarely the bottleneck
Copy back the Reticulum file store	Archive size divided by disk and network throughput, the largest stage by far	Restore assets from storage that is already close to the new host

Measure it with time npm run restore-backup data_backup_1234567890123 on a scratch instance, then add the stages the script does not cover. Two rules follow. First, the file store sets your recovery time objective, so track its growth with du -sh monthly. Second, quote clients a window built from a real rehearsal, not from the script's runtime alone.

How do you run npm run restore-backup without breaking existing room URLs?

A Hubs room URL is built from the room identifier stored in the hubs table, so the URLs survive a restore for free as long as the database rows come back unchanged and the domain in front of them stays the same. What breaks them is everything you do around the restore.

Restore onto a fresh install, never onto a used one: bring up Hubs from hcce.yaml, then restore before anyone creates a room or publishes a scene. New activity writes rows that the incoming dump will collide with or overwrite, and the reconciliation is manual.
Keep the domain identical at restore time: put the same value in hcce.yaml that the archive was taken under, restore, verify, and only then perform a domain change as a separate, deliberate step.
Quiesce the services first: scale the Reticulum deployment to zero with kubectl scale, run the restore, then scale back. Restoring underneath a running Reticulum means live processes hold state that no longer matches the database.
Name the archive explicitly: run npm run restore-backup data_backup_1234567890123 rather than the bare npm run restore-backup, because the no argument form picks the most recent archive it finds and that is rarely what you want during an incident.
Verify before announcing: open one known room URL, one published scene and one custom avatar. Three checks catch the common failure, which is a database restored without its matching files.

The host underneath, a self managed VPS, a home server, a NAS or Yundera, does not change this sequence, only how quickly you can stand up the replacement instance.

Should you back up the Hubs Postgres database separately from the Reticulum file store?

For a single instance you can run npm run backup on a schedule and stop thinking about it. For anything larger, split the two, because they have opposite shapes: the database is small and changes every time someone creates a room, while the file store is large and mostly append only.

Dimension	One combined archive	Database and files backed up separately
Sensible cadence	Whatever the slowest half tolerates, usually nightly	Database hourly, files daily or on change
Storage growth	Every run copies the full file store again	Files deduplicate through incremental tooling, dumps stay small
Tooling	The bundled scripts only	`pg_dump` plus restic, borg or rsync against the storage volume
Recovery granularity	All or nothing, back to the archive time	Roll the database to one point, the files to another
Operational cost	One command, one cron entry, one thing to forget	Two jobs, two retention policies, two things to monitor

The practical rule is the loss window. If your clients publish scenes weekly but create rooms daily, an archive that repeats 40 GB of unchanged GLB files every night buys you nothing except a bigger bill. Dump the database hourly, back the storage volume up incrementally, and keep one full combined archive weekly as the known good fallback that needs no tooling to read.

Split backups carry one obligation: always restore the file store first and the database second, so no row can reference an asset that is not on disk yet. Write that ordering into the runbook, because it is the step people improvise wrongly under pressure.

What changes when you run Hubs against an external database instead of the bundled pgsql pod?

One thing changes and it is the important one: the backup scripts stop covering half your data. With an external database configured, npm run backup and npm run restore-backup handle the Reticulum files only. Nobody prints a warning. You simply get a smaller archive.

You now own the database backup outright: either your provider's automated snapshots and point in time recovery, or your own scheduled pg_dump against the Hubs database. Whichever you pick, it belongs in a runbook next to the file archive, not in your head.
You have two timelines to reconcile: a database recovered to 02:00 and a file archive taken at 03:00 leaves an hour of owned_files rows pointing at assets the file store does not have. Restore the files first, then roll the database forward to a point at or before the file archive, never after.
Credentials become a recovery dependency: the connection string, user and password live in your hcce.yaml and secrets, so losing those means the data survives while access to it does not.
Migrations still run on boot: Reticulum applies its schema migrations when it starts, so a database restored from an older instance can be upgraded by a newer deployment without you asking. Restore onto the same version you backed up from and upgrade deliberately afterwards.
The bundled pod stays simpler for small instances: one archive, one timeline, one restore command, at the cost of the operational features a managed database gives you.

Choose the split deliberately, then write down which system owns which half.

Which Hubs secrets, certificates and configuration files must be saved outside the backup archive?

Sort every item into two buckets before you build the vault: things that can be regenerated on the new host, and things that change behaviour for users if they are regenerated. Only the second bucket is a real backup obligation.

Item	Preserve or regenerate	Where it belongs
`hcce.yaml`	Preserve, it defines your domain, subdomains and admin email	A private git repository, committed on every change
Perms keypair and Reticulum secret key base	Preserve, regenerating invalidates issued room tokens and signed cookies	Encrypted secrets file, sops with age or your password manager
External database credentials	Preserve, the data is useless without access to it	Same encrypted store as the keys, never in the same archive as the dump
SMTP, OAuth and Coturn credentials	Preserve, they come from third parties and cannot be recreated locally	Encrypted store, with the provider account noted beside them
TLS certificates	Regenerate, cert-manager reissues after DNS points at the new host	Nothing to keep, but record the issuer and DNS provider steps
Derived Kubernetes secrets	Regenerate from the two entries above during deployment	Nothing to keep, they are outputs

Capture the live state once with kubectl get secret -n hubs -o yaml so you can see exactly what your instance holds rather than trusting this list. Encrypt that export immediately, because it contains plaintext values.

One discipline makes the whole thing work: the encrypted secrets store must be recoverable without the Hubs instance. If your only copy of the vault key lives on the server you are restoring, you do not have a backup, you have a circular dependency.

How much disk space does a year of Hubs backups need?

Work it out from two measurements rather than a guess. Get the current storage volume size with du -sh inside the Reticulum pod, then take two archives a month apart and subtract to get your monthly growth. Everything else is arithmetic on those numbers.

Full copies multiply, so count them first: a grandfather, father, son policy of 7 daily, 4 weekly and 12 monthly archives is 23 retained copies. With the bundled script, each one contains the whole file store, so the year costs roughly 23 times your current storage size plus the accumulated growth. This is the number that surprises agencies.
Incremental tooling changes the multiplier, not the base: because GLB scenes and avatars are written once and rarely modified, deduplicating backups with restic or borg store close to one copy plus the new uploads, so 23 restore points cost far less than 23 full archives.
Database dumps are rounding error: pg_dump output for room, account and owned_files rows compresses well and stays small next to the assets, which is why hourly database backups are affordable while hourly file archives are not.
Derived media inflates the total without adding value: transcoded video and resized images can be regenerated, so excluding them from the archive shrinks every copy for the whole year.
Off site copies double whatever you decided: the 3-2-1 rule means one primary, one local secondary and one remote, so budget the total twice, not once.

Set retention against a real number. A client that publishes a scene weekly needs different depth than one that uploaded once and never returned.

Snapshots, scripts or object storage: which backup strategy fits a Hubs instance?

Three approaches exist and they solve different failures. Pick by asking what you expect to lose: the whole machine, the data inside it, or the provider account holding both.

Provider or filesystem snapshots of the node: these capture the entire k3s host, so recovery is a rollback rather than a rebuild, and your hcce.yaml, secrets and certificates come back with it. They fail you in two ways: they usually live in the same provider account as the server, and they restore everything or nothing, which is useless when one client wants one room recovered.
The bundled scripts alone: npm run backup is portable, understandable and independent of any provider feature, which makes it the archive you can still read in three years. It covers the two data payloads and nothing around them, so it needs a companion job for configuration and keys.
Incremental backups to object storage: restic or borg pushing the Reticulum storage volume and pg_dump output to an S3 compatible target such as MinIO or Backblaze B2 gives deduplication, encryption at rest and an off site copy in one tool. The cost is a second system to monitor, plus a restore that now depends on network throughput.
The hybrid most agencies land on: nightly snapshots for fast whole host rollback, weekly bundled archives as the provider independent fallback, and continuous incremental pushes off site for the 3-2-1 requirement.

The choice is not about which tool is best. It is about which of the three failures you consider most likely, and whether your recovery needs to be selective.

How do you test a Hubs restore before you actually need it?

Build a scratch instance on a throwaway subdomain, restore last night's archive into it, and check five things by hand. Repeat quarterly and after every version upgrade, because an untested archive is a hypothesis.

Use a separate domain, never the live one: set a value such as hubs-drtest.example.com in the scratch hcce.yaml. Restoring production data onto production DNS during a drill is how a test becomes an outage.
Join a room and check presence works: open a restored room URL in two browsers and confirm audio and video connect. This exercises Dialog and Coturn, which a database check alone never touches.
Load a published GLB scene, not just the room list: rooms that open with a missing environment are the signature of a database restored without its matching file store, and the room index looks perfectly healthy in that state.
Load a custom avatar and a room thumbnail: avatars and thumbnails are separate owned_files rows, so they fail independently of scenes and prove the file tree copied completely rather than partially.
Time each stage and write the number down: run the drill with a stopwatch, record the total, and give clients that figure rather than an estimate. The number moves as the file store grows.

Finish by destroying the scratch instance and any DNS records it created, so nobody stumbles into stale rooms months later. Keep a one page log of every drill: the date, the archive name, the elapsed time and what broke. Three entries in that log tell you more about your recovery position than any amount of configuration review.

What breaks when you restore Hubs onto a different domain or a different host?

A different host alone is uneventful: the archive is portable and the deployment is rebuilt from hcce.yaml, so a move between a self managed VPS, a home server, a NAS or Yundera changes little beyond throughput. A different domain is the one that hurts, because the old hostname is written into places the restore script does not touch.

Stored absolute URLs: rows created under the old domain can carry fully qualified asset and scene URLs. After a domain change, query the database with psql for the old hostname before you assume the restore was clean, and update what you find.
Links your clients already shared: room URLs printed in emails, calendar invites and slide decks point at the old host. Keep the old domain resolving with a redirect for at least one full booking cycle rather than a fixed number of days.
OAuth and email: third party callback URLs and the sending domain in your SMTP configuration are registered against the old hostname and reject the new one until you update both providers.
TURN and media: Dialog and Coturn advertise addresses derived from your deployment configuration, so audio and video can fail while the room list looks perfectly healthy.
Certificate issuance order: DNS must point at the new host before cert-manager can complete a challenge, so the sequence is DNS first, deploy second, restore third.

Do the domain change as its own step, after a same domain restore has been verified. Two changes at once means any failure gives you two suspects instead of one.

DEV Community: John

Self-Hosted WordPress vs WordPress.com Business vs WP Engine and Kinsta: The Real 3-Year Cost for a Two-Person Startup

Table of contents

How much does WordPress really cost a two-person startup over 3 years?

What goes into the total cost beyond the hosting bill

What does self-hosting WordPress cost in year one, year two and year three?

How WordPress.com Business pricing and plan limits play out over three years

What do WP Engine and Kinsta charge once you hit visit and storage limits?

Premium plugins and themes: the renewal costs that grow each year

How many hours a month does self-hosted WordPress maintenance actually take?

Backups, staging and disaster recovery across the three options

Is self-hosted WordPress secure enough without a managed host's protection?

What happens to the cost when traffic grows or WooCommerce is added?

Where to run self-hosted WordPress: VPS, home server or personal cloud server

Data sovereignty and hosting location for a small WordPress site

How hard is it to switch between self-hosted and managed WordPress later?

Which option fits your startup: recommendations by profile

Netdata Alerts in Week One: Which to Keep, Tune or Silence, and How to Route Them to Slack, Discord and ntfy

Table of contents

Why do Netdata's stock alerts fire so often in the first week?

How Netdata's health configuration is structured on disk

Which stock alerts should you keep exactly as shipped?

Which alerts are worth tuning rather than deleting?

Which alerts can a small team silence outright?

How do you change thresholds, delays and hysteresis without losing them on upgrade?

Anomaly detection versus fixed thresholds for a two-person rotation

How do you send Netdata alerts to Slack, Discord and ntfy?

Splitting pages from notices with roles and severities

rclone mount vs rclone bisync after Dropbox: the real latency, RAM and conflict numbers

Table of contents

What does an rclone mount actually replace when the Dropbox client is gone?

How does rclone bisync differ from a mount in day to day use?

Which VFS cache mode should you run: off, minimal, writes or full?

How much RAM and disk does an rclone mount really consume?

What latency do open, stat and write calls show against a local disk baseline?

How fast do remote changes appear, and what do dir-cache-time and poll-interval control?

How do you size the VFS cache without filling the disk?

Conflicts, renames and deletes: what bisync does and what the first resync costs

What breaks when the network drops or the provider rate limits you?

Running the mount under systemd and recovering it after a reboot

Where should the mount run: home server, NAS, VPS or managed Personal Cloud Server?

How do you reach the same folder from a phone or a second laptop?

Should Ntfy Run on the Home Server It Is Meant to Warn You About? Where Alerts Fail and How to Avoid It

Table of contents

What actually goes silent when your home server goes down?

Which outages can a same-host Ntfy still report, and which can it never report?

How Ntfy's message cache and missed-message recovery behave during an outage

Why silence is the signal: dead man's switch patterns for Ntfy alerts

Is ntfy.sh reliable and private enough for critical home server alerts?

Is a second, off-site Ntfy instance worth the extra maintenance?

Where should the Ntfy instance that watches your home server run?

Does the phone side of Ntfy add its own failure points?

Wiring Uptime Kuma, Healthchecks and cron to Ntfy without a shared failure domain

Docmost Content In and Out: What Import, Storage and Handover Really Cost Over Three Years

Table of contents

What does three years of Docmost content logistics actually cost?

How faithful is the Confluence import into Docmost?

How faithful is the Notion import into Docmost?

Post import cleanup: the line item agencies forget to quote

How fast does the Docmost Postgres database grow per space?

Redis, websockets and the real time collaboration layer

Local disk or S3 for Docmost attachments over three years?

What has to be in a Docmost backup for the restore to actually work?

Exporting client content out of Docmost when the engagement ends

Handover: transferring a running Docmost instance to the client

Plex Server Sizing: Quick Sync, Discrete GPU or Raw CPU for 3, 5 and 10 Simultaneous Transcodes

Table of contents

Why does Plex transcode at all, and how do you stop it?

What does "3, 5 or 10 simultaneous streams" actually mean?

How much CPU do you need for software only transcoding?

How many streams can an Intel Quick Sync iGPU handle?

When does a discrete GPU beat Quick Sync, and where do AMD and Apple Silicon land?

What 4K HDR tone mapping does to your hardware budget

Subtitles: the setting that turns a hardware transcode back into CPU work

How much RAM and what scratch disk does the Plex transcoder need?

How much upload bandwidth do 3, 5 and 10 remote streams need?

What Plex Pass unlocks, and why it changes the hardware maths

Three reference builds sized for 3, 5 and 10 concurrent transcodes

Migrating to Hubs Community Edition: what survives the move, and what you rebuild by hand

Table of contents