.

Backupbottwo.md

@@ -0,0 +1,293 @@
+---
+title: Backupbot-two
+---
+
+# For Operators
+
+## Deployment
+
+**1. Create a new app:**
+
+```
+abra app new backup-bot-two
+```
+
+**2. Configure :**
+
+## Usage
+
+Run the cronjob that creates a backup, including the push notifications and docker logging: abra app cmd <backupbot_name> app run_cron
+
+### Create a backup of all apps:
+
+```
+abra app run <backupbot_name> app -- backup create
+```
+
+    The apps to backup up need to be deployed
+
+### Create an individual backup:
+
+```
+abra app run <backupbot_name> app -- backup --host <target_app_name> create
+```
+
+### Create a backup to a local repository:
+
+```
+abra app run <backupbot_name> app -- backup create -r /backups/restic
+```
+
+It is recommended to shutdown/undeploy an app before restoring the data
+
+### Restore the latest snapshot of all including apps:
+
+```
+abra app run <backupbot_name> app -- backup restore
+```
+
+### Restore a specific snapshot of an individual app:
+
+```
+abra app run <backupbot_name> app -- backup --host <target_app_name> restore --snapshot <snapshot_id>
+```
+
+### Show all snapshots:
+
+```
+abra app run <backupbot_name> app -- backup snapshots
+```
+
+### Show all snapshots containing a specific app:
+
+```
+abra app run <backupbot_name> app -- backup --host <target_app_name> snapshots
+```
+
+### Show all files inside the latest snapshot (can be very verbose):
+
+```
+abra app run <backupbot_name> app -- backup ls
+```
+
+### Show specific files inside a selected snapshot:
+
+```
+abra app run <backupbot_name> app -- backup ls --snapshot <snapshot_id> --path /var/lib/docker/volumes/
+```
+
+### Download files from a snapshot:
+
+filename=$(abra app run <backupbot_name> app -- backup download --snapshot <snapshot_id> --path <absolute_path>)
+abra app cp <backupbot_name> app:$filename .
+
+# For Maintainers
+
+TODO:
+pre/post hooks
+- Simple command
+- accessing secrets
+- more complex scripts mounted in the container
+
+From the perspective of the recipe maintainer, backup/restore is just more
+`deploy: ...` labels. Tools can read these labels and then perform the
+backup/restore logic.
+
+## Tools
+
+Two of the current "blessed" options are
+[`backup-bot-two`](https://git.coopcloud.tech/coop-cloud/backup-bot-two) &
+[`abra`](https://git.coopcloud.tech/coop-cloud/abra).
+
+### `backup-bot-two`
+
+`backup-bot-two` is a recipe which gets deployed on the server, it can perform automatic backups.
+Please see the [`README.md`](https://git.coopcloud.tech/coop-cloud/backup-bot-two#backupbot-ii) for the full docs.
+
+### `abra`
+
+`abra` will read labels and store backups in `~/.abra/backups/...` .
+
+## Backup
+
+Unless otherwise stated all labels should be added to the main service (which should be named `app`).
+
+1. Enable backups for the recipe:
+You need to enable backups for the recipe by adding the following label:
+```
+backupbot.backup=true
+```
+
+2. Decide wich volumes should be backed up:
+By default all volumes will be backed up. To disable a certain volume you can add the following label:
+```
+backupbot.backup.volumes.{volume_name}=false
+```
+
+3. Decide which path should be backed up on each volume
+By default all files get backed up for a volume. To only include certain paths you can add the following label:
+```
+backupbot.backup.volumes.{volume_name}.path=/mypath1/foo,/mypath2/bar
+```
+
+Note: You cann include multiple paths by providing a comma seperated list
+Note: All paths are specified relativ to the volume root
+
+4. Run commands before the backup
+For certain services like a database it is not reccomend to just backup files, because the backup might end up in a corrupted state. Instead it is reccomended to make a database dump. You can run arbitrary commands in any container before the files are backed up.
+To do this add the following label to the service on which you want the command being run:
+```
+backupbot.backup.pre-hook=mysqldump -u root -pghost ghost --tab /var/lib/foo
+```
+
+5. Run commands after the backup
+Sometimes you want to clean up after the backup. You can run arbitrary commands in any container after the files were backed up.
+To do this add the following label to the service on which you want the command being run:
+```
+backupbot.backup.post-hook=rm -rf /var/lib/mysql-files/*
+```
+
+### Testing the backup
+That's it your recipe can now be backed up. But how can you make sure your configuration is correct?
+
+TODO:
+
+### Examples
+
+## Restore
+
+Restore, in this context means, "moving a compressed archive back to the
+container backup paths". So, if you set
+`backupbot.backup.path=/var/lib/foo,/var/lib/bar` and you have a backed up
+archive, tooling will unzip files in the archive back to those paths.
+
+In the case of restoring database tables, you can use the `pre-hook` &
+`post-hook` commands to run the insertion logic.
+
+## Configuration Examples
+
+### Mysql
+
+### Postgres
+
+# Specification
+
+TODO:
+    - should the post hook be executed when the backup/restore fails?
+
+## Summary
+
+Creating automated backups of docker swarm services is an often needed task. This specification describes how backups can be configured via [service labels](https://docs.docker.com/compose/compose-file/compose-file-v3/#labels-1) in a standardised way.
+
+## Requirements
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in [RFC-2119].
+
+When backing up a docker stack you MUST first check if the `backupbot.backup`. It MUST be set to true, for the backup to happen.
+
+## Backup
+
+To enable backups for a docker stack, the `backupbot.backup=true` label MUST be on any of its services. It SHOULD be declared on the first service.
+A `backupbot.backup.pre-hook` MAY be set on a service. When set the command MUST be executed inside the running container of the service before backup up files.
+By default all volumes MUST be backed up. A volume MAY be excluded from backing up when `backupbot.backup.volumes.{volume_name}=false` is set, where `{volume_name}` is the name of the volume.
+By default all files MUST be backed up on a volume. `backupbot.backup.volumes.{volume_name}.path` MAY be set to limit the paths for that volume. The value MUST be a valid path relative to the volume root. It MAY contain multiple paths which get seperated by a comma.
+A `backupbot.backup.post-hook` MAY be set on a service. When set the command MUST be executed inside the running container of the service after backing up all files.
+A backup implementation SHOULD provide the backup of one or multiple stacks in a `.tar.gz` format.
+
+## Restore
+
+A `backupbot.restore.pre-hook` MAY be set on a service. When set the command MUST be executed inside the running container of the service before restoring backup files.
+By default all files MUST be restored into their volume. A volume or path MAY be excluded from restoring.
+A `backupbot.restore.post-hook` MAY be set on a service. When set the command MUST be executed inside the running container of the service after restoring backup files.
+
+## Labels
+
+### `backupbot.backup`
+
+**Type:** boolean
+**Default:** false
+**Description:**
+Enables backupbot for this compose stack. The labe should be added to the main service of the compose stack.
+
+**Example:**
+
+```
+backupbot.backup: true
+```
+
+### `backupbot.backup.volumes.{volume_name}`
+
+**Type:** boolean
+**Default:** true
+**Description:** When set to false the volume is excluded from backups.
+
+**Example:**
+
+```
+backupbot.backup.volumes.{volume_name}: false
+```
+
+### `backupbot.backup.volumes.{volume_name}.path`
+
+**Type:** string
+**Default:** ""
+**Description:**
+A comma seperated list of paths. When one or more paths are set, it only backups up those on the given volume instead of the whole volume.
+
+**Example:**
+
+```
+backupbot.backup.volumes.{volume_name}.path: '/var/lib/mariadb/dump.sql.gz'
+```
+
+### `backupbot.backup.pre-hook`
+
+**Type:** string
+**Default:** ""
+**Description:**
+A command, that gets executed before the files are backed up.
+
+**Example:**
+
+```
+backupbot.backup.pre-hook: 'mysqldump -u root -p"$(cat /run/secrets/db_root_password)" -f /volume_path/dump.db'
+```
+
+### `backupbot.backup.post-hook`
+
+**Type:** string
+**Default:** ""
+**Description:**
+A command, that gets executed after the files are backuped.
+
+**Example:**
+
+```
+backupbot.backup.post-hook: "rm -rf /volume_path/dump.db"
+```
+
+### `backupbot.restore.pre-hook`
+
+**Type:** string
+**Default:** ""
+**Description:**
+A command, that gets executed before the files are restored.
+
+**Example:**
+
+```
+backupbot.restore.pre-hook: "lock db"
+```
+
+### `backupbot.restore.post-hook`
+
+**Type:** string
+**Default:** ""
+**Description:**
+A command, that gets executed after the files are restored.
+
+**Example:**
+
+```
+backupbot.restore.post-hook: "sqldump dump.sql && unlock db && rm dump.sql"
+```

docs/federation/index.md

@@ -6,9 +6,36 @@ Welcome to the Co-op Cloud Federation documentation!
 
 This is the public facing page where we publish all things federation in the open.
 
-- [FAQ](/federation/faq): Take a look if you're curious about the Federation is about 🤓
-- [Resolutions](/federation/resolutions): All draft, in-progress and passed resolutions ✊
-- [Finance](/federation/finance): How we deal with money 💸
-- [Membership](/federation/membership): See who's already joined in 🥰
-- [Minutes](/federation/minutes): All minutes from our meetings 📒
-- [Digital tools](/federation/tools): Tools we use to organise online 🔌
+<div class="grid cards" markdown>
+
+- __Resolutions__
+
+    Our drafts, in-progress and passed resolutions ✊
+
+    [Read More](/federation/resolutions){ .md-button .md-button--primary }
+
+- __Finance__
+
+    Learn about how we deal with money and how to get paid 💸
+
+    [Read More](/federation/finance){ .md-button .md-button--primary }
+
+- __Membership__
+
+    See who's already joined us 🥰
+
+    [Our Members](/federation/membership){ .md-button .md-button--primary }
+
+- __Minutes__
+
+    All minutes from our meetings 📒
+
+    [Past Meetings](/federation/minutes){ .md-button .md-button--primary }
+
+- __Digital Tools__
+
+    Tools we use to organise online 🔌
+
+    [Tools We Use](/federation/tools){ .md-button .md-button--primary }
+
+</div>

docs/federation/minutes/2023-05-03.md

@@ -0,0 +1,82 @@
+---
+title: 2023-05-03
+---
+
+# Co-op Cloud Federation Meeting 2023-05-03
+
+Notes from last meeting: https://docs.coopcloud.tech/federation/minutes/2022-03-03/
+
+Metadata
+
+* Time / date: May 3 @ 1500-1630 UTC https://time.is/0330PM_3_May_2023_in_UTC
+* Location: https://meet.jit.si/coop-cloud-federation-meeting
+* Attending: Autonomic (trav, 3wc), Local-IT (yksflip, Moritz), decentral1se (🐺 /free agent)
+* Facilitation: Calix
+* Notes: trav
+
+Agenda
+
+_(All times UTC, as sharp as possible)_
+
+* Introductions / checkins (5m)
+  * How you're doing
+  * Which organisation are you attached to? (if applicable)
+  * a fun (or terrible) Co-op Cloud experience you've had recently
+    * Packaging Rustdesk server 🥳
+    * Realising backupbot labels didn't work 😱
+    * Upgrading with missing backups 😅 Deployed 18-20 apps at once, wrote a script 🤯
+    * Immovable force meets unstoppable bug, no deployments ⛔
+* Decisions - what passed, any new proposals? (10m) https://docs.coopcloud.tech/federation/resolutions/
+  * we review the existing resolutions
+  * Resolution 005 / process 
+    * trav: sticking to 2 week deadline for proposals?
+    * d1: there was a meeting where we talked about it being a small decision but then it became medium. G
+    * trav: ahh mixups happen, I don't feel strongly ultimately.
+    * yksflip: maybe check-in with cas but call it passed (?). 2 weeks is a good amount of time but can understand you'd want to move on more quickly.
+    * 3wc: 2 week default good. Very async coordination, espeically if folks have to go back to their co-op to check-in. Fewer people will see it the shorter it is.
+    * Moritz: how to know size of the decision?
+      * 3wc: smallest decision size that seems fair. 
+      * d1 in chat: 'who is affected by the decision'
+    * d1: 2 weeks seems good, simpler to stick to that going forward. Super duper emergency budget
+  * What does the second point of Resolution 004 mean
+    * 3wc: first Budget is a budget for these meetings. 
+  * Superduperemergencybudget
+    * Trav: For emergency work?
+    * d1: yes, but the part that's missing is to know what is super duper emergency. There are a lot of P1 bugs but they're not all show-stoppers. There are a number of things that need to be fixed quicker than 2 weeks
+    * 3wc: emergency firefighter. Up to whoever proposes the budget as to what the structure would look like.
+* abra fixes Budget / proposal thingy
+  * https://pad.autonomic.zone/Fp6Zi846TNqATulYFqcJqw
+  * d1: if this was proposed today, wait 2 weeks and then I'd fix them. Or standing budget?
+  * trav: suggestion is wait 2 weeks then implement? or agree standing budget?
+  * 3wc: yes, but also passing emergency budget would also take 2 weeks, no?
+  * d1: propose this and do 10 hours or do a "10 hours" proposal and fit this into it. Not show-stopping bugs but 2 weeks wont kill us.
+  * trav: might be worth passing 10h/mo, something/month for fixes, maintenance / emergency. non-binding poll / gitea voting → what to work on. vs having to package bug work together. less bureaucracy.
+  * d1: can re-work decision 6 into a maintenance budget. Curious how we want to bubble-up the bugs. Board? Label?
+  * yksflip: standing maintenance makes sense to me. 
+* federation bootstrap funds 🤑
+  * trav: there's money leftover from donor
+  * d1: 6k in the pot, get the work funded.
+  * trav: buffer tho?
+  * Moritz: I'm paid from Local IT. How to decide who is doing which fixes?
+  * d1: people tend to do stuff they want to see done. Some way to share would be good....?
+  * 3wc: tags. Tickets labeled as part of maintenance budget. If assigned to someone, they are point person. Plot twist: time expectation. Someone takes something on and it's unclear when that's going to happen. Claim things for up to a week or 2 but don't claim it until you're ready to work on it.
+  * ** we love it **
+  * **d1 to roll into maintenance proposal**
+* doop coop dues waiver https://pad.autonomic.zone/xgd7lLxzT520O4KRXuWyuQ#
+  * 3wc: yusef posted, side project, low income, would like to participate. 1 year waiver of dues. They seem enthusiastic and helpful person to be around.
+  *  trav: can decide now? " Individuals/groups wanting to join Co-op Cloud who aren’t able to make a financial contribution may request a solidarity free membership." doesn't say how to make decision
+  *  d1: medium seems fine
+  *  Moritz: instead of dues perhaps doing some abra fixes
+  *  Philip: agree on waiving fees for them. How to define time to spend on project. Alternative membership fee, donate time?
+  *  3wc: part of inspiration for fedration is Co-op Cycle: too complicated to track work and money. Have to track money so wont track work. Like the simplicity. Wage is €20/h, in-kind work contribution would be 30 minutes of work contribution per month. 
+  *  d1: reflecting on unions etc, pay dues and also contribute. Something to think about.
+
+* Checkouts
+
+didn't get to:
+* Breakout groups?
+  * Software tools
+  * Finances
+  * Outreach
+  * Development
+* next meeting? Is it monthly? I forget.

docs/federation/minutes/2024-02-01.md

@@ -0,0 +1,79 @@
+---
+title: 2024-02-01
+---
+
+# Co-op Cloud Federation meeting 2024-02
+
+Date poll: https://crab.fit/coop-cloud-federation-february-2024-576238
+
+Previous notes: https://docs.coopcloud.tech/federation/minutes/2023-05-03/
+
+## Agenda
+
+- check-in
+  - name
+  - pronouns
+  - organisation
+  - how we're feeling
+  - anything we want to get out of today
+- emotional support for abra bugs
+- missed october 2023 membership dues review ([R002](https://docs.coopcloud.tech/federation/resolutions/passed/002/)), what now?
+- [backup restore / testing update](https://pad.riseup.net/p/UEC2JUPGb6tmRCZ7RX9X-keep)
+- collective abra next release planning
+- ✅ bonfire co-op network hosting proposal
+- ✅ next meeting
+- check-out
+  - how was the meeting?
+  - recommendations for next meeting
+  - what are you doing for the rest of the day?
+
+## Notes
+
+Here: Calix, Mayel, Moritz, p4u1, d1
+Facilitating: Calix
+Notes: Mayel
+
+- local-it has test framework with Playwright to test deployment, eg. testing customised configs or modified recipes - not testing app functionality but rather customisation or integrations between apps, eg. SSO - so can check if an upgrade would break - would be nice to integrate the tests into the recipes to they can be linked to the version (ie. update recipe when updating a recipe/app) - in future want to automate into CI (eg drone runner) to auto-update recipes and check for failure - will publish test framework next week on coopcloud gitea - run them first on test deployments to check in advance if update works but also then run in prod to make sure thing runs correctly in prod (eg. if email notifs are working in each app) - this does require extra thinking (eg. deleting data created by tests)
+    - sounds really cool! going to look into playwright. could be handy for federated apps
+    - sounds like something that orgs like nlnet may fund, maybe can merge these into a proposal to fund this + the more boring coopcloud maintainance
+
+## organise meeting schedule
+- would be nice to find a regular rythm for federation meetings instead of needing date polls
+- same time? once a month?
+- in social.coop TWG they've been getting 2-3 people showing up, maybe just because haven't polled for new regular meeting time for a while
+- need someone with capacity to organise (coordination role), whether it's setting up poll or prompting people to join, to get us all in the room
+- will someone set up a date poll for march? or re. meeting frequency / how we decide  -> Moritz volunteered
+
+### bonfire co-op network hosting proposal
+- https://bonfirenetworks.org/hosting/
+
+what co-op cloud combined with servers.coop would do. idea comes from a need from bonfire team, people who are looking to adopt bonfire, individuals, small collectives, large organisations who might not have tech savvy to set up and maintain own hosting / instances, would rather have as a service .. but we decided early on we didn't want to offer hosting ourselves. and we don't want to host any flagship instances (because centralisation). calls for easy way for people to set up and maintain instances. not just infrastructure, labour, savvy, mnaintenance and support, backups. like community-supported agriculture, "community-supported software" = community gets a say in software, have a say in prioritising. large part of funds goes into infra and labour of maintaining / operating. split among participants.
+
+last funding from NLNet, included milestone. prototype instance setup wizard and management dashboard. €3k to start. small tech component, organisational and infra.
+
+what would m like from CC at this stage?
+
+participants help with prototyping
+start small - organisational & infrastructural side is 
+communities already want instances!
+not setup wizard required, just send us an email etc. do it by hand
+
+budget avail now
+
+one group focused on open science, one on digital radios, online communities around music. possibilities of them finding grants, other sources of income. donations from community members? assume = there would be funds eventually. might have to be a bit of upfront freebie service, especially as we're prototyping. closed beta as we're trying things out.
+
+### missed october 2023 membership dues
+- we were going to review who's paying, how's the amount. we didn't! what to do.
+
+### backup restore / testing update
+- after meeting about backup bot in januarry, need to document what already exists and what has been decided, there was a proposal - will followup async
+
+### collective abra next release planning
+- some are in process of improving backup/restore (still WIP) and some bugs were also found, so now it's difficult to make a release - many are self-building abra so not an issue for them, but would be good to make a plan first (next time) to avoid large refactors that block releases
+- also plan around how long features take to implement, maybe during federation meetings
+- proposal for next abra release: some bugs are fixed in main branch but release blocked by backup stuff, so could create a new branch from point where backup stuff was not merged and create release from there, so don't need to worry about incomplete backup stuff, should be pretty easy, that way can finish backup with no rush
+- if we do so, need 1 or 2 people to run integration tests + fix any bugs that appear and then do the release - ideally 1 person who has released before (d1 volunteers) + another who hasn't (p4u1 volunteers)
+
+
+## check out
+- in future need to talk about how long meeting can go before starting + agenda prioritisation

docs/intro/comparisons.md

@@ -15,14 +15,16 @@ Here is a short overview of the pros/cons we see, in relation to our goals and n
 
 ### Cloudron
 
-#### Pros
+[Cloudron](https://www.cloudron.io) is complete solution for running apps on your own server
+
+**Pros**
 
 - 👍 Decent web interface for app, domain & user management.
 - 👍 Large library of apps.
 - 👍 Built-in SSO using LDAP, which is compatible with more apps and often has a better user interface than OAuth.
 - 👍 Apps are actively maintained by the Cloudron team.
 
-#### Cons
+**Cons**
 
 - 👎 Moving away from open source. The core is now proprietary software.
 - 👎 Libre tier has a single app limit.
@@ -37,7 +39,9 @@ Here is a short overview of the pros/cons we see, in relation to our goals and n
 
 ### YunoHost
 
-#### Pros
+[YunoHost](https://yunohost.org) is an operating system aiming for the simplest administration of a server
+
+**Pros**
 
 - 👍 Lovely web interface for app, domain & user management.
 - 👍 Bigger library of apps.
@@ -46,7 +50,7 @@ Here is a short overview of the pros/cons we see, in relation to our goals and n
 - 👍 Doesn't require a public-facing IP.
 - 👍 Supports system-wide mutualisation of resources for apps (e.g. sharing databases by default)
 
-#### Cons
+**Cons**
 
 - 👎 Upstream libre software communities aren't involved in packaging.
 - 👎 Uninstalling apps leaves growing cruft.
@@ -55,7 +59,9 @@ Here is a short overview of the pros/cons we see, in relation to our goals and n
 
 ### Caprover
 
-#### Pros
+[CapRover](https://caprover.com) is an easy to use app/database deployment & web server manager for applications
+
+**Pros**
 
 - 👍 Bigger library of apps.
 - 👍 Easy set-up using a DigitalOcean one-click app.
@@ -63,7 +69,7 @@ Here is a short overview of the pros/cons we see, in relation to our goals and n
 - 👍 Deploy any app with a `docker-compose.yml` file as a "One Click App" via the web interface.
 - 👍 Multi-node (multi-server) set-up works by default.
 
-#### Cons
+**Cons**
 
 - 👎 Single-file app definition format, difficult to tweak using entrypoint scripts.
 - 👎 Nginx instead of Traefik for load-balancing.
@@ -74,46 +80,57 @@ Here is a short overview of the pros/cons we see, in relation to our goals and n
 
 ### Ansible
 
-#### Pros
+[Ansible](https://www.ansible.com) mature automation and deployment tool.
+
+**Pros**
 
 - 👍 Includes server creation and bootstrapping.
 
-#### Cons
+**Cons**
 
 - 👎 Upstream libre software communities aren't publishing Ansible roles.
 - 👎 Lots of manual work involved in things like app isolation, backups, updates.
 
 ### Kubernetes
 
-#### Pros
+[Kubernetes](https://kubernetes.io) (or K8s) is a system for automating deployment, scaling, and
+management of containerized applications.
+
+
+**Pros**
 
 - 👍 Helm charts are available for some key apps already.
 - 👍 Scale all the things.
 
-#### Cons
+**Cons**
 
 - 👎 Too big -- requires 3rd party tools to run a single-node instance.
 - 👎 Not suitable for a small to mid size hosting provider.
 
 ### Docker-compose
 
-#### Pros
+[Docker Compose](https://docs.docker.com/compose/) is a tool for defining and running multi-container applications.
+
+**Pros**
 
 - 👍 Quick to set up and familiar for many developers.
 
-#### Cons
+**Cons**
 
 - 👎 Manual work required for process monitoring.
 - 👎 Secret storage not available yet.
-- 👎 [Swarm is the new best practice](https://github.com/BretFisher/ama/issues/8#issuecomment-367575011).
+- 👎 Swarm is the new best practice.
 
 ### Doing it Manually (Old School)
 
-#### Pros
+If you are an absolute Shaman in a Shell and learning new gadgets just slows you down,
+have it, but maybe ask how old [is old enough](https://en.wikipedia.org/wiki/Printing_press)?
+
+**Pros**
 
 - 👍 Simple - just follow upstream instructions to install and update.
 
-#### Cons
+**Cons**
 
 - 👎 Loads of manual work required for app isolation and backups.
 - 👎 Array of sysadmin skills required to install and maintain apps.
@@ -123,14 +140,17 @@ Here is a short overview of the pros/cons we see, in relation to our goals and n
 
 ### Stackspin
 
-#### Pros
+[Stackspin](https://www.stackspin.net) deployment and management stack for a
+handful of popular team collaboration apps.
+
+**Pros**
 
 - 👍 Easy instructions to install & upgrade multiple tightly integrated apps.
 - 👍 Offers a unified SSO user experience.
 - 👍 Offers tightly integrated logging, monitoring, and maintenance.
 - 👍 Has a strong focus and attention to security.
 
-#### Cons
+**Cons**
 
 - 👎 Upstream libre software communities aren't involved in packaging.
 - 👎 It is not designed to be a general specification.
@@ -142,12 +162,14 @@ Here is a short overview of the pros/cons we see, in relation to our goals and n
 
 ### Maadix
 
-#### Pros
+[Maadix](https://maadix.net) managed hosting and deployment of popular privacy preserving applications.
+
+**Pros**
 
 - 👍 Nice looking web interface for app, domain & user management.
 - 👍 Offers a paid hosting service to get up and running easily.
 
-#### Cons
+**Cons**
 
 - 👎 Upstream libre software communities aren't involved in packaging.
 - 👎 It is not designed to be a general specification.

docs/intro/faq.md

@@ -8,7 +8,12 @@ Co-op Cloud aims to make hosting libre software apps simple for small service pr
 
 ## Who is behind the project?
 
-The project was started by workers at [Autonomic](https://autonomic.zone/) which is a [worker-owned co-operative](https://en.wikipedia.org/wiki/Worker_cooperative). We provide technologies and infrastructure to empower users to make a positive impact on the world. We're using Co-op Cloud in production, amongst other systems.
+The project was started by workers at [Autonomic](https://autonomic.zone/) which
+is a [worker-owned co-operative](https://en.wikipedia.org/wiki/Worker_cooperative) who provides
+technologies and infrastructure to empower users to make a positive impact on
+the world. Numerous other like minded co-ops have since joined our
+[Federation](/federation/) and rely *Co-op Cloud* in production.
+
 
 ## Why Co-op Cloud?
 
@@ -32,13 +37,13 @@ The project was started by workers at [Autonomic](https://autonomic.zone/) which
 
 ## Why start another project?
 
+We think our carefully chosen blend of technologies and our [social approach](/federation/) is quite unique in today's technology landscape.
 Please read our [initial project announcement post](https://autonomic.zone/blog/co-op-cloud/) for more on this.
-
 Also see our [strategy page](../strategy/).
 
 ## How do I make a recipe for (package) an app?
 
-See ["Package your first recipe"](/maintainers/tutorial/#package-your-first-recipe) for more.
+Head on over to **Maintainers** section and see ["Package your first recipe"](/maintainers/tutorial/#package-your-first-recipe) for more.
 
 
 ## Which technologies are used?
@@ -102,13 +107,28 @@ We are happy to see the compose specification emerging as a new open standard be
 
 ## Why Docker Swarm?
 
-While many have noted that "swarm is dead" it is in fact [not dead](https://www.mirantis.com/blog/mirantis-will-continue-to-support-and-develop-docker-swarm/). As detailed in the [architecture overview](/operators/tutorial/#container-orchestrator), swarm offers an appropriate feature set which allows us to support zero-down time upgrades, seamless app rollbacks, automatic deploy failure handling, scaling, hybrid cloud setups and maintain a decentralised design.
+While many have noted that "swarm is dead" it is in fact [not dead](https://www.mirantis.com/blog/mirantis-will-continue-to-support-and-develop-docker-swarm/) (2020). As detailed in the [architecture overview](/intro/strategy/#container-orchestrator), *Swarm* offers an appropriate feature set which allows us to support zero-down time upgrades, seamless app rollbacks, automatic deploy failure handling, scaling, hybrid cloud setups and maintain a decentralised design.
 
-While the industry is bordering on a [k8s](https://kubernetes.io/) obsession and the need to [scale down](https://microk8s.io/) a tool that was fundamentally built for massive scale, we are going with swarm because it is the tool most suitable for [small technology](https://small-tech.org/).
+While the industry is bordering on a [k8s](https://kubernetes.io/) obsession and the need to [scale down](https://microk8s.io/) a tool that was fundamentally built for massive scale, we are going with *Swarm* because it is the tool most suitable for [small technology](https://small-tech.org/).
 
+The _Co-op Cloud Community’s_ forecast at the start of 2024 for the future of *Docker Swarm* is positive after five years after *Mirantis’s* acquisition of Docker Enterprise
+in 2018. Since then, their strategy has developed towards using *Docker Swarm* as an intermediary step between Docker/Docker-Compose, and *Kubernetes* – where
+previously it seemed like their aim was to migrate all their customers’ [deployments to Kubernetes](https://www.mirantis.com/blog/kubernetes-vs-swarm-these-companies-use-both) (Oct, 2022).
+*Mirantis* acquired Docker Enterprise in 2019 and today delivers enterprise-grade Swarm—either as a managed service or with enterprise support through Mirantis Kubernetes Engine.
+
+There is reasonably healthy activity in their issue tracker with label [`area/swarm`](https://github.com/moby/moby/issues?q=+label%3Aarea%2Fswarm+).
+Additionally, we see it as reassuring that *Mirantis* has a growing number of pages relating to *Docker Swarm*:
+
+- [Mirantis' Product Page](https://www.mirantis.com/software/swarm/)
+- [What's next for Swarm: New features, the same world-class support](https://www.mirantis.com/blog/what-s-next-for-swarm) (Oct, 2022)
+- [Docker Swarm Still Thriving Three Years after Mirantis Acquisition](https://www.mirantis.com/company/press-center/company-news/docker-swarm-still-thriving-three-years-after-mirantis-acquisition-often-running-side-by-side-with-kubernetes/) (Nov, 2022)
+
+Lastly, it’s worth mentioning that much of the configuration involved in setting up *Docker Swarm*, particularly in terms of preparing images, and in managing the conceptual side, are transferable to other orchestration engines.
 We hope to see a container orchestrator tool that is not directly linked to a for-profit company emerge soon but for now, this is what we have.
 
-If you want to learn more, see [dockerswarm.rocks](https://dockerswarm.rocks/) for a nice guide. See also [`BretFisher/awesome-swarm`](https://github.com/BretFisher/awesome-swarm).
+If you want to learn more, see [dockerswarm.rocks](https://dockerswarm.rocks/) for a nice guide.
+See also this list of [`awesome-swarm`](https://github.com/BretFisher/awesome-swarm) by Bret Fisher.
+
 
 ## What licensing model do you use?
 

mkdocs.yml

@@ -58,12 +58,12 @@ markdown_extensions:
 nav:
   - "Introduction":
       - index.md
-      - "Frequently asked questions": intro/faq.md
-      - "Project strategy": intro/strategy.md
+      - "Frequently Asked Questions": intro/faq.md
+      - "Project Strategy": intro/strategy.md
       - "Comparisons": intro/comparisons.md
-      - "Project status": intro/bikemap.md
-      - "Managed hosting": intro/managed.md
-      - "Get in touch": intro/contact.md
+      - "Project Status": intro/bikemap.md
+      - "Managed Hosting": intro/managed.md
+      - "Get In Touch": intro/contact.md
       - "Credits": intro/credits.md
   - "Operators":
       - operators/index.md
@@ -126,8 +126,11 @@ nav:
           - federation/resolutions/in-progress/017.md
       - "Minutes":
         - federation/minutes/index.md
-        - "2022":
+        - "Recently":
+          - federation/minutes/2024-02-01.md
+        - "Archive":
           - federation/minutes/2022-03-03.md
+          - federation/minutes/2023-05-03.md
       - "Digital Tools": federation/tools.md
   - "Glossary":
     - glossary/index.md