Seven ways to run it, one product

A hub for work, one for the household, one for the flat you are renovating. Under each, the lists you actually keep. Recurring bills, a shopping list, the maintenance schedule for a bike — and the whole thing on a machine in your own home, with the full feature set and nothing withheld.

Free, and free with the condition stated out loud. Hubtask is open source under Apache-2.0, with no feature gate and no licence key — and the project makes no promise about maintenance. If it stops tomorrow, every version you are running is still yours to run, change and carry on. That is written into the licence rather than promised in a blog post.

What matters here

• Nothing phones home No telemetry, no licence check, no font loaded from a foreign domain.
• Backups you configure Your own target, your own schedule, encrypted, with a restore that has been drilled.
• Export whenever CSV, JSON and ICS from any view; a full workspace export as a use case.
• One container and a database The homelab standard, not a stack of five services.
• A forgotten password is survivable Recovery codes you can copy and replace, without a mail server.
• Set up in the browser Planned The first start prints a one-time code, and the browser creates your workspace and account — no terminal, no database shell.
• Passkeys Planned Signing in without a password, as its own milestone.

One installation for the household: a hub for the groceries, one for the holidays, one each for the things that are nobody else’s business. A person can be a member of one hub and see nothing else, which is how a child gets their own corner. Reminders, recurring chores and templates for the weekly routine work the same for everybody.

The technical parent sets the rules once. Who may sign in how, who needs a second factor, what is kept and for how long — set in the administration, and the others never see a settings screen.

What matters here

• A hub per person or topic Membership on one hub reaches that hub and nothing above it.
• Private hubs Planned A hub another adult cannot open just because they are an administrator too, with an emergency access that tells every member at once.
• Accounts without a mail address Planned A child or a grandparent signs in with a name and a start password Hubtask makes, and changes it at the first sign-in.
• Invitations without mail Planned Handed over as a link or a code when the household runs no mail server.

Every customer gets a workspace of their own, behind the same database boundary as every other. Your purchase or sign-up platform creates it through the API, suspends it when a payment fails and resumes it when it arrives — with an idempotency key, so a webhook that arrives twice creates nothing twice. Hubtask holds the state; your platform holds the contract, the price and the invoice.

Your imprint and privacy notice, on every sign-in page, locked. The installation sets a value and decides whether a workspace may change it. You see numbers and states for every workspace, never a customer’s content.

What matters here

• A credential for the platform A service account provisions workspaces, not a token belonging to an employee. On the operator screen Planned; through the API today.
• Google and Microsoft sign-in Offered to every workspace by the installation, admitting only people who were invited.
• Limits per workspace Visible before they hurt; a workspace at its limit is refused the next thing, never loses the last.
• Terms agreed and re-agreed Planned With the version and the moment on the account.
• AI included Planned A model the provider offers, one click for the customer, counted against a budget.
• Plans Planned Limits, features and locks per plan; a downgrade stops, never deletes. Its own milestone.
• Sign in with Apple Planned Needs a signed client secret and its own decision.

In multi-workspace mode each client is a workspace: its own hubs, its own members, its own labels, its own retention rules — and its own backup and its own export, rather than one undifferentiated dump you would have to cut up by hand if a client left.

The boundary is in the database. Row level security enforces it, every query runs inside a transaction that has declared which tenant it is acting for, and a cross-tenant test exists for every repository method — a gate in the build fails when one is missing. It is not a WHERE clause somebody has to remember on a Friday.

What matters here

• Each client configures itself Its own directory, legal texts and sign-in rules — within the defaults and locks you set for every workspace.
• Providers you offer Sign-in providers configured once by the installation and switched on by each client, without seeing a secret.
• Provisioning and suspension Creating, suspending and deleting a workspace are operations, not database surgery.
• Quotas and fairness One noisy workspace does not become everybody’s latency.
• An export a client can take Leaving is a supported operation, which is what makes staying a choice.
• AI you offer, or theirs Planned Offer your own model, let a client bring theirs, or require a minimum jurisdiction.
• The client’s own domain Planned Two DNS records to copy, the rest automatic — after passkeys and plans.

An installation’s defaults and locks — sign-in rules, legal texts, limits, language defaults — can live in one file: written once on the first start, or enforced on every start with the screens refusing to change it. Container images and a Helm chart, migrations that run as their own job and are safe during a rolling update, and a health report and metrics on a port of their own.

What matters here

• The installation as code One file, seeded or enforced, and the health report says which applies.
• An operator register The people and machines who may run the installation, separate from every workspace’s administrators, with an hour of elevated access after a fresh proof.
• Key rotation with a census Rotate the installation’s keys and see which secrets moved.
• Operators from the file Planned Who runs the installation, named in the file and the environment, and a command in the server binary to get back into an installation nobody can run.

The specification is written first and the code is generated from it; the interface is one client among several. Everything a person can do, a token can do — with idempotency keys so a retry does not duplicate, optimistic concurrency so a blind write does not clobber, and errors that carry a code and parameters rather than a sentence to parse. Client libraries for Go, TypeScript and Python are generated from the same document, and the n8n and Zapier connectors are built and tested, to be published with the convergence milestone.

An agent gets the same catalogue over MCP, running inside your installation. It holds a scoped credential, it is refused exactly what that credential would be refused over HTTP, and every action it takes is in the trail marked as an agent’s.

# The whole product, from a terminal
hubctl item create --collection "$C" \
  --type TASK --title "Renew the domain"

hubctl due set "$ID" --at 2027-01-31
hubctl recur set "$ID" --rule "FREQ=YEARLY"

# Follow the change stream
hubctl watch

# Or pipe it
hubctl search domain --json | jq '.items[].title'