MirLabs / How I secure my sites

How I secure my sites

My sites are built with the help of an AI and run on a server I manage on my own. Here is how they are protected, what is already live and what is being set up. No embellishment.

Who can do what

Me

I keep the keys: the accounts, the production secrets, access to the server. I decide what goes live whenever a decision is needed.

The AI

It writes the code and the tests, in a separate environment. It has no access to the server, and no password or key ever goes through our exchanges.

The server

It reads the code on GitHub but cannot write anything there. It does the mechanical jobs on its own: backups, patches, scans.

The chain, from code to production

Each link has one job. A link "being set up" is shown as such, and becomes "live" once it has actually run.

  • Live

    Every change is tested before it is sent

    The AI works in a throwaway copy of the project, separate from the server, and runs the automated tests there before each push. A change that breaks a test does not go out.

  • Live

    Security patches applied at night

    Every night, the server compares each site's PHP with the latest patch release, and rebuilds the site when it is behind or when its base image is republished. Every week, everything is rebuilt from scratch.

  • Live

    A vulnerability scan every night

    Everything that runs is scanned every night for known vulnerabilities: system, PHP, Python, JavaScript. A serious one with a fix available reaches me in the morning.

  • Live

    A sentinel inside each application

    Sentinelle, my open-source bundle, spots attempts (secret files, injections), blocks the offending addresses, and emails me at once only when a sensitive answer actually went out. The rest is summed up once a day. Live on this site and on LiaScan; the other sites get it with their next release.

  • Live

    A nightly database backup, checked

    Every database is dumped every night, and every dump is read back to check it can be used. Two weeks are kept.

  • Being set up

    Upgrades prepared apart, approved by me

    PHP, Symfony and dependency upgrades are prepared at night in a separate copy and a throwaway container, tested, then wait for my approval. Nothing goes to production on its own.

  • Being set up

    Encrypted backups off the server

    An encrypted copy of the databases and a copy of every code repository at a second provider, with a retention period nobody can shorten, not even me. And a restore test every month: a backup never restored is not a backup.

  • Being set up

    Automatic rollback

    After each deploy, the site is checked. If it stops answering, the previous version comes back by itself and I am told. Ready, waiting for a first real run in production.

  • Being set up

    Two-factor authentication everywhere

    App-based two-factor authentication (not SMS) on the accounts that matter: email, code, hosting, payments. Recovery codes printed and kept offline.

What this page does not promise

No site is unbreakable, and I do not claim otherwise. I am not certified and I do not do penetration testing. What I do: reduce what can go wrong, see it quickly when it does, and be able to go back.

This page says how, not where: no address, no path, no version, no account name. On purpose.

Report a vulnerability

Found a vulnerability on one of my sites or in one of my bundles? Email me privately, before any publication: cdelage.dev@gmail.com.

I answer within 72 hours, I fix it, and I credit you if you wish. For the bundles, GitHub's private reporting works too.

Every site publishes /.well-known/security.txt (RFC 9116), the standard format for these reports, which points to my responsible-disclosure policy: timelines, rules and safe harbour. Responsible disclosure · security.txt

The tools, open source

On the blog

All the security articles →

Page updated on 27 October 2026.

Want the same for your sites?I can set up this chain, or part of it, on your Symfony applications.
Contact me