Comment bien déployer un site web

Vous avez un site, une application ou une API. Vous souhaitez la déployer afin qu’elle soit publiquement accessible, tout en contrôlant les coûts et en évitant de payer trop cher.

Je vais vous présenter deux solutions simples pour y parvenir facilement et proprement.

Pour les plus connaisseurs d’entre vous : initialement, j’hébergeais mes applications sur un cluster Kubernetes complet en haute disponibilité. Avec le recul, c’était une solution bien trop sophistiquée pour mon usage. Même si c’est très efficace, cela demande plus d’attention, de maintenance et, côté coût, c’est entre 4 et 10 fois plus cher.

Donc, si vous n’avez pas absolument besoin d’un tel setup, choisissez plutôt quelque chose de plus simple et pratique.

Mais, dans un premier temps, pour héberger votre service simplement, je vous conseille d’acheter un nom de domaine. Personnellement, j’achète mes domaines sur Porkbun.

Libre à vous d’utiliser le registrar de votre choix.

VPS + Docker

Cette solution consiste à héberger ses services sur un simple VPS en exploitant Docker et Docker Compose.

Pour le VPS, je vous conseille Hetzner.

Pourquoi ?

Hetzner propose une bonne API et est compatible avec Terraform. De plus, Hetzner fournit un outil CLI très bien conçu.

Ce sont des caractéristiques que l’on retrouve sur des plateformes comme AWS ou Azure.

Même si ce n’est évidemment pas aussi complet que ces plateformes, cela reste une fraction du prix pour un VPS équivalent, ce qui en fait, selon moi, l’un des meilleurs fournisseurs de VPS.

Création du VPS

Pour ce test, vous aurez besoin d’un VPS de votre choix avec une IPv4 publique. Je vous conseille également d’ajouter un accès SSH.

Voici les commandes pour vérifier si vous avez déjà une clé SSH :

ls ~/.ssh/*.pub

Si vous voyez par exemple id_ed25519.pub, il suffit de copier son contenu et de le coller lors de la création du VPS.

Sinon, vous pouvez en créer une avec :

ssh-keygen -t ed25519 -C "[email protected]"

Pour le système d’exploitation, je choisis souvent Ubuntu 24.04 LTS. Honnêtement, prenez surtout celui avec lequel vous êtes le plus à l’aise.

Une fois le serveur lancé, vous pouvez vous y connecter en SSH avec :

ssh root@ip_du_vps

Installation de Docker

Pour installer Docker, le mieux est de suivre la procédure décrite dans la documentation officielle.

Suppression des versions existantes

apt remove $(dpkg --get-selections docker.io docker-compose docker-compose-v2 docker-doc podman-docker containerd runc | cut -f1)

Ajout des dépôts Docker

apt install ca-certificates curl
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc

Ajout des dépôts aux sources APT :

tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
EOF

Mise à jour :

apt update

Installation de Docker et Docker Compose :

apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Si tout s’est bien passé, la commande suivante doit indiquer que Docker est en cours d’exécution :

systemctl status docker

Reverse proxy / serveur web

Avec Docker installé, vous allez pouvoir déployer des conteneurs. Parmi les conteneurs nécessaires, vous aurez besoin au minimum d’un serveur web et, plus généralement, d’une combinaison serveur web + reverse proxy.

Il y a plusieurs scénarios :

Vous déployez un ou plusieurs sites web statiques
Vous déployez un service web (site, API, agent IA, etc.)

Dans le premier cas, vous pouvez n’utiliser qu’un serveur web comme Caddy ou Nginx.

Dans le second cas, vous aurez besoin d’un reverse proxy qui redirigera le trafic entrant vers le bon service. Le serveur web de votre application pourra être Node.js, Bun, Uvicorn, etc.

Dans tous les cas, nous allons utiliser Caddy dans les exemples.

Les fichiers suivront généralement une arborescence similaire à celle-ci :

Cas 1 : site statique

Pour un site statique, la stratégie que je conseille est de créer un volume Docker contenant les fichiers statiques du site, puis de monter ce volume dans le conteneur Caddy.

Pour cela, il suffit de créer un Dockerfile et un docker-compose qui build le site et place l’export statique dans un volume Docker.

Le compose.yaml de Caddy peut ressembler à ceci :

services:
  caddy:
    image: caddy:2.10.2-alpine
    container_name: caddy_static
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - $PWD/conf:/etc/caddy
      - site_1:/sites/site_1
      - caddy_data:/data
      - caddy_config:/config

volumes:
  caddy_data:
  caddy_config:
  site_1:
    external: true

On choisit une version stable (non bêta) de Caddy, et la version Alpine pour une image plus légère.

Exemple de Caddyfile :

example.com {
    root * /sites/site_1
    file_server
    encode gzip
    try_files {path} {path}/ /index.html
}

Il faudra d’abord créer le volume en lançant le docker compose du site statique, puis démarrer Caddy :

docker compose up -d

Cas 2 : service web (API, backend, etc.)

Dans ce cas plus général, le docker-compose de votre service doit utiliser un réseau Docker partagé avec le conteneur Caddy.

Votre service doit évidemment être en cours d’exécution.

Le docker-compose de Caddy :

services:
  caddy:
    image: caddy:2.10.2-alpine
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - $PWD/conf:/etc/caddy
      - caddy_data:/data
      - caddy_config:/config
    networks:
      - web

networks:
  web:
    external: true

volumes:
  caddy_data:
  caddy_config:

Exemple de Caddyfile :

api.example.com {
    reverse_proxy fastapi_app:8000
}

Ici, fastapi_app est le nom du conteneur Docker, exposant le port 8000.

Il est bien sûr possible d’héberger plusieurs services, et même de combiner sites statiques et services dynamiques.

Dans tous les cas, il faudra ajouter un enregistrement DNS de type A pour chaque service, pointant vers l’adresse IPv4 publique de votre VPS.

Site statique avec GitHub Pages

Si vous avez uniquement besoin de déployer un site statique (blog, portfolio, landing page), GitHub Pages est une excellente solution gratuite, avec la possibilité d’utiliser votre propre nom de domaine.

Étapes générales

Activer GitHub Actions et configurer les accès

Ajouter une action de déploiement

Exemple de workflow que j’utilise personnellement :

.github/workflows/deploy-gh-pages.yml

name: Deploy banner-with-socials

on:
  push:
    branches:
      - main

permissions:
  contents: write

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install Bun
        run: |
          curl -fsSL https://bun.sh/install | bash
          echo "$HOME/.bun/bin" >> $GITHUB_PATH

      - name: Install dependencies
        working-directory: banner-with-socials
        run: bun install

      - name: Build project
        working-directory: banner-with-socials
        run: bun run build

      - name: Deploy to gh-pages
        uses: peaceiris/actions-gh-pages@v4
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: banner-with-socials/dist

L’idée est de build le site et de pousser l’export statique sur la branche gh-pages à chaque commit sur main.

Ici, c’est adapté à ma stack et plus précisément au framework Qwik.

J’ai écrit un article complet sur ma stack frontend si cela vous intéresse.

Une fois l’action ajoutée :

Ajoutez les enregistrements DNS fournis par GitHub Pages
Sélectionnez la branche gh-pages comme source
Indiquez votre nom de domaine

Après la validation DNS, votre site sera accessible via votre domaine.

Quelques précisions

Lorsque vous déployez un site statique (GitHub Pages ou autre), pensez bien à configurer votre nom de domaine dans votre framework (adapter statique, manifest, base URL, etc.).

Une astuce utile avec GitHub Pages est de s’en servir pour héberger de petits fichiers statiques (images, vidéos légères).

Cela évite de multiplier les services d’hébergement, et c’est parfait pour des portfolios par exemple.

Il existe bien sûr d’autres solutions comme Netlify ou Vercel. Elles sont excellentes pour degros projets ou pour aller vite, mais peuvent devenir coûteuses avec l’augmentation du trafic, car le prix est directement lié à celui-ci.

Pour un projet de taille petite à moyenne, une solution basée sur un VPS est souvent beaucoup plus avantageuse en termes de coût, tout en restant professionnelle.

Les solutions présentées ici couvrent donc environ 90 % des cas, et constituent des options solides, économiques et fiables.