Self-Hosted Task Managers vs Local-First Apps in 2026

Running your own task server gives you control over its operation. Keeping tasks on your device avoids running a server at all. Those are different answers to different problems. Before installing anything, decide whether you need shared projects, independent offline work, or a sync operator that cannot decrypt task content.

Direct answer: personal inbox or maintained team service?

Choose local-only or local-first capture for personal tasks when you do not need shared project administration. Choose a self-hosted multi-user app when shared projects and operator control justify maintaining a service. If hiding task content from the server operator is mandatory, evaluate documented end-to-end encryption separately: neither your own server nor local-first storage proves that property. These models can also be combined.

Methodology and facts checked: November 2, 2026

This is an ownership-model comparison, not an installation benchmark or a hands-on security audit. We checked official deployment, storage, synchronization, backup, and feature documentation for Vikunja, Radicale, Tasks.org, and Etebase, plus Zero-Friction's current client and REST API implementation. Every table row was reviewed against those sources on this date.

The criteria are operator access, offline independence, remote access, collaboration, update responsibility, backup scope, and recovery effort. We do not rank monthly prices: a free software license does not establish a free hosting, support, or recovery budget. No measured uptime, installation-time, or performance claim is made.

Self-hosted and local-first describe different layers

Self-hosted describes who operates the service. A server on your NAS or rented infrastructure still runs software that needs updates, access controls, and recoverable storage. A rented server also introduces an infrastructure provider; moving away from a SaaS vendor does not remove every third party.

Local-first describes where useful work can happen. The Ink & Switch local-first essay puts local data and offline work at the center rather than treating the device as a disposable server cache. A particular app may implement only some of those ideals. Check behavior rather than treating a label as certification.

Local-only is a narrower configuration: tasks remain on one device unless you deliberately copy or export them. Local-first software can synchronize across devices and can support collaboration; it is not inherently a synonym for a single-user app. Conversely, a self-hosted web app is not automatically local-first because you own its server.

For a deeper explanation of the offline boundary, read what offline-first changes about task-app privacy. This article stays focused on operating responsibility rather than ranking every private task app.

Vikunja: self-hosted collaboration with a real service to maintain

Vikunja is a concrete choice when you need projects shared with other users or teams. Its feature documentation lists assignments, recurring tasks, attachments, and list, table, Kanban, and Gantt views. Those capabilities address a different problem from a small personal capture inbox.

The installation documentation says its API and frontend ship in one deployable binary or container. It supports SQLite, PostgreSQL, MySQL, and MariaDB. That does not mean every deployment has one moving part: the full Docker examples also cover databases and reverse proxies for access under a domain.

Use those official instructions for the release you deploy. This comparison deliberately does not provide a copied Compose file, choose your authentication settings, or imply that starting a container completes a production installation.

What control you gain, and what remains readable

You choose the host, update policy, access arrangements, and backup destination. You can operate a service without putting task management under a separate SaaS account. Those are meaningful control gains.

They do not demonstrate that the server cannot read the tasks it manages. The reviewed deployment and backup documentation describes server-side task storage, not a task-content E2EE configuration. Treat privileged application, database, and storage access as trusted unless a separately verified encryption layer changes that boundary. A promise not to sell task data is not evidence about key custody.

Back up more than the container image

Vikunja's backup documentation explicitly identifies two data components: the database and attachment files. It also warns that project deletion is permanent and irreversible. A clean container image is not a copy of either data component.

Keep the configuration and credentials needed to rebuild the service under separate protection. Before an update, read the release notes, make an appropriate backup, and understand migrations. Test restoring into an isolated instance rather than discovering at the next outage that the attachment folder was omitted.

Choose this model when: shared projects and administrator control are worth sustained maintenance. Do not choose it merely because: a server you own sounds automatically more private than every local app.

Tasks.org plus Radicale: separate the task client from the sync server

Tasks.org can operate offline or synchronize with several services. Its sync matrix and CalDAV guide list self-hostable backends including Radicale and Nextcloud. This is a useful middle ground for someone who wants a local Android task client and control over the synchronization endpoint.

Radicale's official documentation describes a CalDAV/CardDAV server that supports to-do records and stores data in a filesystem folder structure. It supplies a synchronization service, not a replacement for every project-management interface. You must choose compatible clients for the other devices you use.

Ordinary CalDAV is not task-content E2EE. HTTPS can protect a connection to the server, while the server still processes readable calendar/task records. Radicale specifically warns that unauthorized access to its storage folder can expose calendar data. Disk encryption and careful file permissions matter, but they do not turn this into a provider-blind protocol.

Check authentication before making a test service reachable

Radicale's quick-start example deliberately uses no authentication for local testing. The documentation labels that mode insecure and directs remote users to proper configuration. Do not publish a test setup to the internet because it happened to work on localhost.

Plan authentication, authorization, transport protection, and network access deliberately. A private network or VPN can narrow exposure, but neither replaces application updates nor guarantees protection if a device or operator account is compromised.

Check field continuity, not just whether login works

A successful sync does not prove that every task detail survives. Tasks.org's current matrix distinguishes backend support for subtasks, recurrence, reminders, and other fields; attachments and timer data are not carried by the listed sync options. Check your required fields on both clients.

Use a few non-sensitive sample tasks: one recurring item, one with a description, and one completed on the other device. Edit them while disconnected, reconnect, and inspect the result. These are recommended evaluation steps, not tests we claim to have performed for this comparison.

Etebase: owning the server and encrypting content can coexist

If the sync operator must not receive readable synchronized task content, consider the encrypted protocol as well as the hosting location. Tasks.org's EteSync documentation identifies EteSync as an E2EE option and supports hosted service or a self-run instance.

The official Etebase server repository provides deployment and configuration instructions for running the service yourself. It calls for a proper production setup with TLS and identifies both the database and stored user-data directory as backup targets. E2EE does not remove those duties.

This is not equivalent to entering the same credentials into an ordinary CalDAV endpoint. You need compatible clients and the correct server configuration. Tasks.org also keeps local lists separate from the lists in its EteSync account until you deliberately move the data.

Keep the claim narrow: E2EE protects the covered synchronized content, not necessarily every identifier, connection log, device copy, notification, or exported file. A server backup alone also does not establish that a user who loses necessary decryption credentials can recover readable tasks. Verify that recovery path before relying on it.

Three encryption boundaries to check in any deployment

1. Encryption in transit: TLS protects traffic between endpoints. A server that terminates the connection can still process the content.
2. Encryption at rest: encrypted disks or database storage can protect stored media under a particular threat model. An operating service with the keys can still read data.
3. Task-content end-to-end encryption: covered content is encrypted and decrypted at the participating clients without giving the sync operator the content-decryption capability. Inspect the actual fields, integrations, and key-handling paths.

Metadata needs its own questions. Who sees account identifiers, timestamps, list relationships, notification details, and connection records? Self-hosting changes who administers those records; it does not make them nonexistent. None of these deployment labels alone establishes legal compliance or a guarantee against compromise.

The maintenance decision: who owns the next outage?

For a personal local-only list, you maintain the device and a recovery route. For a shared server, you also own an application's availability for other people. Before committing a team to self-hosting, name an operator and a backup person rather than relying on the one colleague who enjoys containers.

Write down a small operating agreement:

• Updates: who follows application and dependency releases, schedules patches, and checks whether migrations succeeded?
• Access: who can administer accounts, read storage, inspect logs, and revoke an old device or integration?
• Backups: which database, attachments, configuration, and credentials are required, and where is a protected independent copy?
• Recovery: who has actually restored a disposable test instance, and what loss of recent edits is acceptable?
• Remote use: which service is reachable, from where, and what happens when the home connection or server is unavailable?
• Continuity: can the real clients read and create tasks offline, and what happens to competing edits on reconnection?

This is work even if the software license costs nothing. Existing hardware does not eliminate electricity, storage, operator time, or the consequences of an incomplete restore. Managed hosting can transfer some operating work, but you must still understand its contract and content-access model.

When local-only is simpler, and when collaboration is worth the server

For one person capturing a grocery reminder or a next action, a local list can be the smaller system. It has no remote task service to patch or expose. The trade-off is continuity: losing the only device without a usable backup can mean losing the only copy. Operating-system backups, browser storage, and manual exports need explicit review rather than assumed equivalence.

For a team assigning work, shared state can justify a maintained service. Vikunja's shared projects and assignment model provide capabilities a personal inbox does not. The question is not whether collaboration is inherently unsafe, but whether the benefits justify the access model and operating work you accept.

If you need product choices after settling the ownership model, use the private and local-first task-app comparison. Do not choose a server architecture to avoid deciding which task workflow you actually need.

Who Zero-Friction is for, and who it is not for

Zero-Friction Tasks fits someone who wants fast personal capture without creating an account first and without maintaining a task server. Local-first capture and optional cross-device sync are its narrower role. It is not a self-hosted project suite, and we are not offering a supported self-hosting deployment in this comparison.

Choose something else if you need shared project administration, team assignments, an audited provider-blind service, or control over the sync server itself. A minimalist inbox is not a functional substitute for those requirements.

Its sync is encrypted, but not provider-blind

The reviewed client code encrypts task text before normal sync. That does not establish encryption of every field: pin state, ordering, identifiers, and timestamps remain separate metadata, and legacy/error paths must not be described as universally encrypted.

The sync code reaches the backend. The public REST API authenticates with that code, and its current implementation can derive the key and decrypt stored task text server-side for responses. We therefore do not claim that the provider can never process readable content or that everything is E2EE. Local capture, optional sync, and provider-blind encryption are distinct properties.

For that exact boundary, see private task sync: what leaves your device. Test with non-sensitive tasks before enabling a sync or API workflow you intend to trust with more important information.

Want the smaller personal inbox rather than another server to operate? Download Zero-Friction Tasks.