Convert the remaining Serveex and recycled articles to steps

This commit is contained in:
Djeex
2026-09-04 15:57:38 +02:00
parent cd75fd2288
commit a7b3880088
29 changed files with 249 additions and 106 deletions
+18 -12
View File
@@ -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 doesnt 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 !
::
Thats 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 youve 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 youve 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:
@@ -26,6 +26,9 @@ tree:
---
::
::steps{level="3"}
### Deploy the stack
Open Dockge, click on `compose`, name the stack `vaultwarden`, and paste the following:
```yaml [compose.yaml]
@@ -70,6 +73,8 @@ services:
```
::
### Set your environment variables
Next, generate a password hash to put in the `TOKEN` variable in `.env`:
```bash [Terminal]
@@ -94,6 +99,9 @@ Then deploy the container.
Recently, Vaultwarden requires SSL to be accessed, which prevents access via a local IP. We'll expose it with SWAG, which provides an SSL certificate.
### Done !
::
::caution
__If it fails:__ check your firewall rules.
@@ -106,6 +114,9 @@ The main benefit of Vaultwarden is being able to access it remotely from any dev
📋 __Before you start:__ Make sure you've created a DNS subdomain like `vault.yourdomain.com` with `CNAME` pointing to `yourdomain.com` and (unless using Cloudflare Zero Trust) that you've forwarded port `443` from your router to your server's `443` via [NAT rules](/general/networking/nat).
::
::steps{level="3"}
### Add Vaultwarden's network to SWAG
In Dockge, go to the SWAG stack and edit the compose file to add the Vaultwarden network:
```yaml [compose.yaml]
@@ -132,6 +143,8 @@ We're assuming the network name is `vaultwarden_default`. You can check connecti
Restart the stack by clicking "Deploy" and wait for SWAG to be fully operational.
### Create the subdomain.conf file
In SWAG's config folder, create the file `vault.subdomain.conf`:
::tip{icon=""}
@@ -230,6 +243,9 @@ server {
Press :kbd{value="Ctrl+O"}, then :kbd{value="Enter"} to save, and :kbd{value="Ctrl+X"} to exit.
### Done !
::
And there you go! Vaultwarden is now exposed! Visit `https://vault.yourdomain.com/admin` to access the admin panel and paste the password you specified when generatique the `ADMIN_TOKEN`. For more information, see the [Bitwarden documentation](https://bitwarden.com/help/).
Don't forget to install Bitwarden browser extensions (they work with Vaultwarden) for [Chrome](https://chromewebstore.google.com/detail/gestionnaire-de-mots-de-p/nngceckbapebfimnlniiiahkandclblb) and [Firefox](https://addons.mozilla.org/fr/firefox/addon/bitwarden-password-manager/), as well as [iOS](https://apps.apple.com/fr/app/bitwarden/id1137397744) and [Android](https://play.google.com/store/apps/details?id=com.x8bit.bitwarden&hl=fr) apps to sync your passwords.