Two failure modes dominate small-community infrastructure, and most of the writing about sovereign cloud skips both. The first is the stack: fifteen apps, single sign-on, backups, monitoring, each fiddly, none of it funded. The second is the operator: one volunteer, or one consultant, holding all of it in their head. Papermerge is living the second one right now — nine years of OSS work, a 30-day "seeking maintainers" clock that runs out early October, and if nobody steps up the repo archives. This post is about a project that attacks the first problem structurally and has an honest, unfinished answer to the second. The source is a Free Knowledge Institute community call with KolliCloud from May 2026, with recording, slides, and transcription all public — an unusual amount of receipts for this space.

What KolliCloud is, and what the interesting part actually is

KolliCloud is developed by Local-IT e.V., a German registered association — ~35 members, six part-time positions — building free software for associations, using the tools themselves. A Verein building for Vereine: the operator is the same organizational form as the users, which is not incidental, it is the design constraint doing its job.

The platform itself is a curated bundle of roughly fifteen free-software applications — Nextcloud, Authentik, Element/Matrix, Wekan, OnlyOffice, Vikunja, Vaultwarden among them — deployed as one integrated platform with SSO, automated backups, and monitoring included from the first minute. Three deployment models: self-hosting (public config repos and guides), managed hosting (€20-200/month, averaging around €60), and the middle path — collective hosting, more on which below.

But the app list is not the story. Anyone can copy a list of apps. The interesting part is what KolliCloud is built on and what it adds.

It is built on the Co-op Cloud Federation's configuration commons — community-maintained application recipes plus the abra deployment tool. Co-op Cloud answered "how do I install one app." KolliCloud takes the next step: "how do I run all of them together as one coherent platform." Local-IT's own slides say it plainly: self-hosting doesn't remove the work — it shifts it. Where does the work shift? Onto configuration glue, maintenance cadence, and the person holding the admin password. Which is exactly where small organizations die.

What KolliCloud adds on top is Alakazam — a meta-configuration layer and abra wrapper with hierarchical YAML configuration and inheritance. Defaults defined once; each instance specifies only what differs. Critically, it understands combinations: declare that an instance has both Authentik and Nextcloud and Alakazam applies the correct integration configuration to both, instead of a human looking up which environment variables must match. Local-IT runs ~230 deployed applications across their managed instances. Their staging-first workflow — two weeks in staging, then a single command pushes to all production — ran across all 230 apps a month before the May session. Total effort: a few hours.

That number is the entire economic argument for cooperative hosting in one line. If upgrading fifty instances takes fifty times the work, community hosting is unaffordable. If it takes roughly the same time regardless of instance count, the economics change shape.

Alakazam itself is honest about its stage: the repo warns it is experimental, in production for a tailored use case, with features being mainlined into abra over time. The Co-op Cloud Federation passed Resolution 037 in February 2026 formally adopting it as an official federation project — which means the methodology propagates beyond one organization, with docs, tests, and teaching as the stated collaborative work.

Who runs it

The user profile is exactly the audience this site writes for: organizations with real collaborative needs, no dedicated IT staff, and a desire to operate on tools they control. A volunteer fire brigade. Social organizations with over 100 user accounts. The most vivid example is Lambda Bundesverband — Germany's largest queer youth organization — whose entire support infrastructure runs on KolliCloud: a Zammad ticketing system integrated with Matrix/Element and a Signal bridge, so volunteers respond to support requests directly from their chat client. That is not a file share with a login page. That is a small organization running a coordinated service stack on infrastructure it controls.

Local-IT also demonstrated a live deployment during the call: fourteen applications, SSO wired, backups and monitoring configured, from empty server to running platform in under thirty minutes — consistent with their documented benchmark, including VM, backup, and monitoring. The demo also surfaced an ampersand-in-password parsing error live, which is worth knowing: the system works, and it still needs polish before it is fully turnkey for independent operators. Both facts are true at once.

The collective hosting model — and what it is actually for

The most interesting and underdeveloped idea in KolliCloud's architecture is collective hosting: what Simon described as "the same idea as Co-op Cloud, one layer down." Seven members host seven instances on a shared framework, with multiple admins holding access to the same infrastructure. The practical benefit is mutual cover: if one administrator goes on holiday, someone else can step in when infrastructure breaks. This is the beginning of federated mutual aid applied not at the application layer — where the federation already operates — but at the infrastructure layer.

The observation from the floor is worth quoting directly: if each community in the network runs a cloud like this, a genuinely federated cloud — distributed, community-governed, resilient — is not far away.

Read that against the last two months of this site's coverage. File Browser: 36,000 GitHub stars, ten years old, archived September 1, 2026 — the repository went read-only, and the maintainer's own write-up is more honest about the cause than most: security advisories kept coming, the architecture needed rewrites the code could not absorb, and the will was gone. Papermerge: nine years, one maintainer, a 30-day "seeking maintainers" clock that runs out early October; if nobody steps up, the repo archives too. The pattern is consistent: healthy-looking projects with a bus factor of one, closing with either a licence change (Notifuse, BSL 1.1, named gated features, four-year AGPL conversion — the gentler version) or a maintainer loss (File Browser, Papermerge — the harsher version, because a licence scanner catches the first and nothing catches the second until the CVE feed goes quiet).

The tool-layer fixes — Co-op Cloud's recipe commons, Alakazam's hierarchical config — attack the wrong axis for that failure mode. They make the work shareable. They do not, by themselves, put a second person's SSH key on the server. Collective hosting does exactly that: multiple admins holding access to the same infrastructure, so an absence is a schedule change, not an outage.

This is the same argument this site made about community networks: the bottleneck is not the software. It is the runbook, the second operator, the monitoring that pages someone, the answer to "who fixes this in eighteen months." KolliCloud is one of the first projects in this space to take that seriously at the platform layer rather than the application layer — and honest that the answer is incomplete.

The economics: Local-IT's own numbers, unflattering and published

The most respectable thing in the whole session is Local-IT's own accounting of its sustainability. Approximately €540,000 in development funding since 2021, from German public and civic sources — Akademie für die ländlichen Räume, DSEE, Kreis Ostholstein, Stadtwerke Eutin, DigitalHub.SH, the Fernsehlotterie. Managed instances at €20-200/month, averaging around €60. And Local-IT's own estimate of what it takes to sustain two to three part-time positions: roughly 500 instances. They are not there yet.

Asked directly — "we're approaching some of the most underfunded parts of society and asking them to pay us for something they get 'for free'. How can we make this sustainable?" — Simon's answer was: "We need to work on this more." That is the opposite of the sovereignty-washing this site keeps flagging. A project that names its own unsolved economics is one you can build on. A project that markets around them is one you should audit harder.

The proposed path is not growth into a centralized provider. It is mutualization: shared administration across a wider community, the collective hosting model, so per-instance maintenance does not multiply with instance count. That is also — Local-IT is explicit about this — work in progress.

What is actually copyable

For a community operator deciding what to take from this, the copyable parts are specific:

  • The recipe commons model. Co-op Cloud maintains ~200 community-maintained recipes for standard FOSS apps; abra deploys them; the recipes carry the maintenance pattern, not just the install script. Any org can adopt that layer on its own hardware today.
  • The hierarchical configuration pattern. Alakazam's core idea — defaults at the top, instance deltas below, integration combinations handled automatically — works as an approach even if you never touch Alakazam itself. A Git repository with a defaults file and per-instance diffs is implementable in any config management stack, including Ansible and kustomize.
  • The collective hosting governance layer. Seven members, seven instances, multiple admins with access — a mutual-aid layer at the infrastructure layer. The mechanism is boring and concrete: shared SSH access with named humans, shared runbooks, shared on-call expectations. This is the part that answers "who fixes this when I'm on holiday" for the fire brigade, the queer youth org, the food co-op.
  • The honesty as a template. Publish the funding history. Publish the per-instance price. Publish the sustainability gap — and what closing it is estimated to require (500 instances). A project that publishes its own unsolved economics is one you can plan around. A project that markets around them is not.

Two honest caveats before adopting: self-hosting guides are currently in German with English translation in progress — a real cost for non-German-speaking operators. And the economics are not solved: if you adopt this model for a paid service, know that you are building on a grant-supported foundation whose long-term business model is still being worked out in public. Both are facts, not disqualifiers. The tool layer is real and working — 230 apps upgrade in a few hours, a new instance comes up in under thirty minutes, and the federation has adopted the methodology. The social layer is what still needs builders.

Sources: Free Knowledge Institute: Cooperative Clouds in Practice — KolliCloud (May 21, 2026 community call, with recording, slides, and transcription); KolliCloud; Local-IT e.V.; Alakazam repository; Co-op Cloud Resolution 037 (passed February 2026); Co-op Cloud Federation; Papermerge maintainer search; elest.io Self-Hosted Weekly, week 38.