diff --git a/docs/architecture/services-communication.md b/docs/architecture/services-communication.md
index 7ce661c18..f3e827426 100644
--- a/docs/architecture/services-communication.md
+++ b/docs/architecture/services-communication.md
@@ -7,4 +7,4 @@ geekdocEditPath: edit/master/docs/architecture
 geekdocFilePath: services-communication.md
 ---
 
-{{< svg src="/ocis/static/ocis-services-communication.drawio.svg" >}}
\ No newline at end of file
+{{< figure src="/ocis/static/ocis-services-communication.drawio.svg" >}}
diff --git a/docs/extensions/storage/_index.md b/docs/extensions/storage/_index.md
index 8ae194026..1c4e140f1 100644
--- a/docs/extensions/storage/_index.md
+++ b/docs/extensions/storage/_index.md
@@ -16,7 +16,7 @@ The storage extension wraps [reva](https://github.com/cs3org/reva/) and adds an
 
 *Clients* will use the *Spaces Registry* to poll or get notified about changes in all *Spaces* a user has access to. Every *Space* has a dedicated `/dav/spaces/<spaceid>` WebDAV endpoint that is served by a *Spaces Provider* which uses a specific reva storage driver to wrap an underlying *Storage System*.
 
-{{< svg src="extensions/storage/static/overview.drawio.svg" >}}
+{{< figure src="/extensions/storage/static/overview.drawio.svg" >}}
 
 The dashed lines in the diagram indicate requests that are made to authenticate requests or lookup the storage provider:
 1. After authenticating a request, the proxy may either use the CS3 `userprovider` or the accounts service to fetch the user information that will be minted into the `x-access-token`.
@@ -31,4 +31,4 @@ The bottom part is lighter because we will deprecate it in favor of using only t
 In order to reason about the request flow, two aspects in the architecture need to be understood well:
 1. What kind of [*namespaces*]({{< ref "./namespaces.md" >}}) are presented at the different WebDAV and CS3 endpoints?
 2. What kind of [*resource*]({{< ref "./terminology.md#resources" >}}) [*references*]({{< ref "./terminology.md#references" >}}) are exposed or required: path or id based?
-{{< svg src="extensions/storage/static/storage.drawio.svg" >}}
+{{< figure src="/extensions/storage/static/storage.drawio.svg" >}}
diff --git a/docs/extensions/storage/namespaces.md b/docs/extensions/storage/namespaces.md
index 19864a6e7..227835acd 100644
--- a/docs/extensions/storage/namespaces.md
+++ b/docs/extensions/storage/namespaces.md
@@ -10,7 +10,7 @@ geekdocFilePath: namespaces.md
 A *namespace* is a set of paths with a common prefix. Depending on the endpoint you are talking to you will encounter a different kind of namespace:
 In ownCloud 10 all paths are considered relative to the users home. The CS3 API uses a global namespace and the *storage providers* use a local namespace with paths relative to the storage providers root.
 
-{{< svg src="extensions/storage/static/namespaces.drawio.svg" >}}
+{{< figure src="/extensions/storage/static/namespaces.drawio.svg" >}}
 
 The different paths in the namespaces need to be translated while passing [*references*]({{< ref "./terminology.md#references" >}}) from service to service. While the oc10 endpoints all work on paths we internally reference shared resources by id, so the shares don't break when a file is renamed or moved inside a storage [*space*]({{< ref "./spaces" >}}). The following table lists the various namespaces, paths and id based references:
 
diff --git a/docs/extensions/storage/spaces.md b/docs/extensions/storage/spaces.md
index 45b445c79..567e8ddf2 100644
--- a/docs/extensions/storage/spaces.md
+++ b/docs/extensions/storage/spaces.md
@@ -186,7 +186,7 @@ The current implementation in oCIS might not yet fully reflect this concept. Fee
 A storage *space* is a logical concept. It organizes a set of [*resources*]({{< ref "#resources" >}}) in a hierarchical tree. It has a single *owner* (*user* or *group*),
 a *quota*, *permissions* and is identified by a `storage space id`.
 
-{{< svg src="extensions/storage/static/storagespace.drawio.svg" >}}
+{{< figure src="/extensions/storage/static/storagespace.drawio.svg" >}}
 
 Examples would be every user's personal storage *space*, project storage *spaces* or group storage *spaces*. While they all serve different purposes and may or may not have workflows like anti virus scanning enabled, we need a way to identify and manage these subtrees in a generic way. By creating a dedicated concept for them this becomes easier and literally makes the codebase cleaner. A storage [*Spaces Registry*]({{< ref "./spacesregistry.md" >}}) then allows listing the capabilities of storage *spaces*, e.g. free space, quota, owner, syncable, root etag, upload workflow steps, ...
 
diff --git a/docs/extensions/storage/spacesprovider.md b/docs/extensions/storage/spacesprovider.md
index 5a706ff51..589c9ff29 100644
--- a/docs/extensions/storage/spacesprovider.md
+++ b/docs/extensions/storage/spacesprovider.md
@@ -17,18 +17,18 @@ The current implementation in oCIS might not yet fully reflect this concept. Fee
 A *storage provider* manages [*resources*]({{< ref "#resources" >}}) identified by a [*reference*]({{< ref "#references" >}})
 by accessing a [*storage system*]({{< ref "#storage-systems" >}}) with a [*storage driver*]({{< ref "./storagedrivers.md" >}}).
 
-{{< svg src="extensions/storage/static/spacesprovider.drawio.svg" >}}
+{{< figure src="/extensions/storage/static/spacesprovider.drawio.svg" >}}
 
 
 ## Frontend
 
 The oCIS frontend service starts all services that handle incoming HTTP requests:
 - *ocdav* for ownCloud flavoured WebDAV
-- *ocs* for sharing, user provisioning, capabilities and other OCS API endpoints 
+- *ocs* for sharing, user provisioning, capabilities and other OCS API endpoints
 - *datagateway* for up and downloads
 - TODO: *ocm*
 
-{{< svg src="extensions/storage/static/frontend.drawio.svg" >}}
+{{< figure src="/extensions/storage/static/frontend.drawio.svg" >}}
 
 ### WebDAV
 
@@ -83,7 +83,7 @@ The API [already returns the storage id](https://doc.owncloud.com/server/develop
     <file_source>3994486</file_source>
     <file_parent>3994485</file_parent>
     <file_target>/Shared/Paris.jpg</file_target>
-``` 
+```
 [Creating shares only takes the **path** as the argument](https://doc.owncloud.com/server/developer_manual/core/apis/ocs-share-api.html#function-arguments) so creating and navigating shares only needs the path. When you update or delete a share it takes the `share id` not the `file id`.
 {{< /hint >}}
 
@@ -109,4 +109,4 @@ It is used by the reva *gateway*
 to look up `address` and `port` of the [*storage provider*]({{< ref "#storage-providers" >}})
 that should handle a [*reference*]({{< ref "#references" >}}).
 
-{{< svg src="extensions/storage/static/storageregistry.drawio.svg" >}}
\ No newline at end of file
+{{< figure src="/extensions/storage/static/storageregistry.drawio.svg" >}}
diff --git a/docs/extensions/storage/spacesregistry.md b/docs/extensions/storage/spacesregistry.md
index d5be48f8a..4880536e9 100644
--- a/docs/extensions/storage/spacesregistry.md
+++ b/docs/extensions/storage/spacesregistry.md
@@ -17,5 +17,4 @@ The current implementation in oCIS might not yet fully reflect this concept. Fee
 
 A storage *spaces registry* manages the [*namespace*]({{< ref "./namespaces.md" >}}) for a *user*: it is used by *clients* to look up storage spaces a user has access to, the `/dav/spaces` endpoint to access it via WabDAV, and where the client should mount it in the users personal namespace.
 
-{{< svg src="extensions/storage/static/spacesregistry.drawio.svg" >}}
-
+{{< figure src="/extensions/storage/static/spacesregistry.drawio.svg" >}}
diff --git a/docs/extensions/storage/terminology.md b/docs/extensions/storage/terminology.md
index e40e2ad04..4ff810e67 100644
--- a/docs/extensions/storage/terminology.md
+++ b/docs/extensions/storage/terminology.md
@@ -64,12 +64,12 @@ Technically, this means that every storage driver needs to have a map of a `uuid
 ## Technical concepts
 
 ### Storage Systems
-{{< svg src="extensions/storage/static/storageprovider.drawio.svg" >}}
+{{< figure src="/extensions/storage/static/storageprovider.drawio.svg" >}}
 
 A *storage provider* manages multiple [*storage spaces*]({{< ref "#storage-space" >}})
 by accessing a [*storage system*]({{< ref "#storage-systems" >}}) with a [*storage driver*]({{< ref "#storage-drivers" >}}).
 
-{{< svg src="extensions/storage/static/storageprovider-spaces.drawio.svg" >}}
+{{< figure src="/extensions/storage/static/storageprovider-spaces.drawio.svg" >}}
 
 ## Storage Space Registries
 
@@ -81,7 +81,7 @@ It is a tree of [*resources*]({{< ref "#resources" >}})*resources*
 with a single *owner* (*user* or *group*),
 a *quota* and *permissions*, identified by a `storage space id`.
 
-{{< svg src="extensions/storage/static/storagespace.drawio.svg" >}}
+{{< figure src="/extensions/storage/static/storagespace.drawio.svg" >}}
 
 Examples would be every user's home storage space, project storage spaces or group storage spaces. While they all serve different purposes and may or may not have workflows like anti virus scanning enabled, we need a way to identify and manage these subtrees in a generic way. By creating a dedicated concept for them this becomes easier and literally makes the codebase cleaner. A [*storage space registry*]({{< ref "#storage-space-registries" >}}) then allows listing the capabilities of [*storage spaces*]({{< ref "#storage-spaces" >}}), e.g. free space, quota, owner, syncable, root etag, upload workflow steps, ...
 
@@ -98,4 +98,3 @@ There might be multiple [*storage drivers*]({{< ref "./storagedrivers.md" >}}) f
 
 ### Gateways
 A *gateway* acts as a facade to the storage related services. It authenticates and forwards API calls that are publicly accessible.
-
diff --git a/docs/ocis/_index.md b/docs/ocis/_index.md
index 766df0526..73c3bcc15 100644
--- a/docs/ocis/_index.md
+++ b/docs/ocis/_index.md
@@ -21,7 +21,7 @@ The below diagram shows the core conceps that are the foundation for the new arc
 - [*Storage spaces*]({{< ref "../extensions/storage/terminology#storage-spaces" >}}) represent a collection of files and folders. A users personal files are contained in a *storage space*, a group or project drive is a *storage space*, and even incoming shares are treated and implemented as *storage spaces*. Each with properties like owners, permissions, quota and type.
 - [*Storage providers*]({{< ref "../extensions/storage/terminology#storage-providers" >}}) can hold multiple *storage spaces*. At an oCIS instance, there might be a dedicated *storage provider* responsible for users personal storage spaces. There might be multiple, either to shard the load, provide different levels of redundancy or support custom workflows. Or there might be just one, hosting all types of *storage spaces*.
 
-{{< svg src="ocis/static/idea.drawio.svg" >}}
+{{< figure src="/ocis/static/idea.drawio.svg" >}}
 
 As an example, Einstein might want to share something with Marie, who has an account at a different identity provider and uses a different storage space registry. The process makes use of [OpenID Connect (OIDC)](https://openid.net/specs/openid-connect-core-1_0.html) for authentication and would look something like this:
 
@@ -63,4 +63,4 @@ We run a huge [test suite](https://github.com/owncloud/core/tree/master/tests),
 
 Running `bin/ocis server` will start the below services, all of which can be scaled and deployed on a single node or in a cloud native environment, as needed.
 
-{{< svg src="ocis/static/architecture-overview.drawio.svg" >}}
+{{< figure src="/ocis/static/architecture-overview.drawio.svg" >}}
diff --git a/docs/ocis/adr/0014-microservices-runtime.md b/docs/ocis/adr/0014-microservices-runtime.md
index 820c7f673..89f68523c 100644
--- a/docs/ocis/adr/0014-microservices-runtime.md
+++ b/docs/ocis/adr/0014-microservices-runtime.md
@@ -56,7 +56,7 @@ Number 3: A hybrid solution between framework and in-house.
 
 ### Design
 
-{{< svg src="ocis/static/runtime.drawio.svg" >}}
+{{< figure src="/ocis/static/runtime.drawio.svg" >}}
 
 First of, every ocis service IS a go-micro service, and because go-micro makes use of urfave/cli, a service can be conveniently wrapped inside a subcommand. Writing a supervisor is then a choice. We do use a supervisor to ensure long-running processes and embrace the "let it crash" mentality. The piece we use for this end is called [Suture](https://github.com/thejerf/suture).
 
diff --git a/docs/ocis/config.md b/docs/ocis/config.md
index a07e12725..f4ab30cf6 100644
--- a/docs/ocis/config.md
+++ b/docs/ocis/config.md
@@ -15,7 +15,7 @@ In order to simplify deployments and development the configuration model from oC
 
 ## Overview of the approach
 
-{{< svg src="ocis/static/ocis-config-redesign.drawio.svg" >}}
+{{< figure src="/ocis/static/ocis-config-redesign.drawio.svg" >}}
 
 ## In-depth configuration
 
diff --git a/docs/ocis/deployment/monitoring-tracing.md b/docs/ocis/deployment/monitoring-tracing.md
index 26c2c2ee2..139a8e7b1 100644
--- a/docs/ocis/deployment/monitoring-tracing.md
+++ b/docs/ocis/deployment/monitoring-tracing.md
@@ -17,7 +17,7 @@ This documentation describes how to set up a long running monitoring & tracing i
 
 # Overview about the proposed solution
 
-{{< svg src="ocis/static/monitoring_tracing_overview.drawio.svg" >}}
+{{< figure src="/ocis/static/monitoring_tracing_overview.drawio.svg" >}}
 
 ## Monitoring & tracing clients
 
diff --git a/docs/ocis/flow-docs/public-upload-flow.md b/docs/ocis/flow-docs/public-upload-flow.md
index 78adf0c04..ae9a5d025 100644
--- a/docs/ocis/flow-docs/public-upload-flow.md
+++ b/docs/ocis/flow-docs/public-upload-flow.md
@@ -12,4 +12,4 @@ geekdocFilePath: public-upload-flow.md
 
 The following diagram describes the flow of requests:
 
-{{< svg src="ocis/static/tus-public-upload.svg" >}}
+{{< figure src="/ocis/static/tus-public-upload.svg" >}}