[{"data":1,"prerenderedAt":136},["ShallowReactive",2],{"seo-verification":3,"blog-self-hosted-apps-the-patching-routine-ma-en":6,"promo-bar-likely":20},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-self-hosted-apps-the-patching-routine-ma-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":20,"publishedAt":21,"updatedAt":22,"category":23,"categories":29,"featuredImage":31,"bgImage":32,"posterImage":33,"relatedSolution":31,"intro":34,"sections":35,"ctaTitle":78,"ctaBody":79,"ctaButton":80,"ctaUrl":81,"relatedPosts":82},224,"self-hosted-apps-the-patching-routine",{"fr":12,"en":10,"ar":13,"es":14},"routine-correctifs-apps-self-hosted","التطبيقات-المستضافة-ذاتيا-روتين-التصحيحات","apps-self-hosted-rutina-de-parches","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,true,"2026-08-05T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":24,"name":25,"slug":26,"color":27,"icon":28},8,"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[30],{"id":24,"name":25,"slug":26,"color":27,"icon":28},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.",[36,40,49,52,71,75],{"type":37,"title":38,"body":39},"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":41,"title":42,"items":43},"ul","What breaks when nobody owns it",[44,45,46,47,48],"**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":37,"title":50,"body":51},"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":53,"title":54,"steps":55},"steps","The routine, in five moves",[56,59,62,65,68],{"title":57,"body":58},"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":60,"body":61},"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":63,"body":64},"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":66,"body":67},"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":69,"body":70},"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":72,"title":73,"body":74},"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":37,"title":76,"body":77},"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",[83,101,118],{"id":84,"slug":85,"slugs":86,"title":90,"excerpt":91,"readTime":17,"views":18,"isPinned":19,"noindex":20,"publishedAt":92,"updatedAt":22,"category":93,"categories":98,"featuredImage":31,"bgImage":32,"posterImage":100,"relatedSolution":31},202,"securing-your-npm-ci-supply-chain-after-asyncapi",{"fr":87,"en":85,"ar":88,"es":89},"securiser-chaine-approvisionnement-npm-ci","تأمين-سلسلة-توريد-npm-في-ci-بعد-حادثة-asyncapi","proteger-la-cadena-de-suministro-npm-tras-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.","2026-08-01T00:00:00+00:00",{"id":17,"name":94,"slug":95,"color":96,"icon":97},"Development","developpement","bg-warning\u002F10 text-warning","dev",[99],{"id":17,"name":94,"slug":95,"color":96,"icon":97},"\u002Fblog\u002Fcovers\u002Fsecuriser-chaine-approvisionnement-npm-ci-poster.svg",{"id":102,"slug":103,"slugs":104,"title":108,"excerpt":109,"readTime":110,"views":111,"isPinned":19,"noindex":19,"publishedAt":112,"updatedAt":113,"category":114,"categories":115,"featuredImage":31,"bgImage":32,"posterImage":117,"relatedSolution":31},113,"automate-your-vps-backups-with-restic",{"fr":105,"en":103,"ar":106,"es":107},"sauvegardes-restic-vps","أتمتة-نسخ-خادمك-vps-الاحتياطية-باستخدام-restic","copias-de-seguridad-vps-con-restic","Automate Your VPS Backups with Restic","Automate your VPS backups with Restic: encrypted snapshots, deduplication and shipping to S3 or any object backend.",11,0,"2026-02-27T00:00:00+00:00","2026-11-08T01:13:12+00:00",{"id":24,"name":25,"slug":26,"color":27,"icon":28},[116],{"id":24,"name":25,"slug":26,"color":27,"icon":28},"\u002Fblog\u002Fcovers\u002Fsauvegardes-restic-vps-poster.svg",{"id":119,"slug":120,"slugs":121,"title":125,"excerpt":126,"readTime":24,"views":111,"isPinned":19,"noindex":19,"publishedAt":127,"updatedAt":128,"category":129,"categories":130,"featuredImage":31,"bgImage":32,"posterImage":132,"relatedSolution":133},105,"monitoring-your-vps-with-uptime-kuma",{"fr":122,"en":120,"ar":123,"es":124},"superviser-vps-uptime-kuma","مراقبة-خادمك-الافتراضي-vps-باستخدام-uptime-kuma","supervisar-vps-con-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","2026-11-09T20:55:19+00:00",{"id":24,"name":25,"slug":26,"color":27,"icon":28},[131],{"id":24,"name":25,"slug":26,"color":27,"icon":28},"\u002Fblog\u002Fcovers\u002Fsuperviser-vps-uptime-kuma-poster.svg",{"categorySlug":134,"appSlug":135},"monitoring-observability","uptime-kuma",1794270499397]