diff --git a/docs/ansible/topology.md b/docs/ansible/topology.md
index da3f6e5..e4e4ad5 100644
--- a/docs/ansible/topology.md
+++ b/docs/ansible/topology.md
@@ -1,6 +1,6 @@
 # Ansible Environments
 
-As explained in the [Overview](/#available-environments), we use different ansible inventories based on the target infra that we'll target.
+As explained in the [Overview](../index.md#available-environments), we use different ansible inventories based on the target infra that we'll target.
 
 Apart from the roles and playbooks which are all common for *all* environments, each env will use its own :
 
diff --git a/docs/apps/blog.md b/docs/apps/blog.md
index 19e63ea..2008904 100644
--- a/docs/apps/blog.md
+++ b/docs/apps/blog.md
@@ -6,7 +6,7 @@ It's available at [https://blog.centos.org](https://blog.centos.org) and it's ju
 
 To keep it simple, we try to rely only on wordpress 'core' and just deploy some needed plugins, like : 
 
- * openid : needed to let users log in through our [authentication platform](/infra/authentication/)
+ * openid : needed to let users log in through our [authentication platform](../infra/authentication.md)
  * classic-editor : request from Community Manager to let people edit easily drafts/posts
  * akismet : classic one that is used against spammers
 
@@ -18,4 +18,4 @@ Once logged in, a contributor has to ask a wordpress admin (using the Community 
 
 ## Operations
 
-See [dedicated section](/operations/apps/blog/) about some BAU operations needed for Wordpress
+See [dedicated section](../operations/apps/blog.md) about some BAU operations needed for Wordpress
diff --git a/docs/apps/mailman.md b/docs/apps/mailman.md
index 463d9c6..778a51b 100644
--- a/docs/apps/mailman.md
+++ b/docs/apps/mailman.md
@@ -4,7 +4,7 @@ The CentOS Project hosts some public mailing lists that people can subscribe to.
 
 It's hosted at [https://lists.centos.org](https://lists.centos.org) and on a sponsored node.
 
-Due to the fact that it was created (back in time decision) on the centos.org MX machine , the lists are using the `@centos.org` domain, and so mailman is hosted *on* the main centos [mailserver](/apps/mailservers/), reason why the postfix ansible role will have the `postfix_mailman` [variable boolean](https://github.com/CentOS/ansible-role-postfix/blob/master/defaults/main.yml#L80) set to `True`, as it will automatically create the `<list>@centos.org` aliases on the host (needed to pass through mailman)
+Due to the fact that it was created (back in time decision) on the centos.org MX machine , the lists are using the `@centos.org` domain, and so mailman is hosted *on* the main centos [mailserver](../infra/mailservers.md), reason why the postfix ansible role will have the `postfix_mailman` [variable boolean](https://github.com/CentOS/ansible-role-postfix/blob/master/defaults/main.yml#L80) set to `True`, as it will automatically create the `<list>@centos.org` aliases on the host (needed to pass through mailman)
 
 Some links:
 
diff --git a/docs/buildsys/git.md b/docs/buildsys/git.md
index e323786..59342db 100644
--- a/docs/buildsys/git.md
+++ b/docs/buildsys/git.md
@@ -22,7 +22,7 @@ It's mainly used for :
 
 ## Authentication
 
-Our pagure instance is tied with our existing [Authentication service](/infra/authentication/) so one needs to first have a account there to interact with the pagure instance (except of course for Read-Only operations like cloning a repository, etc)
+Our pagure instance is tied with our existing [Authentication service](../infra/authentication.md) so one needs to first have a account there to interact with the pagure instance (except of course for Read-Only operations like cloning a repository, etc)
 
 When a user is added in a SIG group , and logs in again, its membership will be reflected at the pagure/git.centos.org side.
 
diff --git a/docs/buildsys/intro.md b/docs/buildsys/intro.md
index 93bff7d..dedba4c 100644
--- a/docs/buildsys/intro.md
+++ b/docs/buildsys/intro.md
@@ -3,11 +3,11 @@
 To build artifacts that will be released/pushed to the mirror network, CentOS Project relies on distributed build systems, mostly :
 
   * [Koji](https://pagure.io/koji)
-  * [reimzul](/buildsys/reimzul/)
+  * [reimzul](reimzul.md)
 
 While reimzul is still being used for CentOS Linux 7 rpm builds, koji is now the one being used for CentOS Linux 8 and all Stream releases (but different environments)
 
-RPM packages built by/for Special Interest Groups on our [Community Build Service](/buildsys/koji-cbs/) are also built on a koji instance, different from the one[s] used to build CentOS Linux/Stream distributions.
+RPM packages built by/for Special Interest Groups on our [Community Build Service](koji-cbs.md) are also built on a koji instance, different from the one[s] used to build CentOS Linux/Stream distributions.
 
 We adviced you to read upstream koji documentation to have details of all needed components and how they can be combined all together to be able to build/distribute packages, but here is a quick overview :
 
diff --git a/docs/buildsys/koji-cbs.md b/docs/buildsys/koji-cbs.md
index c54a785..f9b5986 100644
--- a/docs/buildsys/koji-cbs.md
+++ b/docs/buildsys/koji-cbs.md
@@ -6,18 +6,18 @@ It does *not* build any official CentOS Linux/Stream package used in the distrib
 
 ## Authentication
 
-The whole CBS/koji infra is using the centralized [Authentication service](/infra/authentication/) so both the infra components (services/nodes) and the users are authenticated with TLS certificates.
+The whole CBS/koji infra is using the centralized [Authentication service](../infra/authentication.md) so both the infra components (services/nodes) and the users are authenticated with TLS certificates.
 
-That means that for each node, we need a valid [TLS cert signed by IPA](/security/tls/#ipadogtag-central-authentication).
+That means that for each node, we need a valid [TLS cert signed by IPA](../security/tls.md#ipadogtag-central-authentication).
 
 Same rule applies for `users` : they need to be authenticated with valid TLS certificated signed by same CA but we'll consider two kind of users:
 
-  * service account[s]: used to run services (not real users) so can be [created](/security/tls/#tls-service-account) by infra team
-  * real users: they can use instructions to create their [own TLS cert](/infra/authentication/#tlsx509-authentication)
+  * service account[s]: used to run services (not real users) so can be [created](../security/tls.md#tls-service-account) by infra team
+  * real users: they can use instructions to create their [own TLS cert](../infra/authentication.md#tlsx509-authentication)
 
 ## Koji tags structure
 
-When the Special Interest Groups ([SIG](https://wiki.centos.org/SpecialInterestGroup) in short) wanted to start building , the idea discussed on the centos-devel list (back in 2014) was to create some koji [tags](https://docs.pagure.org/koji/HOWTO/#package-organization) that would let people build/test/promote their packages that would then be pushed to the external mirrors CDN (while being signed with a specific [GPG key](/koji-cbs-sigs/#security-gpg-key-for-packages-signing))
+When the Special Interest Groups ([SIG](https://wiki.centos.org/SpecialInterestGroup) in short) wanted to start building , the idea discussed on the centos-devel list (back in 2014) was to create some koji [tags](https://docs.pagure.org/koji/HOWTO/#package-organization) that would let people build/test/promote their packages that would then be pushed to the external mirrors CDN (while being signed with a specific [GPG key](koji-cbs-sigs.md#security-gpg-key-for-packages-signing))
 
 The proposed and agreed levels are :
 
diff --git a/docs/index.md b/docs/index.md
index 0c25115..851aa4a 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -38,7 +38,7 @@ Worth also knowing that this site is automatically rendered from a [git reposito
 ## Available Environments
 
 While the same automation code should be used to configure all infra/services nodes within CentOS Infra, it's worth knowing that we still "divide" it into sub-sections, and so having different environments.
-Let's just have a quick look at the existing environments, *each* using its own dedicated [Ansible](/ansible) inventory, and so various settings and/or permitted access :
+Let's just have a quick look at the existing environments, *each* using its own dedicated [Ansible](ansible/index.md) inventory, and so various settings and/or permitted access :
 
   * `CentOS main` : if not defined, all the nodes considered as "production" nodes and managed as such
     * `CentOS staging` (STG) : pre-prod environment, with limited number of nodes, but mostly used to test changes/deployments before being rolled-out to the `CentOS main` one
@@ -49,4 +49,4 @@ Let's just have a quick look at the existing environments, *each* using its own 
 
 ## CentOS Infra team
 
-See the [dedicated section](/infra/team/) 
+See the [dedicated section](infra/team.md)
diff --git a/docs/infra/authentication.md b/docs/infra/authentication.md
index 8662c6b..e6e7d78 100644
--- a/docs/infra/authentication.md
+++ b/docs/infra/authentication.md
@@ -18,7 +18,7 @@ The https://accounts.centos.org community portal is based on [Noggin](https://gi
 CentOS Infra team though is in charge of the [haproxy](https://github/centos/ansible-role-haproxy) node in front of openshift and routing requests to correct openshift compute nodes from Fedora infra.
 All the needed variables for haproxy are stored in the CentOS ansible inventory, either through group_vars and/or host_vars variables
 
-Same goes for the TLS certificates used on the haproxy reverse proxy : automatically applied by the ansible role *after* they are renewed through BAU process (see [dedicated TLS](/security/tls/#how-to-renew-existing-certs) documentation)
+Same goes for the TLS certificates used on the haproxy reverse proxy : automatically applied by the ansible role *after* they are renewed through BAU process (see [dedicated TLS](../security/tls.md#how-to-renew-existing-certs) documentation)
 
 ### Identity Provider (IdP)
 
diff --git a/docs/infra/dns.md b/docs/infra/dns.md
index a22f701..b64f8c5 100644
--- a/docs/infra/dns.md
+++ b/docs/infra/dns.md
@@ -65,7 +65,7 @@ dig @ns1.centos.org -t TXT _kerberos.centos.org +short
 We also have a specific `acme.centos.org` zone, that is only use for one specific purpose : creating on the fly TXT records that will be used by LetsEncrypt/ACME for DNS challenge.
 For this we use [acme.sh](https://github.com/Neilpang/acme.sh) tool that will do that automatically for us : it will use nsupdate with specific allowed key to create dynamically the needed record that ACME server will verify to validate and then sign the CSR.
 
-See [TLS section](/tls/#how-to-obtain-new-cert-dns-challenge-is-the-preferred-way) on how to use it.
+See [TLS section](../security/tls.md#how-to-obtain-new-cert-dns-challenge-is-the-preferred-way) on how to use it.
 
 Some pointers:
 
diff --git a/docs/infra/openshift.md b/docs/infra/openshift.md
index ff08eea..0a249af 100644
--- a/docs/infra/openshift.md
+++ b/docs/infra/openshift.md
@@ -52,7 +52,7 @@ So one can use [EFS](https://docs.aws.amazon.com/efs/?icmpid=docs_homepage_stora
 Here is an an overview of the deployed ocp ci cluster : 
 
 	
-![CI Infra overview](/img/duffy-aws.drawio.png)
+![CI Infra overview](../img/duffy-aws.drawio.png)
 
 Apart from the FAS/auth/EFS volumes, it's worth knowing that : 
 
diff --git a/docs/infra/team.md b/docs/infra/team.md
index 62576e7..3b92667 100644
--- a/docs/infra/team.md
+++ b/docs/infra/team.md
@@ -6,8 +6,8 @@ CentOS Infra is mainly managed by the [Community Platform Engineering](https://d
 
 All that is possible at various levels :
 
- * Application level : granted needed credentials (usually authenticated through [ACO](/infra/authentication/))
- * Ansible role level : through Pull Requests against our [Ansible](/ansible/) roles and/or inventories
+ * Application level : granted needed credentials (usually authenticated through [ACO](authentication.md))
+ * Ansible role level : through Pull Requests against our [Ansible](../ansible/index.md) roles and/or inventories
  * Machine/Infra level : granted shell/elevated rights based on Ansible rights
 
 ## Onboarding infra members
@@ -24,11 +24,11 @@ This is an overview of needed steps to onboard a new sysadmin, having so access 
 While being part of the `sig-infra` group doesn't grant any shell/sudo permission *anywhere* , it at least reflect that new person joigning the team will be a PoC for infra and also automatically granted : 
 
  * rights to build/promote pkgs on the [infra koji tags](https://cbs.centos.org/koji/search?match=glob&type=tag&terms=infra*)
- * a `@centosproject.org` email address (see also the [postfix](/infra/mailservers) section)
+ * a `@centosproject.org` email address (see also the [postfix](mailservers.md) section)
 
 ### Ansible inventory access (for "full" sysadmin)
 
-Based on the [Environment](/#available-environments) that new infra team member needs access to (delegation, as some are in charge of CentOS CI but not -yet- other parts, etc), one needs to be added in a specific ansible list/variables in inventory, the [admins_list](https://github.com/CentOS/ansible-role-baseline/blob/master/defaults/main.yml#L5) that contains list of shell accounts to create , with their ssh pub key and if they are granted sudo rights.
+Based on the [Environment](../index.md#available-environments) that new infra team member needs access to (delegation, as some are in charge of CentOS CI but not -yet- other parts, etc), one needs to be added in a specific ansible list/variables in inventory, the [admins_list](https://github.com/CentOS/ansible-role-baseline/blob/master/defaults/main.yml#L5) that contains list of shell accounts to create , with their ssh pub key and if they are granted sudo rights.
 
 From that point, next time Ansible will be ran across servers fleet (either automatically through central mgmt station *or* manually for the machines in the `manual-run` specific group), it will add the new sysadmin (or modify/remove) on the nodes.
 
@@ -47,7 +47,7 @@ curl --silent --fail --negotiate -u : https://fasjson.fedoraproject.org/v1/users
       * have enabled OTP on their account for authentication services
 
 
-Once you have verified the GPG public key, you can (for `git-crypt`ed git repositories for ansible, add the new collaborator like this (do this on *each* [git repo](/ansible/topology/) that the new sysadmin is granted access to).
+Once you have verified the GPG public key, you can (for `git-crypt`ed git repositories for ansible, add the new collaborator like this (do this on *each* [git repo](../ansible/topology.md) that the new sysadmin is granted access to).
 So after you've added the gpg in your own keyring, you can add it to git-crypt
 
 ```
diff --git a/docs/operations/ci/adding_cico_tenant/adding_cico_tenants.md b/docs/operations/ci/adding_cico_tenant/adding_cico_tenants.md
index 5d707bc..ea6e2cb 100644
--- a/docs/operations/ci/adding_cico_tenant/adding_cico_tenants.md
+++ b/docs/operations/ci/adding_cico_tenant/adding_cico_tenants.md
@@ -2,11 +2,11 @@
 
 ## Steps
 
-1. Create an entry in duffy db (with ssh key) - [follow adding-duffy-tenant.md](/operations/ci/adding_cico_tenant/adding-duffy-tenant/)
+1. Create an entry in duffy db (with ssh key) - [follow adding-duffy-tenant.md](adding-duffy-tenant.md)
 2. Create an OpenShift namespace/project (done with ansible)
 3. Create a PV(Persistent Volume) and deploy Jenkins instance (done with ansible)
 
-## Create an entry in duffy db (with ssh key) - [follow adding-duffy-tenant.md](/operations/ci/adding_cico_tenant/adding-duffy-tenant/)
+## Create an entry in duffy db (with ssh key) - [follow adding-duffy-tenant.md](adding-duffy-tenant.md)
 
 
 ### Create an OpenShift namespace
diff --git a/docs/operations/ci/seamicro/basic_seamicro_operations.md b/docs/operations/ci/seamicro/basic_seamicro_operations.md
index 86b59c7..d7d3128 100644
--- a/docs/operations/ci/seamicro/basic_seamicro_operations.md
+++ b/docs/operations/ci/seamicro/basic_seamicro_operations.md
@@ -1,4 +1,4 @@
 ## This guide is for admins to troubleshoot seamicro chassis when needed
 
 !!! note
-    This section was moved to [Tips and Tricks/hardware](/tips/hardware/#seamicro-chassis)
+    This section was moved to [Tips and Tricks/hardware](../../../tips/hardware.md#seamicro-chassis)
diff --git a/docs/operations/decommission.md b/docs/operations/decommission.md
index 3a8dfe5..50afb70 100644
--- a/docs/operations/decommission.md
+++ b/docs/operations/decommission.md
@@ -6,7 +6,7 @@ This is an overview of the needed tasks to perform when we want to remove a node
 
   * Delete/reinstall the (virtual) machine (cleaning up)
     * If hosted within Red Hat DC, update [internal ip inventory](https://docs.google.com/spreadsheets/d/1K-aewLJ17z3pRC6K5qyBRJYtNXy1WcxRSVwPkGf4NXQ) (Obviously need RH SSO and permission)
-  * Remove from [DNS](/infra/dns/) (public or internal, depending on the case and don't forget to also remove from PowerDNS if record is delegated to that dns infra, see below)
+  * Remove from [DNS](../infra/dns.md) (public or internal, depending on the case and don't forget to also remove from PowerDNS if record is delegated to that dns infra, see below)
   * Remove it from Ansible inventory (and search for references for that node in case of)
   * Remove it from Zabbix monitoring
   * (optional and if sponsored : remove sponsor logo from [website git repo](https://git.centos.org/centos/centos.org) )
diff --git a/docs/operations/deploy/bare-metal.md b/docs/operations/deploy/bare-metal.md
index d3e7592..ccf0607 100644
--- a/docs/operations/deploy/bare-metal.md
+++ b/docs/operations/deploy/bare-metal.md
@@ -59,5 +59,5 @@ When we receive a new dedicated server, hosted in another DC that we don't contr
   * we receive initial credentials
   * we collect needed informations (like ipv4/ipv6 address[es], dns resolvers, etc)
   * we perform remotely (without remote console access) a reinstall on itself (faster then auditing the state in which we receive a machine) that is reinstalled following our standards
-  * we add node in dns/ansible (see [Common section](/operations/deploy/common) )
+  * we add node in dns/ansible (see [Common section](common.md) )
 
diff --git a/docs/operations/deploy/common.md b/docs/operations/deploy/common.md
index 83c9ddd..a810494 100644
--- a/docs/operations/deploy/common.md
+++ b/docs/operations/deploy/common.md
@@ -10,7 +10,7 @@ Requirements:
 
 ## Adding node
 
-You first need to add the node into DNS (either internally or externally) so please have a look at the dedicated [DNS section](/infra/dns), and that means kicking the `role-bind.yml` or `role-unbound.yml` playbooks based on the need, and after having pushed the change to git.
+You first need to add the node into DNS (either internally or externally) so please have a look at the dedicated [DNS section](../../infra/dns.md), and that means kicking the `role-bind.yml` or `role-unbound.yml` playbooks based on the need, and after having pushed the change to git.
 
 Once the node is available, we need *once* to initialize the node to confirm access and ssh host key/fingerprint and then sign it with our SSH CA.
 
@@ -55,7 +55,7 @@ The `adhoc-init-node.yml` will do the following :
 
   * (optional) retrieve the public IP and allow incoming connections from that new ip for some infra services restricted by iptables
   * retrieve ssh host keys, sign these and push the signed 
-  * retrieve locally some facts that can be used later for basic host_vars template
+  * retrieve locally some facts that can be used later for basic `host_vars` template
   * play the `baseline` role (common for *all* nodes but with different settings, based on inventory
     * if that's a RHEL host, either point to internal mirror, or RH CDN (based on `rhel_host_use_cdn` variable/boolean in ansible)
   * (optional): play other roles that are tied to ansible inventory group membership (if you added the host already in some specific groups) 
diff --git a/docs/security/ssh.md b/docs/security/ssh.md
index 7776b94..95f175d 100644
--- a/docs/security/ssh.md
+++ b/docs/security/ssh.md
@@ -4,9 +4,9 @@
 
 Except for some identified ssh Jump Hosts, or for public services over ssh (like pushing to git.centos.org), the tcp/22 port used by sshd is [firewalled](https://github.com/CentOS/ansible-role-iptables/blob/master/defaults/main.yml#L11) on almost all the fleet.
 
-As part of the `init` [process](/operations/deploy/common/) we sign the sshd host key, meaning that once it's signed by central key, you just have to trust that cert-authority and so not have to confirm each host key/fingerprint when connecting to a server over ssh.
+As part of the `init` [process](../operations/deploy/common.md) we sign the sshd host key, meaning that once it's signed by central key, you just have to trust that cert-authority and so not have to confirm each host key/fingerprint when connecting to a server over ssh.
 
-The Ansible [sshd](https://github.com/CentOS/ansible-role-sshd) is also distributing a ssh_known_hosts system file, so that each node (if needed) can also ssh into other centos nodes (like for backup purposes), as long as of course :
+The Ansible [sshd](https://github.com/CentOS/ansible-role-sshd) is also distributing a `ssh_known_hosts` system file, so that each node (if needed) can also ssh into other centos nodes (like for backup purposes), as long as of course :
 
   * a valid user pub key is injected
   * tcp/22 isn't blocked through iptables from ansible
@@ -19,9 +19,9 @@ Apart from that, our default sshd_config :
   * Doesn't permit password authentication
   * specify the `HostCertificate` (see the node about CA sshd host above)
 
-From a client perspective, all users ssh public keys are distributed by ansible (for sysadmin) or coming from [IPA](/infra/authentication/) through ipsilon for some services able to query/import ssh public keys through openid/openidc (like for example pagure/git.centos.org)
+From a client perspective, all users ssh public keys are distributed by ansible (for sysadmin) or coming from [IPA](../infra/authentication.md) through ipsilon for some services able to query/import ssh public keys through openid/openidc (like for example pagure/git.centos.org)
 
-We also tune the default ciphers in our host sshd_config to match current security standards and following best practices in that regard.
+We also tune the default ciphers in our host `sshd_config` to match current security standards and following best practices in that regard.
 
 ## Bastion hosts