[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fF7eLpWYk4zy2NXTGk0sV0AAHbQg1sG3JhKnQQokDSEU":3,"$fInjZVRcj7ulPnpsecWaGZgoA34-dJTfT7Aq584Kiy84":21},{"id":4,"slug":5,"titleFr":6,"titleEn":7,"titleKm":8,"contentFr":9,"contentEn":10,"contentKm":8,"excerptFr":11,"excerptEn":12,"excerptKm":8,"tags":13,"createdAt":19,"updatedAt":20},123,"scale-to-zero-cout-quasi-zero","Scale-to-zero : de 30 €/mois à presque rien","Scale-to-zero: from €30/month to almost nothing",null,"## 30 € par mois pour des serveurs qui dormaient\n\nAvant la migration, mes projets perso me coûtaient environ **30 €/mois** de compute sur GCP Cloud Run. Rien de dramatique. Mais quand j'ai regardé les métriques, le constat piquait : ces services **dorment 95% du temps**. Je payais surtout du vide.\n\nCe billet raconte comment je suis passé à **quasi 0 €** — non pas en coupant des features, mais en changeant de modèle d'exécution.\n\n## Le secret : scale-to-zero, pour de vrai\n\nUn *Serverless Container* configuré en **min-scale = 0** ne garde aucune instance allumée quand personne ne l'utilise. Au premier visiteur, il démarre à froid en quelques secondes ; ensuite il reste chaud le temps du trafic, puis s'éteint. Pour un usage perso — quelques visites par jour — ça veut dire : **on ne paie que les secondes réellement servies.**\n\nC'était déjà possible sur Cloud Run, mais Scaleway ajoute deux choses qui font la différence sur ce profil :\n\n- **Pas de frais par requête** (Cloud Run facture aussi la requête)\n- **Object Storage gratuit sous 75 Go** + egress quasi nul entre services co-localisés à Paris\n\n## Les chiffres\n\n| Poste | Avant (GCP) | Après (Scaleway) |\n|---|---|---|\n| Compute perso | ~30 €/mois | ~0 € au repos |\n| Stockage (~5 Go) | facturé | gratuit (\u003C75 Go) |\n| Egress inter-services | cross-cloud | co-localisé ~0 |\n\n## Le vrai piège à éviter\n\nLe scale-to-zero a un coût caché : le **cold start**. Sur une app lourde, quelques secondes d'attente au réveil peuvent gêner. Deux parades : garder les images Docker légères (multi-stage build), et — si un service a vraiment besoin d'être toujours chaud — assumer un `min-scale = 1` ciblé. Le bon réflexe FinOps, ce n'est pas « tout à zéro », c'est **payer pour ce qu'on utilise vraiment**.\n\nMoralité : sur un patrimoine de petits services, l'architecture d'exécution pèse plus lourd que le prix du vCPU affiché. Le scale-to-zero, bien utilisé, transforme une facture fixe en dépense proportionnelle à l'usage réel.","## €30 a month for servers that were asleep\n\nBefore the migration, my personal projects cost me about **€30/month** of compute on GCP Cloud Run. Nothing dramatic. But when I looked at the metrics, the takeaway stung: these services **sleep 95% of the time**. I was mostly paying for emptiness.\n\nThis post is about how I got to **near €0** — not by cutting features, but by changing the execution model.\n\n## The secret: scale-to-zero, for real\n\nA *Serverless Container* set to **min-scale = 0** keeps no instance running when nobody uses it. On the first visitor it cold-starts in a few seconds; then it stays warm for the duration of traffic, then shuts down. For personal use — a few visits a day — that means: **you only pay for the seconds actually served.**\n\nThis was already possible on Cloud Run, but Scaleway adds two things that matter for this profile:\n\n- **No per-request fee** (Cloud Run also bills the request)\n- **Free Object Storage under 75 GB** + near-zero egress between services co-located in Paris\n\n## The numbers\n\n| Item | Before (GCP) | After (Scaleway) |\n|---|---|---|\n| Personal compute | ~€30/mo | ~€0 at rest |\n| Storage (~5 GB) | billed | free (\u003C75 GB) |\n| Inter-service egress | cross-cloud | co-located ~0 |\n\n## The real pitfall to avoid\n\nScale-to-zero has a hidden cost: the **cold start**. On a heavy app, a few seconds of wake-up delay can annoy. Two remedies: keep Docker images light (multi-stage build), and — if a service truly needs to stay warm — accept a targeted `min-scale = 1`. The right FinOps reflex isn't \"everything to zero,\" it's **paying for what you actually use**.\n\nBottom line: across a fleet of small services, the execution architecture weighs more than the advertised vCPU price. Scale-to-zero, used well, turns a fixed bill into spending proportional to real usage.","Comment le scale-to-zero transforme une facture compute fixe en dépense proportionnelle à l'usage réel — chiffres, tableau comparatif et le piège du cold start.","How scale-to-zero turns a fixed compute bill into usage-proportional spend — numbers, comparison table, and the cold-start pitfall.",[14,15,16,17,18],"scaleway","finops","serverless","coûts","devops","2026-05-25T10:00:00","2026-07-06T17:21:54.473772",[]]