Docs

Versions

Versions du manager, de la plus récente à la plus ancienne, avec pour chacune le routeur installé et les changements apportés.

22 min de lectureManager 0.21.0

Dernière0.21.02026-11-03 · routeur 0.36.0

Publiée une seule fois, jamais modifiée

Chaque version est publiée une seule fois sur releases.dormeto.com, sans jamais être écrasée, avec la somme de contrôle SHA-256 de chaque fichier. Le fichier latest.json indique la plus récente. Pour mettre à jour, modifiez la version dans l'argument source de votre module (Démarrer). L'encadré Accès précise quand réappliquer les rôles des comptes membres ou la politique de délégation.

0.21.0

2026-11-03 · routeur 0.36.0 · SHA256SUMS

• Une plage d'un horaire se répète chaque jour, chaque semaine, chaque mois un jour donné ou un jour de semaine, tous les N jours, semaines ou mois, chaque année, ou selon une expression cron. Elle peut avoir une date de début et une date de fin. L'éditeur la redit en une phrase, avec ses prochaines occurrences : Horaires.
• Plages réunies : deux plages d'un même type séparées d'au plus 15 minutes comptent pour une, et l'écart ne réveille ni n'endort le workload. Cela s'applique aux horaires déjà enregistrés : réglez joinMinutes à 0 pour garder un écart. Il se règle pour l'organisation, un routeur ou un workload : Horaires.
• Do not repeat crée une plage d'une seule date. Sur le calendrier Schedules, faites glisser un élément, ou son bord haut ou bas. Pour une plage qui se répète, le tableau de bord demande : cette occurrence seulement, ou toute la série. Un horaire compte jusqu'à 100 plages.
• Les plages terminées quittent leur horaire : la vérification d'un routeur retire une plage sans occurrence valide depuis un an et sans occurrence à venir. Routers › Workload defaults règle ce délai, 0 pour les garder : Horaires.
• La fenêtre Schedule place chaque plage dans un onglet, et le panneau de Schedules accepte 1 000 workloads. Les titres des pages tiennent sur une ligne, et leurs descriptions sont passées dans des infobulles. Le titre et la description de la page d'attente acceptent le Markdown.
• Avec la CLI 0.10.0, settings set --join-minutes et --ended-window-days, et routers settings --join-minutes. schedule show décrit les récurrences en mots : CLI. La page Update indique les commandes dormeto aws, à partir de la CLI 0.9.0.

0.20.0

2026-11-01 · routeur 0.35.0 · SHA256SUMS

• La page d'attente personnalisée : pendant le réveil d'un workload, ses visiteurs voient une page que vous réglez, sous forme de modèle (une icône, un titre et une description) ou de page HTML complète de votre cru. Elle se règle à trois niveaux, chacun l'emportant sur le précédent : l'organisation, un routeur et un workload. L'icône est le favicon de l'application, ou un fichier téléversé. La page s'affiche dans la langue du visiteur, français ou anglais, avec une barre de progression calculée sur les durées de réveil récentes du workload. Une page personnalisée demande un administrateur. Un workload écrit par Terraform se change avec waiting_page dans son module. Les routeurs lisent directement la page de l'organisation : un changement atteint les visiteurs en une minute environ : Workloads.
• La lecture du favicon est activée par défaut : le routeur lit le favicon de l'application juste avant une sieste, au plus une fois par jour. Réglez l'icône sur none pour la désactiver, pour un workload, les workloads d'un routeur ou toute l'organisation (un niveau inférieur peut encore indiquer auto).
• Avec la CLI 0.8.0, dormeto workloads waiting-page, routers waiting-page et settings waiting-page affichent, définissent et effacent la page à chaque niveau : CLI. Cette même CLI apporte dormeto gcp pour Google Cloud, au degré d'essai que sa page indique : Google Cloud. La page d'attente ne s'applique pas à Google Cloud.

0.19.0

2026-10-24 · routeur 0.33.0 · SHA256SUMS

• Clusters EKS privés : un cluster dont le point de terminaison est privé, ou public mais limité à certaines adresses avec l'accès privé activé, est joint par une petite fonction proxy dans son VPC. Le manager la met en place pour les routeurs qu'il installe. Pour les autres, utilisez le module kubernetes-proxy du dépôt du routeur : Accès à l'organisation.
• Hibernation EC2 : une sieste met en hibernation une instance EC2 autonome lancée avec l'hibernation au lieu de l'arrêter, qui se réveille avec sa mémoire et ses processus tels qu'ils étaient. Activée par défaut, réglable pour le manager, un routeur ou un workload : Workloads.
• Descriptions : un texte Markdown facultatif sur chaque routeur et chaque workload, affiché dans leurs vues et sur une ligne dans les listes : Workloads.

0.18.0

2026-10-21 · routeur 0.31.0 · SHA256SUMS

• Le dernier administrateur actif ne peut plus être rétrogradé ni désactivé : l'API répond 409 « the last administrator: give the admin role to another user first », quel que soit le demandeur. Un appelant signé avec des identifiants AWS (la CLI) n'est jamais « vous-même » : c'est ce garde-fou qui l'empêche de retirer le dernier administrateur.
• Avec la CLI 0.6.0, chaque opération du manager se fait aussi depuis un terminal : CLI.

0.17.1

2026-10-20 · routeur 0.31.0 · SHA256SUMS

• La fenêtre Pause disait d'un workload en pause qu'il « is napped while paused » : elle dit désormais qu'il n'est pas mis en veille et, pour un routeur, qu'aucun de ses workloads ne l'est.
• Dans la vue Schedules, la fenêtre New window affiche en entier le libellé de son champ Workload, qui était coupé en haut.

0.17.0

2026-10-20 · routeur 0.31.0 · SHA256SUMS

• Une vue Schedules, sous Fleet, montre les horaires des workloads sous forme de calendriers, par jour, semaine de travail, semaine ou mois (Horaires). Un panneau liste les workloads, avec une recherche et un filtre « Scheduled only ». Jusqu'à 20 calendriers peuvent être activés, chacun avec sa couleur, conservés par utilisateur dans le navigateur. Les fenêtres d'éveil sont pleines, les fenêtres de sieste en contour, chaque plage déjà passée estompée, et un repère montre le réveil de maintenance d'une sieste maximale.
• Glisser sur une plage, ou le bouton New window, ajoute une fenêtre hebdomadaire à un workload que l'utilisateur peut modifier (jours, heures, type et mode de réveil modifiables avant l'enregistrement). Sélectionner des jours dans la vue mois ajoute des fenêtres de sieste de 24 heures. Cliquer sur une fenêtre ouvre la boîte Schedule du workload, qui propose désormais « Clear schedule », sur la page du workload aussi.

0.16.0

2026-10-19 · routeur 0.31.0 · SHA256SUMS

• Horaires des workloads : des fenêtres hebdomadaires d'éveil et de sieste dans un fuseau horaire, des dates d'exception que les fenêtres sautent, et une sieste maximale (1 à 60 jours) après laquelle le workload est réveillé pour sa maintenance (Horaires). Le routeur les applique à sa vérification, désormais calée sur les multiples de 5 minutes de l'horloge (cron(0/5 * * * ? *)). Les routeurs que le manager installe ou met à jour reçoivent cette vérification. Pendant une fenêtre de sieste, les requêtes reçoivent la page d'attente, qui indique la fin de la sieste, ou ne réveillent qu'avec x-dormeto-wake: 1 si la fenêtre le permet.
• Les horaires se définissent et s'effacent depuis la carte Schedule de la page d'un workload, avec PUT et DELETE /api/workloads/{router}/{id}/schedule (et sous /iam/), ou avec la CLI 0.5.0. Ils sont permis à qui peut à la fois réveiller et endormir le workload, et audités sous schedule et schedule-clear. L'état du workload porte l'horaire, ses prochains événements et la date de la maintenance due.
• La chronologie nomme les nouvelles causes (une fenêtre planifiée, un réveil de maintenance), et la liste des workloads affiche une icône de calendrier sur les workloads planifiés.

0.15.0

2026-10-19 · routeur 0.30.0 · SHA256SUMS

• Les routeurs et les workloads depuis la CLI 0.4.0 (dormeto routers list, dormeto routers upgrade, dormeto workloads list, Démarrer) : l'API du manager gagne des routes autorisées par IAM, ANY /iam/{proxy+}. Elles sont traitées comme les routes /api/ du tableau de bord avec une identité d'administrateur nommée par l'ARN AWS de l'appelant, hors de la politique MFA. Seuls les principaux du compte du manager autorisés à execute-api:Invoke sur la nouvelle sortie api_iam_arn du module peuvent les appeler. /api/ et sa connexion Cognito sont inchangées.

0.14.0

2026-10-19 · routeur 0.30.0 · SHA256SUMS

• Tags de workload : vos propres étiquettes (team=payments), 50 au plus par workload, conservées par le routeur. Les administrateurs les définissent à l'intégration d'un workload (la boîte de dialogue peut copier, sur demande, les tags AWS du groupe cible) et depuis la page du workload. Un workload géré avec Terraform prend les tags de son module workload. La liste des workloads gagne une colonne Tags et un filtre par tag.
• Groupes et droits : les administrateurs créent des groupes personnalisés dans la vue Users. Chaque groupe a des droits : un sélecteur de tags et read, wake ou nap (wake et nap incluent read ; sans tag, tous les workloads). Un utilisateur sans groupe intégré est un membre et ne voit, dans les listes, les compteurs, les économies, les alertes, les opérations et l'historique, que les workloads que ses groupes lui donnent. L'appartenance à un groupe s'applique au prochain jeton de l'utilisateur (sous une heure), les droits sous une minute. Chaque route de workload vérifie les droits, le tableau de bord n'affiche que les actions permises, et les actions refusées sont auditées avec leur motif et les groupes de l'appelant. Les invitations acceptent le rôle member et des groupes.
• Passkeys, dans les modes MFA optional et operators : les utilisateurs enregistrent des passkeys (empreinte, visage, code PIN ou clé de sécurité) depuis la page Account et s'en servent pour se connecter. La nouvelle entrée passkeys du module vaut true par défaut. Avec false, ou avec mfa = required, le pool d'utilisateurs reste mot de passe plus application d'authentification. Le pool est modifié sur place. Avec une application d'authentification activée, Cognito n'autorise pas la connexion par passkey : en mode optional, l'utilisateur désactive l'application une fois une passkey enregistrée. En mode operators, un administrateur réinitialise sa vérification en deux étapes, puis il ajoute aussitôt une passkey.
• Une vérification quotidienne des nouvelles versions du manager, désactivée tant qu'un administrateur ne l'active pas dans la carte « Daily check » de la page Mise à jour. Les administrateurs voient alors un avis sur la vue d'ensemble, et la version est envoyée une fois au topic d'alertes avec kind = update et level = info (les filtres warning et error ne la reçoivent pas). Le module gagne une petite fonction et son planning quotidien.
• Le routeur 0.30.0 porte les tags des workloads dans leur configuration.

0.13.0

2026-10-18 · routeur 0.29.0 · SHA256SUMS

• La barre latérale du tableau de bord affiche la version du manager en bas, et la marque et le favicon sont le logo du site. L'icône Opérations est deux engrenages qui s'engrènent, chacun tournant sur son propre axe.
• La page Mise à jour montre les commandes de la CLI pour cette installation : installer la CLI, mettre à jour depuis un poste avec la région et l'environnement de cette installation, suivre l'installation. Elle a des boutons de copie, des liens vers la CLI et le manager sur GitHub et vers la documentation de la CLI. Elle a une action « Check for updates » avec l'heure de la dernière vérification. GET /api/update gagne les champs env et region de l'installation.

0.12.0

2026-10-18 · routeur 0.29.0 · SHA256SUMS

• Le tableau de bord est refondu dans le design du site : thèmes nuit et clair (celui du système tant que l'utilisateur n'en choisit pas un dans la barre du haut), polices et icône animée de Dormeto, et chaque vue redessinée. La vue d'ensemble montre la flotte en direct, avec les icônes de ses 96 premiers workloads par routeur et le compte de chaque routeur, et l'énergie que les siestes n'ont pas utilisée, avec son carbone.
• Les états des workloads et les chiffres de chaque workload gagnent energy : les kWh et kg de CO2e que ses siestes n'ont pas utilisés sur les 30 derniers jours. C'est une estimation à partir de ce que chaque dernière sieste a arrêté sur les heures de sommeil comprises dans la base de référence des économies. Elle utilise les coefficients de Cloud Carbon Footprint pour AWS et l'intensité du réseau électrique de chaque région. Elle exige les prix.
• La nouvelle page Mise à jour du tableau de bord s'adresse aux administrateurs d'un manager installé avec dormeto install 0.2.0 ou une version plus récente : elle montre la version en cours et les versions publiées plus récentes avec leurs notes de version. Un administrateur prépare une mise à jour (le plan de ce qui change), la confirme et suit sa progression jusqu'à ce que la nouvelle version réponde. L'entrée Mise à jour du menu indique vers combien de versions le manager peut être mis à jour, et chaque demande est une opération, « Manager update », dans la liste des opérations des seuls administrateurs, liée à son build dans la console CodeBuild.
• La nouvelle entrée facultative install du module du manager (bucket, project, log_group) est renseignée par dormeto install : laissez-la vide sinon. Quand elle l'est, l'API gagne des droits sur le bucket d'installation, sur le projet CodeBuild d'installation et sur ses journaux.
• Chaque publication écrit manager/versions.json à côté de latest.json : les versions publiées, de la plus récente à la plus ancienne, avec leur routeur, la plus ancienne CLI dont l'installation peut les mettre à jour, et leur date. La page Mise à jour le lit.
• Un mode démo, réservé au développement, répond à l'API, à la connexion et à Cognito dans le navigateur à partir d'une organisation générée. Un build le refuse, et la release refuse un tableau de bord qui le contient.

0.11.0

2026-10-17 · routeur 0.29.0 · SHA256SUMS

• L'entrée organization_id du module du manager est facultative : un manager dans un compte hors de toute organisation travaille au sein de son seul compte, y assume les rôles de découverte et de commande et y accepte les événements et les listes des routeurs.
• La nouvelle entrée discovery_mode (organization par défaut, ou account, obligatoire sans organisation) est le mode de la configuration par défaut du périmètre de découverte, celle qu'aucun administrateur n'a encore enregistrée.

0.10.0

2026-10-11 · routeur 0.29.0 · SHA256SUMS

• Workloads Kubernetes sur Amazon EKS : un Deployment ou un StatefulSet derrière un ALB de l'AWS Load Balancer Controller (via un Ingress ou un TargetGroupBinding) est mis en veille en passant à zéro réplica, puis réveillé en retrouvant ses réplicas. Un ScaledObject KEDA est mis en pause pendant la veille. Un HPA ne demande aucune action. Dormeto ajoute son propre Ingress à votre IngressGroup et ne modifie jamais les vôtres. Un Ingress isolé est patché, puis restauré à l'identique lors du retrait. Le point de terminaison de l'API du cluster doit être public.
• La découverte lit les clusters et remonte de chaque target group jusqu'à sa ressource propriétaire, avec son Ingress, son autoscaling, son propriétaire GitOps (Argo CD, Flux) et sa capacité. La boîte de dialogue d'intégration fournit l'extrait qui empêche GitOps d'annuler la mise en veille.
• Économies : les pods Fargate sont valorisés au prix Fargate, les pods sur nœuds EC2 à hauteur de leur part du nœud, lorsqu'un autoscaler de nœuds (Karpenter, Cluster Autoscaler) supprime les nœuds ainsi libérés.
• La suppression d'un routeur efface les entrées d'accès de ses rôles dans les clusters.

0.9.0

2026-10-10 · routeur 0.28.1 · SHA256SUMS

La version 0.8.1 n'a pas été publiée. Sa modification est incluse dans celle-ci.

• Aide au choix du délai d'inactivité : la carte Idle window de chaque workload rejoue ses 14 derniers jours de requêtes avec des délais de 5 à 120 minutes, ainsi qu'avec son délai actuel. Elle affiche les économies estimées par mois, les réveils et l'attente des visiteurs par jour, et le délai recommandé : le plus court qui évite déjà 90 % des réveils évités par le plus long. Comme le rejeu compte chaque requête, la carte le compare aux réveils réels et signale quand il en compte nettement plus.
• Chaque appel AWS des routeurs est borné dans le temps : connexion en 3 secondes au plus, réponse avant 10 secondes de silence. Sinon, l'appel est relancé sur une nouvelle connexion. Une vérification d'inactivité n'attend donc jamais une réponse qui ne vient pas.

0.8.0

2026-10-09 · routeur 0.28.0 · SHA256SUMS

Les versions 0.4.0 à 0.7.0 n'ont pas été publiées. Leurs modifications sont incluses dans celle-ci et regroupées ci-dessous par thème.

Économies et historique

• Capacité Spot valorisée au prix Spot : les routeurs 0.28.0 indiquent ce qui s'est exécuté en Spot. EC2 Spot est valorisé d'après l'historique des prix Spot de la région, Fargate Spot à 30 % du prix à la demande (AWS ne publie pas de prix Fargate Spot, et retenir la remise maximale annoncée donne l'économie la plus faible). Un service Fargate qui combine capacité Fargate et EC2 ne compte que sa part Fargate.
• Remises sur engagement : sur la carte Savings, les administrateurs indiquent, sous forme de taux moyen, ce que les Savings Plans, les instances réservées ou votre accord AWS déduisent des prix catalogue, pour le calcul (EC2, Fargate) et les bases de données (RDS, Aurora). Ce taux ne s'applique jamais au Spot, et chaque modification est auditée. Elle prend effet à partir du prochain jour calculé.
• Économies estimées : les ressources arrêtées à chaque mise en veille (instances EC2 et capacité Auto Scaling par type, tâches Fargate par taille, RDS et Aurora par classe, Aurora Serverless v2 à son minimum) sont valorisées aux prix catalogue à la demande d'AWS. Seul compte le temps en veille pendant lequel la référence aurait fonctionné (savings_baseline : always, ou business-hours dans savings_timezone). Sur l'Overview, la carte Savings présente les 30 derniers jours, le mois en cours et le cumul depuis le début, nets du coût estimé de Dormeto lui-même, ainsi que les principaux workloads. Le stockage, les équilibreurs de charge et le transfert de données ne sont pas comptés, et les remises ne sont pas connues.
• Historique des états : chaque changement d'état de chaque workload est conservé (history_days, 400 jours par défaut). Dans la vue d'un workload, la carte History couvre 24 heures, 7 ou 30 jours : part du temps en veille, réveils (durée médiane et maximale), phases de chaque jour et origine de chacune.
• Workloads : pour chaque workload, une barre montre le temps passé dans chaque état sur les 7 derniers jours et les économies dues à ses mises en veille. L'en-tête de la vue Workloads affiche la même barre pour l'ensemble, à partir de chiffres mis en cache une heure (states_cache_minutes).
• Vue d'un workload : toutes ses actions sont regroupées dans un menu. Chaque backend et chaque cible affichent leur ID, leur ARN et leur service dans une infobulle, et chaque backend son prix catalogue et son économie mensuelle.

Échecs et alertes

• Un réveil en échec en indique la cause (capacité insuffisante, quota, permission, configuration, aucune cible saine, limitation de débit, délai dépassé), avec l'étape, le backend et le message d'AWS. Un lancement impossible échoue immédiatement, sans attendre l'expiration du délai de réveil.
• Capacité : un démarrage refusé faute de capacité est retenté dans la limite du délai de réveil, et une instance EC2 peut basculer sur d'autres types d'instance (fallback_instance_types ou boîte de dialogue d'intégration). Après un réveil en échec, les requêtes ne relancent une tentative qu'au bout de failed_retry_seconds, délai doublé à chaque échec. La page d'attente indique ce qui s'est passé et l'heure de la prochaine tentative.
• Alertes de santé : toutes les 5 minutes, le manager contrôle ce que remonte chaque routeur. Un routeur qui ne remonte plus rien ou qui signale un problème, comme chaque réveil en échec, ouvre une alerte. Elle est envoyée à alert_emails et à tous les abonnements du topic alerts_topic_arn, avec un message adapté à Amazon Q Developer in chat applications et des attributs pour les politiques de filtrage des abonnements. L'Overview liste les alertes ouvertes.

Listes d'IP et sécurité

• Listes d'IP gérées par le manager (ip_lists) : téléchargées une seule fois pour tous les routeurs, et vérifiées (une version qui a perdu plus de la moitié de ses entrées est rejetée). Elles sont publiées dans un bucket que les routeurs de votre organisation lisent toutes les 5 minutes. Une modification du catalogue leur parvient sans mise à jour.
• Vérification en deux étapes (mfa) : administrateurs et opérateurs configurent une application d'authentification depuis la page Account. La page Users indique qui en dispose, et un administrateur peut réinitialiser l'application perdue d'un autre utilisateur.
• Un workload placé derrière une règle qui s'authentifie avec Amazon Cognito peut être intégré, mis en veille et réveillé.

Tableau de bord

• Les routeurs ont leur propre vue : version et mise à jour, santé et alerte, workloads par état, pauses, et configuration, avec pour chaque réglage l'endroit où le modifier.
• L'état d'un workload s'affiche avec une icône, une couleur dédiée, une infobulle et sa date de début. Les échecs apparaissent dans la vue du workload.
• Des notifications indiquent ce qu'une mise à jour, une intégration ou un retrait a lancé et comment l'opération s'est terminée, avec un lien vers ses étapes dans Operations. Discovery signale une opération en cours sur un candidat.
• La santé des routeurs n'attribue plus chaque correction de dérive à l'infrastructure as code. Chaque problème signalé porte un code stable.
• Audit : une action ou une cible trop longue est tronquée sur une ligne, avec le texte complet dans une infobulle.

0.3.0

2026-10-06 · routeur 0.23.0 · SHA256SUMS

• Rafraîchissement de la découverte sur événement, désactivé par défaut (réglages Perimeter) : le manager raccorde les comptes prêts qui disposent d'un trail CloudTrail, via un relais (un rôle et une règle par région, créés par appels d'API avec le rôle de commande). Les modifications de leurs équilibreurs de charge apparaissent en 5 minutes environ. Si vous désactivez ce rafraîchissement, les relais sont supprimés. Avant de désinstaller, désactivez-le et laissez une exécution déconnecter les comptes.
• Les comptes configurés pour la découverte seule (module d'accès avec create_command_role = false, ou script AWS CLI sans rôle de commande) le signalent sur leur rôle de découverte. Le manager les comptabilise à part et y refuse l'intégration en indiquant ce motif.

0.2.2

2026-10-06 · routeur 0.22.6 · SHA256SUMS

• Sans identité SES, les invitations envoyées depuis le tableau de bord partent immédiatement via Cognito.
• deletion_protection protège la table (routeurs installés, opérations, audit) en plus des utilisateurs.
• Le code des fonctions est livré au format zip dans la release. Rien n'est écrit dans votre configuration au moment du plan : un plan appliqué dans un autre job ou par HCP Terraform fonctionne donc.
• Le module d'organisation conserve les autres déclarations de l'organisation dans son unique politique de délégation (additional_statements). La procédure AWS CLI fusionne avec la politique existante et ne retire que la déclaration de Dormeto.

0.2.1

2026-10-06 · routeur 0.22.6 · SHA256SUMS

• Les installations de développement (utilisateur de smoke test, sans domaine personnalisé) n'échouent plus lors de l'apply.

0.2.0

2026-10-06 · routeur 0.22.6 · SHA256SUMS

• Installation par un module Terraform issu d'une release, qui contient le code compilé du manager et le routeur qu'il installe. Domaine personnalisé et identité SES en option, deletion_protection pour les utilisateurs.
• Accès à l'organisation sans CloudFormation, par les modules d'accès et d'organisation ou le script AWS CLI, partagés entre plusieurs environnements. Les deux rôles sont vérifiés à chaque exécution de la découverte. L'intégration et l'installation de routeurs sont refusées là où le rôle de commande est absent.
• Montée en charge jusqu'à 1 000 comptes : les routeurs transmettent leur état, la découverte est répartie par compte et l'intégration se fait en masse.
• Intégration, retrait et installation des routeurs par appels d'API. Gestion des routeurs (santé, pause, exclusions). Découverte de l'organisation avec filtres, et workloads couvrant plusieurs règles.

Les versions antérieures n'ont pas été publiées.