DEV Community: John

Tailscale vs Cloudflare Tunnel: How to Reach Self-Hosted Docker Services Without a Public IP

John — Tue, 06 Oct 2026 07:06:43 +0000

Use Tailscale when every person and device that needs access can install a client, and use Cloudflare Tunnel when someone with only a browser and a link has to get in. Tailscale builds an encrypted WireGuard mesh between your own machines, so your Docker services stay invisible to the public internet and any TCP or UDP port works. Cloudflare Tunnel runs an outbound-only connector from your host to Cloudflare's edge, publishing a hostname on the public internet with TLS terminated by Cloudflare. Neither needs a static IP, a port forward or a manually issued certificate, and running both on the same host is a normal, supported setup.

TL;DR by reader profile:

Two person startup running internal tools (founders sharing Gitea, Grafana and a Postgres box): Tailscale, because nothing you self-host ever gets a public hostname and both of you already control every laptop involved.
Freelancer showing a client a staging site (a preview build that must open in Safari on someone else's phone): Cloudflare Tunnel, because the visitor installs nothing and the link just works.
Sysadmin living in SSH, RDP and database clients (managing five Docker hosts across two locations): Tailscale, because arbitrary TCP and UDP ports and direct peer-to-peer routing matter more than a pretty URL.
Homelabber streaming media to family (Jellyfin and Navidrome for four relatives): Tailscale, because large non-HTML media served through Cloudflare's free proxy sits against its terms, and direct WireGuard paths beat a proxied round trip.
Small team publishing a real public service (a marketing site plus a webhook receiver for Stripe): Cloudflare Tunnel, because you want external systems and strangers to reach it without an invitation.
Anyone who needs both at once (private admin panel, public app, one host): run both connectors side by side and split by hostname.

The central tradeoff is simple: Tailscale asks you to install a client on every device that needs access, while Cloudflare Tunnel asks you to route your traffic through a third party edge that terminates your TLS.

What do Tailscale and Cloudflare Tunnel actually do differently?
How does each one reach a Docker container with no public IP?
How do you set up Tailscale on a Docker host, step by step?
How do you set up Cloudflare Tunnel on a Docker host, step by step?
Which one is better for private admin panels only your team touches?
Which one is better for a service you need to share with clients?
Do SSH, RDP, UDP and other non-HTTP services work on each one?
How much latency and throughput do you give up with each?
How much does each really cost over three years?
Tailscale Serve and Funnel vs Cloudflare public hostnames: where do they overlap?
Who can see your traffic, and what does each side log?

What do Tailscale and Cloudflare Tunnel actually do differently?

They solve two different problems that happen to share a symptom. Tailscale is a private network. Cloudflare Tunnel is a publishing pipe. Both remove the need for port forwarding, and that is where the similarity ends.

Tailscale installs a daemon, tailscaled, on each machine and gives it a stable address in the 100.64.0.0/10 range. Peers then negotiate direct WireGuard sessions with each other. Cloudflare Tunnel installs cloudflared, which dials out to Cloudflare's edge over HTTPS and waits for inbound requests aimed at a hostname on a domain in your Cloudflare account.

Aspect	Tailscale	Cloudflare Tunnel
What it creates	A private mesh between your own devices, addressed over 100.64.0.0/10	A public hostname on a domain you have delegated to Cloudflare
Who can connect	Only devices enrolled in your tailnet and allowed by your ACL policy	Anyone on the internet, unless you add a Cloudflare Access policy
Transport	WireGuard, direct peer-to-peer when NAT traversal succeeds, DERP relay when it fails	TCP connections from `cloudflared` to Cloudflare, then HTTPS from the edge to the visitor
Protocol scope	Any IP traffic, including UDP, SMB, RDP and database wire protocols	HTTP and HTTPS by default, other protocols only through extra client tooling
Client requirement	A Tailscale client on every participating device	Nothing on the visitor side, just a browser
TLS ownership	End to end between peers, no certificate to manage	Terminated at Cloudflare's edge, certificate issued and held there

The free tiers reflect that split: Tailscale's Personal plan counts devices and users, while Cloudflare's Zero Trust free tier counts seats behind Access policies.

How does each one reach a Docker container with no public IP?

Both approaches ignore your router entirely. Neither one opens an inbound port, because both rely on connections that your host makes outward.

Tailscale on the host, services on published ports: you install the client on the Docker host, then reach containers at http://100.x.y.z:8096 using whatever port each container publishes. This is the simplest layout and needs no compose changes at all.
Tailscale as a sidecar container: you run the tailscale/tailscale image with NET_ADMIN and /dev/net/tun, then attach the app with network_mode: "service:tailscale". The app gets its own address and hostname in the tailnet, separate from the host, which is how you give one container an identity your ACLs can target.
Tailscale as a subnet router: you start the client with --advertise-routes=172.18.0.0/16 and approve the route in the admin console, so remote peers address containers on the Docker bridge network directly. Useful, but Docker's dynamically assigned subnets make this brittle unless you pin them in your compose file.
cloudflared on the host or in compose: the connector joins your Docker network and proxies to a service name, so an ingress rule points at http://nextcloud:80 rather than a published port. Your container never needs a host port binding, which is the cleanest firewall posture of the four.
Outbound requirements for both: cloudflared needs outbound TCP 443 and works behind almost any NAT, while Tailscale prefers UDP 41641 outbound for direct paths and falls back to relaying over 443 when UDP is blocked.

The practical difference: Tailscale gives the machine an address, Cloudflare Tunnel gives the service a URL.

How do you set up Tailscale on a Docker host, step by step?

The whole process takes about ten minutes on a fresh Debian or Ubuntu host, and most of that is waiting for an apt install.

Create the tailnet first: sign up, then note the ACL editor in the admin console. Everything you do later, including which laptop may reach which container, is expressed in that one JSON policy file, so it pays to open it before you enroll anything.
Install the client on the host: run curl -fsSL https://tailscale.com/install.sh | sh, then sudo tailscale up. The command prints a login URL. Approve it once and the machine keeps its address across reboots.
Use an auth key for unattended hosts: generate a pre-authorized key in the admin console and pass it with sudo tailscale up --authkey=tskey-auth-.... Tag the key, for example --advertise-tags=tag:docker, so ACLs can match the host by role instead of by name.
Disable key expiry on servers: device keys expire by default, which silently drops a headless box off the tailnet. Set the node to never expire in the console, or plan a renewal.
Turn on MagicDNS and verify: with MagicDNS enabled you reach the box at http://docker-host:8096 rather than memorizing a 100.x address. Confirm the path with tailscale status, which marks each peer as direct or relay.

Where that host lives is your decision. A home mini PC, a rented VPS, a NAS and a managed service are all valid. 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. In each case the install steps above are identical, because Tailscale only needs outbound connectivity.

How do you set up Cloudflare Tunnel on a Docker host, step by step?

The prerequisite is the part people miss: you need a domain whose nameservers point at Cloudflare. Without that delegation there is no hostname to publish, and no amount of connector configuration fixes it.

Delegate the domain: add the zone in the Cloudflare dashboard and switch your registrar's nameservers to the pair Cloudflare assigns. Propagation is usually quick, but allow for a slow registrar before you plan the rest.
Create the tunnel and copy the token: in Zero Trust, under Networks, create a tunnel and choose the Docker install method. Cloudflare hands you a long-lived token. Treat it as a credential, because anyone holding it can publish from your name.
Run the connector as a container: use cloudflare/cloudflared:latest with the command tunnel --no-autoupdate run --token $TUNNEL_TOKEN, put the token in an .env file rather than inline in docker-compose.yml, and attach the container to the same Docker network as your app.
Add public hostname routes: map app.example.com to a service URL such as http://gitea:3000. The DNS record is created for you as a proxied CNAME, so there is nothing to add by hand.
Decide on Access before you share the link: a bare public hostname is open to the internet and to crawlers. Adding an Access policy with email one time passcodes puts a login in front of it.
Where the connector runs: a home server, a NAS, a VPS and Yundera are all workable hosts, and on Yundera each app is reachable on a public HTTPS subdomain via NSL.SH mesh routing, so a tunnel is one choice among several rather than the only route in.

Verify with cloudflared tunnel list, which shows the connection count.

Which one is better for private admin panels only your team touches?

Tailscale, and the margin is not close. A Portainer instance on port 9443, a Traefik dashboard or a Grafana admin login has no business resolving in public DNS, and with a tailnet it never does.

Nothing to discover: a tailnet device has no public DNS record and answers nothing from the open internet, so credential stuffing and scanner traffic against your admin panel drop to zero by construction. A Cloudflare hostname stays publicly resolvable even with an Access policy in front, which means the login page itself is reachable and probeable.
Authentication you already own: Tailscale authenticates the device through your existing identity provider at enrollment, then every later connection rides that enrolled key. Nobody types a password into a self-hosted admin panel from an unknown browser.
ACLs scoped to a port: the policy file lets you write a rule granting tag:founder access to tag:docker:9443 and nothing else. The same box can hold a database on 5432 that only one machine may reach, expressed in a few lines of JSON rather than in iptables.
Tailscale SSH as a bonus: the client can terminate SSH itself, so you get access to the Docker host without distributing authorized_keys files or leaving port 22 listening anywhere.
The real cost: every admin needs the client installed. On a two person team with two laptops and two phones, that is four installs inside the Personal plan's limits. On a 30 person company with contractors on their own hardware, it becomes an onboarding task.

Use Cloudflare Tunnel for an admin panel only when you genuinely cannot install software on the accessing device, and then put an Access policy in front of it.

Which one is better for a service you need to share with clients?

Cloudflare Tunnel wins here for the same reason it loses on admin panels: the visitor needs nothing but a link. A client reviewing a staging build on an iPad in a meeting will not install a mesh VPN, and asking them to is how a review slips a week.

Zero friction on the far side: app.example.com resolves, serves a valid certificate and opens. No client, no invitation to accept, no device enrollment, no explanation of what a tailnet is.
Access policies instead of accounts: a Cloudflare Access policy with email one time passcodes lets you allow a named list of client addresses, for example everyone at @clientcompany.com, without creating users inside your self-hosted app. The visitor gets a six digit code by email and lands on your service.
Webhooks and machine callers work: Stripe, GitHub and any other service that posts to a URL can reach a tunnel hostname. They can never reach a tailnet address, so if your app receives webhooks, the decision is already made.
Sharing scales without seats on your side: 50 clients browsing a public hostname cost you nothing extra in connector configuration, while 50 Tailscale users means 50 enrollments and a plan that counts them.
What you give up: your traffic transits Cloudflare's edge, your certificate lives there, and the hostname is visible in Certificate Transparency logs, so the existence of the service is public even when the content is gated.

Tailscale has one credible answer for shared access: node sharing, which invites an external person's own tailnet device to reach a single machine. It works well for a contractor who already uses Tailscale. It does not work for a client who does not.

Do SSH, RDP, UDP and other non-HTTP services work on each one?

Tailscale treats everything as IP traffic, so the answer is yes by default. Cloudflare Tunnel is built around HTTP, and anything else needs either a client install on the far side or a paid Zero Trust feature, which undoes the main reason you picked it.

Protocol	Tailscale	Cloudflare Tunnel
SSH on 22	Works natively, plus optional Tailscale SSH with ACL-based authorization	Needs `cloudflared access ssh` on the client, or browser rendered SSH through Zero Trust
RDP on 3389	Works natively, connect to the peer address in any RDP client	Needs the WARP client enrolled, or browser rendered RDP on a paid Zero Trust plan
PostgreSQL on 5432 or MySQL on 3306	Works natively, point your client at the tailnet hostname	Needs `cloudflared access tcp --hostname db.example.com --url localhost:5432` on each developer machine
SMB on 445	Works, which is why Tailscale is common for NAS shares across sites	Not a practical fit, SMB over a public HTTP edge is not the intended use
UDP services, for example a game server on 25565 or a DNS resolver on 53	Works, UDP is carried like any other IP traffic	Private network UDP requires WARP, there is no plain tunnel equivalent
Plain HTTP and HTTPS apps	Works	Works, this is the native case

The pattern is consistent. If the thing you need to reach speaks anything other than HTTP, Tailscale handles it with no extra moving parts, while Cloudflare asks you to install cloudflared or WARP on the client. At that point you have a client install on every device anyway, and the comparison collapses back to which mesh you prefer.

How much latency and throughput do you give up with each?

Measure it yourself rather than trusting any published figure, because both results depend almost entirely on your network path. The shape of the cost, though, is predictable.

Tailscale on a direct path: two peers that complete NAT traversal exchange packets straight to each other, so added latency is roughly the encryption overhead plus the difference between the direct route and your old route. Confirm the path with tailscale ping hostname, which reports whether it went direct or via a relay, and check candidate paths with tailscale netcheck.
Tailscale on a DERP relay: when UDP is blocked, traffic detours through a Cloudflare-independent relay server chosen by region, adding that round trip to every packet. Relayed sessions are the single biggest performance cliff in a tailnet, and tailscale status flags them with relay next to the peer.
Kernel versus userspace WireGuard: on Linux the client uses the in-kernel WireGuard implementation where available and falls back to userspace wireguard-go otherwise, which costs CPU on low-power hosts. Tailscale's default MTU of 1280 bytes also means slightly more packets per megabyte than an untunneled link.
Cloudflare Tunnel is always a detour: the visitor connects to a Cloudflare data centre, which forwards to wherever your connector sits. If the visitor is next to your server but the chosen edge is not, you pay that geography twice on every request.
Hard protocol limits to plan around: Cloudflare returns error 524 when an origin takes longer than 100 seconds to respond, and the free plan caps request body size at 100 MB. Large uploads and long-running jobs need chunking or a different route.

For bulk transfers and interactive SSH, a direct tailnet path is the better instrument.

How much does each really cost over three years?

Both start at zero for a two person team, so the three year number is driven by what grows: users on one side, domains and plan tiers on the other. Check current pricing pages before you commit, because per user rates change.

Cost line	Tailscale over 36 months	Cloudflare Tunnel over 36 months
Entry tier	Free Personal plan covers 3 users and 100 devices, which fits a founder pair with laptops, phones and several Docker hosts	Tunnels are free on any Cloudflare plan, and Zero Trust access policies are free up to 50 seats
What makes it grow	Headcount and contractors, since billing is per user per month on paid plans once you pass the free user count	Feature tier, since larger upload limits, longer timeouts and advanced policies sit on paid plans
Mandatory extras	None, you do not need to own a domain	A registered domain delegated to Cloudflare, renewed annually for the full three years
Hidden operational cost	Onboarding each new device and renewing or disabling key expiry on headless hosts	Guarding the tunnel token, rotating it after staff changes, and auditing which hostnames are publicly resolvable
Escape hatch if pricing shifts	Headscale, an open source control server you self-host, keeps the same clients working	Nothing equivalent, moving off means rebuilding ingress with a reverse proxy and your own certificates

The honest summary: for two people, both are effectively free for 36 months and the money is not the deciding factor. The decision becomes financial somewhere around the point where you add a tenth teammate, and at that point Tailscale's per user billing is the line that moves while Cloudflare's stays flat.

Tailscale Serve and Funnel vs Cloudflare public hostnames: where do they overlap?

This is the one place the two products compete directly. Funnel publishes a tailnet service to the open internet, which is exactly what a Cloudflare public hostname does.

Serve is internal only: tailscale serve --bg 8096 puts a valid HTTPS certificate on your MagicDNS name, so you reach https://docker-host.tailnet-name.ts.net instead of an IP and a port. Nothing becomes public. This is the fastest way to stop browser certificate warnings on a self-hosted app.
Funnel is the public step: tailscale funnel --bg 8096 takes that same service and makes it reachable from any browser. You must first enable HTTPS certificates for the tailnet and grant the node the funnel attribute in your policy file, which is a deliberate speed bump.
Funnel's port restriction is the catch: inbound Funnel traffic is accepted on 443, 8443 and 10000 only. A Cloudflare hostname always answers on 443 with whatever path routing you configure, with no port list to work around.
The hostname is not yours: Funnel serves on a subdomain of ts.net, so you cannot publish app.yourcompany.com through it. If branding or a customer-facing URL matters, Cloudflare Tunnel or a reverse proxy is the answer.
Throughput expectations differ: Funnel traffic is relayed through Tailscale infrastructure and is positioned for demos, webhooks and light sharing rather than serving a busy site.
Where the service runs is a separate choice: a home server, a NAS, a VPS and Yundera all host the same containers, and each app on Yundera already answers on a public HTTPS subdomain via NSL.SH mesh routing, so Funnel may be redundant there.

Use Funnel for a quick public link. Use Cloudflare for a hostname you intend to keep.

Who can see your traffic, and what does each side log?

This is the sharpest privacy difference between the two, and it is structural rather than a matter of policy. With Tailscale your payload stays encrypted end to end between peers. With Cloudflare Tunnel your TLS terminates at the edge, so Cloudflare handles your requests in cleartext.

Tailscale sees metadata, not content: the coordination server distributes public keys and endpoint candidates so peers can find each other. It does not hold your private keys, which never leave the device. Even relayed traffic through DERP stays encrypted, because the relay forwards WireGuard packets it cannot read.
Cloudflare sees everything by design: terminating TLS is how it serves a certificate, applies WAF rules and enforces Access policies. Request headers, URLs, cookies and bodies pass through its proxy in plaintext. That is not a flaw, it is the only way an HTTP edge can work, but it means your self-hosted service is no longer a two party conversation.
What each dashboard records: Tailscale keeps network flow logs and device audit logs on paid tiers, showing which node talked to which and when. Cloudflare keeps Access authentication events naming who logged in, and HTTP analytics on the zone.
Public exposure is permanent: issuing a certificate for app.example.com writes that name into Certificate Transparency logs, which are searchable forever. A tailnet address appears in no public log at all.
The mitigation if you need Cloudflare anyway: keep anything sensitive behind a tailnet and publish only what genuinely needs a public URL, for example a marketing page or a webhook endpoint on a dedicated hostname.

If your threat model includes the transit provider, that rules out any proxy that holds your certificate.

Odoo Community Self-Hosted vs Odoo Online: Is a Private Cloud ERP Worth It for a Family of Four?

John — Sat, 03 Oct 2026 07:06:26 +0000

For a family of four, self-hosted Odoo Community is worth it in exactly one case: you already run a home server or a VPS, and you want several household functions (budgeting, shared expenses, household inventory, a family project board, contacts) living in one database with one login and one backup. If that is not you, Odoo Online's free single-app tier or two small single-purpose apps will serve the household better, because Odoo's real cost is not the licence, which is zero for Community, it is the hours you spend on upgrades, backups and access rules. Odoo Community is a genuine ERP with no per-user fee and no feature meter, but it hands you the full administration burden of an ERP for a workload that four people could partly cover with a shared spreadsheet.

TL;DR by reader profile

The household that already self-hosts (you run Docker on a mini PC and have Jellyfin, Nextcloud and Vaultwarden up): go Odoo Community self-hosted, because the marginal cost is one more container, one more subdomain and one more line in your backup job.
The single-purpose family (you only want to stop arguing about who paid for the groceries): stay off Odoo entirely and use a focused tool, because one Odoo app for shared expenses means carrying the whole framework, the Postgres database and the upgrade cycle for a fraction of its surface.
The home-business household (a parent invoices freelance clients and the family also wants shared budgeting): go Odoo Community self-hosted, because real invoicing, VAT handling and double entry accounting justify the suite, and per-user billing on the hosted side gets expensive once four people need logins.
The non-technical family with a willing admin of one (one parent is comfortable, nobody else is): stay on Odoo Online, because a database you cannot restore is worse than a subscription, and the single admin problem is the real failure mode here.
The privacy-led household (you want financial records and household data off third party servers on principle): go Odoo Community self-hosted, because Community has no licence lock, no telemetry requirement and the Postgres database is yours to dump, inspect and move.
The curious tinkerer (you want to learn ERP concepts and do not mind breaking things): go Odoo Community self-hosted on a disposable instance, because learning the data model is the point and nothing of value is at risk.

The central tradeoff is simple: Odoo Online charges you money per user and keeps the maintenance, while Odoo Community charges you nothing per user and hands you every upgrade, every backup and every access rule to manage yourself.

What can Odoo actually do for a family of four?
Odoo Community vs Odoo Online: what actually changes when you self-host
How much does it really cost over three years?
What hardware and resources does self-hosted Odoo need for four users?
How do you run Odoo Community in Docker on a home server?
Is moving a database off Odoo Online clean, or does it break?
Which Odoo apps are worth enabling for a household, and which ones add noise?
How do you give four family members the right level of access?
What breaks at upgrade time, and how much work is it?
Backups, restore and what happens when the household admin is away
Odoo versus Firefly III, Grocy and Mealie: is one big ERP the right shape?

What can Odoo actually do for a family of four?

Odoo is a modular business suite, not a personal finance app. You install individual apps onto one Postgres database, and each one adds models, menus and permissions to the same system. For a household, four or five of the roughly fifty official apps carry real weight, and the rest are commercial machinery you will never open.

Accounting (Community edition, named Invoicing in some releases): gives you double entry bookkeeping with bank accounts, journals and reconciliation, so shared household spending reconciles against a real statement import rather than a manual tally.
Expenses: lets each family member log a receipt against a category and have it approved, which is the closest Odoo gets to the Splitwise style question of who paid for what.
Inventory: tracks physical stock with locations and quantities, usable for a pantry, a freezer, tools or spare parts, with reordering rules that trigger when a quantity drops below a threshold you set.
Project and To-do: provide shared task boards with assignees and deadlines, suitable for a renovation, a holiday or a weekly chore rota.
Contacts and Calendar: hold the household's address book and shared events, with the caveat that Odoo's calendar is not a CalDAV server, so phone sync is not native.

Two honest limits. Odoo has no household mode, so every concept arrives in business vocabulary: your family members are partners or employees, and the grocery budget is an analytic account. And Community omits Odoo Studio, the no code customisation layer, so reshaping those labels means Python modules or XML views, not a settings screen.

Odoo Community vs Odoo Online: what actually changes when you self-host

Odoo Online is the hosted SaaS run by Odoo SA, billed per user, with upgrades and backups handled for you. Odoo Community is the open source edition under LGPLv3 that you run yourself. They are not the same product with a different bill attached, and the gaps matter before you commit a household to one.

What changes	Odoo Online	Odoo Community self-hosted
Cost model	Per user per month, with a free plan limited to one app	No licence fee, unlimited users, you pay for hardware and your time
Enterprise-only apps	Studio, Sign, Documents and the IAP services are available	Absent, so customisation means Python modules and XML views
Bank and OCR automation	Bank statement sync and invoice digitisation sold as paid IAP credits	Manual CSV or OFX statement import, no OCR
Third party modules	Blocked, you run Odoo's code only	Any module, including the free OCA catalogue of community addons
Upgrades	Run by Odoo on request	Yours, via the migration scripts or OpenUpgrade
Database access	No direct Postgres access	Full `psql` access, `pg_dump` whenever you want

Where you run it is the next decision. Four users with light use is a small workload, so the realistic options are a home server or mini PC, a NAS that supports Docker, a self-managed VPS, 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. All four keep the database on infrastructure you control, which is the actual point of leaving the hosted edition.

How much does it really cost over three years?

Do not compare a monthly subscription against zero. Compare it against hardware, electricity and your own hours. Odoo ships a major release roughly once a year, so a 36 month window contains two or three version jumps, and that is where self-hosting spends its real budget.

Cost line	Odoo Online	Odoo Community self-hosted
Licence	Published per user, per month fee, multiplied by 4 users and 36 months	Zero, LGPLv3, unlimited users
Hardware	None	One mini PC, NAS or VPS, amortised over 36 months, shared with your other containers
Electricity	None	A low power x86 box runs continuously, so count 36 months of standby draw at your tariff
Upgrades	Included, Odoo runs the migration	2 to 3 major jumps, each a test restore plus a production run, measured in evenings not minutes
Backups	Included	Your own `pg_dump` plus filestore copy, plus offsite storage you pay for
Paid add-ons	Bank sync and OCR sold as IAP credits per document	Not available, so the cost becomes your manual data entry time

The honest arithmetic is this. Take the published Odoo Online price for your country, multiply by 4 users and 36 months, and that is the number self-hosting must beat. Then price your own time at anything above zero and add 2 to 4 hours per upgrade cycle, plus the first weekend you lose to setup and chart of accounts configuration. If the box already exists and already has Docker, self-hosting usually wins on cash and loses on hours. If you would buy hardware purely for Odoo, the subscription often wins outright at four users.

What hardware and resources does self-hosted Odoo need for four users?

Four users is a tiny workload. The constraint is not CPU, it is RAM, because Odoo keeps a Python worker process per concurrent request and Postgres wants cache of its own.

RAM, the real floor: budget 4 GB for the box if Odoo and Postgres are the only things on it, and 8 GB if it shares a host with Jellyfin, Nextcloud or Immich, because Odoo's upstream sizing guidance assumes roughly a gigabyte per worker once the soft and hard memory limits are respected.
Workers, sized down not up: the documented rule is workers = 2 * cores + 1, which on a 4 core mini PC suggests 9, and that is absurd for a household, so set workers = 2 in odoo.conf and leave the rest of the memory to Postgres.
Postgres, a separate container: run a recent major version, 13 or newer for current Odoo releases, with its own named volume, and never let it share a volume with the Odoo filestore.
Disk, driven by attachments not rows: the database itself stays small for a family, but the filestore under /var/lib/odoo/filestore grows with every scanned receipt and PDF invoice, so plan storage around how many documents you attach.
Architecture, check before you buy: the official Odoo Docker images have historically targeted amd64, so a Raspberry Pi is not a safe default and an x86 mini PC or a small VPS is the lower risk choice.

Where this runs is a separate question from how much it needs. A NAS with Docker, a self-managed VPS and a home mini PC all clear the bar. 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 in the same list of options.

How do you run Odoo Community in Docker on a home server?

The shape is two containers and three volumes. Odoo publishes official images on Docker Hub, tagged by major version, so you pin odoo:18 rather than latest and decide for yourself when to jump.

Pin both images: one service from the odoo image and one from postgres, each with an explicit tag, because an unpinned Postgres that jumps a major version on docker compose pull will refuse to start on the old data directory.
Pass the database credentials Odoo expects: the image reads HOST, USER and PASSWORD, and Postgres needs matching POSTGRES_USER, POSTGRES_PASSWORD and POSTGRES_DB, so a typo here produces a database selector that never loads.
Mount three things, not one: a named volume on /var/lib/odoo for the filestore and sessions, a Postgres volume on /var/lib/postgresql/data, and a host directory on /mnt/extra-addons so OCA modules survive a container rebuild.
Expose 8069 and 8072: the web interface answers on 8069, and longpolling or the gevent worker answers on 8072, which chat and live notifications need, so a reverse proxy that forwards only 8069 leaves the interface silently waiting.
Lock the first boot down: set a real admin_passwd in odoo.conf, set list_db = False once your database exists, and set proxy_mode = True behind a reverse proxy so Odoo trusts the forwarded headers and generates correct HTTPS links.

That reverse proxy and certificate work is the part families underestimate. Yundera installs self-hosted apps from an app store in one click rather than assembling compose files by hand, and reaches each app on a public HTTPS subdomain via NSL.SH mesh routing, so no static IP, no port forwarding and no manual certificate setup are required. A self-managed VPS with Caddy or Nginx Proxy Manager, or a NAS with its own reverse proxy app, gets you to the same place by hand.

Is moving a database off Odoo Online clean, or does it break?

It is mechanically simple and semantically messy. Odoo Online lets you download a full backup, so you get your data out without a scraper, but a database that touched Enterprise apps will not load cleanly into Community.

Export the right artefact: the Odoo Online database manager produces a zip containing dump.sql, a filestore/ directory and manifest.json, and you want the version with the filestore, because the SQL alone leaves every attachment and logo as a broken reference.
Match the major version exactly: a dump from Odoo 17 restores into Odoo 17, not into 18, so your first self-hosted deployment should pin the version you are leaving and upgrade afterwards as a separate, reversible project.
Uninstall Enterprise apps before you dump, not after: manifest.json lists installed modules, and Community has no web_enterprise, Studio, Sign or Documents, so a restore that still references them throws module loading errors on first boot and leaves views blank.
Expect customisations to vanish: anything built in Studio lives in Enterprise machinery, so field additions and custom views made there are the one category of work you genuinely lose, and you rebuild them as XML or accept the stock layout.
Restore twice, deliberately: load the zip through the database manager with list_db = True temporarily enabled, confirm your journals, partners and attachments open, then restore again into a clean container before you let the family near it.

Budget a full evening. The data moves in minutes. Proving that four people's accounting history, document attachments and sequence numbers all survived is what takes the time.

Which Odoo apps are worth enabling for a household, and which ones add noise?

Installing an Odoo app is close to irreversible. Each one pulls dependencies, adds menus and creates records, and uninstalling drops the data those modules own rather than politely hiding it. Enable fewer apps than you think you need, then add one at a time.

App	Enable or skip for a family	Why
Invoicing or Accounting	Enable first, alone	It forces the fiscal localisation choice, which is effectively permanent once journal entries exist
Project or To-do	Enable	Shared task boards with assignees cost nothing in configuration and get used weekly
Inventory	Enable only if you will actually count things	It adds warehouses, operation types and stock moves, so a pantry list becomes 3 clicks instead of 1
Sales and CRM	Skip unless a parent invoices clients	They add pipelines, quotation templates and customer stages with no household meaning
Website and eCommerce	Skip	They expose a public CMS surface you then have to secure and patch for zero family benefit
Employees and Payroll	Skip	Payroll localisations are an Enterprise concern, so Community gives you the HR shell without the useful part
Point of Sale and Manufacturing	Skip	Both require session or routing workflows that make no sense at four users

Two practical rules. Test every app on a duplicate database first, because the database manager can clone yours in one action and the clone is the only safe place to discover what Website installs alongside itself. And watch the menu count: once the top bar carries more than 6 or 7 apps, the people who are not the household admin stop opening Odoo at all, which quietly ends the project.

How do you give four family members the right level of access?

Community has no per-user fee, so create four real users rather than sharing one login. The work is not account creation, it is deciding who can see the bank journal.

Separate internal users from portal users: internal users get the back office and count against nothing in Community, while a portal user sees only documents explicitly shared with them, which suits a teenager who needs to view a chore board but not the mortgage.
Grant per app, never globally: the Settings and Administration groups unlock everything including other users' records, so exactly 1 account in the household should hold them, and the other 3 get app level rights such as Accounting Billing instead of Billing Administrator.
Use record rules for the money: group membership controls which menus appear, but row level visibility comes from ir.rule records, so hiding one bank journal or one analytic account from the children means a rule, not a checkbox, and you need developer mode to see the full group list at all.
Turn on two factor authentication for the admin: the TOTP support in Community covers the account that can reassign every right, and that is the one worth protecting if the instance answers on a public hostname.
Decide about SSO deliberately: the auth_oauth and auth_ldap modules exist in Community, so Odoo can join an existing household identity provider, but every extra authentication path is another thing that breaks at upgrade time.

Expect iteration. The first configuration is always too open, the second too tight, and the version that actually works usually arrives after someone finds a report they should not have been able to open.

What breaks at upgrade time, and how much work is it?

This is the single biggest difference between the two editions, and it is where a family instance either survives or quietly freezes on an old version forever. Odoo cuts a major release about once a year and maintains roughly the three most recent, so standing still is a decision with an expiry date.

There is no in place jump: you move one major version at a time, 17 to 18 and then 18 to 19, because the database schema migration scripts are written per version step and skipping one leaves tables half converted.
The free route is OpenUpgrade: Odoo's own upgrade service is tied to its subscriptions and platforms, so the dependable Community path is the OCA OpenUpgrade project, which means running migration scripts yourself against a restored copy rather than clicking a button.
Third party modules decide your calendar: every OCA addon in /mnt/extra-addons needs a branch for the target version, and if one of your 3 or 4 installed addons has not been ported, you either wait, port it, or uninstall it and lose its data.
Postgres upgrades separately: bumping the Odoo image does not touch the database engine, so plan a second, independent pg_dump and restore cycle when you change Postgres major versions.
Accounting is the risky surface: reports, taxes and localisation modules change between releases, so verify a tax report and a reconciliation after the upgrade, not just that the login page loads.

Realistic cost: one evening per major step on a test restore, plus a shorter production run once the test passed. Do it annually and it stays an evening. Skip three years and it becomes a project.

Backups, restore and what happens when the household admin is away

Two things must leave the box: the Postgres database and the filestore. A backup of one without the other restores an Odoo that opens, lists every invoice, and cannot show you a single attachment.

Dump the database on a schedule: a nightly docker exec running pg_dump -Fc into a dated file is enough at four users, and the compressed custom format restores selectively, which matters when you only want one table back.
Copy the filestore in the same job: archive /var/lib/odoo/filestore alongside the dump and keep the pair together, because a mismatched dump and filestore produce broken document links that are tedious to trace.
Get a copy off the hardware: restic, Borg or Duplicati to a second disk and a remote target satisfies the 3-2-1 rule, and the household's financial history is exactly the data you do not want living on 1 drive in 1 building.
Test a restore every 3 months: restore the latest pair into a throwaway container, log in, open a bank reconciliation and a receipt attachment, then delete it, because an untested backup is a hypothesis.
Write the runbook down: one page covering where backups live, the admin_passwd master password, the restore commands and the hostname, stored in a shared vault such as Vaultwarden, is what turns a 2 week outage into a 1 hour one.

The admin being away is the real risk, not disk failure. A hosted database has a support channel when the person who built it is on a plane. A self-hosted one has whoever else in the house can follow your page of instructions, so write them for someone who has never opened a terminal.

Odoo versus Firefly III, Grocy and Mealie: is one big ERP the right shape?

The fair comparison is not feature by feature, it is one database and one upgrade cycle against three or four small apps that each do one job properly.

Household need	Odoo Community	The focused alternative
Shared budgeting and bank reconciliation	Real double entry, journals and tax handling, configured once in business vocabulary	Firefly III is built for personal finance, but its data model is per user, so a shared household view usually means 1 shared login
Pantry and household stock	Inventory with locations and reordering rules, overbuilt for a fridge	Grocy tracks products, expiry dates, chores and batteries, in household language from the first screen
Recipes and meal planning	Nothing native	Mealie does recipes, meal plans and shopping lists, which Odoo cannot approach
Chores and shared tasks	Project boards with assignees and deadlines	Vikunja or a Nextcloud Deck board, lighter and faster to open
Freelance invoicing from the same data	Invoices, sequences and VAT reports that reference the same partners and accounts	Needs a separate invoicing tool and manual reconciliation between systems
Operational load	2 containers, 1 Postgres, 1 annual upgrade, 1 backup pair	3 or 4 containers, 3 or 4 release cycles, 3 or 4 backup targets to remember

The deciding question is whether your household genuinely needs one of those rows joined to another. If invoices, expenses and the shared budget must reconcile against each other, Odoo's single database earns its weight. If the needs are a budget, a pantry list and a chore board that never touch, the focused apps win, because each one is understandable by every member of the family rather than only the admin.

How to Self-Host WordPress with Docker and Strip Every Third-Party Tracker

John — Thu, 01 Oct 2026 07:06:23 +0000

A self-hosted WordPress install is not private by default. A stock install of WordPress 6.x on Docker reaches out to api.wordpress.org on a schedule, loads visitor avatars from Gravatar, and the moment you add Jetpack, Akismet, Elementor or a theme that bundles Google Fonts remotely, your visitors' IP addresses start landing in logs you do not control. The fix is mechanical and takes an afternoon: a three-container compose stack, roughly a dozen constants in wp-config.php, a handful of remove_action calls in a must-use plugin, locally hosted fonts, and a network capture to prove the page now talks to exactly one domain.

TL;DR

The two person startup running its own marketing site (a founder and a designer, no sysadmin): Self-host WordPress on a small VPS or a Personal Cloud Server and spend the afternoon on the de-telemetry pass, because the alternative is paying a hosted builder monthly and still handing visitor data to its CDN.
The agency shipping client sites under GDPR scrutiny (a two person studio with EU clients): Do the full pass and keep it as a reusable mu-plugin, because "we removed Google Analytics" is not a defensible answer when the theme still pulls fonts.google.com on every page load.
The homelab tinkerer running WordPress behind Tailscale or a reverse proxy: Strip the outbound calls anyway, because an internal-only site that still phones home leaks the fact that your instance exists along with your server's IP.
The developer who wants automatic updates and plugin installs from the dashboard: Use the partial profile, leave DISALLOW_FILE_MODS off and block only the avatar, font and analytics calls, because full lockdown trades convenience for a monthly manual update ritual.
The site owner with an existing WordPress install on shared hosting: Migrate to Docker first, then strip, because you cannot capture outbound traffic or edit php.ini on a host that gives you cPanel and nothing underneath it.
The reader who only needs a brochure site and no comments, no forms, no accounts: Consider a static generator instead, because the cheapest way to leak nothing is to ship HTML with no PHP runtime at all.

The central tradeoff: every outbound call you cut removes a convenience that WordPress built on top of it, so you are trading dashboard update notices, spam filtering and free avatars for a page that touches your domain and nothing else.

What does a stock WordPress install actually send to third parties?
Which Docker setup do you need before you can audit anything?
How do you capture every outbound request your site makes?
What exactly does Jetpack send, and what breaks when you remove it?
How do you stop Gravatar leaking your commenters' email hashes?
How do you self-host Google Fonts without breaking your theme?
Should you block api.wordpress.org, and what do you lose?
Which plugins phone home silently, and how do you catch them?
How do you replace Google Analytics with something you own?
What cookies does WordPress set, and which ones actually need consent?

What does a stock WordPress install actually send to third parties?

Download WordPress 6.x, run it with nothing added, and the install is already talking to servers outside your control. Most of it is core behaviour, not plugins, and none of it is announced in the admin UI.

Update checks to api.wordpress.org: Core, themes and plugins each poll separate endpoints on a twice daily schedule through WP-Cron, and the core request sends your site URL, PHP version, MySQL version, locale and installed plugin list as query parameters.
Gravatar avatar requests to secure.gravatar.com: Every comment and every author byline renders an <img> pointing at an MD5 hash of the user's email address, so your visitor's browser, not your server, makes that request and exposes their IP to Automattic.
Browse Happy and Serve Happy notices: The dashboard calls out to check whether the visiting browser or your PHP version is considered outdated, which fires from wp-admin rather than the front end.
Bundled remote fonts in the active theme: Twenty Twenty-Four ships fonts locally, but a large share of commercial themes still enqueue fonts.googleapis.com in functions.php, which means a font request on every single page view.
oEmbed discovery for pasted links: Paste a YouTube or X URL into the editor and WordPress fetches metadata from that provider at save time, then embeds an iframe that loads on render.

Where you run the stack determines whether you can see any of this. 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. A self-managed VPS, a home server, a NAS or Yundera all give you container level network visibility; shared cPanel hosting does not.

Which Docker setup do you need before you can audit anything?

You cannot see what you cannot intercept. Shared hosting hands you a dashboard and hides the network layer, so the first step is a stack where every container is yours and docker compose logs is available.

Three services, not one: Run wordpress:6-php8.3-fpm for PHP, mariadb:11 for the database and nginx:alpine as the front end, defined in a single docker-compose.yml. The all-in-one wordpress:apache image works too, but splitting nginx out lets you log and block outbound traffic at one chokepoint later.
A bind mount, not an anonymous volume: Map ./wp-content:/var/www/html/wp-content so you can grep a theme's functions.php for fonts.googleapis.com from the host without entering the container.
A WP-CLI sidecar: Add a wordpress:cli service sharing the same volume. Commands like wp plugin list --format=csv and wp cron event list become one-liners, and you will use both when you hunt for scheduled phone-homes.
A dedicated bridge network: Put the three services on their own network rather than the default bridge. This becomes the boundary you watch, and it keeps MariaDB off any published port, so only port 443 reaches the internet.
Real DNS and TLS before you test: Font fallbacks, oEmbed and update checks behave differently over plain HTTP, so audit the site at its final HTTPS hostname, not at localhost:8080.

Any of a self-managed VPS, a home server, a NAS or Yundera gives you that container level control, and Yundera installs the stack from an app store rather than from a compose file you write yourself. What matters for the audit is only that you own the host and can reach the Docker socket.

How do you capture every outbound request your site makes?

Two different leaks need two different instruments. Server side calls come from PHP via the WP HTTP API and never appear in your browser. Front end calls come from the visitor's browser and never appear in your server logs. Audit both, or you will declare victory while Gravatar is still loading.

Method	What it catches	What it misses
Browser DevTools, Network tab, hard reload	Every font, avatar, iframe, script and beacon the page loads, with the full third party domain list	All PHP side requests, including update checks and oEmbed fetches
`pre_http_request` filter in a mu-plugin, logging to `error_log`	Every WP HTTP API call with URL, method and calling plugin	Direct `curl_exec` or raw socket calls that bypass the API
`tcpdump -i any -n 'port 53'` inside the container	DNS lookups for anything the stack resolves, including bypasses	Nothing on the wire, but it shows domains without payloads
nginx or firewall egress logs at the host	Every connection the container actually opens, by destination IP	Domain names, since you see IPs and must reverse them

Start with the filter. Drop a file in wp-content/mu-plugins/audit.php that hooks pre_http_request, writes the URL and debug_backtrace() to the PHP log, and returns null so nothing is blocked. Then run wp cron event run --due-now to force the scheduled checks instead of waiting 12 hours. Finally load the front page in a private window with cache disabled and count the distinct domains in DevTools. On a stock install with one commercial theme you will typically see 3 to 6 external domains. Write that number down. It is your baseline.

What exactly does Jetpack send, and what breaks when you remove it?

Jetpack is not a plugin so much as a client for WordPress.com. Activating it requires connecting your site to an Automattic account, and from that point several of its features work by proxying through Automattic infrastructure rather than running on your server. That is the design, not a flaw, and it is the reason a privacy clean install cannot keep it.

Stats and the activity log: Page views are recorded by a pixel served from Automattic, so visitor IP and user agent are processed off your server. Replace it with a self-hosted analytics tool and you lose the dashboard widget, nothing else.
Photon and the CDN for images: Your uploads are fetched by Automattic, cached, and served to visitors from their edge. Turn it off and images come from your own wp-content/uploads, which means your server now carries that bandwidth.
Related Posts and search: Both are computed from an index Automattic holds of your content. Removing them costs real functionality, and the local replacements are slower on sites past a few thousand posts.
Akismet spam filtering: Comment text, author name, email and IP are sent to Akismet for scoring. The honest replacement is closing comments, moving them to a self-hosted system, or accepting manual moderation.
Downtime monitoring and backups: These depend on an external service by definition. Swap in your own uptime check and a mysqldump cron.

Remove it cleanly with wp plugin deactivate jetpack && wp plugin delete jetpack, then check wp option list --search='jetpack*' because the connection tokens and ten or more options survive deletion. Disconnect the site from WordPress.com before deleting, otherwise the stale connection lingers on their side.

How do you stop Gravatar leaking your commenters' email hashes?

A Gravatar URL is not anonymous. WordPress hashes the lowercased email address and puts that hash in the image path, and because email addresses come from a small guessable space, anyone holding the hash can confirm a specific address by hashing it themselves. The request also carries the visitor's IP and the referring page, so Automattic sees who read which article, not just who commented.

Turn avatars off globally: Settings, then Discussion, then uncheck Show Avatars. From the CLI that is wp option update show_avatars 0. This kills the request on the front end and in the comments list, and it is the only change that removes the hash entirely rather than hiding it.
Do not rely on the default avatar setting: Choosing Mystery Person or Blank still generates a secure.gravatar.com URL with the d= parameter, so the lookup happens anyway. Only the Gravatar logo option behaves differently, and it is still a remote call.
Serve local avatars if you need faces: Simple Local Avatars stores an uploaded image per user in your own media library and short circuits get_avatar. Useful on a multi author blog where bylines matter.
Filter it in code for belt and braces: In your mu-plugin, add add_filter('pre_get_avatar', ...) returning an empty string, or add_filter('option_show_avatars', '__return_zero'). A theme or plugin that calls Gravatar directly bypasses the setting, and the filter catches most of those.
Check the admin side too: The user list, the at a glance widget and comment moderation screens all render avatars, so confirm with DevTools on /wp-admin/users.php after the change.

Reload the front page and the external domain count from your baseline should drop by one.

How do you self-host Google Fonts without breaking your theme?

Remote font loading is the leak most people miss, because the page looks identical whether the font comes from your domain or from Google. A German court has already ruled that passing visitor IP addresses to Google this way without consent is unlawful, so this is not a theoretical concern for an EU facing site.

Find the enqueue first: Run grep -ri "fonts.googleapis\|fonts.gstatic" wp-content/ on the host. Expect hits in the theme's functions.php, in theme.json under fontFace, and inside page builders like Elementor or Astra, which often expose a Load Fonts Locally toggle in their own settings.
Download only what you use: A typical theme requests 2 font families at 2 weights each. Pull the woff2 files, latin subset only, and you end up with 4 to 8 files of a few tens of kilobytes rather than a stylesheet that resolves to a second domain.
Declare them yourself: Put the files under wp-content/themes/<child>/fonts/, write @font-face blocks with font-display: swap, and keep the exact same font-family names the theme uses in its CSS. Matching the names is what stops the layout shifting.
Dequeue the remote handle: In your mu-plugin call wp_dequeue_style() and wp_deregister_style() against the theme's font handle, then enqueue your local stylesheet with a later priority. OMGF automates the same job if you prefer a plugin.
Preload the two critical faces: Add <link rel="preload" as="font" crossorigin> for the body and heading weights only. Preloading all eight costs more than it saves.

Serving those files is your server's job now, which is true on a self-managed VPS, a home server, a NAS or Yundera alike. Verify with DevTools that fonts.gstatic.com no longer appears.

Should you block api.wordpress.org, and what do you lose?

This is the one call worth keeping. The update check tells your site that WordPress 6.x shipped a security release, and a site that never learns about security releases is a worse privacy outcome than one that pings a known endpoint twice a day. The useful move is to narrow the allowlist to that single destination and block everything else by default.

Level	How you do it	What it costs you
Allowlist only wordpress.org	`define('WP_HTTP_BLOCK_EXTERNAL', true);` plus `define('WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.wordpress.org');` in `wp-config.php`	Nothing functional, and any plugin that quietly calls a vendor endpoint now fails silently, which is how you find it
Drop the cosmetic pings	`remove_action('admin_init', 'wp_check_browser_version')` and the Serve Happy hook in your mu-plugin	Two dashboard notices you were ignoring
Disable auto updates, keep checks	`define('AUTOMATIC_UPDATER_DISABLED', true);`	You now apply every release by hand, so budget 15 to 30 minutes per month
Full lockdown	`define('DISALLOW_FILE_MODS', true);` plus unscheduling `wp_version_check`	No update notices, no plugin installs from the dashboard, and you must track releases yourself

Pick the first two rows and stop. The data in a core update request is your site URL, PHP and database versions and a plugin list, which is modest compared with losing patch awareness. If you do go to full lockdown, pair it with a rebuild pipeline: pin the image tag in docker-compose.yml, update the tag deliberately, and run wp core version after every rebuild to confirm what you are actually serving.

Which plugins phone home silently, and how do you catch them?

Assume every plugin with a paid tier talks to its vendor. Licence validation is legitimate, but the same request often carries an install fingerprint, and some plugins bundle a telemetry SDK that reports your active plugin list and admin email unless you decline a prompt you clicked past during setup.

Licence and activation checks: Premium page builders, form plugins and SEO tools validate a key against the vendor's API, usually on a daily schedule. These cannot be removed without disabling the licence, so the honest options are to accept the call, allowlist that one host, or use a free alternative.
Opt in telemetry frameworks: Freemius is the common one, and it appears inside dozens of freemium plugins rather than as a plugin of its own. Grep for it directly with grep -rl "freemius\|Freemius" wp-content/plugins/, then check for a wp_fs_* prefixed row in the options table.
Remote asset loading: Some plugins pull icon sets, map tiles or script libraries from a CDN at render time rather than bundling them. DevTools catches these because they show up as front end requests from a domain you never configured.
Analytics and consent plugins: A cookie banner plugin that fetches its own config from the vendor is leaking the exact visitors it claims to protect. Check these first, since they load before anything else on the page.
Email and form delivery: A contact form that posts through a vendor relay instead of your SMTP server sends submission content off your server. Point it at your own SMTP host instead.

Your audit log from earlier makes this quick: run wp cron event run --due-now, then read the mu-plugin log and map each logged URL to the plugin that called it using the backtrace.

How do you replace Google Analytics with something you own?

GA4 is the single largest leak on a typical WordPress site, and it is also the easiest to remove because nothing on the site depends on it. The replacement question is really about how much infrastructure you want to run for the numbers you actually read.

Option	What it adds to your stack	Tradeoff
Matomo, self-hosted	One PHP container plus a database, or the WP-Matomo plugin inside the existing install	Heaviest feature set, including goals and heatmaps, and the database grows fastest
Plausible Community Edition	Two more containers, PostgreSQL and ClickHouse	Cookieless by design and a very small script, but the most moving parts to maintain
Umami	One Node container plus PostgreSQL or MySQL	Light and simple, with a narrower report set than Matomo
GoAccess on nginx logs	Nothing in the browser at all	Zero JavaScript and zero consent question, but no distinction between a human and a crawler without tuning

Four practical notes. Configure IP anonymisation before you record a single hit: Matomo can mask the last 2 bytes of each address, which keeps country level reporting while discarding the identifier. Serve the tracker from your own domain, not a vendor CDN, otherwise you have moved the leak rather than closed it. Keep the script local by enqueueing it in your mu-plugin with wp_enqueue_script so a theme update cannot reintroduce the Google tag. Finally, delete the old integration properly: wp plugin list --status=active will often reveal a Site Kit or GA plugin still present, and the measurement ID is frequently hardcoded in the theme's header template as well.

Server log analysis is the one option that survives an ad blocker.

What cookies does WordPress set, and which ones actually need consent?

A clean install sets fewer cookies than most people assume, and almost all of them fall under the strictly necessary exemption, which means no banner is required for them. The banner question is created by what you add, not by WordPress itself.

wordpress_test_cookie: Set on the login page to confirm the browser accepts cookies, and expires with the session. Strictly necessary, no consent needed, and it never reaches a logged out visitor browsing an article.
wordpress_sec_ and wordpress_logged_in_ with a hash suffix: The authentication pair, scoped to the admin area and the site respectively. They last 2 days, or 14 days when the user ticks Remember Me. Necessary for a logged in session, so exempt.
wp-settings-{user_id} and wp-settings-time-{user_id}: Store admin interface preferences such as editor state for 1 year. Only ever set for authenticated users, so again exempt, and irrelevant on a site with two staff accounts and no public registration.
comment_author_, comment_author_email_ and comment_author_url_: Set when someone comments and retained for roughly a year. Since WordPress 4.9.6 the comment form carries a tick box that gates them, and comment_cookies_consent records the choice. Leave that box unticked by default.
WooCommerce session and cart cookies: woocommerce_cart_hash, woocommerce_items_in_cart and wp_woocommerce_session_ appear the moment you install the plugin. Cart function is necessary; the marketing extensions bolted onto it usually are not.

Verify the real list rather than trusting a policy template. Open DevTools, Application, Cookies, then load the front page in a private window as an anonymous visitor. If the only entry is a cookieless analytics flag or nothing at all, you do not need a consent banner for a reading visitor.

Best Spliit Alternatives for Self-Hosting: When Splitwise, a Spreadsheet or a Plain-Text Ledger Wins

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

Self-host Spliit only if the group splitting the bills is stable, recurring and at least four people, and you already run Postgres with nightly backups for something else. For a single holiday, a two-person household or a group that scatters after one weekend, the hosted instance at spliit.app, Splitwise, a shared spreadsheet or three lines in a plain-text ledger will settle the same money with none of the container, database, domain and backup upkeep. Spliit is a genuinely good open source Splitwise alternative, but it is a web app with no accounts and no notifications, so the person who hosts it inherits every support request from everyone else in the group.

TL;DR by reader profile:

Solo developer with an established homelab (you already run a Docker host, Postgres and restic snapshots for a flatshare of four): self-host Spliit, because the marginal cost is one container, one database and one subdomain on infrastructure you already patch.
Occasional trip organiser (one ten day ski trip a year, eight people, half of them on iPhones you will never configure): use the hosted spliit.app instance or Splitwise, because uptime and link sharing matter more to you than owning the rows.
Flatshare with fixed monthly bills (rent, power, internet, same four names every month): use a shared spreadsheet with one row per bill, because your split rarely changes and a sheet needs no reverse proxy.
Plain-text accounting user (you already keep hledger or beancount files in Git): keep using the ledger, because one split posting per shared expense reuses a workflow you trust and version control you already back up.
Nextcloud owner (you run Nextcloud for files and calendars anyway): install Cospend in Nextcloud instead, because you inherit real user accounts, sharing and existing backups rather than adding a second stack.
Privacy-driven self-hoster (you will not put who you travelled with on a third-party server): self-host Spliit, but plan the network exposure first, because its group URLs are the only access control it ships with.

The central tradeoff is simple: Spliit gives you ownership of the data and none of the convenience of an account system, so you are trading a managed service's uptime and push notifications for a container you patch, a database you back up and a link every group member must not lose.

What Spliit actually does, and what it leaves out on purpose
Which Spliit alternatives are genuinely comparable?
When is hosted Splitwise the better answer than a Spliit container?
Can a shared spreadsheet replace Spliit for a four-person flatshare?
When does a plain-text ledger beat Spliit outright?
Spliit vs Nextcloud Cospend: which self-hosted splitter fits a homelab?
What does Spliit's no-login group URL model mean for you?
Does Spliit survive contact with non-technical group members?
Are the receipt scanning and S3 document features worth wiring up?
How much maintenance does a Spliit stack really cost over three years?
Where should you run Spliit, and who holds the data?

What Spliit actually does, and what it leaves out on purpose

Spliit is an open source expense splitter: you create a group, add the people in it, log expenses, and it tells you who owes whom. Sébastien Castiel maintains it as a Next.js application backed by PostgreSQL, published as a Docker image, with a free hosted instance at spliit.app. It covers the core Splitwise job well: splits by shares, exact amounts or percentages, expense categories, running balances and a suggested set of reimbursements that clears the debts in the fewest transfers.

The omissions are deliberate, and they decide whether self-hosting makes sense for you.

No user accounts at all: access to a group is the group URL, which contains a random identifier, so there is nothing to log into, no password reset, and no per-member permissions.
No notifications: Spliit sends no email and no push reminders, so nobody is nudged to settle up and you chase people in your group chat anyway.
No money movement: it records that Sam owes you 42 EUR, it does not transfer anything, so you still settle in your banking app.
Identity lives in the browser: the active participant is remembered client side, so opening the same group on a phone and a laptop means selecting who you are again.
No multi-currency conversion: you set a currency symbol for the group, so a trip mixing EUR and CHF receipts needs you to convert before entering the amount.

Everything else in this article compares alternatives against that specific shape: strong splitting mathematics, zero account management, and a database you now own.

Which Spliit alternatives are genuinely comparable?

Four things compete with a self-hosted Spliit container, and only two of them are apps. Ruling out the wrong comparison early saves you a weekend: a budgeting tool like Actual Budget or Firefly III tracks your own money over time, it does not compute who owes whom inside a group, so it is not an alternative here no matter how good it is.

Option	What it is	Where it beats a self-hosted Spliit
spliit.app	The maintainer's own hosted instance of the same code	Identical features and identical group URLs, with somebody else running Postgres and the upgrades
Splitwise	Hosted commercial service with accounts, apps on iOS and Android, and a paid tier	Real logins, push reminders and a phone app your group already has installed
Nextcloud Cospend	A group expense app installed into an existing Nextcloud instance	Reuses Nextcloud users, sharing and your existing backup job instead of adding a second stack
Shared spreadsheet	One Google Sheets or Excel file with a row per expense	Editable by five people at once, no deployment, and everyone already knows how to use it
Plain-text ledger	An hledger, Ledger or Beancount file in Git	Auditable history, arbitrary reporting, and version control you already have

Hosted mobile-first tools such as Tricount and Settle Up sit beside Splitwise: no self-hosting option, so relevant only if you conclude you should not self-host at all. The rest of this article works through when each of these five wins on the merits.

When is hosted Splitwise the better answer than a Spliit container?

Splitwise wins whenever the people in the group matter more than the rows in the database. It has native iOS and Android apps, accounts with password recovery, and reminders that arrive without you sending them. Spliit has none of those, so the moment your group includes someone who will not keep a URL safe, the hosted service is doing work your container cannot.

One-off groups: a single ten day trip with eight people does not justify a Postgres instance you will still be patching in two years, and Splitwise costs you nothing to start.
Groups that must not depend on you: if you are away with no laptop when your home server reboots into a failed migration, nobody can add an expense, and the people chasing money are your friends.
Phone-first participants: Splitwise is installed from the App Store or Play Store in one tap, while Spliit is a web app you have to explain, including how to add it to a home screen.
Nagging and settle-up prompts: Splitwise pushes reminders, and its paid tier adds extras billed per person per year, so check the current figure before comparing it against your hosting bill.

Choose Splitwise unless you have a concrete reason not to, typically that you refuse to put your travel and flatmate history on a third-party service. If that is your reason, the hosting decision is separate from the app decision: a self-managed VPS, a home server, a NAS or a managed option all run the same image. 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.

Can a shared spreadsheet replace Spliit for a four-person flatshare?

For fixed monthly bills, yes, and it usually wins. A flatshare paying rent, power, internet and water splits the same four amounts between the same four names every month. That is a table, not an application. Six columns get you there: date, description, payer, amount, split rule, and a per-person column each. One =SUMIF(D:D,"Sam",E:E) style total per flatmate gives you the balance Spliit would have computed, and Google Sheets or a file in a Nextcloud instance handles four people editing at once.

Setup time: a working sheet takes about 15 minutes, against a container, a Postgres volume, a subdomain and a backup job for Spliit.
Zero access control problems: you share the sheet with four Google accounts or four Nextcloud users, and you can revoke one of them without invalidating everyone else's link.
Arbitrary rules: one flatmate paying 30 percent of the internet because they work from home is one edited formula, where an app makes you express it as shares or exact amounts on every single expense.
Free-form history: you can add a column for the meter reading or the landlord's invoice number, which no expense splitter will model for you.

The sheet breaks down in three specific cases: high expense volume, where 60 grocery receipts a month makes manual entry miserable; phone entry, where typing into a spreadsheet at a supermarket till is genuinely worse than Spliit's form; and trust, where one careless paste overwrites a formula and nobody notices for a month. If two of those three apply to you, stop defending the sheet.

When does a plain-text ledger beat Spliit outright?

When you already keep one. If your finances live in an hledger, Ledger or Beancount file in Git, shared expenses are just postings, and you get per-person balances from a tool you trust with your own money. A grocery run you paid for, split three ways, is four lines in shared.journal:

2026-03-14 Supermarket
    expenses:food           20.00
    assets:owed:sam         20.00
    assets:owed:alex        20.00
    assets:bank            -60.00

Then hledger -f shared.journal bal assets:owed prints exactly what Spliit's balances screen would show, and hledger reg assets:owed:sam gives the full history behind one number.

Version control for free: every change is a commit with an author and a timestamp, which is stronger provenance than any expense app gives you, and your existing Git remote is the backup.
Reporting you cannot get otherwise: monthly shared spend by category, or a 3 year trend across two different flatshares, is one command with --monthly and a period filter.
Multi-currency done properly: ledger tools price commodities, so a trip mixing EUR and CHF is recorded at the rate on the day rather than converted by hand before entry.
No infrastructure at all: a text file has no Postgres to upgrade, no image to patch and no URL to leak.

The cost is brutal and obvious: nobody else in the group will ever touch it. You become the single point of entry for every receipt, and settling up means exporting a summary your flatmates will believe. Use a ledger when the group is you plus people who are happy to send you photos of receipts, and never when four people all want to log their own spending.

Spliit vs Nextcloud Cospend: which self-hosted splitter fits a homelab?

If you have already decided to self-host, this is the real comparison, and it is decided by what is already running on your box. Cospend is a Nextcloud app by Julien Veyssier, installed from the Nextcloud app store into an instance you already operate. Spliit is a standalone Next.js container plus its own PostgreSQL database.

Dimension	Spliit	Cospend in Nextcloud
What you add	One app container, one Postgres container, one volume, one subdomain	One app inside an existing Nextcloud, no new container and no new database
Identity	No accounts, the group URL is the access token	Nextcloud users and groups, plus link access for people without an account
Backups	A new `pg_dump` target you must remember to add to your backup job	Covered by whatever already backs up Nextcloud's database and data directory
Mobile	A web app you add to the home screen yourself	Web interface plus the MoneyBuster companion app on Android
Failure blast radius	Breaking Spliit breaks only expense splitting	A bad Nextcloud upgrade takes files, calendars and expenses down together

The rule is uncomplicated. Running Nextcloud already? Install Cospend and save yourself a stack. Not running Nextcloud? Do not deploy one just to get expense splitting, because you would be adding a large PHP application and its cron requirements to solve a four person grocery problem. Spliit is the smaller commitment in that case, on a VPS, a home server, a NAS or Yundera, and its single purpose means an upgrade can only break the one thing.

What does Spliit's no-login group URL model mean for you?

It means the URL is the password, and it behaves like a password you cannot change. Anyone holding the group link can read every expense, add new ones, edit amounts and delete history. There is no revocation, no per-member permission, and no record of which participant made a change, so a wrong edit is indistinguishable from a malicious one.

The link spreads the way links spread: it lands in WhatsApp, Telegram and iMessage threads, and some chat platforms fetch previews for URLs they see, so the address leaves your group's control the moment you paste it.
Putting a login in front breaks the feature: wrapping Spliit in Authelia, Authentik or basic auth means every flatmate needs credentials on your server, which removes the one thing that made sharing painless.
A VPN only works if everyone joins it: binding Spliit to Tailscale is the cleanest protection, and it also means installing Tailscale on your sister's phone before she can log a 12 EUR taxi.
Search engines are not the threat, carelessness is: add a robots.txt deny and no indexer will crawl the group, but a screenshot of the browser with the address bar visible undoes that in one post.
The data is more sensitive than it looks: dates, amounts, descriptions and names together show who you travelled with and when, which is exactly the history a hosted service would also hold.

Practical stance: treat each group URL as a bearer token with an unlimited lifetime. If that sentence makes you uncomfortable for your particular group, Splitwise accounts or Cospend's Nextcloud users are the honest answer, not a reverse proxy trick.

Does Spliit survive contact with non-technical group members?

Usually, but you become the support desk, and that cost is the one people underestimate. Spliit's entry form is clean and the maths is invisible, so the app itself is not the problem. The problem is everything around it: getting it onto phones, keeping the link findable, and answering questions at 23:00 on the second night of a trip.

Home screen installation is platform specific: on iOS it is Safari, Share, then Add to Home Screen, and on Android Chrome it is the menu then Install app, so you write two sets of instructions for a group of eight.
Every device asks who you are again: the active participant is stored per browser, so someone switching from their laptop to their phone selects their own name a second time and often picks the wrong one first.
A lost link is a support ticket for you: there is no password reset page to send them to, only you re-sending the URL, and you will re-send it more than once.
Nothing reminds anyone: with no email or push notification, expenses go unlogged for 4 or 5 days and get entered from memory, which is where the wrong amounts come from.
Your uptime is now social: a failed container restart during a holiday is not a homelab incident, it is three people unable to log what they just paid for.

The realistic test is one question: if two of the group refuse to enter their own expenses, you are the only user, and a plain-text ledger or a spreadsheet does the same job with no deployment. Spliit earns its keep only when at least 3 people in the group actually type into it.

Are the receipt scanning and S3 document features worth wiring up?

Only for high volume paper receipts, and only if you have already accepted a third party in the loop. These are optional features, disabled until you add environment variables, so check the repository's .env.example for the exact names your version expects before copying anything.

Receipt attachments need object storage, not a volume: the document feature is switched on with a flag such as NEXT_PUBLIC_ENABLE_EXPENSE_DOCUMENTS and then expects S3 style credentials, bucket, region and endpoint, so you are running MinIO or Garage locally or paying a provider like Backblaze B2 or Cloudflare R2.
Scanning sends the image off your server: the extraction feature uses an OpenAI API key, so every scanned receipt, with its merchant, date and total, leaves the machine you deliberately chose to own.
The cost is per call, not per month: vision requests are billed per token, so the shape is a small charge each time somebody scans, which is fine for 20 receipts on a trip and worth measuring before you leave it enabled for a year.
Your backup surface doubles: a pg_dump no longer captures everything, because the images live in the bucket, and a restore that brings back expenses with broken attachment links is a half restore.
Manual entry is faster than you think: typing 9.80 and the word Taxi takes about 10 seconds, which is the honest benchmark any scanner has to beat.

Recommendation: leave both flags off for a flatshare with fixed bills. Turn them on for expense claims you may need to justify later, where the photo of the receipt is the point and the split is secondary.

How much maintenance does a Spliit stack really cost over three years?

Not much per event, but the events never stop, and three years is long enough that you hit every category at least once. Budget a few hours a year in total, distributed badly: mostly 10 minute jobs plus one bad evening.

Recurring task	Realistic cadence over 3 years	What happens if you skip it
Pull a new app image and let Prisma migrations run on start	Every 1 to 2 months if you track releases	You drift far enough behind that a later upgrade jumps several schema changes at once
PostgreSQL major version upgrade	At least once, since majors ship yearly and support windows run about 5 years	Your database container eventually runs an unsupported major with no security fixes
Verify a restore, not just that the backup ran	Once a quarter, 15 minutes with `pg_restore` into a scratch database	You discover on the day you need it that you have been dumping an empty volume
Domain and certificate upkeep	Renewal yearly, certificate automation checked after each reverse proxy change	The group URL breaks and nobody can reach the app until you notice
Fix an upgrade that changed configuration	Expect one occurrence, an evening's work	The container restarts into a loop and the group has no expense tracker that week

Compare that honestly against the alternatives. Splitwise and spliit.app cost you zero of these. A spreadsheet costs you zero. A Git-backed ledger costs you a push. If the phrase "one bad evening every 18 months" annoys you rather than interests you, that is a real signal, not laziness.

Where should you run Spliit, and who holds the data?

If the reason you are self-hosting is data sovereignty, be precise about it, because Spliit's group data is small and its exposure requirements are large. The database holds names, dates, amounts and descriptions for everyone in the group, not just you, so you are now the custodian of other people's records.

What self-hosting actually buys you:

No third-party account tied to your social graph: the group exists only in your Postgres volume, so nobody profiles who you travel with.
Jurisdiction you choose: a home server or a VPS in a country you picked keeps the data under one legal regime instead of whichever one the vendor operates in.
Retention on your terms: a group from 2023 stays until you run a DELETE, and no product decision archives it for you.
Exit without negotiation: you can pg_dump the whole thing today and move it anywhere.

Where to run it is a separate question from whether to. A home server behind CGNAT needs a tunnel or a relay before anyone outside your LAN can load the app. A VPS solves reachability and moves the disk to a provider. A NAS running Docker works if the unit tolerates a Postgres write load. Yundera is another option alongside those three.

Before you host it for other people, confirm:

The group URL travels over HTTPS only: no plain HTTP fallback on the reverse proxy.
Backups are encrypted and offsite: one copy on the same disk is not a backup.
You can name your recovery time: how long from dead host to working group URL, in hours.
The group knows it is your server: they should know who holds the data before they add a single expense.

How to Back Up Self-Hosted Spliit: PostgreSQL Dumps, S3 Receipts and a Docker Restore That Loses Nothing

John — Sat, 26 Sep 2026 07:06:33 +0000

A complete Spliit backup is three things, not one: a compressed pg_dump of the PostgreSQL database, a copy of the S3 or MinIO bucket holding receipt images, and the .env file that defines your base URL and storage credentials. Capture all three on the same schedule, keep one copy off the machine that runs the containers, and restore them in that order onto a Spliit image of the same minor version. Everything else in the stack, the Next.js application container included, is disposable and rebuilt from your compose file in minutes. The piece almost everyone forgets is the index of your group links, which lives in your browser's local storage and not in the database at all.

TL;DR by reader profile:

The two person household (a couple splitting rent, groceries and one streaming bill): a nightly pg_dump written to a second disk covers you, because the database is measured in kilobytes and you use no receipt uploads.
The flatshare treasurer with five people and two years of history: add dated dumps with a retention window of roughly 30 files, because a wrong split or a deleted expense can go unnoticed for weeks and yesterday's copy will not help.
The trip organiser who scans every receipt: back up the bucket before you worry about anything else, because image blobs are the only part of Spliit nobody can retype from memory.
The privacy-conscious user with no sysadmin background: reduce the whole job to one scripted command and one calendar reminder to rehearse the restore, because an untested backup is a guess rather than a plan.
The homelab owner already running PostgreSQL for other apps: dump Spliit's database on its own rather than taking a cluster wide dump, because a single database dump restores without disturbing your other services.

The central tradeoff: logical dumps are portable and survive PostgreSQL and Spliit upgrades but need a script and a schedule, while volume snapshots are trivial to take and brittle to restore once versions drift.

What do you actually need to back up in a self-hosted Spliit stack?
Where Spliit keeps your data: PostgreSQL rows, S3 receipt images and browser local storage
How do you dump the Spliit PostgreSQL database without stopping the container?
pg_dump versus a Docker volume snapshot: which one restores cleanly?
Backing up the S3 or MinIO bucket that holds your Spliit receipts
Which secrets and environment variables belong in the backup?
A nightly Spliit backup script you can drive from cron
How much storage do three years of Spliit backups really need?
How do you restore Spliit onto a new host, step by step?
What breaks during a restore: Prisma migrations, image drift and group URLs
How do you rehearse a Spliit restore without touching the live instance?
Where should you run Spliit, and where should the backups land?
Privacy and data sovereignty: what a Spliit backup reveals about your household
Which Spliit backup plan fits you?

What do you actually need to back up in a self-hosted Spliit stack?

Four things, and only one of them is the database. A default Spliit deployment is a Next.js container talking to PostgreSQL over DATABASE_URL, with optional S3 compatible storage for expense document images. Strip away what Docker can rebuild and this is your real backup surface.

The PostgreSQL database: every group, participant, expense, split, category and recurring entry lives here, so a logical dump taken with pg_dump -Fc is the single most important file you produce.
The S3 or MinIO bucket: uploaded receipt images are stored as objects outside the database, which means a perfect dump restored against an empty bucket gives you expenses whose attachments load as broken links.
The .env file and compose file: DATABASE_URL, NEXT_PUBLIC_BASE_URL, your S3_* credentials and any OpenAI key for receipt scanning are configuration, not data, and losing them turns a 10 minute restore into an afternoon of guesswork.
The group URLs themselves: Spliit identifies each group by a random id in its address, and your browser keeps the list of groups you have visited in local storage, so export or write down those links before you need them.

What you do not back up is equally clear: the application image, node_modules, the build cache and the container filesystem are all reproducible from docker compose up -d.

Where the stack runs changes none of this. 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. A self-managed VPS, a NAS with Container Manager, a spare mini PC at home and Yundera all present the same four items to protect.

Where Spliit keeps your data: PostgreSQL rows, S3 receipt images and browser local storage

Three storage locations, three different failure modes. Knowing which is which tells you why a single copy of one of them is never a backup.

The PostgreSQL data directory: inside the database container this is /var/lib/postgresql/data, normally mapped to a named Docker volume such as spliit_postgres_data, and it holds the Prisma managed tables for groups, participants, expenses, paid-for splits, categories and recurring expenses.
The _prisma_migrations table: this sits in the same database and records which migrations have already run, so it is the row set that decides whether a restored dump boots cleanly against a given Spliit image or fails on startup.
The S3 compatible bucket: receipt and document uploads go to object storage, and the database keeps only a pointer row per attachment with its URL and dimensions, so the bytes never appear in pg_dump output at all.
Your browser's local storage: Spliit addresses each group by a random identifier in its URL and remembers the groups you have opened on the device you opened them from, which means clearing site data on one laptop can hide groups that still exist perfectly well in the database.

Two practical consequences follow. Restoring a dump onto a fresh bucket produces expenses with unreachable images, and restoring a bucket without the dump produces orphaned objects nothing references. Check both locations on whatever you run, whether that is a VPS, a NAS, a mini PC at home or Yundera, before you trust a schedule you have not tested.

How do you dump the Spliit PostgreSQL database without stopping the container?

You do not need downtime. PostgreSQL dumps run inside a transaction with a consistent snapshot, so pg_dump against a live Spliit instance produces a coherent file even while someone is adding an expense.

The command runs in the database container, not on the host:

docker compose exec -T postgres pg_dump -U spliit -d spliit -Fc \
  > spliit-$(date +%F-%H%M).dump

Use the container's own pg_dump: running the client from inside the image guarantees the client and server versions match, which matters because pg_dump from PostgreSQL 15 refuses to dump a PostgreSQL 16 server.
Prefer -Fc over plain SQL: the custom format is compressed by default and lets pg_restore -j 4 rebuild in parallel and restore selected tables, where a plain .sql file only replays top to bottom.
Pass -T to docker compose exec: without it Docker allocates a pseudo TTY and injects carriage returns into the redirected stream, which corrupts the archive in a way that only shows up when you try to restore it.
Read the credentials from your compose file, not from memory: the user and database name come from POSTGRES_USER and POSTGRES_DB, and docker compose exec postgres env | grep POSTGRES confirms them in one line.
Verify every dump immediately: pg_restore -l spliit-2026-09-26-0300.dump | wc -l lists the archive table of contents, and a file that produces no listing is a failed backup you still have time to retake.

For a household sized instance the whole operation finishes in under 5 seconds.

pg_dump versus a Docker volume snapshot: which one restores cleanly?

Both approaches work. They fail differently, and the difference only appears on the day you restore.

Aspect	`pg_dump -Fc` logical dump	Copy or snapshot of the Postgres volume
Taken while running	Safe, uses a consistent transaction snapshot	Unsafe unless the container is stopped or the filesystem does atomic snapshots
Cross version restore	Restores into PostgreSQL 16 or 17 without touching the data directory	Data directory is tied to one major version, so 16 files will not start under 17
Granularity	`pg_restore -t expenses` recovers one table	All or nothing, the whole cluster comes back together
Typical size	Compressed, a household instance stays in the low megabytes	Includes WAL, free space and indexes, so several times larger
Downtime to take	None	Around 10 to 30 seconds of `docker compose stop postgres`
Repair options	Text inspectable with `pg_restore -f -` before loading	Opaque, a torn copy usually shows as a refusal to start

The honest case for snapshots is speed of recovery. If your host dies, restoring a ZFS or Btrfs snapshot brings Spliit back with the bucket and the compose file in one action, and you skip the ordering problems entirely.

The case for dumps is that they survive change. Spliit and PostgreSQL both move, and a dump taken today still loads next year against a newer image.

Run both if the disk allows: a nightly pg_dump for portability, plus a weekly cold volume copy taken with the stack stopped for a genuine disaster.

Backing up the S3 or MinIO bucket that holds your Spliit receipts

Receipt images are the part of Spliit nobody can reconstruct. An expense can be retyped from a bank statement in 30 seconds. A photo of a till receipt from last March is gone for good.

The tool of choice is rclone, which speaks the same S3 API whether your bucket lives in MinIO on the same host, in Backblaze B2, in Wasabi or in AWS S3:

rclone sync spliit-s3:my-spliit-bucket /backups/spliit-bucket \
  --checksum --transfers 8

Pull the credentials from your existing configuration: the S3_UPLOAD_KEY, S3_UPLOAD_SECRET, S3_UPLOAD_BUCKET, S3_UPLOAD_REGION and endpoint values already in your Spliit environment are exactly what the rclone remote needs, so create a read only key if your provider supports one.
Use sync with --checksum, not copy with timestamps: object storage timestamps change on rewrite, and checksum comparison avoids both re-uploading unchanged images and skipping a changed one.
Never let sync run towards the live bucket: it deletes on the destination, so a reversed argument order replaces your receipts with whatever the backup directory happens to contain.
Back up MinIO as objects, not as its disk: if you self-host MinIO, copy through the API rather than tarring its data directory, because the on-disk layout carries per-version metadata you do not want to depend on.
Keep the bucket copy with the matching dump: store spliit-2026-09-26-0300.dump and that night's bucket sync under the same dated folder, so the pointer rows and the objects they reference always line up.

Which secrets and environment variables belong in the backup?

Configuration is small, and it is the difference between a restore that takes 10 minutes and one that takes a weekend of trial and error. The whole set fits in a single encrypted file.

NEXT_PUBLIC_BASE_URL: this is baked into links Spliit generates and shares, so restoring under a different value changes every group URL you have sent to other people and quietly breaks their bookmarks.
POSTGRES_USER, POSTGRES_PASSWORD and POSTGRES_DB: the dump contains data, not credentials, and a restore into a database whose role name differs from the one recorded in the archive produces ownership errors on every table.
The S3_* block and its endpoint: without the exact bucket name and region the pointer rows in the database resolve to nothing, and a regenerated access key that lacks read permission looks identical to lost images.
OPENAI_API_KEY, if you use receipt scanning: this one is best rotated rather than restored, because a key sitting in an old backup copy is a credential you no longer control.
docker-compose.yml and the image tags it pins: record the exact tag you run, for example postgres:16-alpine alongside your Spliit tag, since latest on restore day is not the image your dump came from.

Encrypt the bundle rather than storing it in plain text. One command covers it:

tar czf - .env docker-compose.yml | age -r <your-public-key> > spliit-config.age

Keep that output in a different place from the dumps, and keep the decryption key somewhere that survives the server, such as a password manager entry or a printed recovery phrase.

A nightly Spliit backup script you can drive from cron

One file, five commands, no orchestration framework. Save this as /usr/local/bin/spliit-backup.sh and make it executable with chmod 750.

#!/usr/bin/env bash
set -euo pipefail
STAMP=$(date +%F-%H%M)
DEST=/backups/spliit/$STAMP
mkdir -p "$DEST"
cd /opt/spliit
docker compose exec -T postgres pg_dump -U spliit -d spliit -Fc > "$DEST/db.dump"
rclone sync spliit-s3:my-spliit-bucket "$DEST/bucket" --checksum
cp .env docker-compose.yml "$DEST/"
pg_restore -l "$DEST/db.dump" > /dev/null
find /backups/spliit -maxdepth 1 -type d -mtime +30 -exec rm -rf {} +

set -euo pipefail is the most important line: without it a failed dump still leaves a zero byte file behind, the script exits 0, and your monitoring reports success for weeks.
One dated directory per run: keeping the dump, the bucket copy and the configuration together means a restore never involves matching files by guesswork.
Verify before pruning: the pg_restore -l check runs before the find deletion, so a broken new backup never triggers the removal of a good old one.
Retention of 30 days is a starting point: raise it to 90 if you settle debts quarterly, since the window that matters is how long a wrong edit can go unnoticed.
Schedule it when nobody is entering expenses: 15 3 * * * /usr/local/bin/spliit-backup.sh >> /var/log/spliit-backup.log 2>&1 puts it at 03:15 and keeps the output where you can read it.

Add a copy step to a second location afterwards, for example restic backup /backups/spliit, because a backup on the same disk as the database survives almost nothing.

How much storage do three years of Spliit backups really need?

Measure your own instance rather than trusting a rule of thumb. Three commands give you every input you need, and the arithmetic afterwards is trivial.

Component	Measure it today	How it grows over 3 years
Database dump	`docker compose exec -T postgres psql -U spliit -d spliit -c "SELECT pg_size_pretty(pg_database_size('spliit'));"`	Roughly linear in expense count, text rows only, stays modest for household use
Bucket objects	`rclone size spliit-s3:my-spliit-bucket`	Dominates everything else, driven by how many receipts you photograph and at what resolution
Config bundle	`du -h spliit-config.age`	Effectively flat, it changes only when you edit `.env`
Cold volume copy	`docker run --rm -v spliit_postgres_data:/v alpine du -sh /v`	Larger than the dump because of WAL and index bloat, and each copy is full size

Two multipliers decide the total. Dumps multiply by your retention count, so 30 dated copies cost 30 times one dump unless you pipe them into a deduplicating tool such as restic or borg, where near identical dumps collapse to a fraction of that. Bucket copies do not multiply if you sync into one directory, because yesterday's images are not rewritten.

The practical result for most self-hosted Spliit instances is that the text data is a rounding error and the receipt images are the entire storage budget. If you want a hard ceiling, resize uploads before you attach them and check rclone size once a quarter. Set your off-site quota from that number, not from the dump.

How do you restore Spliit onto a new host, step by step?

Order matters. Bring up the database first, load data, then start the application so its migration check runs against a populated schema.

Recreate the stack skeleton: install Docker, copy the dated backup directory to the new machine, and place docker-compose.yml and .env in /opt/spliit with the same image tags you recorded, not latest.
Start PostgreSQL alone: docker compose up -d postgres creates an empty database from POSTGRES_DB, and waiting about 10 seconds for it to accept connections avoids a restore that fails on the first table.
Load the dump into that empty database: docker compose exec -T postgres pg_restore -U spliit -d spliit --no-owner --clean --if-exists < db.dump drops any conflicting objects first and ignores ownership differences between hosts.
Push the bucket back before the app starts: reverse the sync direction with rclone sync /backups/spliit/<stamp>/bucket spliit-s3:my-spliit-bucket --checksum, so every pointer row has an object waiting behind it.
Start the application container last: docker compose up -d lets Spliit apply any pending Prisma migrations against real data, and docker compose logs -f shows within 30 seconds whether that succeeded or errored.
Verify with a known group URL: open one group you remember, confirm the balance total and open one receipt image, which tests the database and the bucket in a single click.

The target can be a self-managed VPS, a NAS, a spare mini PC or Yundera, where apps are installed from an app store in one click rather than assembled from compose files by hand. Whichever you choose, keep NEXT_PUBLIC_BASE_URL pointing at the same public hostname.

What breaks during a restore: Prisma migrations, image drift and group URLs

Failed Spliit restores almost never involve lost rows. They involve a schema and an application that disagree about which year it is.

Restoring an old dump into a newer image: Prisma compares your data against _prisma_migrations and applies what is missing, which usually works, but a migration that transforms data can only run in the direction it was written, so jumping several releases at once is riskier than stepping through them.
Restoring a new dump into an older image: this is the failure with no clean recovery, because the schema already contains columns the older code never learned about and Prisma has no downgrade path. Always record the image tag next to the dump.
latest drift on the host: if your compose file says latest, the image pulled on restore day can be months newer than the one that produced the dump, which turns a restore into an unplanned upgrade at the worst possible moment.
PostgreSQL major version mismatch: the dump itself is portable, but confirm the new server is equal or newer, since pg_restore into PostgreSQL 15 from a PostgreSQL 16 archive can reject syntax the older server does not parse.
A changed base URL: every group link you shared carries the hostname from NEXT_PUBLIC_BASE_URL, so moving from one domain to another leaves other participants with dead bookmarks even though the group identifier is unchanged.
The group list nobody backed up: the database is complete, but without the URLs you have no menu, so export them once with docker compose exec -T postgres psql -U spliit -d spliit -c "SELECT id, name FROM \"Group\";" and store the output alongside your dumps.

How do you rehearse a Spliit restore without touching the live instance?

Run the drill in a second compose project on the same machine. It costs one spare port, a scratch directory and about 15 minutes, and it is the only thing that converts a backup into a plan.

Isolate with a project name: copy the backup directory to /opt/spliit-drill, then run every command with docker compose -p spliit-drill, which creates separate containers and separate volumes so nothing can collide with production.
Change three values in the copied .env: map the web container to an unused port such as 3001, point NEXT_PUBLIC_BASE_URL at http://localhost:3001, and set the bucket to a throwaway target, because a drill that writes into the real bucket is not a drill.
Restore from the archive you actually stored: use the most recent nightly file rather than a fresh dump, since the whole point is to test the file your cron job produced, not the command you typed by hand.
Check four things in the running copy: one group opens, its balance total matches production, one receipt image loads from the scratch bucket, and docker compose -p spliit-drill logs shows no migration error.
Write down the elapsed time: the number you record becomes your realistic recovery estimate, and knowing it is 20 minutes rather than an unknown afternoon changes how you react during a real outage.
Tear it down completely: docker compose -p spliit-drill down -v removes the drill volumes, and the -v matters because a forgotten copy of household finances is an avoidable data exposure.

Repeat the exercise once a quarter, and always after you change the Spliit image tag or the PostgreSQL major version.

Where should you run Spliit, and where should the backups land?

These are two separate decisions, and the second one matters more. A self-managed VPS, a NAS running Container Manager, a mini PC at home and Yundera all run the same stack, where each app is reachable on a public HTTPS subdomain via NSL.SH mesh routing so no static IP or port forwarding is required in that last case. What changes your risk profile is how far the backup copy sits from the running container.

Backup destination	Protects against	Does not protect against
Second disk in the same host	A failed data disk, a bad `pg_restore`, a deleted group	Theft, fire, a ransomware event that reaches every mount
NAS on the same LAN	Total host loss, a reinstalled operating system	Anything affecting the building, including a power surge
Object storage off-site, such as Backblaze B2 or Wasabi	Site loss, hardware theft, accidental `docker volume prune`	Credential compromise, unless the key is write limited
A second machine you control elsewhere	Site loss plus provider account lockout	Neglect, since nobody checks a target they never open
Encrypted USB disk rotated by hand	Everything online, because it is offline most of the time	Human forgetfulness, the copy is only as fresh as your last swap

The workable minimum for household finances is two destinations from different rows: one nearby for fast recovery, one off-site for the bad day. Point restic at the off-site target, keep the local dated directories for quick access, and confirm both once a month with restic snapshots and a directory listing. A backup you have never listed is a backup you do not have.

Privacy and data sovereignty: what a Spliit backup reveals about your household

A Spliit dump is a financial diary. It names every participant, dates every purchase, and the receipt images often show a shop, a street, a card's last four digits and a time you were somewhere. That is more sensitive than the app feels while you use it, and it is why the destination of the copy matters as much as its existence.

Advantages of keeping the backup under your own control:

No third party index: the only systems that can read your expense history are ones you chose, so nobody profiles your spending as a side effect of storing it.
You set retention, not a vendor: deleting a group deletes it from your dumps too, once your 30 day window rolls over.
Jurisdiction is a choice: picking a storage region puts the data under a legal regime you selected rather than one attached to a product.
Portability by default: a .dump file plus a bucket directory is a complete export, with no API rate limit between you and your own records.

Checklist before you call the backup private:

Encrypt at rest: wrap every copy with age or restic, which encrypts client side, so the storage provider holds bytes it cannot read.
Restrict the upload key: give the off-site key append and write permission only, so a compromised host cannot delete history.
Store the passphrase off the server: a key living next to the encrypted archive protects nothing.
Check file permissions: chmod 600 on .env and chmod 700 on /backups/spliit, because a world readable dump on a shared box is the quiet failure.
Delete drill copies: scratch restores contain the same data and deserve the same handling.

Which Spliit backup plan fits you?

Match the effort to what you would actually lose. Six profiles cover almost every self-hosted Spliit instance.

Profile	Recommendation	Main reason
Couple, one group, no receipts	Weekly `pg_dump` to a second disk	Data volume is tiny and retyping a month of expenses is plausible
Flatshare treasurer, 5 people	Nightly dump, 30 dated copies, one off-site target	A wrong split surfaces weeks later, so depth beats frequency
Trip organiser with receipt uploads	Nightly dump plus `rclone sync` of the bucket	Images are the only unreproducible data in the stack
No sysadmin background	One cron script plus `restic` to object storage	Fewer moving parts means the schedule survives your attention
Homelab with existing backup stack	Add Spliit to the current `restic` or `borg` job	Deduplication makes 90 daily dumps cheap
Shared instance for several groups	Nightly dump, quarterly restore drill, exported group list	Other people depend on links you cannot regenerate
Running receipt scanning with an API key	Everything above, plus key rotation on restore	A restored key is a credential with unknown exposure

Next steps:

If you have no backup at all today:

Run one pg_dump -Fc by hand and verify it with pg_restore -l.
Copy it off the host.
Add the cron entry.

If you already dump the database:

Add the bucket sync.
Add the encrypted config bundle.
Set retention to 30 days or more.

If you have all three:

Book a 20 minute restore drill this quarter.
Record the elapsed time.
Export your group URLs and store them with the dumps.

RClone vs Dropbox and Google Drive Sync: Does Client-Side Crypt Give You Private Cloud Storage?

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

Yes, an rclone crypt remote keeps the provider from reading your file contents and, if you enable filename encryption, your file names too. It does not hide your directory structure, your approximate file sizes, your access times or the fact that you are storing data at all. Crypt is a strong answer to "can Dropbox read my documents" and a weak answer to "can Dropbox profile my behaviour". Treat it as an encryption layer bolted onto a service you still do not control, not as a replacement for controlling where the bytes live.

TL;DR by reader profile:

Leaving a paid Dropbox plan for privacy reasons, like a freelance designer with 400 GB of client work: wrap your existing provider in a crypt remote first, then decide about moving hosts later, because encryption is the part that actually changes the provider's access.
Wanting the sync experience back, like a household sharing photos across three laptops: crypt plus rclone breaks the native desktop client, so budget for rclone bisync or mount and accept manual conflict handling.
Storing backups rather than working files, like a homelab owner pushing nightly Restic or Borg snapshots: skip crypt entirely, because Restic and Borg already encrypt client side and a second layer just costs CPU.
Handling regulated or client-confidential data, like a small accountancy practice under GDPR: crypt gives you a defensible encryption story, but the metadata leakage and key custody questions need answering in writing before you rely on it.
Running a home server or NAS already, like a Synology owner with 8 TB of disks: use crypt to encrypt an offsite copy, and keep the authoritative copy on hardware you own.
Dealing with millions of small files, like a developer syncing node_modules or a photo library with sidecars: measure first, because the per-file overhead and lost server-side deduplication hit small files hardest.

The central tradeoff: crypt buys you confidentiality against the provider at the cost of native sync clients, server-side deduplication, delta transfers, search, previews and web access, and it never buys you anonymity.

What does rclone crypt actually encrypt, and what does it leave in plain sight?
How does crypt compare to Dropbox and Google Drive server-side encryption?
Is client-side encryption enough to stop a provider reading your files?
How do you set up a crypt remote over Dropbox or Google Drive step by step?
What do the three filename encryption modes cost you in path length and compatibility?
How much storage and speed overhead does crypt add per file?
Why does crypt break deduplication, delta sync and versioning on your provider?
Can you still sync across devices once crypt is in the way?
Where do your crypt passwords and salt actually live, and how do you protect rclone.conf?
What happens if you lose the password, and how do you test a restore?
RClone with crypt vs a self-hosted alternative: which metadata does each expose?
Where should you run rclone: laptop, home server, NAS or VPS?

What does rclone crypt actually encrypt, and what does it leave in plain sight?

Crypt is a wrapper remote. You point it at a path on an existing remote, and every file written through it is encrypted on your machine before a single byte reaches Dropbox or Google Drive. File contents use XSalsa20-Poly1305 in 64 KiB chunks, with a 32 byte header holding a random nonce at the start of each object. The provider stores opaque blobs.

What survives the wrapper is more than most people expect.

Directory structure: crypt encrypts each path component separately, so a 4 level deep tree on your disk is still a 4 level deep tree in the provider's storage, with the same branching shape.
File sizes: an encrypted object is a deterministic function of the plaintext size, 32 bytes of header plus 16 bytes of overhead per 64 KiB chunk, so sizes are recoverable to within a few tens of bytes.
Timestamps and access patterns: modification times are stored as provider metadata in the clear, and the provider logs every read, write and delete with its own timestamps.
File counts and total volume: the number of objects and how they grow over time is fully visible, which is often enough to infer what kind of data you keep.
Filenames, unless you ask: filename_encryption = off leaves names readable, and only standard or obfuscate change that.

Run rclone config show secret: after setup and check the filename_encryption and directory_name_encryption values yourself. The defaults in an interactive rclone config session are standard and true, but a copied config or a scripted setup can quietly leave both disabled.

How does crypt compare to Dropbox and Google Drive server-side encryption?

Both providers encrypt at rest and in transit. The difference is not the algorithm, it is who holds the key.

Property	Provider server-side encryption	rclone crypt
Key custody	Held by Dropbox or Google, rotated without your involvement	Derived from your password and salt in `rclone.conf`
Protects against	Stolen disks, a datacentre breach, an unencrypted backup tape	The provider itself, a subpoena served on the provider, an account takeover
Provider-side features	Web preview, full text search, sharing links, Google Docs conversion	None, the provider sees only blobs
Access by staff or automated scanning	Possible in principle, both run content scanning for abuse and malware	Not possible without your password
What a legal request yields	Readable files and metadata	Ciphertext and metadata only

Server-side encryption answers a threat model that mostly protects the provider, not you. Google Workspace offers client-side encryption on Enterprise Plus tiers, but the key service is still something you configure inside Google's ecosystem. Crypt moves the boundary to your own machine, which is exactly why the web interface stops being useful.

That boundary has a physical location. The key material sits in rclone.conf on whatever device runs the sync, so the security of the whole arrangement reduces to the security of that machine. It might be a laptop, a 5 euro VPS, a NAS, or a 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. Whichever you pick, that box is now the single point that can read your data.

Is client-side encryption enough to stop a provider reading your files?

For file contents, yes. Nobody at Dropbox or Google can turn an rclone crypt blob into a readable document without your password. The honest answer is that "reading your files" is a narrower win than "being private", and the gap is where most people get surprised.

Your identity is still attached: the account is in your name, paid with your card, accessed from your home IP, and the provider retains connection logs regardless of what the objects contain.
Confidentiality is not availability: encryption does not stop an account suspension, a quota enforcement action or a deletion. If the provider locks the account, you have unreadable data you also cannot download.
The key derivation is only as good as the password: crypt runs scrypt over your password and salt. A short passphrase is brute-forceable offline once someone holds the ciphertext, and they hold it permanently.
rclone.conf is the real target: an attacker with that file and the config password, or with none if you never set one, has everything. Storing it in a dotfiles repo has ended more setups than any cryptographic weakness.
Nothing stops traffic analysis: the provider sees a 4 GB upload at 02:00 every night and a burst of reads whenever you open a project. That pattern is informative on its own.

Compare that to Proton Drive or Tresorit, where the encryption is native and the client keeps working. You trade rclone's flexibility for an integrated product. Compare it to self-hosted storage, where the identity and the logs never leave your own machine in the first place.

How do you set up a crypt remote over Dropbox or Google Drive step by step?

Crypt never talks to a provider directly. You build the provider remote first, then wrap it. Expect two entries in rclone.conf for every one encrypted destination.

Create the base remote: run rclone config, choose dropbox or drive, and name it something you will recognise later, for example gdrive. For Google Drive, register your own OAuth client ID in Google Cloud Console rather than using rclone's built in one, which is shared by every user of the tool and throttled accordingly.
Authorise it, headless if needed: on a machine with no browser, run rclone authorize "drive" on your laptop and paste the returned token into the config prompt. This is the normal path for a VPS or a NAS.
Create a container folder: make one directory that will hold nothing but ciphertext, such as gdrive:encrypted. Mixing plaintext and crypt data in the same path makes later auditing painful.
Add the crypt remote: choose crypt, set remote = gdrive:encrypted, accept standard for filename encryption, and answer true for directory name encryption unless you have a specific reason not to.
Generate the password and salt: let rclone generate both at 128 bits rather than typing a passphrase. Write them down offline before you continue, because the config file stores them obscured, not recoverable in your head.
Verify before trusting it: rclone copy ./testdir secret:testdir, then rclone ls gdrive:encrypted to confirm you see gibberish, then rclone check ./testdir secret:testdir to confirm round trips match.

Only after step 6 should you point anything real at it.

What do the three filename encryption modes cost you in path length and compatibility?

filename_encryption has three values, and the default is not the only sensible choice.

standard: names are encrypted with AES in EME mode and encoded, which inflates them. Rclone's own documentation puts the safe threshold at file names under 156 characters, above which you risk breaching provider path limits. Deeply nested project trees with long descriptive names are the usual casualty.
obfuscate: a simple rotating substitution keyed to your password. It defeats casual browsing but not analysis, and it is not real encryption. Its advantage is that name length barely changes, so path limits stop being a problem.
off: names are stored exactly as they are on disk. You get full compatibility and zero inflation, and the provider gets a complete inventory of what you own. 2024-tax-return-final.pdf tells a reader almost everything before they fail to decrypt it.
directory_name_encryption: an independent switch. Set it to false with standard file names if you need readable folders for your own navigation and accept that folder names leak.
filename_encoding: controls the alphabet used. The default base32 is the most portable. base32768 packs more information per character and allows noticeably longer names, but only where the provider handles the wider character set cleanly.

Switching modes later is not a config edit. Rclone cannot recognise files written under a different scheme, so you must create a second crypt remote and run rclone move oldsecret: newsecret:, which means re-uploading every byte. Decide before the first large upload, not after 300 GB.

How much storage and speed overhead does crypt add per file?

The storage cost is deterministic: a 32 byte header, plus 16 bytes of authentication tag for every 64 KiB chunk. That makes it negligible for media and painful for tiny files.

Plaintext size	Stored size	Overhead
100 bytes	148 bytes	48%
1 KiB	1,072 bytes	4.7%
1 MiB	1,048,864 bytes	0.027%
1 GiB	1,074,003,984 bytes	0.024%

A 50,000 file source tree of small text files pays a visible tax. A 400 GB video archive pays almost nothing. Run rclone size ./source against rclone size secret: after your first sync to see your own ratio rather than guessing from this table.

Speed is a different story. XSalsa20-Poly1305 is a stream cipher chosen for software performance, and on any x86-64 machine from the last decade the cipher is not your bottleneck: the upload link is. On a Raspberry Pi 4 or a low-power ARM NAS, encryption can become the limit on a fast fibre connection, so test before assuming.

The real slowdown is per-object, not per-byte. Crypt adds a name encryption step per path component, and rclone must buffer and transform each file rather than streaming it untouched. With --transfers 4 and thousands of small files, the per-file cost dominates. Raising --transfers and --checkers helps until the provider starts returning rate limit errors, which Google Drive does aggressively on per-file operations. Large files, few of them, is the shape crypt handles best.

Why does crypt break deduplication, delta sync and versioning on your provider?

Every file gets a fresh random 24 byte nonce. Encrypt the same 200 MB video twice and you produce two completely different objects. That single design decision, which is correct cryptographically, removes most of what makes a commercial sync service efficient.

Cross-file and cross-account deduplication stops: providers save space by storing one copy of a block that millions of accounts hold. Your ciphertext matches nothing, so you are billed for every byte you upload, including the copies you did not realise you had.
Block-level delta sync stops: the Dropbox desktop client uploads only the changed portion of a file. Rclone through crypt has no equivalent. Change one comment in a 400 MB Photoshop file and you re-upload 400 MB, every time.
Provider-side hash verification stops: rclone cannot compare a local MD5 against the stored object, because the stored object is not your file. Sync falls back to size and modification time. Use rclone cryptcheck secret: ./local to verify properly, and expect it to read data rather than just list it.
Version history becomes opaque: the provider still keeps old revisions, but you cannot preview or diff them in the web interface to decide which one you want. You restore blind, then decrypt to find out.
Trash and selective restore get clumsy: recovering one deleted file means identifying it by an encrypted name in a web UI, which in practice means restoring more than you need.

If you want deduplication and versioning back, that belongs in the tool above rclone. Restic and Borg both dedupe before encrypting, then push the result with rclone as a dumb transport.

Can you still sync across devices once crypt is in the way?

The native Dropbox and Google Drive clients are finished. They sync the plaintext folder on your disk, which is exactly what you are trying to avoid. You replace continuous background sync with something you schedule yourself.

rclone sync for one direction: the laptop is authoritative, the cloud is a mirror. Safe, simple, and it deletes anything on the destination that is gone locally. Always dry run first with --dry-run before trusting a new filter.
rclone bisync for two directions: this is the closest thing to the old behaviour. It needs --resync on first run to establish a baseline, and it stores state listings under ~/.cache/rclone/bisync/. Lose that state and you must resync again.
rclone mount for on demand access: the remote appears as a normal directory. Use --vfs-cache-mode writes at minimum, because many applications fail on a remote without write caching. Expect open and save latency measured in seconds, not milliseconds.
Scheduling instead of watching: rclone has no filesystem watcher driving uploads. You run it from cron or a systemd timer, typically every 5 or 15 minutes, so a change on one machine is not instantly visible on another.
Conflicts are yours to resolve: bisync renames both sides rather than merging. Edit the same document on two laptops within one sync window and you get two files, not a silent winner.
Mobile is the weak point: Android has third party crypt-aware clients such as Round Sync. On iOS there is no comparable maintained option, which rules crypt out for phone-first workflows.

Where do your crypt passwords and salt actually live, and how do you protect rclone.conf?

Run rclone config file to see the path, usually ~/.config/rclone/rclone.conf. Both the crypt password and the salt are written there, obscured rather than encrypted. Obscuring is reversible by design: anyone holding the file can recover the plaintext password with rclone reveal. Treat that file as the key itself, because it is.

Encrypt the config: in rclone config, choose "Set configuration password". The whole file is then encrypted at rest, and rclone prompts on every invocation unless you supply the password another way.
Automate carefully: RCLONE_CONFIG_PASS in the environment or --password-command "pass rclone/config" lets cron jobs run unattended. Both mean the unlock secret sits somewhere on the same machine, so you have traded a prompt for a slightly better hiding place, not for real protection.
Set permissions and check them: chmod 600 ~/.config/rclone/rclone.conf. On a shared box, a world readable config is the entire failure mode.
Keep it out of version control: dotfiles repositories, container images and Ansible playbooks have all leaked working rclone configs. Add the path to .gitignore before you commit anything.
Store the password and salt offline too: a password manager entry or a printed copy in a safe. The config file is a convenience copy, not your only copy.

The machine you choose shapes all of this. A laptop travels and gets stolen. A VPS is reachable from the internet permanently. A NAS at home, or a managed Personal Cloud Server such as Yundera running apps as Docker containers on a server dedicated to you, keeps the key material on hardware you can physically point at.

What happens if you lose the password, and how do you test a restore?

Nothing happens. That is the problem. There is no recovery flow, no support ticket, no key escrow. Lose the password and salt and your 500 GB of ciphertext is permanently unreadable, including by you. Dropbox and Google cannot help, because they never had the key. This is the price of the guarantee in the first place.

A restore drill is the only way to find out whether your setup works. Do it before you delete the local original, and repeat it on a schedule.

Rebuild from nothing, not from your working machine: copy only your recorded password and salt to a clean container or a spare laptop, run rclone config there, and recreate both remotes by hand. If you cannot do it from written notes alone, your notes are incomplete.
Restore a real subset: pull one full project directory with rclone copy secret:projects/2024-archive ./restore-test, not a single test file you uploaded yesterday.
Verify byte for byte: rclone cryptcheck secret:projects ./originals compares decrypted content against your local copy and reports differences explicitly. A successful download is not proof of a correct decryption.
Time it and write the number down: a 200 GB restore over a 100 Mbit connection takes hours. Knowing whether that is 4 hours or 14 changes what you tell a client when something breaks.
Test the config password path too: if the file is encrypted and unlocked by a script, confirm the manual password still works. People forget the one they automated away.

Run the drill every 6 months, and after any change to filename modes, provider or machine.

RClone with crypt vs a self-hosted alternative: which metadata does each expose?

Crypt protects content. Self-hosting protects context. The two answer different questions, and comparing them by metadata makes the gap obvious.

Metadata	rclone crypt on Dropbox or Drive	Self-hosted storage on your own server
File contents	Hidden, ciphertext only	Hidden from third parties, readable by you at rest unless you add encryption
Directory shape and file sizes	Visible to the provider	Never leaves your machine
Access times and frequency	Logged by the provider on every operation	Logged by you, in logs you can rotate or disable
Billing and account identity	Tied to your name, card and IP	Tied to your hosting provider or your electricity bill
Continued access	Subject to the provider's terms and account actions	Subject to your own hardware and backups
Legal exposure	A request goes to Dropbox or Google, who hold metadata	A request comes to you directly

The self-hosted column assumes something is actually running: Nextcloud for a sync client experience, or MinIO, Garage or SeaweedFS if you want an S3 endpoint that rclone can talk to natively. Any of those can run on a home NAS, a rented VPS or a Personal Cloud Server. On a managed Personal Cloud Server such as Yundera, apps are installed from an app store in one click and each is reachable on a public HTTPS subdomain via NSL.SH mesh routing, so no static IP, port forwarding or manual TLS certificate setup is involved.

The pragmatic answer is both. Self-host the primary copy, then use crypt to push an encrypted offsite copy to a provider you have decided not to trust.

Where should you run rclone: laptop, home server, NAS or VPS?

The machine that runs rclone must hold the plaintext, the keys and enough uptime to finish a transfer. Those three requirements rarely point at the same box.

A laptop: simplest, and the right answer if the data lives there anyway. The cost is that syncs only happen when the lid is open, and a 300 GB initial upload becomes a multi-day exercise in not closing it. Use --bwlimit 8M so the machine stays usable.
A NAS or a home server: always on, wired, and holding the authoritative copy. Synology and QNAP ship rclone in community repositories, and a Raspberry Pi 4 handles the cipher fine at typical domestic upload speeds. Schedule with a systemd timer rather than the vendor's task scheduler, which often drops environment variables.
A VPS: useful when you are moving data between two cloud services, because server side transfers never touch your home link. The catch is that your plaintext and your keys now sit on hardware someone else controls, which partly undoes the point of crypt.
A Personal Cloud Server: the same always-on model as a NAS without assembling it yourself. Yundera is one option here, alongside a self-managed VPS, a home server or a NAS.
Inside Docker: the official rclone/rclone image works, but rclone mount needs --device /dev/fuse and --cap-add SYS_ADMIN. If you only run sync or copy on a timer, skip both and keep the container unprivileged.

Pick the box that already stores the files. Every additional hop is another copy of plaintext to defend.

FileBrowser Permissions Explained: How Far Can One Compromised Account Actually Go?

John — Tue, 22 Sep 2026 07:06:46 +0000

A stolen FileBrowser account reaches exactly what its Scope points at, and seven of the eight permission toggles stay inside that directory tree. Execute is the exception: combined with one entry in the Commands allowlist, it starts a real process owned by the same system user FileBrowser runs as, and that process ignores Scope, Rules and every other toggle above it. Symlinks and bind-mounts that sit inside Scope are followed like ordinary folders, so the wall is where the filesystem stops, not where the file list stops. Treat Scope, Rules and the toggles as a usability boundary, and treat the container user, its mounts and its capabilities as the security boundary.

TL;DR by reader profile:

Solo user with one admin account (Tom, one login, photos and documents on a home box): leave Execute off and narrow Scope from the volume root to the two folders you actually open, because a single admin session is the whole application in one credential.
Household sharer (Ana, one shared media folder for two family members): give each person their own account with Scope pinned to their subfolder and Download plus Share only, since per-user Scope is the one control that reliably keeps two people out of each other's files.
Small team lead handing out logins (Marek, six contractors working on one asset library): rely on separate accounts with Create, Rename and Modify but never Admin, because the Admin toggle lets any holder rewrite every other account's Scope in seconds.
Anyone who switched Execute on for one quick script: switch it back off and move the script to a scheduled job outside FileBrowser, as Execute plus a loose Commands entry is a shell, not a file permission.
NAS or VPS owner who mounted a large parent path (Priya, the whole data disk mapped in for convenience): re-mount only the subtrees you need, several of them read-only, since limits below FileBrowser are the only ones a hijacked session cannot edit.

The tradeoff is blunt: every toggle that makes FileBrowser convenient for a second person widens the area a stolen session can read or rewrite, and the only restrictions that survive that session are the ones enforced underneath the application.

What can someone do in the first sixty seconds inside a stolen FileBrowser account?
How does Scope actually work, and what is it anchored to?
What does each of the eight FileBrowser permission toggles really enforce?
Why the Execute permission is not a file permission at all
How does the Commands allowlist decide what is allowed to run?
What do per-user Rules match against, and in what order are they applied?
Do symlinks inside Scope walk straight out of it?
Bind-mounts, volumes and the paths you forgot you handed to FileBrowser
What does the Admin toggle hand over that the other seven never can?
How much protection comes from the system user FileBrowser runs as?
Read-only mounts, dropped capabilities and the limits that live below FileBrowser
What does the FileBrowser database itself expose if someone reaches it?
How do you measure your own blast radius with a throwaway account in thirty minutes?
Does where you run FileBrowser change what a breach can reach?

What can someone do in the first sixty seconds inside a stolen FileBrowser account?

The first minute tells you almost everything, because FileBrowser does not stage its capabilities behind extra confirmations. Whoever holds the session immediately sees the account's Scope as the root of the tree, and every toggle attached to that account is live from the first click. There is no second authentication step for deletion, no confirmation email for a new share link, and no separate re-login before the command console.

Read the entire Scope tree: the file list, the built-in text editor and the preview pane expose every readable file under Scope, including dotfiles such as .env or .ssh/config if they happen to sit inside it.

Pull a bulk copy out: the Download permission zips a selected folder server side and streams it, so a large subtree leaves as one request rather than as hundreds of clicks.

Create a public link: the Share permission mints a link that works for anyone holding the URL, and a link created in the first minute keeps working after you reset the password on the account.

Overwrite or delete in place: Modify and Delete operate directly on the mounted filesystem with no recycle bin and no versioning, so a deleted folder is gone unless your storage layer snapshots it.

Run a process: if Execute is on and the Commands allowlist is not empty, the console runs a real binary as the FileBrowser system user.

The practical consequence is that your recovery plan cannot be "change the password". Revoking existing shares and auditing the tree comes first.

How does Scope actually work, and what is it anchored to?

Scope is not a filter applied to search results. It is the root that FileBrowser hands to the file server for that user, so paths in the URL bar and in the API are resolved against it rather than against the real filesystem root. A user whose Scope is /srv/ana sees /srv/ana/invoices as /invoices, and the layer above is not hidden so much as unreachable by name.

Two roots stack, not one: the server root comes from --root or the "root" key in .filebrowser.json, and each user's Scope is resolved against that root before any request is served.

The Docker image anchors at /srv: the official container sets the root there, which is why a careless -v /:/srv mapping quietly makes the whole host readable to every account in the database.

Scope is stored per user, not per session: it lives in filebrowser.db alongside the account, so changing it with filebrowser users update ana --scope /srv/ana/2024 applies on the next request without a restart.

Path traversal is normalised, not trusted: requests containing ../ are cleaned before the path is joined to Scope, so climbing out with a crafted URL is not the realistic attack here.

Scope is a naming boundary, not an access boundary: anything the operating system user can open through a path inside Scope stays reachable, which is why the two escapes worth worrying about are symlinks and mounts.

Set Scope as narrowly as the person's actual work allows. Widening it later takes one command.

What does each of the eight FileBrowser permission toggles really enforce?

Every toggle maps to a set of API endpoints, not to a mode of thinking. Reading and listing are not toggles at all: any account that can log in can browse its Scope. That baseline matters, because six of the eight only govern writes.

Toggle	What it gates	What it does not stop
Admin	User management, global settings, the whole `/settings` area	Nothing, it supersedes the other seven
Execute	The command console and hook execution	The process itself, which runs outside Scope rules
Create	New files, new folders, uploads into Scope	Overwriting an existing file, which Modify covers
Rename	Renaming and moving within Scope	Moving a file into a share, which stays readable
Modify	Writing to existing files, including the text editor	Silent truncation, there is no version history
Delete	Removing files and folders	Recovery, since there is no recycle bin
Share	Creating public links to anything under Scope	Links already issued, which outlive the toggle
Download	Single files and server-side zipped folders	Reading content through preview and the editor

Two consequences are easy to miss. Turning Download off does not create a read-only viewer, because the built-in editor still renders text files in the browser. Turning Share off later does not retire links created earlier, so revocation is a separate step in the shares list.

A practical baseline for a second person is Download plus Share off, Create and Modify on, Delete off, Execute off, Admin off. Set it with filebrowser users update <name> --perm.delete=false --perm.execute=false and verify it from a logged-out browser.

Why the Execute permission is not a file permission at all

The other seven toggles all end in a filesystem call that FileBrowser makes on your behalf, inside Scope. Execute ends in a process. Once a binary starts, FileBrowser is no longer in the path between that process and the disk, and none of its checks apply to what the process does next.

The process inherits the system user, not the account: it runs as whatever UID the FileBrowser binary runs as, so it can read and write every path that UID can reach, including paths far above Scope.

Scope becomes a working directory, not a boundary: commands start in the folder the user is standing in, but an absolute path such as /etc or /srv resolves normally from inside the process.

A configured shell turns one allowed word into arbitrary syntax: if you have run filebrowser config set --shell "/bin/sh -c", an allowlisted command is passed to a shell that also accepts pipes, semicolons and redirection.

Hooks execute without anyone clicking a console: the global Commands settings attach to events such as before_save and after_upload, so an uploaded file can trigger a command run without an interactive session.

Rules and Scope are never consulted: the allow and deny patterns are enforced by the file API, and a spawned process does not go through the file API.

Treat Execute as equivalent to shell access for that user. If one account needs a periodic script, run it from cron or a systemd timer outside the container and leave perm.execute false for every account in filebrowser.db.

How does the Commands allowlist decide what is allowed to run?

The allowlist is a per user list of words, and the check is a prefix match on the first token of what the user types. Allowing git allows every subcommand and every flag that git accepts. Allowing sh allows everything. The list answers "which binary", never "with which arguments".

Matching stops at the first word: filebrowser users update ana --commands "git,rsync" permits git clone, git config and rsync to any reachable path, because nothing after the first token is inspected.

Binaries still have to exist in the image: the official FileBrowser container is Alpine based and ships busybox, so ls, cp, wget and sh are present even though nobody installed them deliberately.

A busybox wget is an exfiltration path: one allowlisted networking tool turns read access into outbound transfer, which matters more than write access for a privacy focused setup.

An empty list is the real off switch: leaving Commands empty while Execute stays on gives no usable console, but the safer pair is Execute off and the list empty.

Where you run the app decides how much a permitted command finds around it. A self managed VPS carries a full distribution with package managers and SSH keys present on disk. A NAS adds the vendor's own tooling. 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 FileBrowser sits in a container image rather than on a general purpose host, as do the equivalent setups on a home server or a VPS running Docker.

Review the list per account, not once globally.

What do per-user Rules match against, and in what order are they applied?

Rules are the only control that works below the folder level. Everything else grants or denies a whole Scope. A rule is four things: allow or deny, a path or a regular expression, the pattern itself, and the user it belongs to. Default behaviour is allow, so rules exist to carve exceptions out of an otherwise visible tree.

Patterns are matched relative to Scope: a rule written for /secrets matches what the user sees as /secrets, not the host path, so moving Scope changes which files a rule covers.

Regular expressions use Go's RE2 syntax: filebrowser rules add --user ana --regex "\.env$" works, while lookahead and backreferences are not supported and will be rejected rather than silently ignored.

Two lists are in play: there is a global rule list in settings and a per-user list on the account, and a file that survives one list can still be caught by the other, so test the combination rather than reasoning about precedence on paper.

Denied paths disappear from listings and from search: the entry is filtered out of the directory response, which is what makes rules feel like hiding rather than permission.

A deny rule is checked on the request path only: a file reachable under a second name, for example through a folder that a pattern does not cover, is served normally.

Verify with a direct request, not the interface. Log in as the restricted account, then fetch the hidden path by URL and confirm you get an error rather than content. Three well chosen deny rules on dotfiles, key material and backup archives cover most of what a stolen session would want.

Do symlinks inside Scope walk straight out of it?

Yes. FileBrowser cleans ../ out of request paths before joining them to Scope, but it does not resolve symlinks before deciding whether a path is inside Scope. A link that already exists on disk is opened by the operating system like any other directory entry, and the content on the far side is served normally.

The link only has to sit inside Scope: if /srv/ana/host points at /etc, the account browsing /host reads files two levels above its own root, and nothing in the interface signals that it left.

Users cannot create one through the web interface: there is no symlink endpoint in the file API, so the links that matter are ones placed by you, by a backup tool, or by another application sharing the same volume.

Execute closes that gap instantly: a single allowlisted command running ln -s / /srv/ana/root converts a read of one folder into a read of everything the process user can open.

Uploads can carry links inside archives: if an extraction step outside FileBrowser unpacks a tar that contains symlinks, the links land in Scope without anyone typing a command.

Deny rules do not help here: a rule written for /etc matches the path as the user sees it, so the same target reached through /host is not covered.

Audit it directly. Run find /srv -type l -ls against the mounted tree and confirm every result points somewhere you intended. Run it again after restoring a backup, because archive restores are the common way an old link reappears in a Scope that has since been narrowed.

Bind-mounts, volumes and the paths you forgot you handed to FileBrowser

Scope decides what an account sees. The mount list decides what exists to be seen at all. A narrow Scope on top of a wide mount is one admin edit away from being a wide Scope, because an account with the Admin toggle can point Scope at anything the container has.

Mount line	What any account can potentially reach	What it buys you
`-v /:/srv`	Every file the container user can open on the host	Nothing you cannot get another way
`-v /home/tom:/srv`	Shell history, `.ssh`, application tokens under `.config`	One less path to type
`-v /srv/media:/srv/media`	Only the media tree, matching the path on both sides	Predictable paths in backups and logs
`-v /srv/archive:/srv/archive:ro`	The archive tree, readable but not writable	Delete and Modify stop at the kernel
Named volume	Only what you copy into it	Isolation from the host tree

Mount the narrowest set of subtrees that the people using FileBrowser actually need, and mount anything historical read-only. Two or three separate mounts are easier to reason about than one parent path.

Check what is really attached rather than what the compose file says, because an edited file that was never re-deployed proves nothing. Run docker inspect -f '{{json .Mounts}}' filebrowser and read the list. The same applies on a NAS package or a Yundera app install, where the mapping is set once during installation and then forgotten.

Anything on that list is inside the blast radius, whether or not a Scope currently points at it.

What does the Admin toggle hand over that the other seven never can?

Admin is not a stronger version of Modify. It moves the account from working on files to editing the rules about files, which means it can grant itself anything the other seven withhold. That is why an admin session is not bounded by its own Scope in any meaningful sense.

It rewrites Scope, including its own: an admin opens Users, sets Scope to the server root, and every mounted path becomes browsable in one save with no restart.

It flips permissions on any account: Execute and the Commands list are editable from the same form, so the path from Admin to a running process is two clicks rather than a separate vulnerability.

It creates accounts that outlive your response: a new user added quietly keeps working after you reset the password on the account that was originally stolen.

It edits global settings, not just users: branding, the shell used for commands and the global rule list all live behind the Admin toggle, and global rules govern accounts you never touched.

It reads the shares list for everyone: existing public links become visible and reusable, including links created by other people.

Keep exactly one admin account, use it only for administration, and give yourself a second non admin account for daily file work. The blast radius of a compromised daily driver then stops at one Scope. If two people genuinely need to add users, accept that you have two accounts that can reach every mount, and set --perm.admin=false on everyone else with filebrowser users update <name> --perm.admin=false. Review the user list monthly and confirm the count of admins is still one.

How much protection comes from the system user FileBrowser runs as?

More than any toggle in the interface, because this is the limit a hijacked session cannot edit. FileBrowser can only open what its UID and GID can open, and that check happens in the kernel rather than in the application.

Running as root erases the filesystem layer entirely: with a bind mount, root inside the container is root on the host files, so ownership and mode bits stop filtering anything and a read-only intention becomes a suggestion.

A dedicated UID turns ownership into the real allowlist: set user: "1000:1000" in your compose file, then FileBrowser reaches media owned by that UID and gets permission denied on everything else, including files reached through a symlink.

World readable files defeat ownership on their own: a file at mode 0644 is readable by every UID on the system, so tighten the sensitive ones to 0640 or 0600 rather than relying on who owns them.

The database and config still need write access: the chosen UID must own the directory holding filebrowser.db, otherwise the container starts and then fails on the first settings change.

Verify rather than assume. Run docker exec filebrowser id and read the numbers, then stat -c '%U %G %a' /srv/media on the host and compare.

The hosting shape decides how much of this you set yourself. Yundera is a managed Personal Cloud Server built on CasaOS, where self-hosted apps run as Docker containers on a server dedicated to the user and that data stays on the user's own server. A VPS, a home server or a NAS puts the same UID decision in your hands.

Read-only mounts, dropped capabilities and the limits that live below FileBrowser

These controls sit under the application, so no permission edit and no admin session can switch them off. They are also the only ones that constrain a process started through Execute, which every control inside FileBrowser fails to reach.

Control	What it actually stops	What it costs you
`read_only: true` on the container	Any write outside declared volumes, including a dropped binary in `/tmp`	You must add a `tmpfs` for scratch space and keep the database on its own volume
`cap_drop: - ALL`	Capability based tricks such as changing file ownership with `chown`	Nothing for normal browsing, uploading and downloading
`security_opt: - no-new-privileges:true`	A setuid binary inside the image raising privileges mid process	Nothing, FileBrowser does not need it
`pids_limit` and a memory limit	A runaway or deliberate fork loop taking the host down with it	A hard ceiling you have to size once
An internal Docker network with no egress	Outbound copies of your files to somewhere else	Breaks any workflow that expects the container to fetch from the internet

Apply them in that order. Read-only plus dropped capabilities is roughly fifteen minutes of work and survives every future permission mistake you make in the interface.

Test each one after applying it rather than trusting the compose file. Run docker exec filebrowser touch /test and confirm it fails, then confirm that uploading a file through the web interface still succeeds. A read-only container that also blocks legitimate uploads means a volume is missing, not that the control is wrong.

What does the FileBrowser database itself expose if someone reaches it?

Everything FileBrowser knows lives in one bbolt file, normally filebrowser.db. It is not encrypted at rest. If that file ends up inside a Scope, or inside a mount that Scope can reach, a download turns an account compromise into full control of the installation.

It holds the token signing key: the settings bucket stores the key used to sign session tokens, and anyone holding it can mint a valid token for any account without ever knowing a password.

Password hashes are bcrypt, so they resist cracking but not replacement: an attacker with a writable copy does not need to crack anything, they set a new hash and log in as that user.

Every share record travels with it: share hashes and their password hashes are in the same file, so a copy exposes links you issued months ago.

The whole user table is offline readable: filebrowser -d /database/filebrowser.db users ls prints usernames, Scope paths and permission flags from any copy of the file, on any machine.

Backups inherit the same exposure: a nightly archive of the config directory dropped into a browsable folder is the same leak with extra steps.

Store the database outside every served path. A separate mount such as /database for the file and /srv for content is the simple layout, and it keeps the two concerns apart even if you later widen a Scope. Then confirm it from the inside: log in as a restricted account and search for filebrowser.db. Zero results is the outcome you want, and it takes about a minute to check.

How do you measure your own blast radius with a throwaway account in thirty minutes?

Reasoning about permissions on paper produces the wrong answer often enough that it is worth testing. The test is cheap, repeatable, and the only honest way to know what a stolen session sees.

Create the account, 2 minutes: run filebrowser users add audit <password> --perm.admin=false with the same toggles and Scope as your least trusted real user.

Walk upward in a private window, 5 minutes: log in, click to the top of the tree, and write down the highest folder you can list. That folder is your ceiling, not the one in your notes.

Probe the API directly, 10 minutes: the interface hides things the API will still serve. Get a token with curl -X POST -d '{"username":"audit","password":"..."}' https://files.example.com/api/login, then request a path you believe is denied with curl -H "X-Auth: <token>" https://files.example.com/api/resources/secrets. A 403 or 404 is a pass, a JSON listing is a finding.

Test the toggles you believe are off, 5 minutes: try to delete a scratch file, try to create a share, and open the command console. Each failure should be a refusal, not an empty screen you interpret as a refusal.

Check a share from a logged out browser, 3 minutes: copy any link the account can produce and open it in a browser with no session.

Remove the account and its shares, 2 minutes: delete the user, then confirm the shares it created are gone from the list rather than assuming they left with it.

Repeat after any mount or Scope change.

Does where you run FileBrowser change what a breach can reach?

Yes, because the blast radius is defined by what else lives on the machine. The same account with the same Scope reaches very different things depending on what is sitting one directory above it.

Advantages of hosting it yourself:

You choose the neighbours: a box that holds only media files has nothing else to lose, while a general purpose server holds SSH keys, other applications and their databases in the same filesystem.
You set the mount list: nobody else decides which subtrees are attached, so the ceiling from your throwaway account test is a decision rather than a default.
The files never sit in a shared multi-tenant store: a compromise of your account is a compromise of your server, not an entry point into a pooled service.
Retention is yours: snapshots, backup frequency and how long a deleted file really survives are settings you own.

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. A self managed VPS, a home server and a NAS put the same FileBrowser container on hardware you control in different ways.

Checklist before you expose it:

One purpose per host: no SSH keys, no unrelated application data under any mounted path.
HTTPS only: FileBrowser sends credentials in a login request, so plain HTTP on a shared network is not acceptable.
Mount list reviewed: every entry justified out loud.
Database outside every served path: verified by search, not by memory.
Snapshots enabled: because Delete is permanent at the application layer.

How Much of a 900-Recipe Paprika Library Actually Survives the Import into Mealie, and How to Repair the Rest

John — Sat, 19 Sep 2026 07:07:17 +0000

The recipe bodies survive. The structure around them does not. A 900-recipe Paprika export lands in Mealie with names, ingredient text, directions, source URLs and the primary photo intact, but the per-ingredient quantity, unit and food fields arrive as unparsed strings, and anything Paprika stores that has no equivalent in Mealie's recipe model goes quietly: the photo array beyond the first image, the scale factor, the difficulty label, the favourites flag and Paprika's free text nutrition block. Treat this as two separate jobs, the import itself, which is one file upload and a few minutes of waiting, and a scripted repair pass against the Mealie API, which is where the actual work sits.

TL;DR by profile:

The Paprika 3 owner with 900 recipes and ten years of star ratings: import everything in one pass, then audit field by field before you cancel anything, because the loss is concentrated in metadata you cannot reconstruct from the recipe text.
The Nextcloud Cookbook self-hoster moving sideways: expect the cleanest of the three migrations, since each recipe is already a schema.org JSON document that maps almost one to one onto Mealie's model.
The RecipeKeeper user on Windows and iOS: budget the most repair time of the three, because the export is an HTML document plus an image folder and everything Mealie gets has to be scraped back out of markup.
The solo developer with Python 3 and an API token: script the repair, because the whole job is a paginated GET over /api/recipes plus a PATCH per recipe, and 900 recipes is roughly 20 lines of code away from fixed.
The household cook who will never open a terminal: keep the paid app installed and read only for one full season, because the shopping list and offline behaviour matter more than the field mapping.
Anyone still evaluating: run the import against a throwaway Mealie instance with a separate database first, because the importers are not idempotent and a bad run is easier to delete than to unpick.

The tradeoff is plain: Mealie gives you a structured, queryable library you own, and you pay for that structure by rebuilding the parts of your Paprika data that were never structured to begin with.

What a 900-recipe Paprika export actually contains
Where each Paprika field lands inside Mealie
Which Paprika fields disappear without a warning?
Why do your ingredients arrive as plain text instead of structured quantities?
Do your photos survive, and what happens to the second and third one?
Ratings, favourites, scale factors and the metadata that never arrives
How does the Nextcloud Cookbook importer compare with the Paprika one?
What does a RecipeKeeper export lose on the way into Mealie?
How do you audit the import before you cancel the subscription?
Duplicates, failed recipes and the ones that silently never arrive

What a 900-recipe Paprika export actually contains

Export from Paprika 3 and you get a single file with a .paprikarecipes extension. Rename it to .zip and open it: inside sits one gzip-compressed file per recipe, each with a .paprikarecipe extension. Decompress one and you have a flat JSON object. That is the entire format. There is no schema file, no index, no relational structure between recipes.

Run unzip -l library.paprikarecipes | wc -l before you import anything. If your library holds 900 recipes, you should see 900 entries plus the zip header lines. This is your baseline count, and you will compare it against Mealie's recipe total afterwards.

Each JSON object carries a predictable set of keys:

Identity fields: uid and hash, a UUID and a content hash that Paprika uses for sync, with no destination in Mealie's model.
Free text blocks: ingredients, directions, notes and description, all single strings with newline separators rather than arrays.
Timing and yield: prep_time, cook_time, total_time and servings, all stored as human strings such as 1 hr 20 min, not as integers or ISO 8601 durations.
Image payloads: photo_data holding a base64 JPEG, plus photo, photo_hash, image_url and a photos array for additional images.
Classification and personal signal: categories as an array of strings, plus rating, difficulty, on_favorites, scale, source, source_url, created and a free text nutritional_info.

Nothing here is invalid. It is simply a sync format for one application, not an interchange format, and that distinction explains every loss described below.

Where each Paprika field lands inside Mealie

The import itself runs inside the instance, from the Migrations page under group data management. You upload the .paprikarecipes file through the browser, so the whole library crosses your reverse proxy in one request. A 900-recipe export with embedded base64 photos is comfortably large enough to hit the nginx default client_max_body_size of 1m, which returns a 413 before Mealie ever sees the file. Raise that limit first, whether Mealie runs on a self-managed VPS, a home server, a NAS or a Yundera box. 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.

Paprika field	Mealie destination	What changes on the way
`name`	`name` plus generated `slug`	Duplicate names get a numeric suffix appended to the slug
`ingredients`	`recipeIngredient` array	Split on newlines into one entry per line, stored as original text
`directions`	`recipeInstructions` array	Split into steps, with empty step titles and no grouping
`categories`	Categories and tags	Created on demand, so 40 Paprika categories become 40 new records
`photo_data`	`data/recipes/<id>/images/`	Base64 JPEG decoded and rewritten as original, min and tiny WebP
`source_url`	`orgURL`	Preserved verbatim, including dead links
`prep_time`, `cook_time`	`prepTime`, `performTime`	Kept as the original human strings, not parsed into minutes

Every row above is a field that arrives. The next section covers the keys with no row at all.

Which Paprika fields disappear without a warning?

Nothing in the interface tells you what did not make it. The import reports a count of recipes created and stops there. These are the keys that have no destination in Mealie's recipe model:

difficulty: Paprika stores an easy, medium or hard label per recipe, and Mealie has no equivalent field anywhere in its schema, so the value is read and discarded.
scale: the saved serving multiplier vanishes. Mealie scales at view time from recipeYield, which means a recipe you always cooked at 2x reverts to the base quantities in the text.
on_favorites: favourites in Mealie live on the user record, not the recipe record, so a flag set on 120 recipes leaves you with an empty favourites list for every account.
nutritional_info: Paprika holds one free text blob. Mealie expects discrete numeric fields for calories, fat, protein, carbohydrate, fibre, sodium and sugar, and a blob cannot be split into seven typed columns without parsing.
uid and hash: the sync identifiers are replaced by fresh Mealie UUIDs, which removes any stable key for matching a recipe back to its source file later.

Count before you mourn. Decompress the export and run something like for f in *.paprikarecipe; do gunzip -c "$f"; done | jq -r 'select(.difficulty != "") | .name' | wc -l against each field in turn. Most libraries of 900 recipes have a difficulty set on a few dozen and a scale set on fewer still. Repair effort belongs where the field is actually populated, not where it merely exists in the format.

Why do your ingredients arrive as plain text instead of structured quantities?

Because the two applications model an ingredient differently, and the importer refuses to guess.

Mealie stores five fields per ingredient: a numeric quantity, a unit reference, a food reference, a free note and the untouched originalText. Units and foods are separate database tables with their own records, not strings on the recipe.
Paprika stores one line of text: 2 cups all-purpose flour, sifted is a single string with no delimiters, and the export has no field telling you which part is the amount. Mealie's importer keeps the whole line in originalText and leaves quantity, unit and food unset rather than inventing a split.
Scaling stops working: the serving multiplier in the Mealie interface multiplies the numeric quantity. With no quantity stored, pressing 2x changes the yield label and leaves every ingredient line reading 2 cups exactly as before.
Shopping list aggregation stops working: Mealie merges list entries that point at the same food record. Import three recipes needing onions and you get three separate unmergeable lines, because there is no onion record to match on.
Food and unit filters stay empty: browsing by food, or filtering the recipe list on a specific ingredient, queries those tables. After a raw import of 900 recipes, both tables can still contain zero rows.

The volume matters here. At an average of 10 ingredient lines per recipe, 900 recipes is around 9,000 strings needing structure. That is the single largest repair job in the migration, and Mealie ships a parser for exactly this, covered further down.

Do your photos survive, and what happens to the second and third one?

One photo per recipe survives. The rest do not.

The primary image is decoded and re-encoded: the base64 JPEG in photo_data is written to disk as WebP in three sizes, original.webp, min-original.webp and tiny-original.webp, under data/recipes/<uuid>/images/. The picture is intact, but the bytes are not, so checksum comparison against the source file will never match.
The photos array has no destination: Paprika lets you attach several images to one recipe. The Mealie recipe model carries a single main image plus a separate assets folder, and the migration does not populate assets, so photo two onwards is read and dropped.
Recipes holding only image_url arrive blank: if a recipe has a remote URL and no embedded payload, nothing is fetched during the import and the card shows the default placeholder image.
Image storage leaves the database: everything lands on the filesystem, not in SQLite or PostgreSQL. A pg_dump alone is not a backup of your library, and du -sh data/recipes after import is the number that matters for your disk planning.

Count the damage before you decide whether to care. Decompress the export and run jq 'select((.photos | length) > 1) | .name' across the files. Most libraries keep multi-photo recipes in the low dozens, usually the ones you cooked and photographed yourself. If the count is under 50, re-attaching them by hand through the recipe editor is faster than writing an uploader.

Ratings, favourites, scale factors and the metadata that never arrives

Some of this is recoverable from the export file. Some of it is gone for good, because it was never in the export to begin with.

Signal you had	Where it would live in Mealie	What you can do about it
Star ratings	Recipe `rating`, and a separate per-user rating in recent releases	Verify one known 5-star recipe after import, then PATCH the rest from the JSON if the view is empty
Favourites flag	A per-user favourites relation, not a recipe column	Rebuild with one API call per recipe, filtered on `on_favorites` in the source files
Saved scale factor	No field exists	Fold the multiplier into `recipeYield` text by hand, only for recipes you always cooked scaled
Date added	`createdAt` and `dateAdded`	All 900 recipes share the import date, so sort by name until you backfill from the `created` key
Last cooked date and history	`lastMade` plus timeline events	Nothing arrives, and nothing can, because Paprika never exported a cooking log
Tools and equipment	A dedicated tools table	Starts empty, since Paprika has no equivalent concept to map from

Sort your repair list by whether the data exists somewhere. Ratings, favourites and creation dates all sit in the decompressed .paprikarecipe files, so they are a scripted backfill and nothing more. The cooking timeline is different. Mealie builds it from events you record after the fact, which means the history starts the day you import and your previous years of cooking simply do not exist in the new system. Accept that one rather than hunting for a workaround.

How does the Nextcloud Cookbook importer compare with the Paprika one?

It is the cleaner of the two, because the source format was designed for interchange rather than sync.

The unit of migration is a folder, not a blob: Nextcloud Cookbook stores each recipe as a directory holding recipe.json plus full.jpg and thumb.jpg. Zip the parent directory before uploading, and confirm the count first with find . -name recipe.json | wc -l.
recipe.json is a schema.org Recipe document: the same vocabulary Mealie uses internally and the same vocabulary its URL scraper targets, so the mapping is field to field rather than key to guess.
Ingredients arrive pre-split: recipeIngredient is already a JSON array with one entry per ingredient, which removes every newline splitting error. The strings themselves are still unstructured, so the parsing job from the previous section is unchanged and unavoidable.
Durations are ISO 8601: a value of PT1H20M lands as a real duration instead of the human text strings that come across from a Paprika export.
Nutrition maps key by key: the schema.org nutrition object exposes calories, fat, protein and carbohydrate as separate properties, which drop straight into Mealie's seven nutrition fields with no parsing.
Keywords become tags directly: keywords is a flat list, so there is no ambiguity about whether a value belongs in categories or tags.

The loss is different in kind. Nextcloud Cookbook never stored a favourites flag, a cooking log or a personal star rating, so there is no personal signal to lose and nothing to backfill. You migrate structure, and your history was already absent.

What does a RecipeKeeper export lose on the way into Mealie?

RecipeKeeper hands over the weakest of the three formats, because it exports a web page rather than a data file.

The whole library is one document: a zip containing recipes.html plus an images directory. There is no per-recipe file, so your baseline count comes from markup, not from a file listing: grep -c 'itemprop="name"' recipes.html.
Parsing depends on microdata attributes surviving intact: the importer reads itemprop values out of the HTML. Open and resave that file in an editor that rewrites markup and the import will find fewer recipes, report success, and give you no error to investigate.
Photos are referenced by relative path, not embedded: the images folder has to stay inside the zip at the exact path the HTML expects. Rearrange the archive and recipes import cleanly with no picture and no warning.
Unicode fractions come through literally: RecipeKeeper writes ½ and ¼ as single characters. They survive into originalText fine, but the ingredient parser handles 1/2 cup far more reliably than the glyph, which shifts work into the repair pass.
Personal fields are presentation markup: course, rating and source are styled page elements rather than typed columns, so what arrives depends entirely on the markup shape of your export version.
No stable identifiers exist anywhere: run the import twice and you get two complete copies of every recipe, with no key available to match and deduplicate them afterwards.

Verify a sample of 10 recipes chosen to cover every field you care about before you trust a run of 900.

How do you audit the import before you cancel the subscription?

Create an API token from your user profile, then check the library from the outside rather than by scrolling it.

Compare totals before anything else: run curl -H "Authorization: Bearer $TOKEN" "https://your-mealie-host/api/recipes?page=1&perPage=1" | jq .total and hold it against the file count you took from the export. If 900 went in and 894 came out, you have six files to find.
Diff the name lists, not just the counts: pull every name with perPage=1000, sort it, and diff against the names extracted from the source. Numeric slug suffixes expose duplicate titles, and absent names expose skipped files, which counts alone will hide when a duplicate offsets a failure.
Sample 30 recipes at random rather than the first 30: the top of an alphabetical list tends to hold your oldest and simplest entries. Random sampling surfaces the recipes with tables in the directions, nested lists or multiple photos.
Probe images with HEAD requests, not with clicks: loop over the recipe IDs and request the image path for each. Counting 404 responses takes one loop and tells you exactly how many cards are showing a placeholder.
Count the fields you expect to be empty: query how many ingredient entries have no food reference and how many recipes have a null rating. Those two numbers define the size of the repair work ahead.
Archive the export file permanently: the .paprikarecipes zip is now the only copy of every field Mealie discarded, so store it beside your backups.

A matching count proves the rows moved. It does not prove the library is usable.

Duplicates, failed recipes and the ones that silently never arrive

A migration that half worked looks identical to one that worked. The interface reports what it created, never what it skipped.

Individual files fail for boring reasons: a character encoding problem, a truncated base64 photo payload or a malformed JSON body stops that one recipe. The run continues, the total comes back lower than your baseline, and nothing in the browser says which file died.
The container log is the only witness: watch it during the run rather than afterwards, with something like docker logs -f mealie in a second terminal. Per-file errors are named there and nowhere else.
Duplicate titles are usually genuine recipes: Paprika happily stores two entries called Roast Chicken. Mealie keeps both and appends a numeric suffix to the second slug. Deleting everything with a suffixed slug is a fast way to lose real data, so compare bodies before you prune.
The genuine duplicate risk is re-running the import: the migration creates records, it does not match and update them. Upload the same file twice and 900 recipes become 1,800, with no key available to pair the copies back together.
Tag the run so it has a boundary: if the migration form offers to tag what it creates, enable it. Otherwise apply a dated tag such as import-2026-04 immediately afterwards through bulk actions, so one filtered /api/recipes/bulk-actions/delete call unwinds the whole attempt.
Take a Mealie backup before every attempt: restoring a backup from the settings area is a single operation, while deleting 900 recipes by hand is an evening you will not enjoy.

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.

DEV Community: John

Tailscale vs Cloudflare Tunnel: How to Reach Self-Hosted Docker Services Without a Public IP

Table of contents

What do Tailscale and Cloudflare Tunnel actually do differently?

How does each one reach a Docker container with no public IP?

How do you set up Tailscale on a Docker host, step by step?

How do you set up Cloudflare Tunnel on a Docker host, step by step?

Which one is better for private admin panels only your team touches?

Which one is better for a service you need to share with clients?

Do SSH, RDP, UDP and other non-HTTP services work on each one?

How much latency and throughput do you give up with each?

How much does each really cost over three years?

Tailscale Serve and Funnel vs Cloudflare public hostnames: where do they overlap?

Who can see your traffic, and what does each side log?

Odoo Community Self-Hosted vs Odoo Online: Is a Private Cloud ERP Worth It for a Family of Four?

Table of contents

What can Odoo actually do for a family of four?

Odoo Community vs Odoo Online: what actually changes when you self-host

How much does it really cost over three years?

What hardware and resources does self-hosted Odoo need for four users?

How do you run Odoo Community in Docker on a home server?

Is moving a database off Odoo Online clean, or does it break?

Which Odoo apps are worth enabling for a household, and which ones add noise?

How do you give four family members the right level of access?

What breaks at upgrade time, and how much work is it?

Backups, restore and what happens when the household admin is away

Odoo versus Firefly III, Grocy and Mealie: is one big ERP the right shape?

How to Self-Host WordPress with Docker and Strip Every Third-Party Tracker

Table of contents

What does a stock WordPress install actually send to third parties?

Which Docker setup do you need before you can audit anything?

How do you capture every outbound request your site makes?

What exactly does Jetpack send, and what breaks when you remove it?

How do you stop Gravatar leaking your commenters' email hashes?

How do you self-host Google Fonts without breaking your theme?

Should you block api.wordpress.org, and what do you lose?

Which plugins phone home silently, and how do you catch them?

How do you replace Google Analytics with something you own?

What cookies does WordPress set, and which ones actually need consent?

Best Spliit Alternatives for Self-Hosting: When Splitwise, a Spreadsheet or a Plain-Text Ledger Wins

Table of contents

What Spliit actually does, and what it leaves out on purpose

Which Spliit alternatives are genuinely comparable?

When is hosted Splitwise the better answer than a Spliit container?

Can a shared spreadsheet replace Spliit for a four-person flatshare?

When does a plain-text ledger beat Spliit outright?

Spliit vs Nextcloud Cospend: which self-hosted splitter fits a homelab?

What does Spliit's no-login group URL model mean for you?

Does Spliit survive contact with non-technical group members?

Are the receipt scanning and S3 document features worth wiring up?

How much maintenance does a Spliit stack really cost over three years?

Where should you run Spliit, and who holds the data?

How to Back Up Self-Hosted Spliit: PostgreSQL Dumps, S3 Receipts and a Docker Restore That Loses Nothing

Table of contents

What do you actually need to back up in a self-hosted Spliit stack?

Where Spliit keeps your data: PostgreSQL rows, S3 receipt images and browser local storage

How do you dump the Spliit PostgreSQL database without stopping the container?

pg_dump versus a Docker volume snapshot: which one restores cleanly?

Backing up the S3 or MinIO bucket that holds your Spliit receipts

Which secrets and environment variables belong in the backup?

A nightly Spliit backup script you can drive from cron

How much storage do three years of Spliit backups really need?

How do you restore Spliit onto a new host, step by step?

What breaks during a restore: Prisma migrations, image drift and group URLs

How do you rehearse a Spliit restore without touching the live instance?

Where should you run Spliit, and where should the backups land?

Privacy and data sovereignty: what a Spliit backup reveals about your household

Which Spliit backup plan fits you?

RClone vs Dropbox and Google Drive Sync: Does Client-Side Crypt Give You Private Cloud Storage?

Table of contents

What does rclone crypt actually encrypt, and what does it leave in plain sight?

How does crypt compare to Dropbox and Google Drive server-side encryption?

Is client-side encryption enough to stop a provider reading your files?

How do you set up a crypt remote over Dropbox or Google Drive step by step?

What do the three filename encryption modes cost you in path length and compatibility?

How much storage and speed overhead does crypt add per file?

Why does crypt break deduplication, delta sync and versioning on your provider?

Can you still sync across devices once crypt is in the way?

Where do your crypt passwords and salt actually live, and how do you protect rclone.conf?

What happens if you lose the password, and how do you test a restore?