refactor: wording, formatting & links

- use curl for consistency
- copied the warning from the install script (i.e., do not use for prod
  envs)

docs/abra/hack.md

@@ -30,8 +30,7 @@ Install [Go >= 1.16](https://golang.org/doc/install) and then:
 - `make build` to build. If this fails, run `go mod tidy`.
 - `./abra` to run commands
 - `make test` will run tests
-- `make install-abra` will install abra to `$GOPATH/bin`
-- `make install-kadabra` will install kadabra to `$GOPATH/bin`
+- `make install` will install abra to `$GOPATH/bin`
 - `go get <package>`, `go mod tidy` and `go mod vendor` to add a new dependency
 
 Our [Drone CI configuration](https://git.coopcloud.tech/toolshed/abra/src/branch/main/.drone.yml) runs a number of checks on each pushed commit. See the [Makefile](https://git.coopcloud.tech/toolshed/abra/src/branch/main/Makefile) for more handy targets.
@@ -127,16 +126,7 @@ Then, before running tests, set `export BATS_LIB_PATH=~/.local/share/bats/`
 ##### Debian
 
 ```
-apt install bats-file bats-assert bats-support jq make git
-```
-
-Unfortunately, the latest `bats` version in Debian stable does not have the "filter tests by tags" feature, which is very handy for running a subset of the tests. For this, we need to install `bats` from source. It's easy.
-
-```
-apt purge -y bats
-git clone https://github.com/bats-core/bats-core.git
-cd bats-core
-sudo ./install.sh /usr/local
+apt install bats bats-file bats-assert bats-support jq make git
 ```
 
 #### Setup Test Server
@@ -330,7 +320,7 @@ func main() {
 
 Some tools that are making use of the API so far are:
 
-* [`kadabra`](https://git.coopcloud.tech/toolshed/abra/src/branch/main/cmd/kadabra/main.go)
+* [`kadabra`](https://git.coopcloud.tech/toolshed/kadabra)
 
 ## Cross-compiling
 
@@ -369,8 +359,35 @@ For developers, while using this `-beta` format, the `y` part is the "major" ver
 - Push the new tag (e.g. `git push && git push --tags`)
 - Wait until the build finishes on [build.coopcloud.tech](https://build.coopcloud.tech/toolshed/abra)
 - Deploy the new installer script (e.g. `cd ./scripts/installer && make`)
+- Clean up the changelog on the releases page so it includes most relevant
+  changes. See below for the announcement text that needs to be inserted above
+  the generated changelog. You can use something like `git shortlog -e -s -n
+  0.11.0-beta..HEAD` to get the list of authors.
+- Make sure there is a migration guide written in the docs (if necessary)
 - Check the release worked, (e.g. `abra upgrade; abra -v`)
-- Share the announcement:
+- Share the announcement on our General chat and fedi account:
+
+#### Release notes text
+
+```
+## Changelog   
+
+> 🎺🎺🎺 [`0.XX.x-beta` 👉 `0.XX.0-beta` **migration guide**](XXX) 🎺🎺🎺
+
+`abra` update `HOWTO` documentation is [here](https://docs.coopcloud.tech/abra/upgrade/).
+
+The project with all changes and discussions is [here](XXX).
+
+A huge thanks to all our `abra` hackers for this release 💖
+
+```
+...
+```
+
+$CHANGELOG
+```
+
+#### General announcement text
 
 ```
 📢📢📢 abra v0.XX  is finally here 📢📢📢
@@ -389,6 +406,8 @@ https://docs.coopcloud.tech/abra/upgrade/#XXx-beta-0XXx-beta
 A huge thanks to everyone who helped get this release done ❤️‍🔥
 
 Happy Hacking 🫂
+
+-- $handle
 ```
 
 ## Fork maintenance

docs/abra/upgrade.md

@@ -53,6 +53,12 @@ And test things work.
 
 > General release notes are [here](https://git.coopcloud.tech/toolshed/abra/releases/)
 
+### `0.11.x-beta` -> `0.12.x-beta`
+
+* `kadabra` has been archived and is no longer published alongside `abra`
+  releases. See [`#699`](https://git.coopcloud.tech/toolshed/abra/issues/699)
+  for more.
+
 ### `0.10.x-beta` -> `0.11.x-beta`
 
 * Timeouts are no longer used unless specifically set in the app `.env` file,

docs/federation/membership.md

@@ -19,5 +19,5 @@ title: Membership
 | `@decentral1se` | Waiver | - | `@decentral1se` |
 | [ruangrupa](https://ruangrupa.id) | - | - | Henry `@babystepper:matrix.org` |
 | [RTM](https://resisttechmonopolies.online) | ✅ | - | `@ammaratef45:matrix.org` + `@linnealovespie:matrix.org`|
-| [MIR](https://mirnet.org/) | ✅ | - | `@brooke:pub.solar` |
+| [MIR](https://mirnet.org/) | ✅ | - | `@sixsmith:matrix.org` |
 | [Red Abya Yala](https://abyayala.sutty.nl/) | - | - | `@fauno:sutty.nl` |

docs/federation/minutes/2025-12-28.md

@@ -0,0 +1,45 @@
+---
+title: 2025-12-28
+---
+
+## Coop-Cloud Meetup @ 39C3
+
+> Warning: this is no real protocol, since we did not really decide someone to
+> write down something (and what), but it was my try to summarize the
+> conclusive parts. For all attendees, please correct and extend on what i
+> wrote here, if something is missing or wrong :)
+
+### Talk about Coop-Cloud
+
+Simon and d1 are looking into the old state and maybe update it.
+
+### Alakazam workshop
+
+Tomorrow 16:15 at the coop-cloud table.
+
+### Daily things with coop-cloud (what is nice, what not)
+
+* Generally good experience
+* SSO stuff is cumbersome
+* Keeping an eye on recipe changes is a bit hard
+* Onboarding for new users could be easyer
+* Catalog has structural problems
+* All are using several workarounds
+* Upgrading a recipe is cumbersome (there is a proposal to make that better, just has to be implemented)
+
+### More cooperation in general/ reflect on kiteflying / talk about finances:
+
+* Me try to do it once a month with more static topics
+* The radmin role would maybe help to fix to get people payed for stuff through that
+* Draft from p4u1 and d1
+* Maybe a proposal gets made by kawaiipunk to rise the wage for internal tasks (discussions will follow to refine that idea)
+* We want to implement the maintainers proposal to more recipes
+* We should implement default guidelines for cooperation/contribution for the recipes, which can be "overwritten" by each reipe maintainers
+* We want to experiment with automated testing, for recipes, here it would be great to have some kind of a defined list of what should be tested
+* Maybe we could implement a language server for abra
+* Idea: Workaround sharing session or blog write ups about the workarounds used
+* Idea: move away from the env file in the future via defining a standard over alakazam without breaking the env (like upstream alakazam)
+
+### Political Statement in the Documentation
+
+d1 puts survey answers to a text and then we work together and decide it in a kiteflying.

docs/federation/resolutions/passed/032.md

@@ -1,5 +1,5 @@
 ---
-title: "Resolution 032: RIM joins"
+title: "Resolution 032: RTM joins"
 ---
 
 - Topic: RTM joins Coopcloud
@@ -11,7 +11,7 @@ title: "Resolution 032: RIM joins"
 
 Ammar's membership was approved in [Resolution 022](/federation/resolutions/passed/022).
 
-Since the establishment of RTM (Resist Rech Monopolies) collective in Seattle, Ammar has been unofficially representing the collective with coopcloud and vice versa.
+Since the establishment of RTM (Resist Tech Monopolies) collective in Seattle, Ammar has been unofficially representing the collective with coopcloud and vice versa.
 	
 ### Details
 	

docs/federation/resolutions/passed/034.md

@@ -0,0 +1,20 @@
+---
+title: "Resolution 034: Extra budget for Escuela Común recipes"
+---
+
+- Topic: Budget 015: Extra budget for recipes needed by Escuela Común
+- Date: 2025-10-27
+- Deadline: 2025-11-10
+- Size: medium
+
+## Summary
+
+Budget 015 for 20 estimated hours of work towards Escuela Común, **to be reimbursed** from next year's budget from the Sepal fund to the Co-op Cloud Federation Common Fund.
+
+## Details
+
+As Escuela Común 2026 planning proceeds, many `abra` bugs were closed, and we even gained the translations feature, but we've realised that we'll need at least one extra recipe to support Escuela's organizing: [`tellaweb`](https://github.com/Horizontal-org/tellaweb).
+
+This work has been supported by the Sepal fund we're sharing with Escuela Común. The budget allocated for this year has been used in full, so we're requesting the Federation to allocate budget from its own funds to cover for 20 estimated hours, to be reimbursed from next year's budget, that will be available on April 2026.
+
+`@3wc` will carry out this work.

docs/intro/comparisons.md

@@ -175,6 +175,29 @@ handful of popular team collaboration apps.
 - 👎 It is not designed to be a general specification.
 - 👎 Hard to share configurations into the commons.
 - 👎 Limited library of apps.
-- 👎 Uses *OpenNebula*, *Ansible*, and *Puppet* as underlying technologies.
+- 👎 Uses Ansible (see above)
 - 👎 Appears to be only a team of two people.
 - 👎 Appears to be inactive on Mastodon and limited GitLab activity. 
+
+### Dokploy 
+
+[Dokploy](https://dokploy.com/) (who have [their own comparison](https://docs.dokploy.com/docs/core/comparison)).
+
+- 👍 Supports builds from Git repositories, Dockerfiles, Nixpacks, and Buildpacks like Heroku and Paketo.
+- 👍 [~100 application templates](https://docs.dokploy.com/docs/core/templates)
+
+- 👎 [Bespoke TOML config](https://github.com/Dokploy/templates?tab=readme-ov-file#templatetoml-structure)
+- 👎 Community on Discord and Github discussions
+- 👎 Freemium / open-core model
+
+### Cosmos Cloud 
+
+[Cosmos Cloud](https://cosmos-cloud.io/), "The cloud doesn't need to be someone else's computer"
+
+- 👍 [Native client apps](https://cosmos-cloud.io/clients/)
+- 👍 Built-in VPN 
+
+- 👎 Community on Discord, Github discussions, and Reddit
+- 👎 "Up to 19 users" even on paid plans
+- 👎 Freemium / open-core model
+- 👎 ["Commons clause"](https://github.com/azukaar/Cosmos-Server/blob/master/LICENCE)

docs/maintainers/handbook.md

@@ -53,6 +53,12 @@ I.e. `compose.smtp.yml`. These are used to provide non-essential functionality s
 
 If you look at a `compose.yml` file and see a `configs` section, that means this compose file is putting files in the container. This might be used for changing default (vendor) configuration, such as this [fpm-tune.ini file](https://git.coopcloud.tech/coop-cloud/nextcloud/src/commit/28425b6138603067021757de28c639ad464e9cf8/fpm-tune.ini) used to adjust `php-fpm.` See [this handbook entry](/maintainers/handbook/#manage-configs) for more.
 
+### Special environment variables
+
+#### STACK_NAME
+
+Our deployment runtime expects a specific naming convention for Co-op Cloud apps when they are deployed on the server. This is a case of lowercasing/underscoring the domain name, e.g. "foo.coopcloud.tech" -> "foo_coopcloud_tech". This is for the most part an internal implementation detail. However, it is sometimes useful to expose this variable to template configurations when trying to connect apps together via runtime networking. See ["How do I reference serices in configs"](/maintainers/handbook/#how-do-i-reference-services-in-configs) for a practical example.
+
 ## Manage configs
 
 To add additional files into the container, you can use [Docker configs](https://docs.docker.com/engine/swarm/configs/). This usually involves the following:
@@ -86,6 +92,16 @@ Because configurations are maintained in-repository by maintainers, we version t
 export NGINX_CONFIG_VERSION=v1
 ```
 
+!!! warning
+
+    It is **very important** that the naming convention of the config matches
+    the whole way down. In the above example, that is `nginx_config` in the
+    `configs:` stanza, `nginx_config` in `name:
+    ${STACK_NAME}_nginx_config_${NGINX_CONFIG_VERSION}` and finally
+    `NGINX_CONFIG_VERSION` in the `abra.sh`. This is the naming convention that
+    `abra` will perform to carry out the lookup of all matching names/values.
+    See [`#693`](https://git.coopcloud.tech/toolshed/abra/issues/693) for more.
+
 ## Manage environment variables
 
 !!! warning
@@ -124,6 +140,45 @@ You can also access it in your configs using the following syntax:
 {{ env "FOO" }}
 ```
 
+### Example: Adding environment variables to existing recipe
+Here is a four step example how to add a new environment variable to a recipe without breaking existing deployments. 
+
+1. add env-var to the `compose.yml` in section `environment`:
+   ```yaml
+       environment:
+         # ... existing envs
+         - REQUIRE_AUTH_FOR_PROFILE_REQUESTS=${REQUIRE_AUTH_FOR_PROFILE_REQUESTS:-false}
+         # ... other existing envs
+   ```
+
+   With `${REQUIRE_AUTH_FOR_PROFILE_REQUESTS:-false}` you set a default value (`false`), ensuring not to break existing deployments. 
+   If you're sure that it won't cause problems, if operators of existing deployments don't set the variable, you could also just put:
+   ```yaml
+       environment:
+         # ... existing envs
+         - REQUIRE_AUTH_FOR_PROFILE_REQUESTS
+         # ... other exisitng envs
+   ```
+   
+   Note: If you need to break something, make sure to add a [release note](/maintainers/handbook/#how-do-i-write-version-release-notes) explaining to operators what they should change before upgrading.
+
+2. add env-var to the `.env.sample`
+   ```yaml
+   #REQUIRE_AUTH_FOR_PROFILE_REQUESTS=true
+   ```
+
+3. now you can use the environment-variable in your `.tmpl` files, e.g. add to `homserver.yaml.tmpl`
+   ```yaml
+   require_auth_for_profile_requests: {{ env "REQUIRE_AUTH_FOR_PROFILE_REQUESTS" }}
+   ```
+   
+4. increase number of YAML-version in `abra.sh` (e.g. from `v30` to `v31`), only then it will be deployed. 
+   ```yaml
+   export HOMESERVER_YAML_VERSION=v31
+   ```
+
+   Note: If during development and testing you have to increase it several times, you can just "flatten" it in the end. Only make sure that you `undeploy`/`deploy` your existing instance.
+
 ### Global environment variables
 
 - `TYPE`: specifies the recipe name
@@ -274,6 +329,18 @@ Sometimes the containers don't even have Bash installed on them. You had better
 
 When referencing an `app` service in a config file, you should prefix with the `STACK_NAME` to avoid namespace conflicts (because all these containers sit on the traefik overlay network). You might want to do something like this `{{ env "STACK_NAME" }}_app` (using  the often obscure dark magic of the Golang templating language). You can find examples of this approach used in the [Peertube recipe](https://git.coopcloud.tech/coop-cloud/peertube/src/commit/d1b297c5a6a23a06bf97bb954104ddfd7f736568/nginx.conf.tmpl#L9).
 
+!!! warning "Here be `STACK_NAME` dragons 🐉"
+
+    `STACK_NAME` is a [**special environment variable**](/maintainers/handbook/#special-environment-variables) which `abra` generates for you and in the format the runtime deployment expects to see. If you want to expose this environment variable in your template configurations, you need to expose it explicitly to the `env: ...` stanza in your recipe compose configuration. An example follows below.
+
+    ```yaml
+      services:
+        web:
+          image: nginx:1.29.3
+          environment:
+            - STACK_NAME
+    ```
+
 ## How are recipes versioned?
 
 We'll use an example to work through this. Let's use [Gitea](https://hub.docker.com/r/gitea/gitea).
@@ -368,7 +435,7 @@ You'll notice that `abra` figured out how to upgrade the Co-op Cloud version lab
 At this point, we're all set, we can run `abra recipe release --publish wordpress`. This will do the following:
 
 1. run `git commit` the new changes
-1. run `git tag` to create a new git tag named `1.1.0+5.9.0`
+1. run `git tag -am "chore: publish 1.1.0+5.9.0 release" 1.1.0+5.9.0` to create a new annotated git tag named `1.1.0+5.9.0` (abra only accepts annotated tags)
 1. run `git push` to publish changes to the Wordpress repository
 
 !!! warning "Here be more SSH dragons"
@@ -526,7 +593,7 @@ SECRET_JWT_SECRET_VERSION=v1 # charset=default,special
 ```
 
 Options are:
-* `default`: [source](https://github.com/decentral1se/passgen/blob/8404cb922dea92efa8c3514f0ec8c37ce12a880f/const.go#L23)
+
 * `special`: [source](https://github.com/decentral1se/passgen/blob/8404cb922dea92efa8c3514f0ec8c37ce12a880f/const.go#L22C29-L22C43)
 * `safespecial`: [source](https://git.coopcloud.tech/toolshed/abra/src/commit/6abaf7a094df1a96599af2c4cbae1769821ad17c/pkg/secret/secret.go#L182)
 * `default,special`: mix of `default` and `special`
@@ -702,10 +769,10 @@ Please note:
 1. The `file_env` / `_FILE` hack is to pass secrets into the container runtime without exposing them in plaintext in the configuration. See [this entry](/maintainers/handbook/#exposing-secrets) for more.
 
 1. In order to pass execution back to the original entrypoint, it's a good idea to find the original entrypoint script and run it from your own entrypoint script. If there is none, you may want to reference the `CMD` definition or if that isn't working, try to actually specify `cmd: ...` in the `compose.yml` definition (there are other recipes which do this).
-  
+
 1. Also it might be necessary to define command: although there is an original entrypoint. That's [due to the fact](https://docs.docker.com/reference/compose-file/services/#entrypoint) that if entrypoint is non-null, Compose ignores any default command from the image, for example the `CMD` instruction in the Dockerfile.
 
-  1. Pratically you would e.g. look for the Dockerfile of the upstream image. In there you should find the docker-entrypoint.sh (or similar) and where it's located. Furthermore you find the `CMD`-line there. 
+  1. Pratically you would e.g. look for the Dockerfile of the upstream image. In there you should find the docker-entrypoint.sh (or similar) and where it's located. Furthermore you find the `CMD`-line there.
   1. Just put in your entrypoint.sh in the last line: exec /path/to/docker-entrypoint.sh "@" (path and filename you should find in upstream Dockerfile) and insert  command:  to your service in compose.yml with the value of what you find in the CMD line of the Dockerfile.
 
 1. If you're feeling reckless, you can also use the Golang templating engine to do things conditionally.

docs/maintainers/index.md

@@ -2,16 +2,28 @@
 title: Maintainers
 ---
 
-Welcome to the maintainers guide! Maintainers are typically individuals who have a stake in building up and maintaining our digital configuration commons, the recipe configurations. Maintainers help keep recipes configurations up to date, respond to issues in a timely manner, help new users within the community and recruit new maintainers when possible.
+Welcome to the recipe maintainers guide! Recipe maintainers help build up and maintain our recipe configuration commons based on [`R025`](https://docs.coopcloud.tech/federation/resolutions/passed/025/).
 
 <div class="grid cards" markdown>
 
-- __New Maintainers Tutorial__
+- __How to Become a Recipe Maintainer™__
 
-    If you want to package a recipe and/or become a maintainer, start here :rocket:
+    If you want to become a recipe maintainer, start here :heart:
+
+    [Learn more](/maintainers/maintain){ .md-button .md-button--primary }
+
+- __Package your First Recipe Tutorial__
+
+    If you want to package a recipe, start here :rocket:
 
     [Get Started](/maintainers/tutorial){ .md-button .md-button--primary }
 
+- __How to Upgrade a Recipe__
+
+    If you want to upgrade a recipe, start here 🤸‍♀️
+
+    [Start upgrading](/maintainers/upgrade){ .md-button .md-button--primary }
+
 - __Packaging Handbook__
 
     One-stop shop for all you need to know to package recipes :package:

docs/maintainers/maintain.md

@@ -0,0 +1,61 @@
+---
+title: How to Become a Recipe Maintainer
+---
+
+!!! warning
+
+    This guide is a work-in-progress following [`R025`](https://docs.coopcloud.tech/federation/resolutions/passed/025/) and the work to to implement this in [`#60`](https://git.coopcloud.tech/coop-cloud/traefik/issues/60) for the [traefik recipe](https://git.coopcloud.tech/coop-cloud/traefik). Please help us update this documentation with new conventions and practices that emerge.
+
+## What does a recipe maintainer do?
+
+A recipe maintainer takes care of one or more recipes. This includes reviewing issues and pull requests and applying application upgrades which are published upstream. The general expectations for what a recipe maintainer should carry out are defined in [`R025`](https://docs.coopcloud.tech/federation/resolutions/passed/025/).
+
+If recipes are maintained by several maintainers, there is a greater chance of stability for all operators who deploy those recipe upgrades for end-users. Please consider becoming a maintainer for recipes which you rely on!
+
+!!! note "We need More Recipe Maintainers!"
+
+    Since the publishing of [`R025`](https://docs.coopcloud.tech/federation/resolutions/passed/025/) there is a growing consensus that it is critically important that we recruit more recipe maintainers. The recipe configuration commons on its own is not enough. We also need to coordinate our maintenance work to ensure that everyone can benefit from smooth and stable upgrades.
+
+## You can become a recipe maintainer!
+
+Anyone who deploys a recipe can become a recipe maintainer. If you want to ensure that a recipe becomes stable and reliable, then you can become the maintainer. If you maintain a recipe alone, ask for help and encourage others to join in. The only way we can reduce the endless workload of application updates is to coordinate our work together.
+
+### `README.md` and `MAINTENANCE.md`
+
+You can start by reading The Maintainers Proposal: [`R025`](https://docs.coopcloud.tech/federation/resolutions/passed/025/). Check if there are maintainers mentioned in the `README.md` of the recipe repository and if there is a `MAINTENANCE.md` present. For example, for the traefik recipe, here is [the list of maintainers in the `README.md`](https://git.coopcloud.tech/coop-cloud/traefik/src/commit/8eaee04b5d9980a99fdad57677a4c72d7796da10/README.md?display=source#L8) and the maintainers guidelines in the [`MAINTENANCE.md`](https://git.coopcloud.tech/coop-cloud/traefik/src/commit/8eaee04b5d9980a99fdad57677a4c72d7796da10/MAINTENANCE.md). If there is no `MAINTENANCE.md`, copy the template below and create your own.
+
+### Maintainers Team
+
+It is important that only recipe maintainers have write permissions to the repository. As it currently stands, every member of the [Co-operators Team](https://git.coopcloud.tech/org/coop-cloud/teams/co-operators) has write permissions to all recipe repositories for convenience while we are missing enough maintainers.
+
+To change this, create a new team on [`git.coopcloud.tech/coop-cloud/teams`](https://git.coopcloud.tech/org/coop-cloud/teams) for your specific recipe, e.g. `mycoolrecipe-maintainers`. Add yourself and any other maintainers. Remove your recipe repository from the [list of repositories for the Co-operators Team](https://git.coopcloud.tech/org/coop-cloud/teams/co-operators/repositories) so that write permissions are removed.
+
+### Repository Permissions
+
+Under `Branch Protection` in the recipe repository settings, create a new rule
+for the `main` / `master` branch of your repository. Add your maintainer team
+to the following list of permissions.
+
+* Allow only maintainers to push directly to the main branch
+    * `Allowlist Restricted Push` > `Allowlisted teams for pushing`
+* Allow only maintainers to approve pull requests
+    * `Restrict approvals to allowlisted users or teams` > `Allowlisted teams for reviews`
+* Allow only maintainers to merge pull requests
+    * `Enable Merge Allowlist` > `Allowlisted  teams for merging`
+
+## Templates
+
+### `MAINTENANCE.md` template
+
+!!! warning
+
+    We are still considering if it is a good idea to create a `MAINTENANCE.md`
+    for every recipe repository. Maybe it is a better idea to make a single
+    `MAINTENANCE.md` on [docs.coopcloud.tech](https://docs.coopcloud.tech). We
+    look forward to seeing feedback on this from new maintainers.
+
+See the [`MAINTENANCE.md`](https://git.coopcloud.tech/coop-cloud/traefik/raw/branch/master/MAINTENANCE.md) of the Traefik recipe.
+
+### Pull request template
+
+See the [`.gitea/PULL_REQUEST_TEMPLATE.md`](https://git.coopcloud.tech/coop-cloud/traefik/src/branch/master/.gitea/PULL_REQUEST_TEMPLATE.md) of the Traefik recipe.

docs/maintainers/upgrade.md

@@ -0,0 +1,15 @@
+---
+title: How to Upgrade a Recipe
+---
+
+## Updating versions in the `abra.sh`
+
+`#TODO`
+
+## Backwards compatible environment variable changes
+
+`#TODO`
+
+## Creating new release notes
+
+`#TODO`

docs/operators/handbook.md

@@ -118,7 +118,7 @@ Then `$ABRA_DIR` will be automatically picked up as `$PWD`. This is useful when
 
 If you're on an environment where it's hard to run Docker, or command-line programs in general, you might want to install `abra` on a server instead of your local computer.
 
-To install `abra` on the same server where you'll be hosting your apps, just follow [getting started guide](/operators/tutorial#deploy-your-first-app) as normal except for one difference. Instead of providing your SSH connection details when you run `abra server add ...`, just pass `--local`.
+To install `abra` on the same server where you'll be hosting your apps, just follow [getting started guide](/operators/tutorial#deploy-your-first-app) as normal except for one difference. Instead of providing your SSH connection details when you run `abra server add ...`, just pass `--local` and specify the domain during deployment.
 
 ```
 abra server add --local
@@ -320,6 +320,36 @@ If you need to run a command within a running container you can use `abra app ru
 
 If you need to run a command on a container that won't start (eg. the container is stuck in a restart loop) you can temporarily disable its default entrypoint by setting it in `compose.yml` to something like ['tail', '-f', '/dev/null'], then redeploy the stack (with `--force --chaos` so you don't need to commit), then [get into the now running container](#how-do-i-attach-to-a-running-container), do your business, and when done revert the compose.yml change and redeploy again.
 
+## How can I modify/override the `compose.yml-file`?
+
+If you need a customization of the `compose`-file, e.g., override a specific, hard coded value that is not present in the sample-env, add a custom volume, or add an environment variable that the image knows but which is not (yet) included in the `compose.yml` of the recipe, you can do so by using the `COMPOSE_FILE` environment variable ([more details in Docker docs](https://docs.docker.com/compose/how-tos/environment-variables/envvars/#compose_file)).
+
+For details about how the two compose files are merged, consult the official [Docker docs](https://docs.docker.com/compose/how-tos/multiple-compose-files/merge/).
+
+If it's not a special or edge case, perhaps consider modifying the original recipe / racing a feature request so everyone can benefit from your conceptual work?
+
+### Example 
+The upstream image of your `app` allows you to modify the SMTP port with an environment variable called `SMTP_PORT`, but the recipe's maintainers didn't include it in the compose file because they didn't have in mind anyone would need a non-standard port. So you can't simply add `SMTP_PORT` to your `yourapp.example.com.env`, because it won't find its way into the running container.
+
+For a quick fix, you could now create a file, e.g. `yourapp.example.com.compose.override.yml` (naming is up to you) with the content:
+
+```
+services:
+  app:
+    environment:
+      SMTP_PORT: 25
+```
+
+and add to your `yourapp.example.com.env`
+
+```
+COMPOSE_FILE="compose.yml:../../servers/<YOUR-SERVER>/yourapp.example.com.compose.override.yml
+```
+_Make sure you include the original `compose.yml` and place the `yourapp.domain.compose.override.yml` directly alongside of your `yourapp.example.com.env`, or change the (relative) path respectively._
+
+This will now add/overwrite the `SMTP_PORT` environment variable of the `app` container.
+
+`
 ## Can I run Co-op Cloud on ARM?
 
 `@Mayel`:

docs/operators/tutorial.md

@@ -36,7 +36,8 @@ Otherwise, here are the step required:
 ssh <server-domain>
 
 # docker install convenience script
-wget -O- https://get.docker.com | bash
+# not suitable for production environments - refer to the script header for alternatives
+curl https://get.docker.com | bash
 
 # check that docker was installed correctly
 sudo docker run hello-world
@@ -60,6 +61,7 @@ groupadd docker
 # add user to docker group
 sudo usermod -aG docker $USER
 ```
+
 After running `usermod`, you may need to (depending on your system) log out (`exit`) and back in again (`ssh <server-domain>`) to get the required permissions for Docker before proceeding.
 
 The [official Docker documentation](https://docs.docker.com/engine/install/linux-postinstall/) can help if you run into further issues.
@@ -83,10 +85,13 @@ Where `116.203.211.204` can be replaced with the IP address of your server.
 
     You can use a tool like `dig` on the command-line to check if your server has the necessary DNS records set up. Something like `dig +short <domain>` should show the IP address of your server if things are working.
 
+??? question "Can I use DynDNS with a home server?"
+
+    Yes. If your DNS provider does not allow you to set a *. A-Record, you may still be able to use a *. CNAME-Record to your example.com domain.
+
 ### Install `abra`
 
-Now we can install [`abra`](/abra) locally on your machine and hook it up to
-your server. We support a script-based installation method ([script source](https://git.coopcloud.tech/toolshed/abra/src/branch/main/scripts/installer/installer)):
+Now we can install [`abra`](/abra) locally on your machine and hook it up to your server. We support a script-based installation method ([script source](https://git.coopcloud.tech/toolshed/abra/src/branch/main/scripts/installer/installer)):
 
 ```bash
 curl https://install.abra.coopcloud.tech | bash
@@ -110,7 +115,7 @@ you have immediate access to `abra` on the current terminal.
 export PATH=$PATH:$HOME/.local/bin
 ```
 
-If you run into issues during installation, [please report a ticket](https://git.coopcloud.tech/toolshed/organising/issues/new) :pray:
+If you run into issues during installation, [please report a ticket](https://git.coopcloud.tech/toolshed/abra/issues/new) :pray:
 
 ??? question "Can I install `abra` on my server?"
 
@@ -124,7 +129,7 @@ With autocomplete enabled, you can run a command like `abra app deploy myapp.exa
 
 ### Add your server
 
-Now you can connect `abra` with your server. You must have a working SSH configuration for your server before you can proceed. That means you can run `ssh <server-domain>` on your command-line and everything Works :tm:. See the [`abra` SSH troubleshooting](/abra/trouble/#ssh-connection-issues) for a working SSH configuration example.
+Now you can connect `abra` with your server. You must have a working SSH configuration for your server before you can proceed. That means you can run `ssh <server-domain>` on your command-line and everything Works :tm:. See the [`abra` SSH troubleshooting](/abra/trouble/#ssh-connection-issues) for a working SSH configuration example or use `abra server add -h` for the help output.
 
 ??? warning "Beware of SSH dragons :dragon_face:"
 
@@ -146,13 +151,13 @@ It is important to note that `<server-domain>` here is a publicly accessible dom
 
 ??? warning "Can I use arbitrary server names?"
 
-    Yes, this is possible. You need to pass `-D` to `server add` and ensure
-    that your `Host ...` entry in your SSH configuration includes the name.
-    So, for example, in `~/.ssh/config`:
+    Yes, this is possible. You need to ensure that your `Host ...` entry in your SSH configuration includes the name.  So, for example, in `~/.ssh/config`:
+
     ```
       Host example.com example
         ...
     ```
+
     And then:
 
       abra server add example
@@ -167,8 +172,9 @@ abra server ls
 
 ??? question "How do I share my configs in `~/.abra`?"
 
-    It's possible and quite easy, for more see [this handbook
+    It's possible and relatively easy, for more see [this handbook
     entry](/operators/handbook/#understanding-app-and-server-configuration).
+    [Git](https://git-scm.com) skills are generally required.
 
 ### Web proxy setup
 
@@ -182,7 +188,8 @@ You need to keep port `:80` and `:443` free on your server for web proxying to y
 
 ??? question "Do you support multiple web proxies?"
 
-    We do not know if it is feasible and convenient to set things up on an existing server with another web proxy which uses ports `:80` & `:443`. We'd happily receive reports and documentation on how to do this if you manage to set it up!
+    Yes, this is possible. See [this handbook entry](/operators/handbook/#proxying-apps-outside-of-co-op-cloud-with-traefik)
+    for more. Be warned, this is a relatively advanced topic.
 
 **1. To get started, you'll need to create a new app:**
 
@@ -268,35 +275,6 @@ To upgrade an app manually to the newest available version run:
 abra app upgrade <nextcloud-domain>
 ```
 
-### Automatic Upgrades
-
-`kadabra` the auto-updater is still under development, use it with care and don't use it in production environments. To setup the auto-updater copy the `kadabra` binary to the server and configure a cronjob for regular app upgrades. The following script will configure ssmtp for email notifications and setup a cronjob. This cronjob checks daily for new app versions, notifies if any kind of update is available and upgrades all apps to the latest patch/minor version.
-
-
-```bash
-apt install ssmtp
-
-cat > /etc/ssmtp/ssmtp.conf << EOF
-mailhub=$MAIL_SERVER:587
-hostname=$MAIL_DOMAIN
-AuthUser=$USER
-AuthPass=$PASSWORD
-FromLineOverride=yes
-UseSTARTTLS=yes
-EOF
-
-cat > /etc/cron.d/abra_updater << EOF
-MAILTO=admin@example.com
-MAILFROM=noreply@example.com
-
-0  6 * * *       root    ~/kadabra notify --major
-30 4 * * *       root    ~/kadabra upgrade --all
-EOF
-
-```
-
-Add `ENABLE_AUTO_UPDATE=true` to the env config (`abra app config <app name>`) to enable the auto-updater for a specific app.
-
 ## Finishing up
 
 Hopefully you got something running! Well done! The [operators handbook](/operators/handbook) would probably be the next place to go check out if you're looking for more help. Especially on topics of ongoing maintenance.

mkdocs.yml

@@ -125,19 +125,21 @@ nav:
               - federation/resolutions/passed/029.md
               - federation/resolutions/passed/032.md
               - federation/resolutions/passed/031.md
+              - federation/resolutions/passed/033.md
+              - federation/resolutions/passed/034.md
           - "Stalled":
               - federation/resolutions/stalled/013.md
               - federation/resolutions/stalled/030.md
           - "In Progress":
               - federation/resolutions/index.md
-              - federation/resolutions/in-progress/033.md
       - "Minutes":
           - federation/minutes/index.md
           - "Recently":
+              - federation/minutes/2025-12-28.md
+          - "Archive":
               - federation/minutes/2024-08-15.md
               - federation/minutes/2024-04-17.md
               - federation/minutes/2024-03-29.md
-          - "Archive":
               - federation/minutes/2024-02-01.md
               - federation/minutes/2022-03-03.md
               - federation/minutes/2023-05-03.md