Convert the remaining Serveex and recycled articles to steps

content/en/3.serveex/9.apps/1.adguard.md

@@ -5,16 +5,6 @@ description: Install AdGuard Home for network-wide ad and tracker blocking with
 
 
 :ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
-# Adguard Home
-
-::note
-🎯 __Goals:__
-
-- Install and deploy Adguard
-- Expose Adguard
-- Secure DNS queries with SSL/TLS
-- Configure client devices
-::
 
 [AdGuard Home](https://github.com/AdguardTeam/AdGuardHome) is a DNS server that blocks ads and tracking at the system level. Once configured, it will protect ALL your home devices without the need for any client-side software.
 
@@ -22,6 +12,8 @@ It works as a DNS server that redirects tracking domains to a “black hole,”
 
 In practice, once it's in place, all you need to do is set your devices to use Adguard as their DNS server.
 
+![adguard](/img/serveex/adguard.png)
+
 **Quick reminder of how DNS works:**
 
 When you visit a site or use an app, it makes requests to various domains to load content, ads in particular. Your device doesn’t know the IP addresses of these domains, so it contacts a _Domain Name Server_ (DNS), which returns the current IP address.
@@ -57,6 +49,9 @@ tree:
 We will also mount the `/docker/swag/config/etc/letsencrypt` folder to access Swag's SSL certificate.
 ::
 
+::steps{level="3"}
+### Deploy the stack
+
 Open Dockge and click `compose`
 
 Name the stack `adguardhome` and paste the configuration below:
@@ -97,14 +92,17 @@ Deploy the stack.
 
 Go to `http://yourserverip:3000` and follow the setup instructions.
 
+### Done !
+::
+
 That’s it! Adguard is deployed.
 
 ## Exposing AdGuard with SWAG
 To make AdGuard usable from outside your home network, you need to expose it.
 
-::note
+::note{icon=""}
 
-__Prerequisites:__ We assume you've created a subdomain like `adguard.mydomain.com` in your [DNS zone](/general/networking/dns) with a `CNAME` pointing to `mydomain.com`, and that you’ve already forwarded port `443` from your router to port `443` on your server in your [NAT rules](/general/networking/nat). Also forward port `53` and port `853` to your server. These ports are used to route DNS requests.
+📋 __Prerequisites:__ We assume you've created a subdomain like `adguard.mydomain.com` in your [DNS zone](/general/networking/dns) with a `CNAME` pointing to `mydomain.com`, and that you’ve already forwarded port `443` from your router to port `443` on your server in your [NAT rules](/general/networking/nat). Also forward port `53` and port `853` to your server. These ports are used to route DNS requests.
 ::
 
 ::warning
@@ -112,6 +110,9 @@ __Prerequisites:__ We assume you've created a subdomain like `adguard.mydomain.c
 Do not use Cloudflare tunnels to expose AdGuard, and make sure any proxying is disabled.
 ::
 
+::steps{level="3"}
+### Add AdGuard's network to SWAG
+
 In Dockge, go to the SWAG stack and edit the compose file to add the AdGuard network:
 
 ```yaml [compose.yaml]
@@ -138,6 +139,8 @@ We assume here that the AdGuard network is named `adguard_default`. You can veri
 
 Restart the stack by clicking "Deploy" and wait for SWAG to be fully operational.
 
+### Create the subdomain.conf file
+
 Create and open the file `adguard.subdomain.conf`
 
 ::tip{icon=""}
@@ -226,6 +229,9 @@ server {
 }
 ```
 
+### Done !
+::
+
 ## Protecting AdGuard with TinyAuth
 Add [TinyAuth](/serveex/security/tinyauth)'s forward-auth check directly to `adguard.subdomain.conf`, the same way as [the TinyAuth guide](/serveex/security/tinyauth#protecting-an-app-via-reverse-proxy). The `/dns-query` location is left out of the `auth_request` check, since DNS-over-HTTPS clients can't do an interactive login: