[minutes] Kollicloud Demo

docs/federation/minutes/2026-05-21-introducing-kollicloud.md

@@ -0,0 +1,131 @@
+# Community Call "Cooperative Clouds with Kollicloud"
+
+## Date: 2026-05-21 12:00 UTC
+
+## Attendance
+Hosting: Simon, Wouter Tebbens (Free Knowledge Institute)
+
+Minutes: amras
+
+Present: Carla, d1 (coop cloud), Danny (eCommons), Graham (innovation.coop), Jeff, iexos, KawaiiPunk (Autonomic, Co-op Cloud, Tech Care Co-op), mikemh, Moritz, Simon, steven
+
+## Resources
+- [Video recording, and a report by Wouter Tebbens](https://freeknowledge.eu/cooperative-clouds-in-practice-kollicloud-shows-how-affordable-sovereign-infra-is-already-here)
+- [Announcement fediverse toot](https://social.coop/@fkinstitute/116566545446152790)
+- [Post-show fediverse toot](https://social.coop/@fkinstitute/116618445246768053)
+
+## Minutes
+
+### Admin
+Only the presentation will be recorded. Recording switched off for Q&A and conversation.
+
+### Democratic Tech Fund
+[Website](https://democratictech.fund/)
+- w: Democratic Tech means: the community impacted by tech takes responsibility for its own tech. Beyond OSS, OSS+governance+economics.
+- Tech monopolies take political power over a lot of people in our society; impacted+dependant. This is why we work on digital autonomy. Not just technical, but social capacity, appropriate technologies + economics & governance models. This can't be done alone, need to do in a network fashion.
+- 3 domains: collaborative workspaces, decentralized social media, tools for cooperative organizing. We're collectively studying what exists, what works, what people need and how we respond to those needs.
+- Democratic Tech Fund works on discovery of the tech and collective fund raising, vouch funding, public+private match funding. Early stage, building one step at a time. Tough to get started, but in good company.
+- Thanks to ecommons we have a doc server on outline, thank you to d1 for help with running that on a coop cloud recipe.
+- We're asking for donations for DTF.
+
+### Kollicloud
+[Website](https://kollicloud.de/)
+
+Introducing: Simon, Carla, Moritz from [Local-IT](https://local-it.org)
+
+- Q(w): what is the relationship of Kollicloud to the coop cloud federation
+
+> Simon presenting & talking
+
+- Local-IT is a small non-profit.(35 members, 6 part time). Focused on education and networking events to move orgs away from big tech. Digital Sovereingty and free software for society.
+- Building on Co-Op cloud's amazing infrastructure:
+    - configuration commons + abra tool
+    - not going into details, want to focus on demo w/ alakazam
+    - The deployment process with abra is fairly manual, not a lot is preconfigured.
+    - When I discovered this, focus was less on the federation aspect but the tech aspect. After talks at CCC etc, focused more on how we want to govern/collaborate at Local-IT and DTF. This makes Co-op Cloud distinct form similar projects.
+- KolliCloud is a ready-to-use integrated hosting toolkit for clubs, NGOs and collectives in Germany (no international right now). Bundle of 15 apps + SSO, backups, monitoring so it can be deployed quickly.
+
+#### 3 hosting flavors
+- self-hosting with alakazam. We have guides in german on the kollicloud website. Hope to translate to English soon.
+- Managed hosting: we offer support.
+- Collective hosting approach, intermediate between self and managed hosting. Share not only the integrated config but also the infra. Multiple admins on the same infra, cogoverning multiple instances. More on this later.
+
+#### alakazam
+- core of kollicloud; meta-config layer.
+- Managing 230 apps by hand is not an option (if we wanted to do everything with abra)
+- alakazam's commands help us orchestrate instances on multiple VMs, multiple docker swarm instances per VM.
+- hierarchical yaml configs -> generate env files, with different override for testing/production stages.
+- one secret can be shared between multiple instances
+- batch updates, each coop cloud recipe is checked for upgrades, verify nothing broke in testing, and if nothing breaks push to prod. A month ago we did this with our 230 apps.
+
+#### Configuration hierarchy:
+- defaults set, with default app settings grouped by domain.
+- We have defaults for subdomains of our apps
+- ovverrides as you move deeper into the hierarchy; the closer the config is to the instance, the higher prio.
+- a lot of configs depend on app combinations, e.g. authentik (SSO+ident) with nextcloud - alakzam knows what to enable in the authentik and nextcloud env files to make them work together.
+- We want to move these combinations out of global, to per-recipe.
+
+#### Demo, deploying an instance:
+- File structure: 
+    - usually we have one file that specifies backup+monitoring+traffic, named after the vm.
+    - we then have 1 file per instance on that vm, which specifies apps to deploy. Usually, it's enough to name the app, don't need to specify custom configs. Ongoing work: feature packs.
+- alakazam command, layered:
+`alakazam group_dir/server_dir/instance.yml <command>`
+> running config command
+> running secret command
+
+- I commented out the part of the secrets code which prints secrets, for privacy
+- w: time for murphy's law
+- after waiting a minute, error printed in `alakazam.py` (known issue), just rerun secrets.
+> running deploy command
+- deploy dumps all the abra commands in stdout
+- w: a lot of magic happening :)
+> S continues talking while we wait for deployment
+- half a year ago, had a discussion in the coop cloud channel: "the future is not self-hosted". For most people, sh is too difficult, it's only an option for a tech niche. We need a way for everyone to use the tech, not just those who can provide their own software for themselves. Co-op cloud solves a lot of this, because shared recipes are convenient. One of the first things I do when I want to try out new software is I search for a coop cloud recipe; makes it very easy. The next step at KolliCloud is to integrate it with backups, monitoring, defaults.
+
+- When I was using abra, I procrastinated on SSO, and every time I tried it was problematic. KolliCloud is a lot more convenient, because you don't have to think where what secret goes etc.
+- w: demo deployment is up, just opened it https://login.dtf.dev.kolli.cloud/
+> returning to demo
+- s: alakazam deploy won't try to deploy what's already deployed.
+- w: not working on my side
+    - s: right, we need to run a few more commands
+    - w: we're actually short on time, maybe we can move to questions?
+
+### Questions
+- Q(w): what orgs are using kolli cloud?
+    - [Lambda Bundesverband](https://lambda-online.de/) - germany's largest queer youth org. We host their IT tools, next cloud and stuff. We also host a queer support tool, which allows queer people to get in contact with them. This is integrated in the backend with Zammad via Matrix/Element and Signal-Bridge. So people who respond to questions are replying in matrix chat.
+        - Valentin provides them with computers+preinstalled software, tightly integrated with kollicloud, we're providing hosting.
+- Q(w): how large are these groups?
+    - s: 100+ users, not sure how many active at once. But this is more than we aim for. We usually aim for up to 100.
+    - Moritz: we also have a voluteer fire brigade.
+- Q(w): why only associations and clubs? This tooling could be useful in other types of orgs.
+    - M: Local-IT is an association; easier to provide tools for usecases similar to our own. We also have funding that supports associations in Germany, that's why our main focus is on associations.
+    - M: for commercial orgs, we have to check/vet if we can stand behind it. So we're open to providing for commercial orgs, but only aligned with our values. There are a lot of associations in Germany.
+- w: Thank you Simon for your presentation! Switching off recording now.
+- Q(d1): Love the "where actual work sits" slide - progression from coop cloud to kollicloud. I want to hear about the economic side. We know the economics of hosting are shit; we're approaching the most underfunded parts of society and asking them to pay us for something they get 'for free'. How can we make this sustainable in the long term? Interested in the mutualization of labor, shared admin layer. Does that come in to the economics of this?
+    - S: Mostly funding from various sources; calculated we need like 500 instances to pay 2-3 part-time jobs.
+    - S: on shared admin, we need to work on this more. The idea is set - a couple people have admin rights+ssh keys on a server with e.g. 7 VMs. Admins can then assist each other, like "I'm going on holiday; please help if my community's infra breaks". A lot of people are engaged in communities; if each has a cloud like ours then a federated cloud might not be so far away.
+    - d1: seems that our ideas are leading to this point on the horizon.
+- Q(Graham): Interested in that economics question, but also interested in how robust the stack is. It's not a mainstream tech stack, for all of it. How might this apply to small businesses, small cooperatives? It needs to be rock solid if someone runs a business on this.
+    - S: Main reasons we're not targetting small businesses is our own availability. If something goes down, we can't address it in minutes/hours. This expectation is less for associations.
+    - S: I think this stack is quite stable. Most problems arise when the FOSS we use becomes unavailable because of premiumizing. E.g. software makes SSO premium and we have to ask if we have backup options or if we need to spend money on licenses.
+    - M: the stack is quite stable; biggest problems arise from software. Some of what we deploy is maintained a single person in their spare time, so there are bugs/instabilities in the software itself.
+    - M: updates can break a lot of stuff, which is why we test for two weeks on our own servers first before we deploy for production for all the associations. Testing updates is the biggest factor in stability. But there are still bugs we can do nothing about. When we have important security patches, we need to deploy updates even with bugs. You probably know these problems if you self-host open source software.
+- w: Proposal: could you keep this demo deployed so everyone can have a look?
+- Q(mikemh): across all the accounts you operate; are there patterns emerging with the apps or configs people are using? Can you have an expectation of what people will need?
+    - S, M: that's what we're doing with the default configs. We expect most users want to deploy with these configs. We learn from our users and put that into our defaults.
+- Q(w): what if we want to add a new app, that's not in kollicloud? Is that a lot of work? How do you go about that in contact with the co-cop cloud federation?
+    - S: I have a slide for this!
+    - S: Not a lot of work. But you need a well-maintained CC recipe (needs to run).
+    - S: If we need it to integrate we add it to combine.yml.
+    - S: If we want to specify defaults we put them in the kolli-config repo, based on the diff of the config compared to CC's default.
+
+> Demo finishes deploying, it works!
+
+- w: beautiful dashboard with powerdul applications. You're offering a powerful methodology for collaboration. Really promising.
+    -S: thank you! Wanted to show more, but ran out of time.
+- Q(w): how long will you keep this demo site open?
+    - M: for the next few hours.
+    - M: we have other demo instances; you can ask us for credentials :)
+    - w: please post those in the matrix channels!
+- w: another world is possible; you are doing it!