[{"data":1,"prerenderedAt":126},["ShallowReactive",2],{"seo-verification":3,"blog-self-hosted-apps-the-patching-routine-en":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"id":7,"slug":8,"slugs":9,"title":12,"excerpt":13,"readTime":14,"views":15,"isPinned":16,"publishedAt":17,"category":18,"categories":24,"featuredImage":26,"bgImage":27,"posterImage":28,"relatedSolution":26,"intro":29,"sections":30,"ctaTitle":73,"ctaBody":74,"ctaButton":75,"ctaUrl":76,"relatedPosts":77},224,"self-hosted-apps-the-patching-routine",{"fr":10,"en":8,"ar":11},"routine-correctifs-apps-self-hosted","التطبيقات-المستضافة-ذاتيا-روتين-التصحيحات","Self-hosted apps: the patching routine","Inventory, security advisories, a patch window, backups and post-checks: the routine most self-hosted estates are missing.",4,1,false,"2026-08-05T00:00:00+00:00",{"id":19,"name":20,"slug":21,"color":22,"icon":23},8,"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[25],{"id":19,"name":20,"slug":21,"color":22,"icon":23},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Froutine-correctifs-apps-self-hosted-poster.svg","Self-hosting means taking back a job the vendor used to do for you without ever billing it separately: applying its security patches. July 2026 was the reminder, with CVE-2026-63077 in JetBrains TeamCity, already handled on the vendor's cloud side while every On-Premises instance waited for its own administrator. Here is the routine that closes the gap.",[31,35,44,47,66,70],{"type":32,"title":33,"body":34},"h2","Patching is part of what you take back","In a SaaS product, the security update is invisible: the vendor rolls it out across its own fleet, sometimes before the public announcement. The same vulnerability on an instance you host stays open until someone applies the fix. CVE-2026-63077 illustrates the gap: the flaw allowed unauthenticated execution of system commands on TeamCity On-Premises, fixed in versions `2025.11.7` and `2026.1.3`, while the same vendor's cloud deployments required no action from customers. The gap is not technical, it is organisational.",{"type":36,"title":37,"items":38},"ul","What breaks when nobody owns it",[39,40,41,42,43],"**The installed version becomes untraceable** — without an inventory, nobody knows which component runs on which machine, and a security advisory cannot even be triaged.","**The advisory reaches a dead address** — vendor notifications go to a departed contractor's mailbox, or to an alias nobody reads any more.","**The backlog grows into a dead end** — three major versions behind turns a ten-minute patch into a two-day migration.","**The update runs without a safety net** — without a verified backup, a schema migration applied and then regretted cannot be replayed backwards.","**Nobody checks afterwards** — the service restarts, the home page answers, and a queue consumer stays dead for weeks without a single signal.",{"type":32,"title":45,"body":46},"The four prerequisites of a routine that holds","A patching routine does not rest on goodwill, it rests on four written things. An inventory: every application, its version, its host, its owner. Advisory sources narrowed to the components actually installed, because a general feed drowns the signal. An announced window: a recurring slot where downtime is accepted, otherwise the patch waits for a quiet moment that never comes. A restorable backup, tried before it is needed. Without those four, every update turns back into a project to negotiate.",{"type":48,"title":49,"steps":50},"steps","The routine, in five moves",[51,54,57,60,63],{"title":52,"body":53},"Inventory what is actually running","List every exposed application, its exact version, its host and its owner. `docker compose ls` then `docker image inspect` give the real state of your containers; `dpkg -l` or `rpm -qa` that of system packages. Keep this file under version control next to your configurations: an inventory that lives only in someone's memory does not exist.",{"title":55,"body":56},"Subscribe to advisories for installed components, not the whole internet","For each line of the inventory, open a named subscription: the repository's Atom release feed (`https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Freleases.atom`), the vendor's security mailing list, or an NVD query filtered on the product. One subscription per component stays triageable. Route them all to a shared mailbox, never to a personal address.",{"title":58,"body":59},"Set a patch window, and a fast lane","Reserve a recurring slot where downtime is accepted and announced. Two classes are enough: ordinary patches wait for the window; a critical flaw under active exploitation triggers immediate application, outside the window. Writing that rule before the incident spares you from negotiating it during.",{"title":61,"body":62},"Back up right before, and prove the restore","Before applying, take a database export (`mysqldump`, `pg_dump`) and a dated backup of the data volume, then record the version you are leaving. A hypervisor snapshot and an application-level backup (`restic`, `borg`) do not cover the same risk: keep both, and test a restore while it is not urgent.",{"title":64,"body":65},"Verify behaviour afterwards, then hand it to a probe","An open port proves nothing. After each patch, check what the application really does: health endpoint response (`curl -fsS https:\u002F\u002Fyour-domain.com\u002Fhealth`), queues being consumed, a test email actually sent, no new errors in the logs. Then write those checks into permanent monitoring, with Uptime Kuma for instance, which replays them without you.",{"type":67,"title":68,"body":69},"tip","Shrink the surface instead of chasing patches","An admin console or an agent protocol exposed to the public internet turns every unauthenticated flaw into an immediate incident. Put those interfaces behind a private network, a VPN or an allowlist. Updating remains mandatory, but the delay between an advisory and your patch stops being a window of exposure open to everyone.",{"type":32,"title":71,"body":72},"Who updates what, exactly","On a server you administer, the split must stay clear. The host provides and maintains the foundation: the machine, the network, the storage, hypervisor availability. The applications you install on top — their versions, their patches, their configuration — remain under your administration. Nobody will update them for you, and that is the price of the control you chose. The routine described here is what makes that split sustainable: it turns a diffuse load into a short, predictable appointment.","The foundation is ours, your patch schedule stays yours","Root access, complete logs and the freedom to install your own backup and monitoring tools: the infrastructure we operate lets you apply your patches at the moment you decided.","See our security approach","\u002Fpourquoi\u002Fsecurite",[78,96,110],{"id":79,"slug":80,"slugs":81,"title":84,"excerpt":85,"readTime":14,"views":86,"isPinned":16,"publishedAt":87,"category":88,"categories":93,"featuredImage":26,"bgImage":27,"posterImage":95,"relatedSolution":26},202,"securing-your-npm-ci-supply-chain-after-asyncapi",{"fr":82,"en":80,"ar":83},"securiser-chaine-approvisionnement-npm-ci","تأمين-سلسلة-توريد-npm-في-ci-بعد-حادثة-asyncapi","Securing Your npm CI Supply Chain After AsyncAPI","Lockfile policy, hash verification, SLSA provenance and automated SCA: how to harden your CI pipeline after the AsyncAPI incident of July 2026.",0,"2026-08-01T00:00:00+00:00",{"id":14,"name":89,"slug":90,"color":91,"icon":92},"Development","developpement","bg-warning\u002F10 text-warning","dev",[94],{"id":14,"name":89,"slug":90,"color":91,"icon":92},"\u002Fblog\u002Fcovers\u002Fsecuriser-chaine-approvisionnement-npm-ci-poster.svg",{"id":97,"slug":98,"slugs":99,"title":102,"excerpt":103,"readTime":104,"views":86,"isPinned":16,"publishedAt":105,"category":106,"categories":107,"featuredImage":26,"bgImage":27,"posterImage":109,"relatedSolution":26},113,"automate-your-vps-backups-with-restic",{"fr":100,"en":98,"ar":101},"sauvegardes-restic-vps","أتمتة-نسخ-خادمك-vps-الاحتياطية-باستخدام-restic","Automate Your VPS Backups with Restic","Automate your VPS backups with Restic: encrypted snapshots, deduplication and shipping to S3 or any object backend.",3,"2026-02-27T00:00:00+00:00",{"id":19,"name":20,"slug":21,"color":22,"icon":23},[108],{"id":19,"name":20,"slug":21,"color":22,"icon":23},"\u002Fblog\u002Fcovers\u002Fsauvegardes-restic-vps-poster.svg",{"id":111,"slug":112,"slugs":113,"title":116,"excerpt":117,"readTime":104,"views":86,"isPinned":16,"publishedAt":118,"category":119,"categories":120,"featuredImage":26,"bgImage":27,"posterImage":122,"relatedSolution":123},105,"monitoring-your-vps-with-uptime-kuma",{"fr":114,"en":112,"ar":115},"superviser-vps-uptime-kuma","مراقبة-خادمك-الافتراضي-vps-باستخدام-uptime-kuma","Monitoring your VPS with Uptime Kuma","Deploy Uptime Kuma on your VPS to monitor your sites and services self-hosted, with alerts and a public status page.","2026-03-07T00:00:00+00:00",{"id":19,"name":20,"slug":21,"color":22,"icon":23},[121],{"id":19,"name":20,"slug":21,"color":22,"icon":23},"\u002Fblog\u002Fcovers\u002Fsuperviser-vps-uptime-kuma-poster.svg",{"categorySlug":124,"appSlug":125},"monitoring-observability","uptime-kuma",1787581015193]