adding the article suggestion at the end of the blog post

.claude/settings.local.json

@@ -12,7 +12,9 @@
       "Bash(Get-ChildItem -Path \"d:\\\\2 - Projets\\\\matheoguilbert.fr\" -Recurse -Depth 2)",
       "Bash(Select-Object -First 50)",
       "Bash(Format-Table FullName)",
-      "PowerShell(Get-ChildItem -Path \"d:\\\\2 - Projets\\\\matheoguilbert.fr\" -Recurse -Depth 2 | Select-Object -ExpandProperty FullName | Where-Object { $_ -notmatch 'node_modules|\\\\.next' } | Select-Object -First 80)"
+      "PowerShell(Get-ChildItem -Path \"d:\\\\2 - Projets\\\\matheoguilbert.fr\" -Recurse -Depth 2 | Select-Object -ExpandProperty FullName | Where-Object { $_ -notmatch 'node_modules|\\\\.next' } | Select-Object -First 80)",
+      "Bash(grep -o '<pre[^>]*>.\\\\{0,200\\\\}' /tmp/page.html | head -20; echo \"---mermaid---\"; grep -o 'mermaid' /tmp/page.html | head -5; echo \"---count pre---\"; grep -o '<pre' /tmp/page.html | wc -l)",
+      "Read(//tmp/**)"
     ]
   }
 }

.gitea/workflows/deploy-vercel.yml

@@ -0,0 +1,65 @@
+name: Deploy Vercel
+
+on:
+  push:
+    branches:
+      - main
+      - dev
+  pull_request:
+
+jobs:
+  # test:
+  #   runs-on: ubuntu-latest
+
+  #   steps:
+  #     - name: Checkout
+  #       uses: actions/checkout@v4
+
+  #     - name: Setup Node
+  #       uses: actions/setup-node@v4
+  #       with:
+  #         node-version: 20
+  #         cache: npm
+
+  #     - name: Install
+  #       run: npm ci
+
+  #     - name: Lint
+  #       run: npm run lint --if-present
+
+  #     - name: Test
+  #       run: npm test --if-present
+
+
+  deploy-preprod:
+    runs-on: ubuntu-latest
+    if: github.ref == 'refs/heads/dev'
+
+    env:
+      VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
+      VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
+      VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Deploy preprod
+        run: npx vercel@latest deploy --yes
+
+
+  deploy-production:
+    runs-on: ubuntu-latest
+    if: github.ref == 'refs/heads/main'
+
+    env:
+      VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
+      VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
+      VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Deploy production
+        run: npx vercel@latest deploy --prod --yes

app/[locale]/blog/[slug]/_components/OtherArticles.tsx

@@ -0,0 +1,102 @@
+'use client';
+
+import { useRef, useEffect } from 'react';
+import Link from 'next/link';
+import { useTranslations } from "next-intl";
+
+type props = {
+    locale: string;
+    articles: {
+        slug: string;
+        title: string;
+        description: string;
+        cover?: string;
+    }[];
+};
+
+export function OtherArticles({ locale, articles }: props) {
+    const ref = useRef<HTMLElement>(null);
+    const t = useTranslations('blogPage.otherArticles');
+
+    useEffect(() => {
+        const el = ref.current;
+        if (!el) return;
+        const observer = new IntersectionObserver(
+            ([entry]) => {
+                if (entry.isIntersecting) {
+                    el.querySelectorAll('.reveal').forEach((node, i) => {
+                        setTimeout(() => node.classList.add('visible'), i * 120);
+                    });
+                    observer.unobserve(el);
+                }
+            },
+            { threshold: 0.1 }
+        );
+        observer.observe(el);
+        return () => observer.disconnect();
+    }, []);
+
+    if (!articles.length) return null;
+
+    return (
+        <section ref={ref} className="pt-6 pb-20">
+            {/* Divider */}
+            <div className="w-full h-px bg-brand-brown/10 mb-14" />
+
+            {/* Label */}
+            <div className="flex items-center gap-3 mb-6">
+                <span className="w-6 h-px bg-brand-brown/40" />
+                <span className="font-sans text-[10px] uppercase tracking-[0.2em] text-brand-brown/40">
+                    {t('sectionLabel')}
+                </span>
+            </div>
+
+            <h2 className="reveal font-serif text-[clamp(48px,6vw,80px)] leading-none text-brand-brown mb-12">
+                {t('title')}
+            </h2>
+
+            <div className="grid gap-6 md:grid-cols-2">
+                {articles.map((article, i) => (
+                    <Link
+                        key={article.slug}
+                        href={`/${locale}/blog/${article.slug}`}
+                        className="reveal group block cursor-pointer"
+                        style={{ transitionDelay: `${i * 100}ms` }}
+                    >
+                        {/* Image */}
+                        <div className="w-full h-[240px] rounded-xl overflow-hidden bg-brand-brown/5 mb-5">
+                            {article.cover && (
+                                <img
+                                    src={article.cover}
+                                    alt={article.title}
+                                    className="w-full h-full object-cover transition-all duration-700 group-hover:scale-[1.04] group-hover:brightness-105"
+                                />
+                            )}
+                        </div>
+
+                        {/* Text */}
+                        <div className="flex items-start justify-between gap-4">
+                            <div>
+                                <h3 className="font-serif text-2xl text-brand-brown uppercase mb-1.5">
+                                    {article.title}
+                                </h3>
+                                <p className="font-sans text-sm text-brand-brown/55 leading-relaxed">
+                                    {article.description}
+                                </p>
+                            </div>
+                            <svg
+                                className="w-5 h-5 text-brand-brown/30 flex-shrink-0 mt-1 group-hover:translate-x-1 group-hover:text-brand-brown/60 transition-all duration-200"
+                                fill="none"
+                                stroke="currentColor"
+                                viewBox="0 0 24 24"
+                                aria-hidden="true"
+                            >
+                                <path strokeLinecap="round" strokeLinejoin="round" strokeWidth={1.5} d="M17 8l4 4m0 0l-4 4m4-4H3" />
+                            </svg>
+                        </div>
+                    </Link>
+                ))}
+            </div>
+        </section>
+    );
+}

app/[locale]/blog/[slug]/page.tsx

@@ -2,9 +2,10 @@ import React from "react";
 import type { Metadata } from "next";
 import { notFound } from "next/navigation";
 import { MDXRemote } from "next-mdx-remote/rsc";
-import { getArticleBySlug, getAllArticles, getAlternatesArticle } from "@/lib/blog/get-articles";
+import { getArticleBySlug, getAllArticles, getAlternatesArticle, getRandomOtherArticles } from "@/lib/blog/get-articles";
 import { ArticleHero } from "@/app/[locale]/blog/[slug]/_components/ArticleHero";
 import { ArticleSummary } from "@/app/[locale]/blog/[slug]/_components/ArticleSummary";
+import { OtherArticles } from "@/app/[locale]/blog/[slug]/_components/OtherArticles";
 import { locales } from "@/middleware";
 import Link from "next/link";
 import { MermaidDiagram } from "@/components/mdx/MermaidDiagram";
@@ -144,6 +145,13 @@ export default async function ArticlePage({ params }: props) {
 
     const articleUrl = `${siteUrl}/${locale}/blog/${slug}`;
 
+    const otherArticles = getRandomOtherArticles(locale, slug, 2).map((item) => ({
+        slug: item.slug,
+        title: item.title,
+        description: item.description,
+        cover: item.cover,
+    }));
+
     const imageUrl = article.cover
         ? article.cover.startsWith("http")
             ? article.cover
@@ -218,6 +226,9 @@ export default async function ArticlePage({ params }: props) {
                         [&_a]:text-brand-brown [&_a]:underline 
                         [&_ul]:font-sans [&_ul]:text-sm [&_ul]:text-brand-brown/70 [&_ul]:leading-[1.9] [&_ul]:list-disc [&_ul]:pl-5 [&_ul]:space-y-1
                         [&_li]:font-sans [&_li]:text-sm [&_li]:text-brand-brown/70 [&_li]:leading-[1.9]
+                        [&_pre]:bg-brand-brown/5 [&_pre]:border [&_pre]:border-brand-brown/10 [&_pre]:text-brand-brown [&_pre]:rounded-lg [&_pre]:p-4 [&_pre]:overflow-x-auto [&_pre]:text-xs [&_pre]:leading-relaxed
+                        [&_pre_code]:font-mono [&_pre_code]:bg-transparent [&_pre_code]:p-0
+                        [&_code]:font-mono [&_code]:text-xs [&_code]:bg-brand-brown/10 [&_code]:text-brand-brown [&_code]:rounded [&_code]:px-1.5 [&_code]:py-0.5
                     "
                 >
                     <MDXRemote
@@ -226,6 +237,8 @@ export default async function ArticlePage({ params }: props) {
                         components={mdxComponents}
                     />
                 </article>
+
+                <OtherArticles locale={locale} articles={otherArticles} />
             </div>
         </main>
     );

app/[locale]/works/[slug]/page.tsx

@@ -1,6 +1,6 @@
 import { notFound } from "next/navigation";
 import { MDXRemote } from "next-mdx-remote/rsc";
-import { getAllProjects, getProjectBySlug, getProjectSlugs } from "@/lib/projects/get-projects";
+import { getProjectBySlug, getProjectSlugs, getRandomOtherProjects } from "@/lib/projects/get-projects";
 import { mdxComponents } from "@/components/mdx/mdxComponents";
 import { ProjectHero } from "@/app/[locale]/works/_components/ProjectHero";
 import { ProjectMeta } from "@/app/[locale]/works/_components/ProjectMeta";
@@ -38,15 +38,12 @@ export default async function ProjectPage({ params }: props) {
         notFound();
     }
 
-    const otherProjects = getAllProjects(locale)
+    const otherProjects = getRandomOtherProjects(locale, slug, 2).map((item) => ({
-        .filter((item: any) => item.slug !== slug && item.ready)
+        slug: item.slug,
-        .slice(0, 2)
+        title: item.title,
-        .map((item: any) => ({
+        description: item.description,
-            slug: item.slug,
+        cover: item.cover,
-            title: item.title,
+    }));
-            description: item.description,
-            cover: item.cover,
-        }));
 
     return (
         <main className="bg-brand-beige">

app/[locale]/works/_components/OtherProjects.tsx

@@ -10,7 +10,7 @@ type props = {
         slug: string;
         title: string;
         description: string;
-        cover: string;
+        cover?: string;
     }[];
 };
 
@@ -65,11 +65,13 @@ export function OtherProjects({ locale, projects }: props) {
                     >
                         {/* Image */}
                         <div className="w-full h-[240px] rounded-xl overflow-hidden bg-brand-brown/5 mb-5">
-                            <img
+                            {project.cover && (
-                                src={project.cover}
+                                <img
-                                alt={project.title}
+                                    src={project.cover}
-                                className="w-full h-full object-cover transition-all duration-700 group-hover:scale-[1.04] group-hover:brightness-105"
+                                    alt={project.title}
-                            />
+                                    className="w-full h-full object-cover transition-all duration-700 group-hover:scale-[1.04] group-hover:brightness-105"
+                                />
+                            )}
                         </div>
 
                         {/* Text */}

content/.obsidian/workspace.json

@@ -11,10 +11,14 @@
             "id": "224cf476c7b474e6",
             "type": "leaf",
             "state": {
-              "type": "empty",
+              "type": "markdown",
-              "state": {},
+              "state": {
+                "file": "blog/en/03-Deploying-an-infrastructure-for-a-macos-app-distribution.mdx",
+                "mode": "source",
+                "source": true
+              },
               "icon": "lucide-file",
-              "title": "Nouvel onglet"
+              "title": "03-Deploying-an-infrastructure-for-a-macos-app-distribution"
             }
           }
         ]

content/blog/en/03-Deploying-an-infrastructure-for-a-macos-app-distribution.mdx

@@ -1,140 +1,229 @@
 ---
 ready: true
 translationKey: deploying-an-infrastructure-for-a-macos-app-distribution
-title: Deploying a macOS app distribution infrastructure for the price of a monthly dinner
+title: Deploying an Infrastructure for a macOS App Distribution for the Price of a Restaurant Meal per Month
 description: Long live self-hosting!
-date: 2026-05-21
+date: 2026-06-12
 category: Architecture
 tags:
   - Experience
-  - TechStack
+  - Technologies
 readTime: 5 min
 summary:
   - Introduction
-  - "The specifications: Exploit Open Source"
+  - "The Specifications: Leveraging Open Source"
-  - "The core of the problem: making public and private coexist"
+  - "The Core of the Problem: Making Public and Private Coexist"
-  - "Overview: How it runs day-to-day?"
+  - "Overview: How Does It Run Daily?"
-  - The monitoring and the backups
+  - Monitoring and Backups
-  - The costs in all that
+  - The Costs in All This
 cover: /images/blog/03/deploying-an-infrastructure-for-a-macos-app-distribution.png
 ---
 
 ## Introduction
+A few weeks ago at the time of writing this article, I launched into the development of Thence, a macOS application that remembers a developer's project context to save them time and energy when they resume it after a break.
 
-A few weeks ago at the time I am writing this article, I launched into the development of Thence, a macOS application that memorizes a developer's project context to save them time and energy when they resume it after a break.
+The application code as such is only the tip of the iceberg. Very quickly, the reality on the ground catches up with you: to make a product live, you need a whole ecosystem around it. A space for the community, a software license management system, and internal tools to manage everything and make the right decisions for the product's evolution.
 
-The code of the application as such is only the tip of the iceberg. Very quickly, the reality of the field catches up with you: to make a product live, you need an entire ecosystem around it. A space for the community, a software license management system, and internal tools to pilot everything and make the right decisions for the evolution of the product.
+If we turn to all kinds of SaaS, each specializing in a particular task, with the versatility of the necessary systems, we can quickly find ourselves with a hefty bill. Being a student at that time, and having much better plans for my money, I made a radical decision: self-host as much as possible.
 
-If we turn to SaaS of all kinds, each specialized in one task in particular, with the versatility of the necessary systems, you quickly end up with a salty bill. Being a student at that time, and having much better projects for my money, I took a radical decision: self-host as much as possible.
+In this article, I invite you to explore the architecture of my VPS (Virtual Private Server). We will see how I managed to make public and private tools coexist on one and the same machine, the technical choices behind each brick, and how this "system D" (resourceful) approach allowed me to build a reliable, scalable, and available architecture, for not too much money.
 
-In this article, I propose to go through the architecture of my VPS (Virtual Private Server). We will see how I managed to make public and private tools coexist on one and the same machine, the technical choices behind each brick and how this "system D" approach allowed me to build a reliable, scalable and available architecture, for not too expensive.
+## The Specifications: Leveraging Open Source
+The goal was not to host services for the pleasure of testing them, but indeed to meet a real business need for Thence. For each need, I searched for and selected the best free, self-hostable solution in the best-case scenario, capable of running efficiently in Docker containers, without letting myself bury under technical debt.
 
-## The specifications: Exploit Open Source
+### Code Hosting: Gitea
+Goodbye GitHub or GitLab, I wanted to maintain the sovereignty of my code and manage my own CI/CD runners. Gitea is lightweight and does the job, so it stood out as an obvious choice.
 
-The objective was not to host services for the pleasure of testing them, but bel and bien to respond to a real business need for Thence. For each need I searched and selected the best free solution, self-hostable in the best of cases, capable of running efficiently in Docker containers, without however making me collapse under technical debt.
+### Automation: n8n
+To manage my blog's RSS feeds and my newsletter, I needed a conductor. I had wanted to test n8n for a while, it was the perfect opportunity!
 
-### Distribution and licenses: Keygen
+### Distribution and Licenses: Keygen
+For a paid desktop application, software license management is the sinews of war. I needed a system capable of generating keys, managing activations, and ensuring that a user doesn't deploy the application on 10 different machines with a single subscription. I deployed the self-hosted version of Keygen for this.
 
-For a paid desktop application, software license management is the nerve of the war. I needed a system capable of generating keys, managing activations and ensuring that a user does not deploy the application on 10 different machines with a single subscription. I deployed the self-hosted version of Keygen for that.
+### Support and Community: Discourse
+Rather than opening a Discord server that is difficult for Google to index, or managing an unmanageable amount of customer support emails visible only to me, I chose Discourse. It's a forum, exposed to the Internet, which allows me to structure discussions with users, publish roadmaps, and exchange with the community around the application in general.
 
-### Support and community: Discourse
+More precisely, I use it for several things at once:
+* **Pre-registering users:** It is by inviting them to this forum in a dedicated group that I was able to find the beta users of the application, those with whom I am building the MVP (Minimum Viable Product), still at the time of writing this article.
+* **Creating a public knowledge base self-fueled by users:** This is the second strong point of this kind of tool. People ask questions, I answer them, and other people who ask themselves the same questions read the discussions to find their answers. It is a self-fueled FAQ that answers users' questions directly, and not questions that I think users will ask.
 
-Rather than opening a Discord server difficultly indexable by Google, or managing a quantity of support client emails intractable and visible only by me, I chose Discourse. It is a forum, exposed on the Internet, which allows me to structure discussions with users, publish roadmaps, exchange with the community around the application in a general way.
+### Deployment and Monitoring: Komodo
+Deploying applications galore in Docker containers is good. But being able to do it graphically, monitor their health status, and perform their updates in a few clicks is better! Not that typing commands by hand particularly annoys me, on the contrary, but it's mostly tiring, longer. This is where Komodo comes in, my control center to manage the vast majority of my self-hosted applications serenely.
 
-More precisely, I use it for several things at the same time:
+## The Core of the Problem: Making Public and Private Coexist
-* **Pre-register users:** It is by inviting them to this forum in a dedicated group that I was able to find the beta users of the application, those with whom I am building the MVP (Minimum Viable Product), still at the moment I am writing the article.
+You may have noticed, I talked about services accessible to the public like Discourse, but also services that must imperatively remain private like Komodo or Keygen. That is why a good partitioning of the two (public and private) is necessary so as not to expose myself, and user data, to obvious and significant vulnerabilities. 
-* **Create a public knowledge base self-fueled by users:** This is the second strong point of this kind of tool. People ask questions, I answer them, and other people who ask themselves the same questions read the discussions to find their answers. It is a self-fueled FAQ that responds to the questions of the users directly, and not to the questions that I think the users are going to ask themselves.
-
-### Deployment and monitoring: Komodo
-
-Deploying applications galore in Docker containers is good. But being able to do it graphically, monitor their health state, perform their updates in a few clicks is better! Not that typing commands by hand annoys me particularly, on the contrary, but it is especially tiring, longer. This is where Komodo intervenes, my control center to pilot the vast majority of my self-hosted applications serenely.
-
----
-
-## The core of the problem: making public and private coexist
-
-You will have perhaps noticed it, I spoke of services accessible to the public like Discourse, but also of services that must imperatively remain private like Komodo or Keygen. This is why a good cloisonnement of the two (public and private) is needed so as not to expose me, myself and the data of the users, to obvious and important flaws.
 
 Here is how I secured and organized this traffic.
 
-### Who orchestrates the traffic? The duo Vercel and Caddy
+### Who Orchestrates the Traffic? The Vercel and Caddy Duo
+One of the challenges when making several services cohabit on a single server is managing traffic and SSL certificates (HTTPS). In my architecture, I set up a cascading proxy system.
 
-One of the challenges when making several services cohabit on a single server is the management of traffic and SSL certificates (HTTPS). In my architecture, I set up a cascading proxy system.
+#### Public Traffic: Vercel at the DNS, Caddy at the Routing
+For everything accessible by users (like the Discourse forum), the architecture is as follows: 
 
-#### The Public traffic: Vercel in first line, Caddy at the switching
+My main domain name is managed at Vercel. I declared a type A record there for public subdomains (for example `forum.thence.app`) pointing to the public IP of my VPS.
 
-For everything that is accessible by users (like the Discourse forum) the path is the following:
+It is therefore my VPS that receives the connection. Once the request arrives, Caddy takes over. I chose Caddy, among other things, for its native Automatic HTTPS feature. It automatically provides and renews SSL certificates without my intervention. 
 
-Vercel handles the entry. My public domain names point to Vercel. It is its infrastructure that takes the connection first. Vercel handles the public SSL certificate, ensures that the connection is secure, then cleanly redirects the traffic to the IP of my VPS.
+Here is an extract from my Caddyfile for the forum:
 
-Once the request arrives on my VPS, it is Caddy that takes the relay. It inspects the subdomain received: if the request targets `forum.thence.app`, Caddy sends it to the Discourse container.
+File successfully created: deploying-an-infrastructure-for-a-macos-app-distribution.md
 
-This approach allows me to benefit from the power and security of Vercel in frontal, while keeping total flexibility on my VPS thanks to Caddy to dispatch the traffic to my different Docker containers.
+```caddy
+forum.thence.app {
+        reverse_proxy 127.0.0.1:9080 {
+                header_up Host {host}
+                header_up X-Real-IP {remote_host}
+                header_up X-Forwarded-For {remote_host}
+                header_up X-Forwarded-Proto {scheme}
+                header_up X-Forwarded-Host {host}
+        }
 
-#### The Private traffic: The Caddy + Tailscale safe
+        encode gzip zstd
+}
 
-For services that never need to be exposed on the public Web (like my Komodo administration interface), I applied the principle of Zero Trust by combining Caddy and Tailscale. Out of the question that these flows pass through the Internet or through Vercel.
+```
 
-Tailscale is a secure mesh VPN based on the WireGuard protocol. By installing Tailscale on my VPS and on my computers, my server obtains a unique private IP address within my secure network (my tailnet), as well as a private domain name.
+No mention of certificates to manage, Caddy reads the request, manages HTTPS, transmits the correct headers so the application keeps the origin IP, and redirects the flow to the local port of my Discourse container.
 
-Here, Caddy adopts a totally different behavior:
+#### Private Traffic: The Caddy + Tailscale Safe
-* I ask it to listen only on the private network interface of Tailscale for these sensitive services.
-* Caddy will directly ask for an SSL certificate from the local Tailscale daemon to secure access in HTTPS.
 
-#### The result
+For services that never need to be exposed to the public Web (like my Komodo administration interface), I applied the Zero Trust principle by combining Caddy and Tailscale. Out of the question for these flows to pass through the Internet or through Vercel.
 
-If a user or a robot tries to type the URL of my Komodo from the public Web, he runs into a wall: the domain does not exist and the port is closed. For me to be able to administer my infrastructure, I must obligatorily activate Tailscale on my computer. As soon as I am part of the private network, Caddy recognizes my machine, validates the Tailscale HTTPS, and gives me access to my private containers.
+Tailscale is a secure mesh VPN based on the WireGuard protocol. By installing Tailscale on my VPS and on my computers, my server gets a unique private IP address within my secure network (my tailnet).
 
----
+For these services, the Caddy configuration adopts a totally closed approach:
 
-## Overview: How it runs day-to-day?
+```caddy
+vps-939ea86a.tail8644df.ts.net {
+    tls /etc/caddy/certs/cert.crt /etc/caddy/certs/cert.key
+    reverse_proxy 127.0.0.1:9120
+}
 
-To completely understand how all these bricks cohabit without stepping on each other's feet, nothing beats a good diagram.
+```
+
+This block will never respond to a request on the Internet. It only listens on the private domain provided by Tailscale and uses locally generated certificates. If a robot scans my server's public IP, it will find absolutely nothing. To access my administration interface (here on local port 9120), I must imperatively activate Tailscale on my computer.
+
+### Hybrid Cases: The Best of Both Worlds
+
+#### Filtering by HTTP Route (The n8n Example)
+
+Sometimes, a service must be partially public to receive data, but its administration interface must remain strictly inaccessible. This is the case for my n8n instance which must be able to receive webhooks from the outside.
+
+Here is how I secure this flow:
+
+```caddy
+n8n.thence.app {
+        @preflight {
+                method OPTIONS
+                path /webhook/*
+        }
+
+        handle @preflight {
+                header Access-Control-Allow-Origin "[https://thence.app](https://thence.app)"
+                header Access-Control-Allow-Methods "GET, POST, OPTIONS"
+                header Access-Control-Allow-Headers "Content-Type, Authorization"
+                header Access-Control-Max-Age "86400"
+                respond "" 204
+        }
+
+        handle /webhook/* {
+                header Access-Control-Allow-Origin "[https://thence.app](https://thence.app)"
+                header Access-Control-Allow-Methods "GET, POST, OPTIONS"
+                header Access-Control-Allow-Headers "Content-Type, Authorization"
+
+                reverse_proxy [http://100.127.230.106:5678](http://100.127.230.106:5678)
+        }
+
+        handle {
+                respond "Forbidden" 403
+        }
+}
+
+```
+
+Here, I handle:
+
+* CORS "preflight" (OPTIONS) requests to authorize my main application to communicate with the API
+* I authorize the reverse proxy only on the `/webhook/*` path
+* The last handle block acts like an `else`: any other request will be returned a 403 Forbidden error. The tool can thus work serenely with the outside without ever exposing its back-office.
+
+Here, I handle:
+
+* CORS "preflight" (OPTIONS) requests to authorize my main application to communicate with the API
+* I authorize the reverse proxy only on the `/webhook/*` path
+* The last handle block acts like an `else`: any other request will be returned a 403 Forbidden error. The tool can thus work serenely with the outside without ever exposing its back-office.
+
+#### Filtering by Protocol and Network (The Gitea Example)
+
+For my Gitea instance, the hybrid need is different. I want the web interface to be publicly accessible to view what I'm doing, but I also want to lock down write access (clone and push).
+
+To keep control over my source code, the rule is simple: I disable HTTP cloning and force SSH only on the Tailscale domain.
+
+Caddy simply exposes the web interface:
+
+```caddy
+git.matheoguilbert.fr {
+        encode gzip zstd
+        reverse_proxy 127.0.0.1:3000
+}
+
+```
+
+And on the Gitea side, I disable HTTP cloning and specify the SSH domain to use:
+
+```ini
+GITEA__server__DISABLE_HTTP_GIT=true
+GITEA__server__SSH_DOMAIN=vps-939ea86a.tail8644df.ts.net
+GITEA__server__SSH_PORT=222
+
+```
+
+## Overview: How Does It Run Daily?
+
+To understand well how all these bricks cohabit without stepping on each other's toes, nothing beats a good diagram.
 
 ```mermaid
 graph TD
-    %% Flux Public
+    %% Public Flow
-    Internet([Le Web Public]) --> Vercel[Vercel]
+    Internet([The Public Web]) -.->|DNS Resolution| VercelDNS[Vercel DNS]
-    Vercel --> Caddy
+    Internet -->|Direct HTTPS Traffic| Caddy
 
-    %% Flux Privé
+    %% Private Flow
-    MonMac([Mon Mac]) --> Tailscale[Tailscale VPN]
+    MonMac([My Mac]) --> Tailscale[Tailscale VPN]
     Tailscale --> Caddy
 
-    %% Le VPS et Caddy
+    %% The VPS and Caddy
-    subgraph Mon VPS
+    subgraph Mon VPS [My VPS]
         Caddy[Reverse Proxy: Caddy]
         
-        %% Dispatching vers Docker
+        %% Dispatching to Docker
         Caddy -->|Public| Discourse[Discourse Forum]
-        Caddy -->|Public| Keygen[Keygen Licences]
+        Caddy -->|Public| Keygen[Keygen Licenses]
-        Caddy -->|Privé| Keygen2[Keygen Admin]
+        Caddy -->|Hybrid| N8N[n8n Webhooks]
-        Caddy -->|Privé| Komodo[Komodo Admin]
+        Caddy -->|Hybrid| Gitea[Gitea Web]
+        Caddy -->|Private| Komodo[Komodo Admin]
     end
+
 ```
 
----
+## Monitoring and Backups
-
-## The monitoring and the backups
 
 An infrastructure is only viable if it is monitored and backed up.
 
-* **The administration:** This is where Komodo takes all its meaning. Since my PC (via Tailscale), I have access to a dashboard that allows me to see the health state of each container, to consult the logs in one click and to restart a service if necessary.
+* **Administration:** This is where Komodo makes perfect sense. From my PC (via Tailscale), I have access to a dashboard that allows me to see the health status of each container, view logs in one click, and restart a service if necessary.
+* **Backup Strategy:** The trap of self-hosting is losing everything if the server crashes. To avoid this, I automated my backups with Restic, an open-source tool that natively encrypts and deduplicates data. Every night, a Bash script performs a hot dump of my databases (via `mongodump`), then Restic directly backs up my Docker volumes (`/var/lib/docker/volumes`) to my S3 storage. The script even includes a retention policy (`restic forget --keep-daily 7`) to automatically purge backups older than a week and optimize storage costs.
 
-* **The Backup strategy:** The trap of self-hosting is to lose everything if the server crashes. I have therefore automated the backup of Docker volumes. Each night, a script encrypts these data and sends them to an S3 compatible object storage.
+## The Costs in All This
 
----
+For the server itself, I went through OVH, it's quite reliable and not too expensive. I pay around €10.20 per month.
 
-## The costs in all that
+For Thence's public domain name, I went through Vercel, which I use to host the website. I pay €14.99 per year.
 
-* For the server itself, I went through OVH, it is quite reliable and not too expensive. I pay around **10.20€ per month**.
+For S3 storage, I have 1 TB with the premium plan of Next.ink, an independent French tech journal. I pay €8 per month.
 
-* For the public domain name of Thence, I went through Vercel, with which I host the website. I pay 14.99€ per year.**.
+That makes a total of €33.19 per month, which is quite a low amount for the resource I get with it. It will take a lot of traffic on Thence to reach saturation, and at that point, I don't believe the financial side will be a real obstacle.
 
-* For the S3 storage, I have 1 To with the premium plan of Next.ink, a French and independent tech journal. I pay 8€ per month.**.
+On that note, thank you for reading this far and see you next time in another article.
 
-That makes a total of 33.19€ per month, it is a quite low amount for the resource I have with that. It will take a lot of traffic on Thence to arrive at saturation, and at that moment, I do not believe that the financial side will be a real break.
+Mathéo G
-
-On this, thank you for having read until here and to the next one in another article.
-
-**Mathéo G**

content/blog/fr/03-Deploying-an-infrastructure-for-a-macos-app-distribution.mdx

@@ -3,7 +3,7 @@ ready: true
 translationKey: deploying-an-infrastructure-for-a-macos-app-distribution
 title: Déployer une infrastructure pour la distribution d'une app macOS pour le prix d'un resto par mois
 description: Vive le self-hosting !
-date: 2026-05-21
+date: 2026-06-12
 category: Architecture
 tags:
   - Expérience
@@ -23,7 +23,7 @@ cover: /images/blog/03/deploying-an-infrastructure-for-a-macos-app-distribution.
 
 Il y a quelques semaines au moment où j'écris cet article, je me suis lancé dans le développement de Thence, une application macOS qui mémorise le contexte projet d'un développeur pour lui faire gagner du temps et de l'énergie quand il le reprend après une pause.
 
-Le code de l'application en tant que tel n'est que la partie émergée de l'iceberg. Très vite, la réalité du terrain vous rattrape : pour faire vivre un produit, il faut tout un écosystème autour. Un espace pour la communauté, un système de gestion des licences logicielles, et des outils internes pour piloter le tout et prendre les bonnes décisions pour l'évolution du produit. 
+Le code de l'application en tant que tel n'est que la partie émergée de l'iceberg. Très vite, la réalité du terrain vous rattrape : pour faire vivre un produit, il faut tout un écosystème autour. Un espace pour la communauté, un système de gestion des licences logicielles, et des outils internes pour piloter le tout et prendre les bonnes décisions pour l'évolution du produit.
 
 Si on se tourne vers des SaaS en tout genre, chacun spécialiste d'une tâche en particulier, avec la polyvalence des systèmes nécessaires, on a vite fait de se retrouver avec une facture salée. Étant étudiant à ce moment-là, et ayant de bien meilleurs projets pour mon argent, j'ai pris une décision radicale : auto-héberger au maximum.
 
@@ -33,27 +33,37 @@ Dans cet article, je vous propose de parcourir l'architecture de mon VPS (Serveu
 
 L'objectif n'était pas d'héberger des services pour le plaisir de les tester, mais bel et bien de répondre à un vrai besoin métier pour Thence. Pour chaque besoin, j'ai cherché et sélectionné la meilleure solution gratuite, auto-hébergeable dans le meilleur des cas, capable de tourner efficacement dans des conteneurs Docker, sans pour autant me faire crouler sous la dette technique.
 
+### Hébergement du code : Gitea
+
+Au revoir GitHub ou GitLab, je voulais garder la souveraineté de mon code et gérer mes propres runners CI/CD. Gitea est léger et fait l'affaire, il s'imposait donc comme une évidence.
+
+### Automatisation : n8n
+
+Pour gérer les flux RSS de mon blog et ma newsletter, il me fallait un chef d'orchestre. J'avais envie de tester n8n depuis un moment, c'était l'occasion rêvée !
+
 ### Distribution et licences : Keygen
 
-Pour une application de bureau payante, la gestion des licences logicielles est le nerf de la guerre. Il me fallait un système capable de générer des clés, de gérer les activations et de s'assurer qu'un utilisateur ne déploie pas l'application sur 10 machines différentes avec un seul abonnement. J'ai déployé la version auto-hébergée de Keygen pour cela. 
+Pour une application de bureau payante, la gestion des licences logicielles est le nerf de la guerre. Il me fallait un système capable de générer des clés, de gérer les activations et de s'assurer qu'un utilisateur ne déploie pas l'application sur 10 machines différentes avec un seul abonnement. J'ai déployé la version auto-hébergée de Keygen pour cela.
 
 ### Support et communauté : Discourse
 
 Plutôt que d'ouvrir un serveur Discord difficilement indexable par Google, ou de gérer une quantité de mails de support client intraitable et visible uniquement par moi, j'ai choisi Discourse. C'est un forum, exposé sur Internet, qui me permet de structurer les discussions avec les utilisateurs, de publier les roadmaps, d'échanger avec la communauté autour de l'application de manière générale.
 
 Plus précisément, je l'utilise pour plusieurs choses à la fois :
-* **Préinscrire les utilisateurs :** C'est en les invitant sur ce forum dans un groupe dédié que j'ai pu trouver les bêta-utilisateurs de l'application, ceux avec qui je construis le MVP (Produit Minimum Viable), encore au moment où j'écris l'article. 
+
+* **Préinscrire les utilisateurs :** C'est en les invitant sur ce forum dans un groupe dédié que j'ai pu trouver les bêta-utilisateurs de l'application, ceux avec qui je construis le MVP (Produit Minimum Viable), encore au moment où j'écris l'article.
+
 * **Créer une base de connaissances publique auto-alimentée par les utilisateurs :** C'est le deuxième point fort de ce genre d'outil. Les gens posent des questions, j'y réponds, et d'autres personnes qui se posent les mêmes questions lisent les discussions pour y trouver leurs réponses. C'est une FAQ auto-alimentée qui répond aux questions des utilisateurs directement, et non aux questions que je pense que les utilisateurs vont se poser.
 
 ### Déploiement et monitoring : Komodo
 
-Déployer des applications à gogo dans des conteneurs Docker, c'est bien. Mais pouvoir le faire graphiquement, surveiller leur état de santé, effectuer leurs mises à jour en quelques clics, c'est mieux ! Non pas que taper les commandes à la main m'agace particulièrement, au contraire, mais c'est surtout fatiguant, plus long. C'est là que Komodo intervient, mon centre de contrôle pour piloter la grande majorité de mes applications auto-hébergées sereinement.
+Déployer des applications à gogo dans des conteneurs Docker, c'est bien. Mais pouvoir le faire graphiquement, surveiller leur état de santé, effectuer leurs mises à jour en quelques clics, c'est mieux ! Non pas que taper les commandes à la main m'agace particulièrement, au contraire, mais c'est surtout fatigant, plus long. C'est là que Komodo intervient, mon centre de contrôle pour piloter la grande majorité de mes applications auto-hébergées sereinement.
 
 ---
 
 ## Le cœur du problème : faire coexister public et privé
 
-Vous l'aurez peut-être remarqué, j'ai parlé de services accessibles au public comme Discourse, mais aussi de services qui doivent impérativement rester privés comme Komodo ou Keygen. C'est pourquoi il faut un bon cloisonnement des deux (public et privé) de sorte à ne pas m'exposer, moi et les données des utilisateurs, à des failles évidentes et importantes.
+Vous l'aurez peut-être remarqué, j'ai parlé de services accessibles au public comme Discourse, mais aussi de services qui doivent impérativement rester privés comme Komodo ou Keygen. C'est pourquoi il faut un bon cloisonnement des deux (public et privé) de sorte à ne pas m'exposer, moi et les données des utilisateurs, à des failles évidentes et importantes. 
 
 Voici comment j'ai sécurisé et organisé ce trafic.
 
@@ -61,29 +71,112 @@ Voici comment j'ai sécurisé et organisé ce trafic.
 
 L'un des défis quand on fait cohabiter plusieurs services sur un seul serveur, c'est la gestion du trafic et des certificats SSL (le HTTPS). Dans mon architecture, j'ai mis en place un système de proxy en cascade.
 
-#### Le trafic Public : Vercel en première ligne, Caddy à l'aiguillage
+#### Le trafic Public : Vercel au DNS, Caddy à l'aiguillage
 
-Pour tout ce qui est accessible par les utilisateurs (comme le forum Discourse), le chemin est le suivant :
+Pour tout ce qui est accessible par les utilisateurs (comme le forum Discourse), l'architecture est la suivante : 
 
-Vercel gère l'entrée. Mes noms de domaine publics pointent vers Vercel. C'est son infrastructure qui encaisse la connexion en premier. Vercel gère le certificat SSL public, s'assure que la connexion est sécurisée, puis redirige proprement le trafic vers l'IP de mon VPS.
+Mon nom de domaine principal est géré chez Vercel. J'y ai déclaré un enregistrement de type A pour les sous-domaines publics (par exemple forum.thence.app) qui pointent vers l'IP publique de mon VPS.
 
-Une fois la requête arrivée sur mon VPS, c'est Caddy qui prend le relais. Il inspecte le sous-domaine reçu : si la requête cible `forum.thence.app`, Caddy la renvoie vers le conteneur Discourse.
+C'est donc mon VPS qui reçoit la connexion. Une fois la requête arrivée, c'est Caddy qui prend le relais. J'ai choisi Caddy, entre autres, pour sa fonctionnalité native d'Automatic HTTPS. Il fournit et renouvelle automatiquement les certificats SSL sans intervention de ma part. 
 
-Cette approche me permet de bénéficier de la puissance et de la sécurité de Vercel en frontal, tout en gardant une flexibilité totale sur mon VPS grâce à Caddy pour dispatcher le trafic vers mes différents conteneurs Docker.
+Voici un extrait de mon Caddyfile pour le forum :
+```
+forum.thence.app {
+        reverse_proxy 127.0.0.1:9080 {
+                header_up Host {host}
+                header_up X-Real-IP {remote_host}
+                header_up X-Forwarded-For {remote_host}
+                header_up X-Forwarded-Proto {scheme}
+                header_up X-Forwarded-Host {host}
+        }
+
+        encode gzip zstd
+}
+```
+
+Aucune mention de certificat à gérer, Caddy lit la requête, gère le HTTPS, transmet les bonnes en-têtes pour que l'application conserve l'IP d'origine et redirige le flux vers le port local de mon conteneur Discourse.
 
 #### Le trafic Privé : Le coffre-fort Caddy + Tailscale
 
-Pour les services qui n'ont jamais besoin d'être exposés sur le Web public (comme mon interface d'administration Komodo), j'ai appliqué le principe du *Zero Trust* en combinant Caddy et Tailscale. Hors de question que ces flux passent par Internet ou par Vercel.
+Pour les services qui n'ont jamais besoin d'être exposés sur le Web public (comme mon interface d'administration Komodo), j'ai appliqué le principe du Zero Trust en combinant Caddy et Tailscale. Hors de question que ces flux passent par Internet ou par Vercel.
 
-Tailscale est un VPN maillé sécurisé basé sur le protocole WireGuard. En installant Tailscale sur mon VPS et sur mes ordinateurs, mon serveur obtient une adresse IP privée unique au sein de mon réseau sécurisé (mon *tailnet*), ainsi qu'un nom de domaine privé.
+Tailscale est un VPN maillé sécurisé basé sur le protocole WireGuard. En installant Tailscale sur mon VPS et sur mes ordinateurs, mon serveur obtient une adresse IP privée unique au sein de mon réseau sécurisé (mon tailnet).
 
-Ici, Caddy adopte un comportement totalement différent :
+Pour ces services, la configuration de Caddy adopte une approche totalement fermée :
-* Je lui demande d'écouter uniquement sur l'interface réseau privée de Tailscale pour ces services sensibles.
+```
-* Caddy va directement demander un certificat SSL au démon Tailscale local pour sécuriser l'accès en HTTPS.
+vps-939ea86a.tail8644df.ts.net {
+    tls /etc/caddy/certs/cert.crt /etc/caddy/certs/cert.key
+    reverse_proxy 127.0.0.1:9120
+}
+```
 
-#### Le résultat
+Ce bloc ne répondra jamais à une requête sur Internet. Il n'écoute que sur le domaine privé fourni par Tailscale et utilise des certificats générés localement. Si un robot scanne l'IP publique de mon serveur, il ne trouvera absolument rien. Pour accéder à mon interface d'administration (ici sur le port local 9120), je dois obligatoirement activer Tailscale sur mon ordinateur.
 
-Si un utilisateur ou un robot tente de taper l'URL de mon Komodo depuis le Web public, il se heurte à un mur : le domaine n'existe pas et le port est fermé. Pour que je puisse administrer mon infrastructure, je dois obligatoirement activer Tailscale sur mon ordinateur. Dès que je fais partie du réseau privé, Caddy reconnaît ma machine, valide le HTTPS Tailscale, et me donne accès à mes conteneurs privés.
+#### Les cas hybrides : le meilleur des deux mondes
+##### Filtrer par route HTTP (L'exemple n8n)
+
+Parfois, un service doit être partiellement public pour recevoir des données, mais son interface d'administration doit rester strictement inaccessible. C'est le cas de mon instance n8n qui doit pouvoir recevoir des webhooks de l'extérieur.
+
+Voici comment je sécurise ce flux :
+```
+n8n.thence.app {
+        @preflight {
+                method OPTIONS
+                path /webhook/*
+        }
+
+        handle @preflight {
+                header Access-Control-Allow-Origin "https://thence.app"
+                header Access-Control-Allow-Methods "GET, POST, OPTIONS"
+                header Access-Control-Allow-Headers "Content-Type, Authorization"
+                header Access-Control-Max-Age "86400"
+                respond "" 204
+        }
+
+        handle /webhook/* {
+                header Access-Control-Allow-Origin "https://thence.app"
+                header Access-Control-Allow-Methods "GET, POST, OPTIONS"
+                header Access-Control-Allow-Headers "Content-Type, Authorization"
+
+                reverse_proxy http://100.127.230.106:5678
+        }
+
+        handle {
+                respond "Forbidden" 403
+        }
+}
+```
+
+Ici, je gère :
+* les requêtes CORS "preflight" (`OPTIONS`) pour autoriser mon application principale à communiquer avec l'API
+* J'autorise le reverse proxy **uniquement** sur le chemin `/webhook/*`
+* Le dernier bloc `handle` agit comme un `else` : toute autre requête se verra retourner une erreur `403 Forbidden`. L'outil peut ainsi travailler sereinement avec l'extérieur sans jamais exposer son back-office
+
+Ici, je gère :
+* Les requêtes CORS "preflight" (OPTIONS) pour autoriser mon application principale à communiquer avec l'API
+* J'autorise le reverse proxy uniquement sur le chemin /webhook/*
+* Le dernier bloc handle agit comme un else : toute autre requête se verra retourner une erreur `403 Forbidden`. L'outil peut ainsi travailler sereinement avec l'extérieur sans jamais exposer son back-office
+
+##### Filtrer par protocole et réseau (L'exemple Gitea)
+
+Pour mon instance Gitea, le besoin hybride est différent. Je veux que l'interface web soit accessible publiquement pour consulter ce que je fais, mais je veux aussi verrouiller les accès en écriture (clone et push).
+
+Pour garder le contrôle sur mon code source, la règle est simple : je désactive le clone en HTTP et je force le SSH uniquement sur le domaine Tailscale. 
+
+Caddy se contente donc d'exposer l'interface web :
+```
+git.matheoguilbert.fr {
+        encode gzip zstd
+        reverse_proxy 127.0.0.1:3000
+}
+```
+
+Et côté Gitea, je désactive le clonage HTTP et spécifie le domaine SSH à utiliser :
+```
+GITEA__server__DISABLE_HTTP_GIT=true
+GITEA__server__SSH_DOMAIN=vps-939ea86a.tail8644df.ts.net
+GITEA__server__SSH_PORT=222
+```
 
 ---
 
@@ -94,8 +187,8 @@ Pour bien comprendre comment toutes ces briques cohabitent sans se marcher sur l
 ```mermaid
 graph TD
     %% Flux Public
-    Internet([Le Web Public]) --> Vercel[Vercel]
+    Internet([Le Web Public]) -.->|Résolution DNS| VercelDNS[DNS Vercel]
-    Vercel --> Caddy
+    Internet -->|Trafic HTTPS direct| Caddy
 
     %% Flux Privé
     MonMac([Mon Mac]) --> Tailscale[Tailscale VPN]
@@ -108,7 +201,8 @@ graph TD
         %% Dispatching vers Docker
         Caddy -->|Public| Discourse[Discourse Forum]
         Caddy -->|Public| Keygen[Keygen Licences]
-        Caddy -->|Privé| Keygen2[Keygen Admin]
+        Caddy -->|Hybride| N8N[n8n Webhooks]
+        Caddy -->|Hybride| Gitea[Gitea Web]
         Caddy -->|Privé| Komodo[Komodo Admin]
     end
 ```
@@ -121,7 +215,7 @@ Une infrastructure n'est viable que si elle est surveillée et sauvegardée.
 
 * **L'administration :** C'est là que Komodo prend tout son sens. Depuis mon PC (via Tailscale), j'ai accès à un tableau de bord qui me permet de voir l'état de santé de chaque conteneur, de consulter les logs en un clic et de redémarrer un service si nécessaire.
 
-* **La stratégie de Backup :** Le piège du *self-hosting*, c'est de tout perdre si le serveur crash. J'ai donc automatisé la sauvegarde des volumes Docker. Chaque nuit, un script chiffre ces données et les envoie vers un stockage objet compatible S3.
+* **La stratégie de Backup :** Le piège du self-hosting, c'est de tout perdre si le serveur crash. Pour éviter cela, j'ai automatisé mes sauvegardes avec Restic, un outil open-source qui chiffre et déduplique nativement les données. Chaque nuit, un script Bash réalise un dump à chaud de mes bases de données (via mongodump), puis Restic sauvegarde directement mes volumes Docker (`/var/lib/docker/volumes`) vers mon stockage S3. Le script inclut même une politique de rétention (`restic forget --keep-daily 7`) pour purger automatiquement les sauvegardes de plus d'une semaine et optimiser les coûts de stockage.
 
 ---
 
@@ -133,7 +227,7 @@ Une infrastructure n'est viable que si elle est surveillée et sauvegardée.
 
 * Pour le stockage S3, je dispose d'1 To avec le plan premium de Next.ink, un journal tech français et indépendant. Je paye **8€ par mois**.
 
-Cela fait un total de **33.19€ par mois**, c'est un montant assez faible pour la ressource que j'ai avec cela. Il va falloir beaucoup de trafic sur Thence pour arriver à saturation, et à ce moment-là, je ne crois pas que le côté financier soit un vrai frein.
+Cela fait un total de 33.19€ par mois, c'est un montant assez faible pour la ressource que j'ai avec cela. Il va falloir beaucoup de trafic sur Thence pour arriver à saturation, et à ce moment-là, je ne crois pas que le côté financier soit un vrai frein.
 
 Sur ce, merci d'avoir lu jusqu'ici et à la prochaine dans un autre article.
 

lib/blog/get-articles.ts

@@ -45,6 +45,17 @@ export function getAllArticles(locale: string): Article[] {
         .sort((a, b) => new Date(b.date).getTime() - new Date(a.date).getTime());
 }
 
+export function getRandomOtherArticles(locale: string, excludeSlug: string, count: number): Article[] {
+    const candidates = getAllArticles(locale).filter((article) => article.slug !== excludeSlug);
+
+    for (let i = candidates.length - 1; i > 0; i--) {
+        const j = Math.floor(Math.random() * (i + 1));
+        [candidates[i], candidates[j]] = [candidates[j], candidates[i]];
+    }
+
+    return candidates.slice(0, count);
+}
+
 export function getAlternatesArticle(article: Article) {
     if (!article.translationKey) {
         return {};

lib/projects/get-projects.ts

@@ -41,4 +41,17 @@ export function getAllProjects(locale: string): Project[] {
         .map((slug) => getProjectBySlug(slug, locale))
         .filter((project): project is Project => project !== null)
         .sort((a, b) => a.priority - b.priority);
+}
+
+export function getRandomOtherProjects(locale: string, excludeSlug: string, count: number): Project[] {
+    const candidates = getAllProjects(locale).filter(
+        (project) => project.slug !== excludeSlug && project.ready
+    );
+
+    for (let i = candidates.length - 1; i > 0; i--) {
+        const j = Math.floor(Math.random() * (i + 1));
+        [candidates[i], candidates[j]] = [candidates[j], candidates[i]];
+    }
+
+    return candidates.slice(0, count);
 }

messages/en.json

@@ -82,6 +82,10 @@
         "noArticles": "No articles yet.",
         "summary": {
             "label": "Summary"
+        },
+        "otherArticles": {
+            "sectionLabel": "Other articles",
+            "title": "See also"
         }
     },
     "projectPage": {

messages/fr.json

@@ -82,6 +82,10 @@
         "noArticles": "Aucun article pour le moment.",
         "summary": {
             "label": "En résumé"
+        },
+        "otherArticles": {
+            "sectionLabel": "Autres articles",
+            "title": "Voir aussi"
         }
     },
     "projectPage": {

package-lock.json

@@ -2134,6 +2134,70 @@
         "node": ">=14.0.0"
       }
     },
+    "node_modules/@tailwindcss/oxide-wasm32-wasi/node_modules/@emnapi/core": {
+      "version": "1.8.1",
+      "dev": true,
+      "inBundle": true,
+      "license": "MIT",
+      "optional": true,
+      "dependencies": {
+        "@emnapi/wasi-threads": "1.1.0",
+        "tslib": "^2.4.0"
+      }
+    },
+    "node_modules/@tailwindcss/oxide-wasm32-wasi/node_modules/@emnapi/runtime": {
+      "version": "1.8.1",
+      "dev": true,
+      "inBundle": true,
+      "license": "MIT",
+      "optional": true,
+      "dependencies": {
+        "tslib": "^2.4.0"
+      }
+    },
+    "node_modules/@tailwindcss/oxide-wasm32-wasi/node_modules/@emnapi/wasi-threads": {
+      "version": "1.1.0",
+      "dev": true,
+      "inBundle": true,
+      "license": "MIT",
+      "optional": true,
+      "dependencies": {
+        "tslib": "^2.4.0"
+      }
+    },
+    "node_modules/@tailwindcss/oxide-wasm32-wasi/node_modules/@napi-rs/wasm-runtime": {
+      "version": "1.1.1",
+      "dev": true,
+      "inBundle": true,
+      "license": "MIT",
+      "optional": true,
+      "dependencies": {
+        "@emnapi/core": "^1.7.1",
+        "@emnapi/runtime": "^1.7.1",
+        "@tybys/wasm-util": "^0.10.1"
+      },
+      "funding": {
+        "type": "github",
+        "url": "https://github.com/sponsors/Brooooooklyn"
+      }
+    },
+    "node_modules/@tailwindcss/oxide-wasm32-wasi/node_modules/@tybys/wasm-util": {
+      "version": "0.10.1",
+      "dev": true,
+      "inBundle": true,
+      "license": "MIT",
+      "optional": true,
+      "dependencies": {
+        "tslib": "^2.4.0"
+      }
+    },
+    "node_modules/@tailwindcss/oxide-wasm32-wasi/node_modules/tslib": {
+      "version": "2.8.1",
+      "dev": true,
+      "inBundle": true,
+      "license": "0BSD",
+      "optional": true
+    },
     "node_modules/@tailwindcss/oxide-win32-arm64-msvc": {
       "version": "4.2.2",
       "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-win32-arm64-msvc/-/oxide-win32-arm64-msvc-4.2.2.tgz",