diff --git a/docker-compose.yml b/docker-compose.yml
index 91ffe052d97865618c99bf0c9847892134aef89c..7db54cdcac7f72c46bfa31895f1c907d83d4e0af 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -1,9 +1,7 @@
-version: '3.7'
-
 services:
   mkdocs:
     container_name: mkdocs
-    image: registry.lakedrops.com/docker/mkdocs:1.5.3
+    image: registry.lakedrops.com/docker/mkdocs:1.6.1
     restart: unless-stopped
     ports:
       - 8999:8000
diff --git a/docs/adrs/.template.md b/docs/adrs/.template.md
new file mode 100644
index 0000000000000000000000000000000000000000..ac3d82f5286c93c3c41292781286c95c1ed6f76f
--- /dev/null
+++ b/docs/adrs/.template.md
@@ -0,0 +1,78 @@
+---
+title: {short title, representative of solved problem and found solution}
+tags:
+  - documentation
+  - adr
+# These are optional metadata elements. Feel free to remove any of them.
+status: "{proposed | rejected | accepted | deprecated | … | superseded by ADR-0123"
+date: {YYYY-MM-DD when the decision was last updated}
+decision-makers: {list everyone involved in the decision}
+consulted: {list everyone whose opinions are sought (typically subject-matter experts); and with whom there is a two-way communication}
+informed: {list everyone who is kept up-to-date on progress; and with whom there is a one-way communication}
+---
+
+# {short title, representative of solved problem and found solution}
+
+## Context and Problem Statement
+
+{Describe the context and problem statement, e.g., in free form using two to three sentences or in the form of an illustrative story. You may want to articulate the problem in form of a question and add links to collaboration boards or issue management systems.}
+
+<!-- This is an optional element. Feel free to remove. -->
+## Decision Drivers
+
+* {decision driver 1, e.g., a force, facing concern, …}
+* {decision driver 2, e.g., a force, facing concern, …}
+* … <!-- numbers of drivers can vary -->
+
+## Considered Options
+
+* {title of option 1}
+* {title of option 2}
+* {title of option 3}
+* … <!-- numbers of options can vary -->
+
+## Decision Outcome
+
+Chosen option: "{title of option 1}", because {justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}.
+
+<!-- This is an optional element. Feel free to remove. -->
+### Consequences
+
+* Good, because {positive consequence, e.g., improvement of one or more desired qualities, …}
+* Bad, because {negative consequence, e.g., compromising one or more desired qualities, …}
+* … <!-- numbers of consequences can vary -->
+
+<!-- This is an optional element. Feel free to remove. -->
+### Confirmation
+
+{Describe how the implementation of/compliance with the ADR can/will be confirmed. Are the design that was decided for and its implementation in line with the decision made? E.g., a design/code review or a test with a library such as ArchUnit can help validate this. Not that although we classify this element as optional, it is included in many ADRs.}
+
+<!-- This is an optional element. Feel free to remove. -->
+## Pros and Cons of the Options
+
+### {title of option 1}
+
+<!-- This is an optional element. Feel free to remove. -->
+{example | description | pointer to more information | …}
+
+* Good, because {argument a}
+* Good, because {argument b}
+<!-- use "neutral" if the given argument weights neither for good nor bad -->
+* Neutral, because {argument c}
+* Bad, because {argument d}
+* … <!-- numbers of pros and cons can vary -->
+
+### {title of other option}
+
+{example | description | pointer to more information | …}
+
+* Good, because {argument a}
+* Good, because {argument b}
+* Neutral, because {argument c}
+* Bad, because {argument d}
+* …
+
+<!-- This is an optional element. Feel free to remove. -->
+## More Information
+
+{You might want to provide additional evidence/confidence for the decision outcome here and/or document the team agreement on the decision and/or define when/how this decision the decision should be realized and if/when it should be re-visited. Links to other decisions and resources might appear here as well.}
diff --git a/docs/adrs/imagemagick.md b/docs/adrs/imagemagick.md
new file mode 100644
index 0000000000000000000000000000000000000000..b015906a8033a9e5739c850df6986e61d4bc1436
--- /dev/null
+++ b/docs/adrs/imagemagick.md
@@ -0,0 +1,59 @@
+---
+title: Ignore ImageMagick alerts in pipelines
+tags:
+  - documentation
+  - adr
+status: "accepted"
+date: 2024-11-15
+decision-makers: Daniel Speicher, Jürgen Haas
+---
+
+# Ignore ImageMagick alerts in pipelines
+
+## Context and Problem Statement
+
+We've received alerts from CI pipelines when end-to-end tests with Cypress wanted to render the link to an embedded PDF
+with a thumbnail. The problem was that ImageMagick was called to create the thumbnail, but PDF files are not available
+to pipelines, so that an error was logged about that missing file.
+
+## Decision Drivers
+
+Alerts always require attention, and their root cause needs to be fixed. Ignoring alerts is unacceptable.
+
+## Considered Options
+
+* Provide all files from the live site to the pipeline
+* Prevent alerts in pipelines generally
+* Ignore that specific alert in pipelines
+* Ignore that specific alert generally
+
+## Decision Outcome
+
+Chosen option: "Ignore that specific alert generally", because it is acceptable to ignore ImageMagick errors that are
+caused by a missing source file.
+
+### Consequences
+
+* Good, because the unnecessary alert will not be created any loinger
+* Bad, because we won't get alerts in production, if a thumbnail of a missing file would be requested
+
+## Pros and Cons of the Options
+
+### Provide all files from the live site to the pipeline
+
+* Good, because the pipeline would exactly match the live system and create the greatest possible certainty that the site actually works correctly
+* Bad, because the data volume can be far too big to make it available in pipelines
+
+### Prevent alerts in pipelines generally
+
+* Bad, because potential errors would remain unnoticed
+
+### Ignore that specific alert in pipelines
+
+* Good, because it's a known issue that doesn't hurt
+* Neutral, because it would require extra complexity to the alert setup to be aware of the stage
+
+### Ignore that specific alert generally
+
+* Good, because it's a known issue that doesn't hurt
+* Neutral, because it may theoretically miss a similar alert in production
diff --git a/docs/adrs/index.md b/docs/adrs/index.md
new file mode 100644
index 0000000000000000000000000000000000000000..f69941627eccc64edecb71324cec999b87f73d2b
--- /dev/null
+++ b/docs/adrs/index.md
@@ -0,0 +1,16 @@
+---
+title: Architecture Decision Records
+tags:
+- documentation
+- adr
+---
+# Architecture Decision Records
+
+Here we publish our general ADRs that are not customer specific.
+
+---
+
+!!! info
+
+    We've taken ideas from the [MADR](https://adr.github.io/madr) project
+    and also from [Lullabot's ADRs](https://architecture.lullabot.com).
diff --git a/mkdocs.yml b/mkdocs.yml
index 2a3414b5dbeb76adf82e179d5b140c60626ad0e9..34ab2049c53a1688469a5ed2d7f0226490821131 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -298,3 +298,6 @@ nav:
               - Wayfinding: projects/drupal/digital_signage/wayfinding.md
       - APIs:
           - projects/api.md
+  - ADRs:
+      - adrs/index.md
+      - Ignore ImageMagick alerts in pipelines: adrs/imagemagick.md