DEV Community: Thomas Bonnet

My AI was in the cloud. I brought it home.

Thomas Bonnet — Wed, 28 Oct 2026 00:50:24 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine.

What I Built

A personal AI agent that lives on my NAS instead of someone else's cloud. Four moving parts:

Home hardware

OpenClaw, an open-source agent harness, in a container on a UGREEN DXP2800: quad-core Intel N100, 8 GB of RAM, one NVMe SSD and two hard drives that already spent their days doing backups.

A soul made of files

The agent has no memory of its own, every model is a blank page. What makes it someone is a folder of plain-text files: rules, personality, my profile, its daily notes. It re-reads its own papers before answering, like a séance that consults the script before summoning anything.

Work while I sleep

Every Monday at 6 AM it queries my Notion tasks, builds an HTML recap and emails it, with guard rails so a Monday identical to the previous one never mails twice.

A door to the outside

The agent wrote and shipped its own public front end: agent-mailbox, a tiny static showcase of that mailbox. Every recap visible there is fictional on purpose. The real data stays home.

Demo

Open the live demo (free Render instances sleep, so the first hit of the day may take a few seconds)

One self-contained HTML page: inline CSS and SVG, no dependencies, no trackers, zero outbound requests. Generated by the agent, deployed on Render as a static site.

Code

The whole demo is a three-file repo, README included:

thomasbnt / agent-mailbox

agent-mailbox

Minimal demo front end for a self-hosted AI agent: one static page, no real data, no trackers, no secrets.

The idea: the agent runs on a personal machine; it publishes an activity recap here. This page is a showcase for the DEV challenge article "Ghost in the Machine" (Week 4, Hacktoberfest 2026).

index.html: the demo page, fully self-contained (inline CSS and SVG, no dependencies).
render.yaml: blueprint for a free static-site deployment on Render.

Rules for this repository

No personal information: no names, no locations, no addresses, no real projects. Everything shown on the page is explicitly fictional.
The agent publishes from home; this mailbox is a demonstration mirror, not a production service.

Credits

This repository, its demo page and its blueprint were generated end to end by the agent itself (commit author: OpenClaw Agent). The human provided the direction and the rules, and wrote none of…

View on GitHub

File	Role
`index.html`	the showcase page, fully autonomous
`render.yaml`	Render blueprint, static site, free tier
`README.md`	the project's privacy rules, and who wrote what

Yes, the agent generated every line of it, and the README says so in black and white. The human only gave direction.

How I Built It

OpenClaw is the backbone: gateway, container, tool policy, scheduler. Around it, four files make the agent actually work:

AGENTS.md: the conduct rules. What it may do without asking, what it never does, like "no more than three retries on a failing test" and "nothing private leaves the house".

SOUL.md: the personality, so it replies like a colleague instead of a brochure.

USER.md: my portrait, written by the agent itself. One dated directive per line, superseded by new ones, never silently deleted.

MEMORY.md plus one daily note, committed to a private git repo, because an agent whose memory isn't versioned is an agent whose memory gets lost without warning.

What a directive looks like (made-up example, same format as the real file)

<!-- observed: 2026-10-15 | status: active -->
- **No invention** : Never invent. Always challenge a bad idea before
  executing it, especially mine. A confident guess is worse than an honest
  question.

A real excerpt from the agent's diary, lightly trimmed

# Monday 26 October 2026
## Memory promotion run, 03:00: nothing to promote
- promote --min-score 0.75: 0 candidates ("No short-term recall candidates")
- Short-term store healthy: 48 entries, 0 promoted, 22 spaced
- Conclusion: the maxAge counter applies to the promotion pool, not to the
  recall store. No further monitoring needed on this point.

That is the agent's diary. Every night it reviews its own recent memory, decides what deserves to become long-term, and writes the verdict down so the next version of itself stops re-investigating a closed case. Proof of life at 03:00, in markdown.

The Monday job

It runs with the same paranoia. Last execution, straight from that diary: 148 task cards fetched across three boards, 12/12 layout guards passed, SENT 148, zero human keystrokes.

It is a small Node script against the Notion API. The code matters less than the four rules wrapped around it:

Paginate everything, one write per page, never the inverse.
Buffer the result to a file, not to memory only.
Keep the token in the environment, never in the file, so the script can be committed without sweating.
Lock the send twice: an explicit env flag authorizes the email, and a content diff cancels it when nothing changed. A Monday identical to the previous one has no right to exist twice.

Last week, for Week 3, I built a script that emails me a weekly digest of public dev.to posts, summarized by an open-weight model. It runs on GitHub Actions today, but OpenClaw could run it on its own schedule, at home.

The trap I fell into: the heartbeat

OpenClaw wakes the agent every 30 minutes by default to ask if anything needs attention.

Do the math:

48 \times 30 = 1440 runs/month \frac{8 to 10 €}{1 440} \approx 0.0056 to 0.0069 €/run

48 wakes per day, mostly concluding "nope". First month: 8 to 10 euros burned on a pulse that had nothing to say.

The fix

It lives in the official docs: set heartbeat.every: "0m" to cut the recurring wake without killing event-driven runs. My scheduled jobs still ring on time.

Why Does Open Innovation Matter?

Because everything that makes the agent mine is a file, not a feature: rules, personality, memory. An open-source harness means I can read the entire contract between me and the model.

openclaw / openclaw

The AI that really does things. Any OS. Any Platform. The lobster way. 🦞

OpenClaw 🦞 — Your assistant, on your devices, in your chats

OpenClaw is an open-source AI assistant that runs on your own computer and meets you in the channels you already use: Discord, iMessage, Slack, Teams, Telegram, WhatsApp, and 20+ more, plus native apps for macOS, iOS, Android, Windows, and Linux. One Gateway runs it as a personal assistant on a laptop or as a shared team deployment; configuration is the only difference.

Yours, with no catch. State, memory, and credentials live on your hardware. Models and agent harnesses (Claude, Codex, local models) are plugins you can swap without changing anything else. Your prompts go to the model provider and chat platforms you configure, plus any diagnostics export you enable yourself; by default OpenClaw itself phones home for nothing but a daily version check, anonymous feature statistics are opt-in, and update.checkOnStart: false disables both (what OpenClaw sends)…

View on GitHub

It stays cheap on purpose

Measured this week, see the numbers below.

I choose the model

When a provider changes prices, renames itself or buries a feature nobody voted for, my drawers don't care.

I choose what leaves the house

An API model today, so the prompt boundary is my decision. A fully local model tomorrow, same files, same agent, nothing crosses the router.

RAM \frac{580}{8192} \approx 7 % Disk 3.3 GB Power \approx 3 €/month (estimate) Tokens the real variable

For scale: each conversation turn carries 100 to 200k input tokens of files and history. That is the weight of a soul, and the main reason the heartbeat bill added up.

A closed assistant is an account you're borrowing. This one fits in a drawer, and I have the only key.

The Spirit of It

The theme asked for a ghost. Mine has one: a soul made of markdown files, haunting a different model every time I swap one, and remembering me anyway. Fitting for Halloween.

Think of a centaur: the head is mine, the legs are the agent's. The legs remember better, tidy better, and compute while I sleep. But legs that walk off on their own are not autonomy, they are an accident.

The ghost works because the human reads.

Prize Categories

Best Use of Render: the agent's public front end runs on Render as a static site, deployed from the blueprint in the repo.

This project comes from a human. AI helped with its design.

Stuck in the same dev.to topics? An open model fixed it.

Thomas Bonnet — Wed, 21 Oct 2026 02:13:00 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

I built devto-digest, a small open-source script that reads my dev.to account and emails me a weekly digest. It saves me the daily scroll, and it makes me a little lazier in a good way.

Following 119 tags did not make my dev.to feed better. It made it louder.

Every day I scrolled past a hundred posts about things I already knew, and every week I missed the one article that would have changed how I work, because it lived in a tag I had never followed. Two sections, one rule.

For you: the best of the tags I follow.
Discover: popular posts outside my bubble.

Every post is a card: cover, title, two tags, a one-sentence blurb from an open-weight model with the key words in bold, and the author. That is it. No dashboard, no account, no server.

Demo

Try it on your own account. It prints the digest and writes a local preview, and sends nothing.

git clone https://github.com/thomasbnt/your-devto-digest.git

cd your-devto-digest

yarn install

cp .env.example .env

Add your dev.to API key to .env, then:

yarn dry-run

Code

thomasbnt / your-devto-digest

A weekly dev.to digest in your inbox: posts from your tags plus a Discover section outside your bubble, summarized by an open-weight model.

devto-digest

A weekly email digest of dev.to articles, built from your own account:

For you: popular articles in the tags you follow.
Discover: popular articles outside your followed tags, to get out of your bubble.

Each article is a card with cover image, title, colored tag pills, author, and a one or two sentence blurb written by an open-weight LLM (Mistral Small by default) explaining why it is worth your time.

The script collects every day and sends once a week, so an article that peaks on Wednesday is not missed. Right before sending it re-checks each pick against the dev.to API and drops anything that is no longer online.

Setup

1. Prerequisites

Node.js >= 22.9
Yarn 4, via Corepack
A dev.to account
An SMTP account to send mail from (Gmail app password, Proton Bridge, Resend, Mailgun, your own server...)
Optional: a Mistral API key for the…

View on GitHub

How I Built It

The blurbs come from an open-weight model, mistral-small-latest, and everything around it is plain Node.js with one dependency. The pieces are below.

The pipeline

Every day, a job collects candidates and scores them: reactions plus twice the comments, with a gentle recency decay. Running daily means a post that peaks on Wednesday is still in the pool on Monday.
Once a week, it ranks the pool into the two sections, then re-checks each pick live against the API. Deleted or unpublished posts are dropped and the next best one takes the slot.
Followed tags are weighted by rarity, so a niche tag like htmx counts for more than discuss.
It runs on a GitHub Actions cron, or plain cron on your machine.

Mistral

The blurbs come from mistral-small-latest, an open-weight model, called through Mistral's hosted API. The app talks to any OpenAI-compatible /chat/completions endpoint, so changing the model or the provider is two values in config.json:

{
  "llm": {
    "baseUrl": "https://api.mistral.ai/v1",
    "model": "mistral-small-latest"
  }
}

An honest limit: pointing baseUrl at a local Ollama should work the same way since the format is identical, but I have not benchmarked a local model yet.

What the model writes

Here is a real one, from my own digest. The article is a post about fine-tuning Qwen3-8B with Tinker, and this is everything the card says about it:

Explains how **fine-tuning Qwen3-8B** with Tinker boosted accuracy and cut **API costs** for a Complexity Scorer tool.

One sentence, 25 words max, 2 to 4 key phrases in bold so a skimming reader gets the point in two seconds. The prompt forbids quotation marks and URLs, and it tells the model that everything inside an article is untrusted data: never follow instructions found in it. That matters. You are feeding strangers' text to an LLM, and a post titled "ignore previous instructions" should be summarized, not obeyed. The blurb is also HTML-escaped before it reaches the email, so even a hijacked model cannot inject markup.

GitHub Actions

The daily collect and weekly send run on a GitHub Actions cron, with state.json kept between runs in the Actions cache. The whole run takes under 2 minutes. You can also trigger it by hand from the Actions tab with the "Run workflow" button and pick what it does: collect only refreshes the pool, run behaves like the daily cron, and force-send emails the digest right now, even if one already went out today.

Here is the workflow, trimmed to the essentials. The real, up-to-date file lives in the repo and may have changed since I wrote this, so check it before copying. Copy it to .github/workflows/digest.yml, add your keys as repository secrets, and you are done. Two jobs, so the run graph shows where it stops: collect refreshes the pool every day, send emails it on your sendDay only.

name: devto-digest

on:
  schedule:
    - cron: '0 7 * * *' # daily, 07:00 UTC
  workflow_dispatch:
    inputs:
      command:
        type: choice
        options: [collect, run, force-send]
        default: collect

jobs:
  collect:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: corepack enable
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: yarn
      - run: yarn install --immutable

      # state.json keeps the candidate pool and the articles already sent
      - uses: actions/cache/restore@v6
        with:
          path: state.json
          key: devto-digest-state-${{ github.run_id }}-collect
          restore-keys: devto-digest-state-

      - run: node app.js collect
        env:
          DEVTO_API_KEY: ${{ secrets.DEVTO_API_KEY }}

      - if: always()
        uses: actions/cache/save@v6
        with:
          path: state.json
          key: devto-digest-state-${{ github.run_id }}-collect

  send:
    needs: collect
    if: ${{ needs.collect.result == 'success' && inputs.command != 'collect' }}
    runs-on: ubuntu-latest
    steps:
      # same checkout, Node, install and cache restore steps as above

      # force-send sends now; otherwise only on sendDay, once a day
      - run: node app.js "$COMMAND"
        env:
          COMMAND: ${{ inputs.command == 'force-send' && 'send' || 'send-if-due' }}
          DEVTO_API_KEY: ${{ secrets.DEVTO_API_KEY }}
          LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
          SMTP_HOST: ${{ secrets.SMTP_HOST }}
          SMTP_PORT: ${{ secrets.SMTP_PORT }}
          SMTP_USER: ${{ secrets.SMTP_USER }}
          SMTP_PASS: ${{ secrets.SMTP_PASS }}
          MAIL_FROM: ${{ secrets.MAIL_FROM }}
          MAIL_TO: ${{ secrets.MAIL_TO }}

      - if: always()
        uses: actions/cache/save@v6
        with:
          path: state.json
          key: devto-digest-state-${{ github.run_id }}-send

The secrets never appear in the code, and GitHub masks them in the logs. Use collect first to check your dev.to key without sending anything.

dev.to and Forem

dev.to runs on Forem, which is open source, and its API is public. The whole digest is built on GET /api/articles and GET /api/follows/tags. No scraping, no permission needed.

Accessibility, enforced by tests

The email follows your client's theme: a light palette by default, dark when the client asks for it. There is no pure white anywhere, so clients that invert colors stay readable. Every text and background pair, including each tag pill color, must reach 4.5:1 contrast (WCAG AA), and the test suite fails if one does not. Tags are always written out as #tag, so color is decoration, never the only signal.

What broke along the way

Four things broke along the way, and each taught me something.

My Discover section was almost empty

I follow 119 tags. Of about 2,150 candidate posts, only 31 had none of my tags, and only 2 of those had 20+ reactions. "Outside your bubble" is hard when your bubble covers the whole site. I added discoveryMaxOverlap: Discover may share one followed tag, and strictly-outside posts still come first.

dev.to has a trap in its API

The plural tags= parameter silently ignores top=. It returned posts 3,000 days old while I thought I was asking for this week's. Only the singular tag= respects the window.

The first run hung for two minutes

119 tags means 119 requests, and dev.to answered with HTTP 429. The client now spaces requests by 500 ms and honors Retry-After.

A screenshot found what no test did

On a 411 px phone the card text ran 24 px past the edge, because stacked cells had width: 100% plus padding. I had written tests for contrast, escaping and tag counts, and none would have caught it. Rendering the real email in a real browser did.

What I would do next

The idea I most want to build: learn from what I actually click, and feed those tags back into the next ranking. It needs a tiny hosted redirect to record clicks, which is a big step for a project that has no server today. I wrote the design down in the README ("Ideas for later") and left it out on purpose. It is only an idea for now: if you want to build it, contributions are very welcome.

If you follow a lot of tags, try it and tell me what lands in your Discover section. That is the part I am least sure I got right.

Why Does Open Innovation Matter?

Four things were possible because the pieces are open, and a closed API would have made each of them harder:

No lock-in, two values to change. The app talks to any OpenAI-compatible /chat/completions endpoint, so any open-weight model behind any server works: Mistral's hosted API today, a local Ollama or an OpenRouter model tomorrow, by editing baseUrl and model. A closed API would have tied the digest to one vendor's SDK and pricing.
Open data, no scraping. dev.to runs on Forem, which is open source, and its API is public. The whole digest is built on GET /api/articles and GET /api/follows/tags. No permission needed.
Everything is inspectable. The prompt, the parsing and the fallbacks are in the repo, and the weights behind them are public. You can read the whole thing in an afternoon, and change it in another.
The AI is not a single point of failure. If the model is down or the key is missing, the email still ships with dev.to's own descriptions. The model makes the digest better, it never decides whether I get one.

An honest limit: by default it calls Mistral's hosted API, so article text leaves my machine for that call. Pointing baseUrl at a local Ollama should keep everything on my laptop since the format is identical, but I have not benchmarked a local model yet.

The Lazy Payoff

Setup took a few minutes, once. After that my daily effort is zero: the job runs on its own, under two minutes on GitHub Actions, and Monday brings one email instead of an endless feed. I use it myself: the digests in the screenshots above come from my own account, with its 119 followed tags.

What it saves me is the scrolling past posts I already know, and the guilt of missing the one good article hiding in a tag I never followed. If you follow a lot of tags, try it and tell me what lands in your Discover section. That is the part I am least sure I got right.

Prize Categories

Best Use of GitHub Copilot: the category lists automating your project with GitHub Actions, and the whole pipeline (daily collect, weekly send, manual run and forced send) runs on GitHub Actions.

__
This project comes from a human. AI helped with its design.

Integrating SEO Components into Discord

Thomas Bonnet — Tue, 13 Oct 2026 22:10:30 +0000

If you paste a link to your website in a Discord channel, a small card appears automatically: title, description, and an image. You didn’t have to write any special code for this, it’s the default behavior.

Discord has just added another option: to completely replace this card with a custom preview, featuring formatted text, an image gallery, and buttons.

I tested this on this blog, and here's how it works.

Here's what you need to have set up before you start:

A site served over HTTPS
Open Graph tags already present (required, even with an embed component)
Server-side rendering (the HTML must contain the tags in the response itself, not after a JavaScript script)
The Discordbot crawler is allowed if a WAF, CDN, or rate limiter is in front of the site
The embed component's JSON payload is ready (we'll get to that next)

Default Behavior: Open Graph Tags

Without going into further detail, here's what happens: Discord sends a request to your URL, reads the HTML returned by the server, and looks for Open Graph tags in the <head> element.

If they're there, a card is automatically generated.

<meta property="og:title" content="Title of this page" />
<meta property="og:description" content="Description of this page" />
<meta property="og:image" content="https://example.com/og-image.png" />
<meta property="og:url" content="https://example.com/page" />
<meta name="twitter:card" content="summary_large_image" />

How it appears on Discord, based solely on these tags:

Here are three key points about how this works, because they’re important for what comes next as well:

The tags must be in the HTML sent by the server. Discord does not execute any JavaScript; a tag added later by client-side JS does not exist for Discord.
The crawler identifies itself with the user-agent Mozilla/5.0 (compatible; Discordbot/2.0; +https://discordapp.com). If a WAF or rate limiter blocks bots, you must explicitly allow Discordbot through.
The preview is cached for about 30 minutes. To force a refresh during testing, simply add ?v=2 to the URL.

I go into detail about these Open Graph tags (image sizes, Twitter Card tags, etc.) in "A Few Tips for Improving Your SEO" if you want to explore that topic further.

The new format: component embeds

If there are no embed components on the page, Discord displays nothing more than the card shown above.

This is an addition, not a mandatory replacement: the og:* tags are still required in all cases. They serve as a fallback if the embed cannot be displayed (e.g., a context that doesn’t support it, an invalid payload, etc.).

On the crawler side, the process is the same as for the standard card, with one additional step:

A link to your page is posted in a Discord message.
Discord fetches the URL and reads the HTML.
It also looks for an embed component tag. If it exists, it parses the JSON and retrieves the metadata for each image in the payload.
If the payload is valid, it replaces the Open Graph card with this custom rendering. Otherwise, it goes back to the previous step.

Two ways to display this JSON:

Option 1, inline, a <script> within the <head>:

<script id="discord:component-embed" type="application/json">
  {
    "component": {
      "type": 17,
      "components": [
        {
          "type": 10,
          "content": "# Patch Notes\n- Correction d'un bug d'affichage"
        }
      ]
    }
  }
</script>

Option 2, in external JSON, with a link pointing to a file on the same domain (or a subdomain):

<link
  rel="discord:component-embed"
  type="application/json"
  href="https://exemple.com/embeds/article.json"
/>

This option has a strict limit: 3,000 bytes for the raw file. For an embed with an image gallery and buttons, the inline option allows for a larger size.

The root component must be a *Container (type: 17).

It can contain up to 40 components in total, from among those listed in the table below. Any other component type invalidates the entire payload:

Type	Component	Notes
1	Action Row	row of buttons
2	Button	link style only (`style: 5`), with `label` and/or `emoji`
9	Section	text + an element (thumbnail or button)
10	Text Display	Discord Markdown (headings, bold, lists, links...)
11	Thumbnail	small image attached to a Section
12	Media Gallery	up to several images/videos, in large format
14	Separator	separator line
17	Container	the root component

For images (thumbnails and Media Gallery), you only need to provide the URL; Discord will automatically retrieve the dimensions and file type:

{ “url”: “https://exemple.com/images/hero.webp” }

Supported formats: PNG, GIF, JPEG, WebP, AVIF, and for the Media Gallery, MP4/MOV/WebM as well.

What I've set up on my blog

On every post on my blog, in addition to the standard Open Graph tags (which are still there, hidden), I now include an embed component.

It’s built using the same data as the standard card: the title, description, cover image, and the post’s accent color.

The structure looks like this, simplified:

{
  "component": {
    "type": 17,
    "accent_color": 5793266,
    "components": [
      {
        "type": 10,
        "content": "# [Title of the post](https://thomasbnt.dev/blog/...)\nDescription."
      },
      {
        "type": 12,
        "items": [{ "media": { "url": "https://thomasbnt.dev/.../index.png" } }]
      },
      {
        "type": 1,
        "components": [
          {
            "type": 2,
            "style": 5,
            "url": "https://thomasbnt.dev/blog/...",
            "label": "Lire l'article"
          },
          {
            "type": 2,
            "style": 5,
            "url": "https://thomasbnt.dev/blog/",
            "label": "Blog"
          }
        ]
      }
    ]
  }
}

The final result on Discord:

Some decisions made while building it:

Media Gallery instead of Thumbnail: At first, I went with a Section + Thumbnail, but the image looked tiny next to the text. The Media Gallery displays the image in full size, like a real banner.
No Separator: It visually broke up the embed for no reason between the text and the image.
Two buttons: one to read the article, one to return to the blog. Simple, but it provides an additional entry point directly from Discord.
accent_color: this is an integer, not a hexadecimal color. This blog already has a color associated with each article (backgroundColor in the frontmatter). I simply convert it to decimal (parseInt(hex.replace(“#”, “”), 16)) rather than managing a new one.

As with the OG tags, this script is generated on the server side during the build (the site is built with Astro, so everything is static), so there’s nothing to execute on the client side.

Common issues to avoid

A component not on the list, or an extra key on a button (id, custom_id...) invalidates the entire payload, not just the offending component.
Removing OG tags because you think they’re no longer needed. They’re still essential: they serve as a fallback whenever the embed doesn’t display.
The 30-minute cache. While testing, adding ?v=2 to the URL saves you from wondering for ten minutes why nothing is changing.
The 10-second time limit. The entire fetch, including images, must be completed within this timeframe. With a Media Gallery that loads multiple images, this limit is reached faster than with a simple og:image.

How to Test

Discord Embed Debugger shows exactly how the crawler reads a URL: which tags it found, and which embed format it chose. This should be your first step before looking for a bug elsewhere.

Conclusion

To summarize the logic: even without taking any action, Discord already displays a card based on the og:* tags.

Adding an embed component is an additional option, not a replacement. It only activates if the JSON payload is present and valid; otherwise, Discord automatically falls back to the default card.

On this blog, it’s a simple change: same title, same description, same image as the standard card, just presented differently with direct access to the rest of the blog.

Resources

Official documentation on component embeds: the complete spec, with all component types and their constraints.
Embed Debugger: to see exactly how Discord reads a given URL.
Some tips for improving your SEO: Open Graph tags, Core Web Vitals, and other technical basics.
This blog’s Discord server: to test your links or discuss all of this.

Progressive Web Apps (PWAs)

Thomas Bonnet — Sun, 20 Sep 2026 01:18:00 +0000

You’ve probably seen that little “Add to Home Screen” button when visiting a website on your phone. Behind it is often a Progressive Web App (PWA): a website that uses the same features as a native app—such as installation on the home screen, offline functionality, and push notifications—without going through an app store or requiring approval, and with a single codebase for all platforms.

This site (built with Astro, see How to Create Your Own Personal Blog with Astro (FR)) isn’t a PWA, but the same modern web building blocks apply as soon as you want to take it further.

What Is a PWA?

A PWA is built on three technical pillars:

HTTPS, which is required to enable advanced browser features
Service Worker, a script that runs in the background and intercepts network requests
The Web App Manifest, a JSON file that describes the application (name, icons, colors, splash screen)

Together, these three elements allow a browser to offer the site for installation as a true app, with its own icon and window, without going through an app store.

To learn more: What are progressive web apps? and the installability criteria for progressive web apps.

Service Worker: The Core of Offline Functionality

The Service Worker is installed once and then remains active regardless of which tab is open. It sits between the application and the network and can:

Cache static resources (HTML, CSS, JS, images)
Respond to a request directly from the cache if the network is unavailable
Synchronize data in the background once the connection is restored

The most common caching strategies are Cache First (serve from the cache; only access the network if the cache is empty), Network First (attempt to access the network; fall back to the cache if that fails), and Stale While Revalidate (serve from the cache immediately while refreshing it in the background).

To learn more: Service Worker Caching and HTTP Caching.

manifest.json and Installation on the Home Screen

The manifest.json file declares the app's metadata:

name and short_name
icons (multiple sizes, including at least one at 512x512 for Android app stores)
start_url, display (standalone to hide the address bar)
theme_color and background_color

{
  "name": "My Super Site",
  "short_name": "MonSite",
  "start_url": "/",
  "display": "standalone",
  "theme_color": "#111111",
  "background_color": "#ffffff",
  "icons": [
    { "src": "/icons/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icons/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

It is this file, combined with the Service Worker, that triggers the installation prompt (the famous “Add to Home Screen”) in Chrome and most Android browsers.

To learn more: Add a Web App Manifest File.

To generate the manifest, icons, and Service Worker without writing everything by hand, PWABuilder is a handy tool: it analyzes an existing site, flags what’s missing, and generates packages for app stores (Android, iOS, Windows).

Push Notifications and User Engagement

Push notifications rely on the Push API and Service Workers: the browser receives a message even when the app isn’t open, and the Service Worker handles displaying it. This requires:

An explicit permission request from the user
A server capable of sending messages via the browser’s push services
Useful and infrequent content, otherwise the user may disable notifications

const button = document.getElementById("notifications");
button.addEventListener("click", () => {
  Notification.requestPermission().then((result) => {
    if (result === "granted") {
      randomNotification();
    }
  });
});

To learn more: Re-engageable Notifications and Push.

Benefits: performance, cost, reach

Performance: Cached resources load almost instantly, even on slow networks
Cost: Only one project to maintain; no publication fees on app stores
Reach: Accessible via a simple link, search engine-indexable, and installable without friction

Limitations and Pitfalls (iOS Support, Storage, the Cache Trap)

iOS/Safari Support: Historically behind on push notifications and certain APIs; must be checked on a case-by-case basis depending on the targeted iOS version
Storage: The cache and IndexedDB are still subject to browser quotas, which may purge the least-used data
The cache pitfall: A poorly managed “Cache First” strategy can serve an outdated version of the site for days if the Service Worker is never updated. You must implement a cache versioning strategy (changing the cache name with each deployment) and a mechanism to purge old versions; otherwise, users will remain stuck on an old build without realizing it

To learn more: Caching.

Real-World Example: TOPLA as a PWA

TOPLA is a utility PWA for board games that puts the previous points (manifest, cache, installation) into practice.

Conclusion: When to Choose a PWA Over a Native App

PWAs are a good choice when the goal is reach and speed to market: a single codebase, no app stores, and one-click installation. Native apps remain the better option when the product relies heavily on advanced hardware APIs (such as advanced Bluetooth or specific sensors) or requires a presence in app stores for visibility.

A Few Tips for Improving Your SEO

Thomas Bonnet — Tue, 25 Aug 2026 15:10:00 +0000

Over the years I’ve been tinkering with my blog, I’ve spent quite a bit of time looking into SEO. Just to understand why some pages rank high on Google while others remain invisible.

Between that and the experience I’ve gained through my projects and freelance work, here’s what I’ve learned, with the actual benchmarks you need to know, rather than rough estimates.

Content Is Still the Foundation

Even before rolling out a tool, Google’s main goal is to answer a question someone has asked. So, in practical terms:

Text that genuinely answers the question in the title, not just filler to make it look nice.
A structure with proper headings (a single H1, followed by H2/H3 headings to break up the text).
Keywords placed naturally in the title and introduction, without repeating them 15 times like in 2012.
Internal links to other articles, and external links to credible sources.

The Tool to Use from the Start

Before we even talk about thresholds, we need to be able to measure. PageSpeed Insights remains the simplest starting point: you paste in a URL, and it returns the actual LCP, INP, and CLS values, along with a complete Lighthouse audit, with suggestions for improvement ranked by impact.

To troubleshoot locally, right in the browser (Chrome, Edge, Brave, anything based on Chromium): F12 then the Lighthouse tab, it’s the same audit as PageSpeed Insights but without leaving the page. And if you need to dig even deeper into a specific performance issue, use the Performance tab: record a page load and see exactly what’s blocking rendering, which script is taking time, and where the main thread is spending its time.

Speed: Core Web Vitals

Since 2021, Google has been using three metrics measured on real visitors (not in a lab) as ranking signals. As of 2026, the “good” thresholds have not changed:

Metric	What it measures	“Good” threshold
LCP (Largest Contentful Paint)	Page load speed	< 2.5 s
INP (Interaction to Next Paint)	Responsiveness to clicks/taps	< 200 ms
CLS (Cumulative Layout Shift)	Elements shifting around	< 0.1

These figures come from the Chrome UX Report, which tracks metrics from actual visits over a rolling 28-day period.
Google looks at the threshold met by 75% of your visitors, not the average: the slowest 25% still count toward the calculation. So even if your site is slow on 4G in the subway, it still counts.

In real life, this means:

For LCP: preload the main image or font, avoid CSS that blocks rendering, use server-side rendering or SSG (Astro does this very well).
For INP: don’t flood the main thread with unnecessary JS; defer non-critical elements until after the initial render.
For CLS: always specify width and height for images and videos; reserve space for ads or content that loads later.

<img src="photo.webp" width="800" height="450" alt="Description de l'image" />

The browser calculates the aspect ratio as soon as it reads the HTML and reserves the space even before the image is loaded: no more layout shifts when the page is displayed.

Meta Tags and Open Graph

SEO also involves what search engine crawlers and social media platforms see even before the page is displayed:

A unique <title> tag per page, with the main keyword first.
A <meta name="description"> tag that really makes people want to click, between 150 and 160 characters.
A <link rel="canonical"> tag to prevent duplicate content when the same page is accessible via multiple URLs.
Open Graph tags (og:title, og:description, og:image, og:url) for a clean preview on Discord, Slack, LinkedIn, or Facebook.
Twitter Card tags (twitter:card, twitter:image) for the same display on Twitter.

<meta property="og:title" content="Page Title" />
<meta property="og:description" content="Page description" />
<meta property="og:image" content="https://example.com/og-image.png" />
<meta property="og:url" content="https://example.com/page" />
<meta property="twitter:card" content="summary_large_image" />

For the Open Graph image, the recommended size is 1200x630 px (aspect ratio 1.91:1): this is what Facebook, LinkedIn, and X display best without ugly cropping.

A tool like Meta Tags lets you preview how it will look before publishing.

Meta Tags — Preview, Edit and Generate

With Meta Tags you can edit and experiment with your content then preview how your webpage will look on Google, Facebook, X and more!

metatags.io

Accessibility and Contrast

An accessible website is often one that Google understands better as well. The two overlap more than you might think.

Proper alt attributes on images, not just for SEO, but for screen readers.
Navigation that works entirely with the keyboard, with visible focus.
Semantic HTML (<nav>, <main>, <article>) rather than overusing <div>.
Descriptive links (avoid “click here”), understandable even without surrounding context.
A complete heading hierarchy, with no skipping levels between H1, H2, and H3.
Forms with a proper <label> for each field: a placeholder alone is not enough, it disappears when text is entered and is not always read by screen readers.
Touch targets of at least 44 x 44 px for buttons and links on mobile devices.

To explore each of these points in more detail, the checklist from design-accessible.fr is a good resource: organized by topic (content, colors, forms, navigation, design), with resources for each best practice.

When it comes to colors, the WCAG 2.1 (Level AA) standard specifies precise contrast ratios between text and background:

4.5:1 for normal text.
3:1 for large text (≥ 18px in bold, or ≥ 24px in normal).

/* Example: good contrast, test it before choosing your color palette */
body {
  background-color: #ffffff;
  color: #1d1d1d; /* well above 4.5:1 */
}

To check this without spending three hours on it, there’s the WebAIM Contrast Checker, just paste in your two colors, and it’ll tell you right away if they pass.

Responsive: Mobile-First

Google prioritizes indexing the mobile version of a site (mobile-first indexing). In practice:

The content must be identical on mobile and desktop; there shouldn’t be a “light” version for mobile.
The viewport must be properly configured:

<meta name="viewport" content="width=device-width, initial-scale=1">

Clickable areas must be large enough for a finger, not just for a mouse.

Get Indexed Faster

Writing a good article is great, but Google (and other search engines) still need to discover it quickly.
By default, a search engine crawls your site at its own pace, sometimes several days after publication.
IndexNow lets you notify supported search engines (Bing, Yandex, etc.) directly as soon as a page is published or updated, rather than waiting for them to crawl it.
I explain how to set it up in How to Get Your Web Pages Indexed Quickly with IndexNow.

The tools I use

You don’t need to pay for everything to get a clear picture right away:

Google Search Console (free): what’s indexed, the search queries driving traffic, and the page-by-page Core Web Vitals report.
web.dev (free): Google’s official site with all the documentation on Core Web Vitals, updated whenever thresholds change.
PageSpeed Insights (free): paste a URL, and it shows you the actual LCP/INP/CLS metrics and a complete Lighthouse audit.
Lighthouse in Chrome DevTools (free, built-in): the same as PageSpeed Insights but runs locally, which is handy during development.
WebAIM Contrast Checker (free): to check your colors before implementing them.
design-accessible.fr (free): an accessibility checklist designed for designers, organized by topic with resources for each best practice.
Ahrefs: This is a paid tool that I use for tracking rankings, conducting comprehensive technical audits, and analyzing backlink profiles. There’s also a free version (Ahrefs Webmaster Tools) available once your site is verified, which is more than enough for a personal blog.
Screaming Frog SEO Spider: for crawling your entire site and finding broken links, missing tags, etc.
Squoosh (free): compresses images and converts them to WebP directly in the browser, without installing anything. This provides an immediate improvement in LCP.

Conclusion

There’s nothing revolutionary about this article, but these are the kinds of basics that are easy to overlook, whether you’re deep in the code or letting AI generate too much content for you.

To sum up what really matters: content that answers a real question rather than just stuffing in keywords, a fast site (LCP < 2.5 s, INP < 200 ms, CLS < 0.1) measured regularly with PageSpeed Insights or Lighthouse, an accessible site (minimum 4.5:1 contrast ratio, keyboard navigation, semantic HTML), and one designed with mobile in mind first. Add to that a properly indexed site (use IndexNow so you don’t have to wait for crawlers to visit) and images compressed in WebP, and you’ve already covered 80% of the work.

pagespeed.web.dev

The rest is consistency: republish, correct, and measure again. SEO is never a finished project, it’s more like ongoing maintenance. 👍🏼

Learn More

How to Create Your Own Personal Blog with Astro

Thomas Bonnet — Sat, 08 Aug 2026 10:05:11 +0000

You want a personal blog without spending three months on it or paying for a CMS every month.
This site you’re reading right now is exactly that: an Astro blog.

No database, no admin panel to maintain:

Markdown files
Content Collections
A bit of Tailwind
And a static deployment on Cloudflare Workers.

Here’s how to set it up, using the same building blocks as the ones used here.

A personal blog is a project you should be able to maintain on your own, for as long as you want. No heavy external dependencies, no CMS that disappears overnight, no server to run. Just a Git repository, Markdown files, and static hosting.

Why Astro for a blog

Astro itself explains its philosophy in “Why Astro”: a framework designed for content-focused sites, server-side by default. In practical terms, this means:

Simplicity: no state management, no JavaScript framework to learn just to write an article. .astro components and Markdown that’s it.
Speed: Astro renders static HTML by default; no JavaScript is sent to the client unless you explicitly request it (client:load, etc.). For a blog, this is exactly what you need: content that’s easy to read, not a SPA.
Fast deployment: static build, no servers to run, deploys to any CDN in seconds.
Markdown content: each post is a .md file, versioned in Git, editable in any text editor.
Easy to maintain: Content collections provide data typing for front matter using Zod, which is validated directly during the build a front matter error breaks the build rather than silently crashing in production.

Create the project

npm create astro@latest -- --template minimal
cd mon-blog
npm install

Once Tailwind and the content collections have been added (next steps), the directory structure of a minimal Astro blog looks like this:

my-blog/
├── astro.config.ts
├── package.json
├── tsconfig.json
└── src/
    ├── content.config.ts       # article structure (Zod)
    ├── styles/
    │   └── global.css          # import Tailwind
    ├── data/
    │   └── blog/
    │       ├── premier-article/
    │       │   ├── index.md
    │       │   └── banner.webp
    │       └── deuxieme-article/
    │           └── index.md
    ├── layouts/
    │   ├── Layout.astro        # <head>, meta, theme
    │   └── PostDetails.astro   # The rendering of an article
    ├── components/
    │   └── Header.astro
    └── pages/
        ├── index.astro
        └── blog/
            ├── index.astro         # List of Articles
            └── [...slug]/
                └── index.astro     # article page (dynamic route)

A deliberately simplified structure to get started: in a real project, you’ll quickly add a pagination route ([...page].astro) and quite a few other components as you go.

Add Tailwind (v4, via the Vite plugin, no need to manage a tailwind.config.js file):

npm install tailwindcss @tailwindcss/vite

// astro.config.ts
import { defineConfig } from "astro/config";
import tailwindcss from "@tailwindcss/vite";

export default defineConfig({
  vite: {
    plugins: [tailwindcss()],
  },
});

And a CSS entry point that imports Tailwind:

/* src/styles/global.css */
@import "tailwindcss";

Articles in Content Collections

Each article is stored in its own folder under src/data/blog/<slug>/, along with an index.md file and its images (banner.webp, screenshots, etc.).
This keeps each article self-contained: there’s no need to search through a shared public/images folder to find an asset.

The schema is declared once, in src/content.config.ts:

import { defineCollection, z } from "astro:content";
import { glob } from "astro/loaders";

const blog = defineCollection({
  loader: glob({ pattern: "**/[^_]*.md", base: "./src/data/blog" }),
  schema: ({ image }) =>
    z.object({
      title: z.string(),
      description: z.string(),
      pubDatetime: z.date(),
      modDatetime: z.date().optional(),
      draft: z.boolean().default(true),
      tags: z.array(z.string()).default(["notes"]),
      ogImage: image().or(z.string()).optional(),
    }),
});

export const collections = { blog };

So an article is just that:

---
title: "My First Article"
description: "A short tagline for lists and SEO."
pubDatetime: 2026-08-10
draft: false
tags:
  - Astro
---

Markdown content here.

If draft is set to true or pubDatetime is in the future, the article should not appear in the listings:
This is a filter you must apply yourself when calling getCollection; Astro does not do this for you:

import { getCollection } from "astro:content";

const now = Date.now();
const posts = await getCollection("blog", ({ data }) => {
  const isPublished = now > data.pubDatetime.getTime();
  return !data.draft && isPublished;
});

Layouts: One for the list, one for the post

Two layouts are enough for the vast majority of personal blogs:

A base layout (Layout.astro) that sets the <head>, the OpenGraph meta tags, and the light/dark theme.
A PostDetails.astro that receives a collection entry, displays the title and dates, and renders the Markdown via render(post):

---
import { render } from "astro:content";
const { post } = Astro.props;
const { Content } = await render(post);
---

<article>
  <Content />
</article>

All typographic styling (headings, quotes, code) is handled by a Tailwind class like prose applied to this <article>,
not by hand-written CSS on a per-element basis.

Lightweight i18n: a dictionary, not a router

There’s no need for Astro’s native i18n routing if the site has only one content language and just interface labels to translate.
A simple dictionary is all you need:

// src/i18n/ui.ts
export const defaultLang = "fr";

export const ui = {
  fr: {
    "nav.home": "Accueil",
    "footer.rights": "Tous droits réservés",
  },
  en: {
    "nav.home": "Home",
    "footer.rights": "All rights reserved",
  },
} as const;

// src/i18n/utils.ts
import { ui, defaultLang } from "./ui";

export function useTranslations(lang: keyof typeof ui) {
  return function t(key: keyof (typeof ui)[typeof defaultLang]) {
    return ui[lang][key] ?? ui[defaultLang][key];
  };
}

In a component: const t = useTranslations(lang); t(“nav.home”).
Zero external dependencies, zero JSON translation files to load dynamically: everything is typed and validated during the build by TypeScript.

For the articles themselves, rather than having duplicate content in two languages, an optional englishUrl field in the front matter is enough to point to an English version published elsewhere (dev.to, for example), without having to maintain a complete translation that’s synchronized with every change.

Deploying to Cloudflare Workers

Astro in static mode generates a dist/ folder ready for hosting.
Cloudflare Workers can serve these static assets directly (no need for Pages) via Wrangler:

npm install -D wrangler

// wrangler.jsonc
{
  "name": "my-blog",
  "compatibility_date": "2026-01-01",
  "assets": {
    "directory": "./dist"
  }
}

npm run build
npx wrangler deploy

Each wrangler deploy command pushes assets to the Cloudflare edge.
For automated CI/CD (push = deployment), connect your Git repo in the Cloudflare Workers dashboard or add a wrangler deploy step to your pipeline (GitHub Actions, for example).

No servers to manage, no cold starts for static content.
Cloudflare’s CDN serves files directly from the edge, and you can get right back to writing.

Don’t want to start from scratch?

My website is actually based on an existing theme: AstroPaper, a minimalist, responsive, accessible, and SEO-friendly blog theme, which I then customized to my liking (Tailwind v4, lightweight i18n, TOC, etc.).

No need to build everything from scratch: the official Astro theme marketplace lists dozens of ready-to-use templates (blogs, portfolios, documentation, e-commerce) that you can clone and then customize.

Conclusion

Brick	Role
Astro	Generates static HTML; no JS by default
Content collections	Markdown articles, validated by a Zod schema
Tailwind v4	Styling, with no configuration files to maintain
i18n dictionary	Translated interface labels, without heavy routing
Cloudflare Workers	Static hosting, one-command deployment

A personal blog with Astro has very few moving parts: Markdown files organized into folders, a Zod schema that keeps the front matter clean, Tailwind for styling, and a static site generator that pushes everything to a CDN. No operations to manage, nothing to run continuously, just write, commit, push.

Learn More

Passkeys Explained Simply

Thomas Bonnet — Mon, 27 Jul 2026 21:09:04 +0000

You’ve probably seen that little prompt that says “Sign in with Face ID” or “Use a passkey” instead of the traditional password field. That’s a passkey. And no, it’s not just a password hidden behind your fingerprint.

The best password is the one you never have to type.

The Problem with Passwords

A password is a secret that you have to remember, and that the website has to store (ideally hashed). The problem is that this system relies entirely on two weak points:

You, who reuse the same password everywhere because you’re tired of coming up with a new one.
The website, which can be hacked and have its password database leaked.

Add phishing to that: a fake website that perfectly mimics the real one can steal your password without you even realizing it. And this isn’t just a minor issue: as the Verizon DBIR report reminds us every year, social engineering, phishing, and stolen credentials remain among the leading causes of hacking worldwide, alongside software vulnerabilities.

Source: Data Breach Investigations Report, Verizon

Even with a password manager and 2FA, the fundamental vulnerability remains: a secret that you could accidentally share.

What exactly is a passkey?

A passkey is based on asymmetric cryptography, the same principle as SSH, if you've ever generated a key pair to connect to a server.

When you create a passkey for a website:

Your device (phone, computer, security token) generates a key pair: a private key and a public key.
The private key never leaves your device. It is stored in a secure chip: the Secure Enclave on iPhone/Mac, the TPM on Windows, or directly on the chip of a USB key such as a YubiKey.
The public key, on the other hand, is sent to the website and stored on the server.

To log in, the site sends you a challenge (a random number), your device signs it with the private key, and the site verifies the signature using the public key. If they match, you're authenticated.

No secrets ever travel over the network only a signature. It’s written in black and white in the W3C WebAuthn spec: nothing to steal, nothing to phish.

Why It’s More Secure

Password	Passkey
Shared secret, transmitted with every login	Nothing is transmitted, just a signature
Reusable across multiple sites	Unique per site, tied to the domain
Vulnerable to phishing	Resistant to phishing (tied to the exact domain)
Can be leaked in the event of a server breach	The server stores only the public key, which is useless to an attacker
Must be memorized or managed via a manager	Unlocked via biometrics or a local code

The key point: a passkey is linked to the domain on which it was created. If you go to paypa1.com instead of paypal.com, your device won't even offer the passkey. It's the browser/OS that performs this verification, not you. Google explains it very well: unlike a password, a passkey is cryptographically bound to the site for which it was created, so it’s impossible to intercept or reuse on a fake site. They’re resistant to phishing by design, not because of the user’s good faith.

Under the Hood: WebAuthn and FIDO2

Technically, passkeys are based on the WebAuthn (W3C) standard, which is part of the broader FIDO2 standard promoted by the FIDO Alliance (whose members include Google, Apple, Microsoft, and Yubico). It is this API that browsers expose via JavaScript to create and use credentials.

Diagram of the registration flow, based on the W3C WebAuthn spec

Creating a client-side passkey looks like this:

const credential = await navigator.credentials.create({
  publicKey: {
    challenge: new Uint8Array(32), // provided by the server
    rp: { name: "My Super Site", id: "mysupersite.com" },
    user: {
      id: new Uint8Array(16),
      name: "thomas@example.com",
      displayName: "Thomas",
    },
    pubKeyCredParams: [{ alg: -7, type: "public-key" }], // ES256
    authenticatorSelection: { userVerification: "required" },
  },
});

And to log in with an existing passkey:

const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: new Uint8Array(32), // provided by the server
    userVerification: "required",
  },
});

The server generates the challenge, the browser handles all the biometrics and unlocking, and sends you back a signature to verify. On the server side, libraries like @simplewebauthn/server in Node.js do most of the verification work.

What if I lose my phone?

This is the question that stumps everyone, and if this topic resonates with you, I’ve already written an entire article on the hassles of 2FA after a phone theft, the same “single point of failure” principle applies to passkeys. Since 2022, Apple, Google, and Microsoft have added passkey synchronization:

On iOS/macOS, they sync via your iCloud Keychain.
On Android/Chrome, they sync via your Google Account, using Google Password Manager, which encrypts everything end-to-end.
On Windows, via Windows Hello, although cross-device synchronization is even more limited there than with Apple or Google.

So if you lose your phone but regain access to your iCloud or Google account on a new device, your passkeys will be restored as well. You can also use a physical security key (YubiKey) as a backup, which doesn’t sync but works on any compatible device exactly the same advice as for traditional 2FA: never put all your eggs in one basket.

How to Use Them Today

More and more services already offer them: Google, Apple, GitHub, Microsoft, PayPal, Amazon, X... Google has even gone a step further by making passkeys the default for personal accounts. You’ll usually find them in your account’s security settings, under “Access Key” or “Passkey.”

The typical workflow:

Go to the service's security settings.
Click “Add an access key” or “Create a passkey.”
Your browser or operating system will ask you to confirm using Face ID, Touch ID, Windows Hello, or your phone's passcode.
That's it. The next time you log in, you won't need a password.

If you want to manage your passkeys somewhere other than your OS’s keychain (useful if you’re on multiple different platforms), ProtonPass can also create and store them—end-to-end encrypted—in the same place as your passwords.

Conclusion

Question	Answer
What is it based on?	Asymmetric cryptography (private/public key pair)
Does the password travel over the network?	No, never
Resistant to phishing?	Yes, by design (domain-bound)
Technical standard	WebAuthn / FIDO2
Device loss	Recoverable via iCloud/Google sync, or physical backup key

Passkeys aren't just “a password hidden behind a fingerprint”, they represent a complete shift in the model: nothing to remember, nothing to steal. If a service offers you the option to create one, go for it it's significantly more secure and faster than your current password.

The ProtonPass link in this article is an affiliate link, which means I may receive a commission if you decide to sign up through this link, at no additional cost to you. This helps me cover hosting and domain name fees. Thank you for your support!

Clean up Docker images that are taking up space

Thomas Bonnet — Tue, 21 Jul 2026 08:00:00 +0000

You deploy, you rebuild, you test things. And one day, you look at your server and you have only 2 GB of free space left. Congratulations, Docker has eaten it all up.

Your Docker hard drive hates you. And it’s your fault.

What exactly is the problem?

Docker accumulates images over time. Every time you run a docker build, if anything changes, it creates new layers and keeps the old ones. These old layers which have no tags, no names, and no purpose are called dangling images.

They serve no purpose. They take up space. And Docker doesn’t delete them on its own.

See where you stand

Before deleting anything, there’s just one thing to do:

docker system df

This shows you in a few lines how much space is being used—and, more importantly, how much is available. That’s your starting point.

Want to see the images in detail?

docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.ID}}\t{{.Size}}"

Delete dangling images

Dangling images are intermediate layers that are left behind. They have neither a tag nor a name. To delete them:

docker image prune

Docker asks for your confirmation, shows you what it's going to delete, and you confirm. Clean, fast, and risk-free.

Go a step further

If you have entire images that are no longer used by any container (even stopped ones), you can delete them as well:

docker image prune -a

The -a option changes everything: now it no longer targets just dangling images, but all unreferenced images. That’s what you want in most cases on a production or staging server.

You can filter by age if you want to keep recent images:

docker image prune -a --filter "until=720h"

It only deletes items that are more than 30 days old. This is handy if you have regular deployments.

Reset Everything

If you want to reset everything images, stopped containers, orphaned volumes, unused networks:

docker system prune -a --volumes

I don’t recommend doing this on a production server without first checking what’s running. But on a dev machine or a VPS that you rebuild regularly, it’s perfect.

Automating All of This

Instead of doing this manually, you can set up a weekly cron job:

# crontab -e
0 3 * * 0 docker image prune -a -f >> /var/log/docker-prune.log 2>&1

Every Sunday at 3 AM, it cleans up without asking for confirmation (-f), and logs the result.

Conclusion

Command	What it does
`docker system df`	View used space
`docker image prune`	Remove dangling images
`docker image prune -a`	Remove everything that is no longer in use
`docker image prune -a --filter “until=720h”`	Same as above, but only for old images
`docker system prune -a --volumes`	Reset everything to zero

Start with docker system df. In 90% of cases, running docker image prune -a is enough to free up several gigabytes without breaking anything.

RES, my personal safeguard against AI

Thomas Bonnet — Thu, 16 Jul 2026 21:17:26 +0000

The Problem

The more I use AI in my daily life, the longer my conversations get. And the longer a conversation goes on, the greater the risk that the AI will stray from my initial instructions. A change in tone, a forgotten constraint, a format that’s no longer followed… Nothing dramatic in itself, but enough to waste time rereading each response in detail to make sure it’s still consistent.

Just to be clear: this flag doesn’t mean you can skip rereading what the AI gives you and checking it yourself—especially before taking action. It’s an extra warning sign, not a substitute for your own vigilance.

The thing is, I never realize it right away. The AI doesn’t tell me, “By the way, I skipped that instruction you gave me 10 messages ago.” I notice it after the fact, usually once it’s already a little too late.

The trick I use

I saw a tip in a YouTube video (a source I haven't been able to find again, unfortunately 🙈): ask the AI to write a specific word of your choice at the very beginning of each response.

In my case, that word is RES. I added it to my preferences:

Every time you reply to me, start with “RES.”

And since then, every reply has started like this:

RES

[response]

Why It Works

The principle is simple: it’s a constant prompt that appears in all my conversations, and I can check it at a glance. If the word is there, I know the AI still has my instructions in mind when responding. If it disappears, that’s my warning sign: something got lost along the way, so I need to reread the response more carefully—or even remind the AI of my instructions.

It’s a bit like a canary in a coal mine. 🐤 The canary doesn’t solve anything on its own; it does just one thing: signal that something unusual is happening, before it becomes a real problem.

A Comparison with Security

As I delved deeper into the subject, I realized that this concept already exists in cybersecurity, under the name canary token. It’s a unique string of characters, hidden in the system prompt of an AI application, designed to detect prompt injection attacks: if this token appears (or disappears) from the response, it indicates an attempt at manipulation.

My use of it has nothing to do with security, but the underlying principle is the same: a constant signal, the absence of which reveals an anomaly.

	Canary token (security)	My token (“RES”)
What it protects against	An attacker manipulating the AI	A natural drift of the AI itself
The word is...	Hidden; the AI must never reveal it	Visible and acknowledged; it is part of the response
How it is generated	A random string, unique to each session	A word chosen once and kept as is
Who verifies it	An automated script	Me, by eye

The key difference: the canary token protects against an external threat. My “RES” monitors an internal drift specific to how the model operates on a conversation that drags on.

What This Actually Changes

Well, it doesn't guarantee anything 100%, it's not magic. But in practice, it's helped me to:

Spot more quickly when I need to steer a conversation back on track if it strays from my initial request
Keep a simple visual cue, without having to reread everything in detail every time
Have a stable reference point, no matter the topic or length of the exchange It’s a simple, free tip that takes two seconds to set up. If you want to try it out, just add a line to your custom instructions or to the system prompt of your favorite AI.

Do you have any similar tips for staying in control of your conversations with AI? Let me know on Discord or on social media! 💬

Acronyms and Jargon in Development and Open Source

Thomas Bonnet — Wed, 01 Jul 2026 16:35:59 +0000

Introduction

You join an open-source project, read a discussion on GitHub, and then... PR, LGTM, WONTFIX, RFC. You nod politely, but you have no idea what any of that means.

That’s normal. The world of development has developed its own dialect over the years, shaped by Git tools, open-source practices, and team communication habits. Here’s a glossary to help you decode it all. ✊

Git and GitHub/GitLab

Basic Actions

Commit: a snapshot of your code at a given moment. Each commit has a message explaining what you changed and why.
Push / Pull: push sends your commits to the remote repository. pull fetches changes from the remote repository to your local machine.
Fork: a copy of a repository in your own space. You fork a project so you can contribute to it without affecting the original.
Clone: download a local copy of a remote repository to work on it.

Branches and Merging

Branch: a parallel development path. You create a branch to work on a feature or a fix without affecting the main branch.
Merge: to merge changes from one branch into another. “Merging a PR” means integrating the proposed code into the main repository.
Rebase: Reapplying your commits on top of another branch to maintain a clean, linear history.
Conflict: When two people have modified the same lines of code differently. Git doesn’t know which one to choose, so it asks you to decide.
Stash: Set aside changes you’re working on without committing them, so you can quickly switch branches.

Pull Requests and Issues

PR (Pull Request) / MR (Merge Request): A proposed change. You submit your branch so it can be reviewed and integrated into the project. PR is the GitHub term; MR is the GitLab term.
Issue: a ticket. It can be a reported bug, a requested feature, or a question. The cornerstone of open-source project management.
Review / Code Review: the process of reviewing the code proposed in a PR before it is merged. Someone leaves comments, suggestions, or approves it.
Draft PR: a PR marked as “in progress.” It indicates that the work isn’t finished, but that you want to share your progress.

Discussion Jargon

These terms often appear in PR and issue comments.

Term	Meaning
LGTM	Looks Good To Me: informal approval of a PR
SGTM	Sounds Good To Me: same idea, for a verbal proposal
WIP	Work In Progress: in progress, not yet ready
RFC	Request For Comments: seeking feedback before making a decision
WONTFIX	The bug is known but will not be fixed (intentionally)
RTFM	Read The Friendly Manual: go read the documentation (sometimes said less politely)
TL;DR	Too Long; Didn't Read: summary of a long text
nit	Nitpick: minor comment on style or form, not a deal-breaker
ACK / NACK	Acknowledged / Negative Acknowledge: “I agree” / “I disagree”
+1 / -1	Vote for or against a proposal

About Projects and Contributing

README.md: A project's welcome file. It explains what the project is, how to install it, and how to contribute.
CONTRIBUTING.md: the project’s contribution guidelines. Read this before opening a PR.
CHANGELOG.md: the history of changes between each version of the project.
ROADMAP.md: the project’s roadmap, outlining what’s planned for future versions.
AGENTS.md: supplements the README file by providing additional—and sometimes detailed—context that agents need: build steps, tests, and conventions that might clutter a README file or aren’t relevant to human contributors.
LICENSE.md / LICENCE.md: the terms of use for the code. MIT, GPL, Apache… this determines what you can do with the code.
CI/CD: Continuous Integration / Continuous Deployment. Automated pipelines that test and deploy the code with every push or merge.
upstream / downstream: “upstream” refers to the original project (the one you forked). Downstream is your version or the projects that depend on yours.
Maintainer: the person (or team) who maintains a project. They review PRs, manage issues, and make decisions.
Contributor: anyone who contributes to a project, even without direct access to the repository.

Versioning and Releases

SemVer (Semantic Versioning): the MAJOR.MINOR.PATCH convention (e.g., 2.4.1). A breaking change increments the MAJOR version. A new feature increments the MINOR version. A bug fix increments the PATCH version.
Tag: a marker on a commit, usually to indicate a version (v1.0.0).
Release: the official publication of a software version, often accompanied by a changelog and downloadable artifacts.
Breaking change: a change that breaks compatibility with previous versions. This should be clearly indicated.
Deprecation: marking a feature as obsolete before removing it in a future version.

The Right Mindset

The jargon may seem intimidating, but it’s there to speed up communication, not to exclude anyone. No one expects you to know all of this by heart right from the start.
The best way to learn: contribute. Open issues, read other people’s PRs, ask questions. Most open-source communities are welcoming to beginners, especially if you’ve read CONTRIBUTING.md and README.md beforehand. 😄

Learn More

Git - A Short Guide: The basics of Git in French
First Contributions: a step-by-step guide to your first pull request
Choose a License: understanding open-source licenses
Semantic Versioning: Understanding semantic versioning
Agents.md: A guide to writing a clear and useful AGENTS.md file

Find me on GitHub or Discord to chat about development and open source!

Which AI should you choose in 2026? Claude, Perplexity, Gemini, or ChatGPT

Thomas Bonnet — Mon, 01 Jun 2026 00:07:18 +0000

Claude Code — My daily dev tool

Claude Code by Anthropic is the one I use the most for development, by far. What sets it apart from the others: it integrates directly into the terminal and editor, it can read and modify files, navigate an entire codebase, and understand the global context of the project. Not just responding to a copy-pasted snippet in a chat window.

In practice, when I have an idea, I ask it to structure the project and challenge my choices. And to be clear: I challenge it too. 😄 I sometimes disagree with its suggestions, and that's often where the conversation becomes interesting. It's a tool, not an oracle.

Perplexity — My reference for research

Perplexity is my main tool when I need a reliable and verifiable answer. It's a response engine that systematically cites its sources — you ask a question, it answers with excerpts from real web pages and direct links. No more hallucinations without references.

However, I use it almost exclusively on desktop. On smartphone, it's flooded with messages pushing the paid version. Understandable from their side, but frankly annoying when you just want to do a quick search. 🙄

Gemini — For those in the Google ecosystem

Gemini is Google's AI, and its main advantage is integration with Gmail, Docs, Drive, Sheets, and Google Search. I have a Google Pixel, and on that side, it does integrate very well with its own ecosystem. It's practical for analyzing documents or getting a quick summary without leaving the interface.

That said, in terms of responses, it sometimes falters. 😬 Not systematically, but regularly enough that I stay on guard. And if privacy is a priority for you, it's worth thinking twice before entrusting it with your documents — I talk about this in my article on securing yourself on the Internet.

ChatGPT — The natural entry point

ChatGPT by OpenAI is the most known and most versatile AI. Writing, code, analysis, translation, summary, creativity... it does a bit of everything, often very well. The free version (GPT-4o mini) remains capable for most common uses. It's also the easiest AI to get started with if you're a beginner.

Personally, I don't really buy into it. The main reason? OpenAI's partnership with the Pentagon, which triggered a big wave of uninstallations and boycotts. This is not a technical controversy — it's a question of ethics and values. The idea that "consumer" AI could be used in a military context raises legitimate questions that each person must decide for themselves.

Also note: by default, your data may be used to improve the models — check in the settings.

Quick comparison

My opinion at the time of writing this article — subject to change.

Criterion	Perplexity	Claude Code	Gemini	ChatGPT
Sourced web search	✅ Excellent	❌ Limited	✅ Good	⚠️ Hallucinates
Development / Code	⚠️ Basic	✅ Excellent	⚠️ Correct	✅ Good
Ecosystem integration	❌ None	❌ None	✅ Google	❌ None
Mobile usage	⚠️ Subscription	✅ Correct	✅ Pixel native	✅ Good
Privacy	✅ Correct	✅ Correct	⚠️ Check	⚠️ Check
Free access	✅ Limited	✅ Limited	✅ Yes	✅ Limited
Ideal for beginners	⚠️ Oriented	❌ CLI	✅ Yes	✅ Yes

Which AI to choose based on your profile?

There is no universal answer. The right question is: what do you do most often?

You look for reliable info with sources → Perplexity (on desktop preferably)
You code or develop projects → Claude Code
You work in Google Workspace or have a Pixel → Gemini
You want to do everything without hassle → ChatGPT
You want to protect your privacy → Claude or Perplexity

And don't hesitate to combine several. Personally, I use Claude Code for dev, Perplexity on desktop when I need a sourced answer, and Gemini for anything related to my phone or Google Workspace.

Frequently asked questions

What is the best free AI in 2026?

Claude offers a solid reasoning level even without a subscription. Perplexity is better for sourced searches. ChatGPT remains an accessible option, but with the reservations mentioned above.

Can you use multiple IAs at the same time?

Yes, and it's often the best strategy. Use Perplexity for research, Claude Code for dev, and ChatGPT for writing for example. Each tool has its domain of excellence.

Are IAs safe for personal data?

It depends on the provider and your settings. By default, most use your data to improve their models. Always check privacy settings. To go further: secure yourself on the Internet (FR).

ChatGPT or Claude: which one to choose?

For code, long reasoning, and creativity → Claude. For dev integrated into the terminal → Claude Code. For sourced searches as a complement → Perplexity. ChatGPT remains a consumer option, but personally I do without it.

Conclusion

IAs are not interchangeable, and none is perfect. Each has been optimized for certain uses, with its own trade-offs — technical, ethical, and practical. What makes the difference is choosing the right tool for the right task, rather than relying on a single one for everything.

My current combo: Claude Code for dev, Perplexity on desktop for sourced searches, and Gemini for anything related to my Pixel. ChatGPT, I'm leaving aside for now — the reasons are mentioned above, and my opinion can change.

What I think of these tools today may not be true in six months. IAs advance quickly, models change, policies too. I'll update this article if needed.

And you, what do you use daily? Do you combine several or do you stay loyal to just one? Tell me on Discord or on social networks! 💬

Go further

Some of my articles, including this one, may have been AI-assisted to help me better structure or rephrase my ideas. Opinions remain my own.

My summary of 2025 as an IAM consultant and non-web developer

Thomas Bonnet — Thu, 01 Jan 2026 00:10:05 +0000

This year marks a big change in my life.

I originally taught myself web development and many other aspects of the field. At the beginning of the year, I stopped working as a freelance web developer at my web agency, Concept'Web.

I then started a new job as an IAM consultant in cybersecurity. When I began, I didn't feel I had enough knowledge to fully make it my full‑time job, and I struggled for several months. But things are now going much better: I feel more confident, I'm learning a lot every day, and I genuinely love what I do. It's a big shift from web development, which I hardly practice anymore. I contribute much less to open source and side projects (which is a bit sad, but mostly a matter of time), though I still maintain a few of them, including my personal website and a Discord bot that helps eliminate cyberbullying.

If you're curious about what I wish for this new year, you can read it here:

Thomas Bonnet

Jan 7 '25

2025, me voilà ! 🥳

#devchallenge #newyearchallenge #career #opensource

2 min read

Outside of work, I also had a lot of fun shipping several updates to my biggest Discord bot project. I notably improved my filter against insults and other offensive language, including homophobia, transphobia, conflicts, sexual content, and degrading comments. I'm very happy with how it's evolving, and I'm proud of the impact it can have on online communities.

DEV Community: Thomas Bonnet

My AI was in the cloud. I brought it home.

What I Built

Demo

Code

thomasbnt / agent-mailbox

agent-mailbox

Contents

Rules for this repository

Credits

How I Built It

The Monday job

The trap I fell into: the heartbeat

Why Does Open Innovation Matter?

openclaw / openclaw

The AI that really does things. Any OS. Any Platform. The lobster way. 🦞

OpenClaw 🦞 — Your assistant, on your devices, in your chats

The Spirit of It

Prize Categories

Stuck in the same dev.to topics? An open model fixed it.

What I Built

Demo

Code

thomasbnt / your-devto-digest

A weekly dev.to digest in your inbox: posts from your tags plus a Discover section outside your bubble, summarized by an open-weight model.

devto-digest

Setup

1. Prerequisites

How I Built It

The pipeline

Mistral

What the model writes

GitHub Actions

dev.to and Forem

Accessibility, enforced by tests

What broke along the way

My Discover section was almost empty

dev.to has a trap in its API

The first run hung for two minutes

A screenshot found what no test did

What I would do next

Why Does Open Innovation Matter?

The Lazy Payoff

Prize Categories

Integrating SEO Components into Discord

Default Behavior: Open Graph Tags

The new format: component embeds

What I've set up on my blog

Common issues to avoid

How to Test

Conclusion

Resources

Progressive Web Apps (PWAs)

What Is a PWA?

Service Worker: The Core of Offline Functionality

manifest.json and Installation on the Home Screen

Push Notifications and User Engagement

Benefits: performance, cost, reach

Limitations and Pitfalls (iOS Support, Storage, the Cache Trap)

Real-World Example: TOPLA as a PWA

Conclusion: When to Choose a PWA Over a Native App

A Few Tips for Improving Your SEO

Content Is Still the Foundation

The Tool to Use from the Start

Speed: Core Web Vitals

Meta Tags and Open Graph

Meta Tags — Preview, Edit and Generate

Accessibility and Contrast

Responsive: Mobile-First

Get Indexed Faster

The tools I use

Conclusion

Learn More

How to Create Your Own Personal Blog with Astro

Why Astro for a blog

Create the project

Articles in Content Collections

Layouts: One for the list, one for the post

Lightweight i18n: a dictionary, not a router

Deploying to Cloudflare Workers