Dormeto
ENFR

Docs

Releases

The versions of the manager, newest first, with the router each one installs and what changed.

19 min readManager 0.21.0

Each version is published once on releases.dormeto.com and never overwritten, with the SHA-256 checksum of every file. latest.json names the latest. To upgrade, change the version in your module's source (Get started). The Access line says when the member accounts' roles or the delegation policy must be applied again.

0.21.0

2026-11-03 · router 0.36.0 · SHA256SUMS

Access

Nothing to apply again: the access and organization modules, the AWS CLI script, the routers' boundary and the Kubernetes rights are unchanged. Upgrade the routers to 0.36.0 for what follows: a router before it refuses the new windows and joins none.

  • A schedule's window repeats daily, weekly, monthly on a day or a weekday, every N days, weeks or months, yearly, or by a cron expression. It can have a start date and an end date. The editor says it back in a sentence, with its next occurrences: Schedules.
  • Joined windows: two windows of one kind with a gap of at most 15 minutes read as one, so the gap neither wakes nor naps the workload. This applies to the schedules already saved: set joinMinutes to 0 to keep a gap. Set it for the organization, a router or a workload: Schedules.
  • Do not repeat makes a window of one date. On the Schedules calendar, drag an item, or its top or bottom edge. For a window that repeats, the dashboard asks: only this occurrence, or the whole series. A schedule takes 100 windows.
  • Ended windows leave their schedule: a router's check removes a window with no valid occurrence within the last year and none to come. Routers › Workload defaults sets the delay, 0 to keep them: Schedules.
  • The Schedule dialog puts each window in a tab, and the Schedules panel takes 1,000 workloads. Page titles fit on one line, and the pages' descriptions moved to tooltips. The waiting page's title and description take Markdown.
  • With the CLI 0.10.0, settings set --join-minutes and --ended-window-days, and routers settings --join-minutes. schedule show says recurrences in words: CLI. The Update page names the dormeto aws commands, from the CLI 0.9.0.

0.20.0

2026-11-01 · router 0.35.0 · SHA256SUMS

Access

Nothing to apply again: the access and organization modules, the AWS CLI script, the routers' boundary and the Kubernetes rights are unchanged. Upgrade the routers to 0.35.0: a router before it answers that it must be upgraded.

  • The branded waiting page: while a workload wakes, its visitors see a page you set, as a template (an icon, a title and a description) or as your own full HTML page. It is set at three levels, each overriding the one above: the organization, a router and a workload. The icon is the application's favicon, or an uploaded file. The page reads in the visitor's language, English or French, and shows a progress bar from the workload's recent wake times. A custom page needs an administrator. A workload written by Terraform is changed with waiting_page in its module. Routers read the organization's page directly, so a change reaches visitors within about a minute: Workloads.
  • The favicon read is on by default: the router reads the application's favicon just before a nap, at most once a day. Set the icon to none to turn it off, for a workload, a router's workloads or the whole organization (a lower level can still say auto).
  • With the CLI 0.8.0, dormeto workloads waiting-page, routers waiting-page and settings waiting-page show, set and clear the page at each level: CLI. The same CLI brings dormeto gcp for Google Cloud, at the level of trial its page states: Google Cloud. The waiting page does not apply to Google Cloud.

0.19.0

2026-10-24 · router 0.33.0 · SHA256SUMS

Access

Apply the access module (or the organization configuration) or the AWS CLI script of this release again in every member account, before upgrading its routers. DmtRouterBoundary gains the network-interface rights of the Kubernetes proxies' role. DmtCommandRole gains the EC2 rights for the proxies' security groups, the ingress rules on the EKS cluster security groups and lambda:ListTags. DmtDiscoveryRole may invoke the proxies. The router is 0.33.0.

  • Private EKS clusters: a cluster whose endpoint is private, or public but limited to some addresses with private access on, is reached through a small proxy function in its VPC. The manager sets it up for the routers it installs. For the others, use the router repository's module kubernetes-proxy: Organization access.
  • EC2 hibernation: a nap hibernates a standalone EC2 instance launched with hibernation instead of stopping it, so it wakes with its memory and processes as they were. On by default, set for the manager, a router or a workload: Workloads.
  • Descriptions: an optional Markdown text on each router and workload, shown in their views and as one line in the lists: Workloads.

0.18.0

2026-10-21 · router 0.31.0 · SHA256SUMS

Access

Nothing to apply again: the access and organization modules, the AWS CLI script, the routers' boundary and the Kubernetes rights are unchanged. The router is still 0.31.0.

  • The last enabled administrator can no longer be demoted or disabled: the API answers 409 "the last administrator: give the admin role to another user first", whoever asks. A caller signed with AWS credentials (the CLI) is never "yourself", so this guard is what stops it from removing the last administrator.
  • With the CLI 0.6.0, every operation of the manager also runs from a terminal: CLI.

0.17.1

2026-10-20 · router 0.31.0 · SHA256SUMS

Access

Nothing to apply again: the access and organization modules, the AWS CLI script, the routers' boundary and the Kubernetes rights are unchanged. The router is still 0.31.0.

  • The Pause dialog said a paused workload "is napped while paused": it now says it is not napped, and, for a router, that none of its workloads is napped.
  • The Schedules view's New window dialog shows its Workload field's label whole. It was cut off at the top.

0.17.0

2026-10-20 · router 0.31.0 · SHA256SUMS

Access

Nothing to apply again: the access and organization modules, the AWS CLI script, the routers' boundary and the Kubernetes rights are unchanged. The router is still 0.31.0.

  • A Schedules view under Fleet shows the workloads' schedules as calendars, by day, work week, week or month (Schedules). A panel lists the workloads, with a search and a "Scheduled only" filter. Up to 20 calendars can be enabled, each with its color, kept per user in the browser. Awake windows are filled, nap windows outlined, each window already over dimmed, and a marker shows a maximum nap's maintenance wake.
  • Dragging over a range, or the New window button, adds a weekly window to one workload the user may edit (the days, times, kind and wake mode editable before saving). Selecting days in the month view adds 24-hour nap windows. Clicking a window opens the workload's Schedule dialog, which now has "Clear schedule", on the workload page too.

0.16.0

2026-10-19 · router 0.31.0 · SHA256SUMS

Access

Nothing to apply again: the access and organization modules, the AWS CLI script, the routers' boundary and the Kubernetes rights are unchanged. Upgrade the routers to 0.31.0 for schedules: a router before 0.31.0 refuses a schedule (409) and keeps its check on rate(5 minutes) until upgraded.

  • Workload schedules: weekly awake and nap windows in a time zone, exception dates the windows skip, and a maximum nap (1 to 60 days) after which the workload is woken for maintenance (Schedules). The router applies them at its check, now on the clock's 5-minute marks (cron(0/5 * * * ? *)). Routers the manager installs or upgrades get that check. Inside a nap window, requests get the waiting page, which says when the nap ends, or wake only with x-dormeto-wake: 1 when the window allows it.
  • Schedules are set and cleared from the Schedule card of a workload's page, with PUT and DELETE /api/workloads/{router}/{id}/schedule (and under /iam/), or with the CLI 0.5.0. Allowed to whoever may both wake and nap the workload, and audited as schedule and schedule-clear. The workload's status carries the schedule, its next events and the maintenance due date.
  • The timeline names the new causes (a scheduled window, a maintenance wake), and the Workloads list shows a calendar icon on scheduled workloads.

0.15.0

2026-10-19 · router 0.30.0 · SHA256SUMS

Access

Nothing to apply again: the access and organization modules, the AWS CLI script, the routers' boundary and the Kubernetes rights are unchanged.

  • Routers and workloads from the CLI 0.4.0 (dormeto routers list, dormeto routers upgrade, dormeto workloads list, Get started): the manager's API gains IAM-authorized routes, ANY /iam/{proxy+}, handled as the dashboard's /api/ routes with an administrator identity named by the caller's AWS ARN, outside the MFA policy. Only the principals of the manager's account allowed execute-api:Invoke on the module's new api_iam_arn output can call them. /api/ and its Cognito sign-in are unchanged.

0.14.0

2026-10-19 · router 0.30.0 · SHA256SUMS

Access

Nothing to apply again. Upgrade the routers to 0.30.0 for their workloads' tags: a router before 0.30.0 reports none, so its workloads are seen only by the built-in roles and by groups granting every workload.

Upgrade note

Before 0.14.0, a user in no built-in group was a viewer. They are now a member and see nothing until a group grants them access. Users invited from the dashboard always have a built-in group. Add any user you created by hand in Cognito to dmt-viewer or to a custom group.

  • Workload tags: your own labels (team=payments), up to 50 per workload, kept by the router. Administrators set them when onboarding a workload (the dialog can copy the target group's AWS tags on request) and from the workload's page. A workload managed with Terraform takes the tags of its workload module. The Workloads list gains a Tags column and a tag filter.
  • Groups and grants: administrators create custom groups in the Users view. Each group has grants: a tag selector and read, wake or nap (wake and nap include read; no tag means every workload). A user in no built-in group is a member and sees, in lists, counts, savings, alerts, operations and history, only the workloads their groups grant. Group membership applies at the user's next token (within an hour), grants within a minute. Every workload route checks the grants, the dashboard shows only the actions allowed, and refused actions are audited with their reason and the caller's groups. Invitations take the role member and groups.
  • Passkeys, in the optional and operators MFA modes: users register passkeys (a fingerprint, a face, a PIN or a security key) from the Account page and sign in with them. The module's new passkeys input is true by default. With false, or with mfa = required, the user pool stays password plus authenticator app. The user pool is updated in place. With an authenticator app on, Cognito does not allow passkey sign-in: in the optional mode, users turn the app off once a passkey is registered. In operators, an administrator resets their two-step verification, then they add a passkey right away.
  • A daily check for new manager versions, off until an administrator turns it on in the Update page's "Daily check" card. Administrators then see a notice on the Overview, and the version is sent once to the alert topic with kind = update and level = info (the warning and error filters do not receive it). The module gains a small function and its daily schedule.
  • Router 0.30.0 carries the workloads' tags in their configuration.

0.13.0

2026-10-18 · router 0.29.0 · SHA256SUMS

Access

Nothing to apply again: the access and organization modules, the AWS CLI script, the routers' boundary and the Kubernetes rights are unchanged.

  • The dashboard's sidebar shows the manager's version at its bottom, and the brand mark and favicon are the website's logo. The Operations icon is two meshing cogs, each turning on its own axis.
  • The Update page shows the CLI's commands for this install: installing the CLI, updating from a laptop with this install's region and environment, following the install. It has copy buttons, links to the CLI and the manager on GitHub and to the CLI's documentation. It has a "Check for updates" action with the time of the last check. GET /api/update gains the install's env and region.

0.12.0

2026-10-18 · router 0.29.0 · SHA256SUMS

Access

Nothing to apply again: the access and organization modules, the AWS CLI script, the routers' boundary and the Kubernetes rights are unchanged.

  • The dashboard is redesigned in the website's design: night and light themes (the system's until the user chooses one in the top bar), the Dormeto fonts and animated icon, and every view restyled. The Overview shows the fleet live, with the icons of its first 96 workloads by router and each router's count, and the energy the naps did not use, with its carbon.
  • Workloads' states and each workload's figures gain energy: the kWh and kg CO2e its naps did not use over the last 30 days. It is an estimate from what each last nap stopped over the hours asleep within the savings baseline, with Cloud Carbon Footprint's coefficients for AWS and each region's grid intensity. It needs prices.
  • The dashboard's new Update page is for administrators of a manager installed with dormeto install 0.2.0 or later: it shows the version running and the newer published versions with their release notes. An administrator prepares an update (the plan of what changes), confirms it, and follows its progress until the new version answers. The menu's Update entry shows how many versions the manager can be updated to, and each request is an operation, "Manager update", in the Operations list of administrators only, linked to its build in the CodeBuild console.
  • The manager module's new optional install input (bucket, project, log_group) is set by dormeto install: leave it unset otherwise. When set, the API gains rights on the install bucket, on the install CodeBuild project and on its logs.
  • Each publication writes manager/versions.json beside latest.json: the published versions, newest first, with their router, the oldest CLI whose install they can update, and their date. The Update page reads it.
  • A demo mode for development only answers the API, the sign-in and Cognito in the browser from a generated organization. A build refuses it, and the release refuses a dashboard holding it.

0.11.0

2026-10-17 · router 0.29.0 · SHA256SUMS

Access

Nothing to apply again: the access and organization modules and the AWS CLI script are unchanged.

  • The manager module's organization_id is optional: a manager in an account outside any organization works within its own account only, assuming the discovery and command roles and accepting the routers' events and lists there.
  • The new discovery_mode input (organization by default, or account, required without an organization) is the mode of the discovery perimeter's default configuration, the one an administrator has not saved yet.

0.10.0

2026-10-11 · router 0.29.0 · SHA256SUMS

Access

Apply the access module or the AWS CLI script of this release again in every member account. DmtDiscoveryRole reads the EKS clusters. DmtCommandRole manages the routers' access entries in them (their roles in the group dormeto:router and DmtDiscoveryRole with AmazonEKSViewPolicy, nothing else). The routers' permissions boundary allows eks:DescribeCluster. Then upgrade the routers to 0.29.0, and apply dormeto-kubernetes-0.10.0.yaml in each cluster whose workloads should nap (Kubernetes).

  • Kubernetes workloads on Amazon EKS: a Deployment or StatefulSet behind an ALB of the AWS Load Balancer Controller (an Ingress or a TargetGroupBinding) is napped by scaling it to zero replicas and woken by giving them back. A KEDA ScaledObject is paused for the nap, an HPA needs nothing. Dormeto adds its own Ingress to your IngressGroup and never changes yours. A lone Ingress is patched and restored exactly when offboarded. The cluster's API endpoint must be public.
  • Discovery reads the clusters and traces each target group to its owner, with its Ingress, autoscaling, GitOps owner (Argo CD, Flux) and capacity. The onboarding dialog gives the snippet that keeps GitOps from undoing the nap.
  • Savings: Fargate pods at Fargate prices, pods on EC2 nodes as their share of their node, where a node autoscaler (Karpenter, Cluster Autoscaler) removes the nodes they free.
  • Removing a router deletes its roles' access entries in the clusters.

0.9.0

2026-10-10 · router 0.28.1 · SHA256SUMS

0.8.1 was not published: its change ships in this version.

Access

Nothing to apply again in the member accounts. Upgrade the routers to 0.28.1.

  • Idle window advisor: each workload's Idle window card replays its last 14 days of requests against idle windows from 5 to 120 minutes and its own. It gives the estimated savings a month, the wakes and the visitors' wait a day, and the recommended window: the shortest that already avoids 90% of the wakes the longest one avoids. Every request counts, so the card compares the replay with the real wakes and says when it counts clearly more.
  • Every AWS call of the routers is bounded: connected within 3 seconds, answered within 10 seconds of silence, else retried on a new connection, so an idle check never waits for an answer that does not come.

0.8.0

2026-10-09 · router 0.28.0 · SHA256SUMS

0.4.0 to 0.7.0 were not published: their changes ship in this version, listed below by theme.

Access

Apply the access module or the AWS CLI script of this release again in every member account. The routers' permissions boundary allows reading the account's Cognito user pool clients (AWS requires it to change a rule that authenticates with Amazon Cognito). It also allows ec2:ModifyInstanceAttribute (fallback instance types) and ecs:DescribeTaskDefinition (the size of a Fargate service, for its savings). Then upgrade the routers to 0.28.0.

Upgrade note

mfa is operators by default: after the upgrade every administrator and operator acts as a viewer until they set up an authenticator app from the Account page. Set mfa = "optional" to keep the previous behavior, and keep at least two administrators with an authenticator.

Savings and history

  • Spot capacity at Spot prices: routers 0.28.0 say what ran on Spot. EC2 Spot is priced from the region's Spot price history, Fargate Spot at 30% of on-demand (AWS publishes no Fargate Spot price; its largest announced discount gives the smallest saving). A Fargate service mixing Fargate and EC2 capacity counts only its Fargate share.
  • Discounts for commitments: administrators set on the Savings card what Savings Plans, Reserved Instances or your AWS agreement take off the list prices, for compute (EC2, Fargate) and databases (RDS, Aurora), as an average rate, never off Spot. Audited. A change applies from the next day computed.
  • Estimated savings: what each nap stopped (EC2 instances and Auto Scaling capacity by type, Fargate tasks by size, RDS and Aurora by class, Aurora Serverless v2 at its minimum) priced at AWS's on-demand list prices. It counts the time asleep that the baseline would have run (savings_baseline: always, or business-hours in savings_timezone). The Overview's Savings card shows the last 30 days, this month and since the start, net of Dormeto's own estimated cost, and the top workloads. Storage, load balancers and data transfer are not counted. Discounts are not known.
  • State history: every state change of every workload is kept (history_days, 400 days by default). The workload view's History card shows 24 hours, 7 or 30 days: the asleep share, the wakes (median and longest), the phases of each day and what started each one.
  • Workloads: a bar of each workload's time in each state over the last 7 days, with what its naps saved. The Workloads view's header has the same bar for all workloads, from figures kept an hour (states_cache_minutes).
  • The workload view: its actions in one menu. Each backend and target with its id, ARN and service in a tooltip, a backend with its list price and its saving a month.

Failures and alerts

  • Failed wakes say why (no capacity, quota, permission, configuration, no healthy target, throttled, timeout), with the step, the backend and AWS's message. A launch that cannot happen fails at once instead of at the wake timeout.
  • Capacity: a start refused for capacity is tried again within the wake timeout, and an EC2 instance can fall back to other instance types (fallback_instance_types, or the onboarding dialog). Between failed wakes, requests retry after failed_retry_seconds, doubled after each failure. The waiting page says what happened and when the next attempt is.
  • Health alerts: every 5 minutes the manager checks what each router reports. A router that stops reporting or reports a problem, and each failed wake, opens an alert sent to alert_emails and to any subscription of the alerts_topic_arn topic, with a chat body for Amazon Q Developer in chat applications and attributes for subscription filter policies. The Overview lists the open alerts.

IP lists and security

  • IP lists from the manager (ip_lists): downloaded once for every router, checked (a version that lost more than half its entries is refused) and published to a bucket your organization's routers read every 5 minutes. A catalog change reaches them without an upgrade.
  • Two-step verification (mfa): administrators and operators set up an authenticator app from the Account page. Users shows who has it, and an administrator resets another user's lost authenticator.
  • A workload behind a rule that authenticates with Amazon Cognito can be onboarded, napped and woken.

Dashboard

  • Routers have their own view: version and upgrade, health and alert, workloads by state, pauses, and the configuration with where each setting is changed.
  • A workload's state shows with an icon, its own color and a tooltip, dated from when it began. Failures show on the workload view.
  • Toasts say what an upgrade, onboarding or offboarding started and how it ended, linking to its steps in Operations. Discovery shows an operation running on a candidate.
  • Router health no longer blames infrastructure as code for every drift repair. Each of its problems carries a stable code.
  • Audit: a long action or target is cut on one line, its full text in a tooltip.

0.3.0

2026-10-06 · router 0.23.0 · SHA256SUMS

Access

Apply the access module or the AWS CLI script of this release again in every member account: the discovery role reads CloudTrail trails and its own role's tags, the command role passes the forwarder's role to EventBridge.

  • Event-driven discovery refresh, off by default (Perimeter settings): the manager connects the ready accounts with a CloudTrail trail (a forwarder: a role and a rule per region, by API calls through the command role). Their load balancer changes appear within about 5 minutes. Turned off, the forwarders are removed. Before uninstalling, turn it off and let a run disconnect the accounts.
  • Accounts set up for discovery only (the access module with create_command_role = false, or the AWS CLI script without a command role) say so on their discovery role: the manager counts them apart and refuses onboarding there with that reason.

0.2.2

2026-10-06 · router 0.22.6 · SHA256SUMS

Access

Nothing to apply again in the member accounts.

  • Without an SES identity, invitations from the dashboard go out at once through Cognito.
  • deletion_protection protects the table (installed routers, operations, audit) as well as the users.
  • The functions' code ships zipped in the release: nothing is written in your configuration at plan time, so a plan applied in another job or by HCP Terraform works.
  • The organization module keeps the organization's other statements of its one delegation policy (additional_statements). The AWS CLI procedure merges with the current policy and removes only Dormeto's statement.

0.2.1

2026-10-06 · router 0.22.6 · SHA256SUMS

Access

Nothing to apply again in the member accounts.

  • Development installs (the smoke-test user, without a custom domain) no longer fail at apply.

0.2.0

2026-10-06 · router 0.22.6 · SHA256SUMS

Access

First release: create the roles with the access and organization modules, or the AWS CLI script, of this release.

  • Installed with a Terraform module from a release, carrying the manager's built code and the router it installs. Optional custom domain and SES identity. deletion_protection for the users.
  • Organization access without CloudFormation: the access and organization modules or the AWS CLI script, shared by several environments. Both roles checked at each discovery run. Onboarding and router installs refused where the command role is missing.
  • Scale to 1,000 accounts: routers push their state, discovery fanned out by account, bulk onboarding.
  • Onboarding, offboarding and router installation by API calls. Router management (health, pause, exclusions). Organization discovery with filters and multi-rule workloads.

Earlier versions were not released.