v0.23.0

carlos v0.23.0 (platform 3ca43d33, 2026-10-05)

• A deploy reaches a running instance in seconds. When a box adopts a new release, an instance that is awake restarts onto it within a few seconds. Before, it kept serving the old build for about two minutes, longer than carlos deploy waits, so a deploy could report a timeout and a restart seemed to be needed. Instances on one box restart one at a time, two seconds apart.
• Static sites show a deploy on the next page load. Browsers now check with the edge before reusing a page or file from a static site, and get a quick "not modified" answer while nothing has changed. Before, a browser could keep showing the old page for hours or days after a deploy.
• Read a copy of an instance's database. carlos db pull --app <a> --out <file> saves a copy of a sleeping instance's database on your machine, and carlos db query --app <a> --sql "…" runs one query against a fresh copy. Both say how recent the copy is. The copy is read-only and never touches the live database. Name an instance with --instance when the app has more than one.
• Region flags. carlos apps create, carlos deploy and carlos canary take --region. A console that is not assigning app regions yet says so and starts the app in its home region. carlos deploy --region on an existing app stops before shipping if the region differs from the app's own. The line carlos instances create prints now names the place the instance runs.
• Invite links ask before you join. Opening an invite link shows who invited you and a Join button. Nothing happens until you press it.
• Sending domains you did not set up. If a domain already has a sending identity that your account did not create, carlos email domains add asks you to prove you control it: publish a TXT record at _carlos-mail.<domain> with the value carlos-mail-account=<account>, then add the domain again. A domain another account holds now reads "sending domain unavailable". A claim that is not verified within 7 days can be taken by another account.
• Stores no longer share a bucket by accident. App and environment names are joined with "-", so app shop with environment eu and app shop-eu used to map to the same bucket. The second one is now refused with a 409, and nothing is created.
• Platform domains. An operator can attach one of the deployment's own domains to an app with carlos domains attach --platform. Members cannot attach, change or detach those names.

For operators

• Roll the boxes, then the console. With the new switches left off, either order is safe. The two switches below need every box on v0.23.0 first.
• Leave CONSOLE_SECRETS_ENVELOPE_V2 off until every box runs v0.23.0. When it is on, the console seals new secrets so they open only for their own account and app. A box on an older release cannot open them, and the app's whole config stops updating on that box. Rolling a box back below v0.23.0 after turning it on does the same. A value that is not true or false stops the console from starting.
• v0.23.0 is the first release that understands app regions. That makes it the rollback floor the README describes: once any app holds a region other than the home, do not roll the console below v0.23.0. CONSOLE_APP_REGIONS is off by default. Turn it on only by the README's steps. Boxes now publish serves_shared_pool, accepts_inbound and, where they hold the secrets key, secrets_key_fp in their edges file.
• Boxes restart awake instances when they adopt a release. The agent checks every two seconds and restarts at most one instance per check. Workers still converge on the old 90-second timer. A restart drains the old process as before: new requests wait for the new one.
• Static responses change their headers. They now carry Cache-Control: no-cache and a weak ETag worked out from each file's bytes and type, and no Last-Modified. The first request for a file after a deploy reads it once to work out the tag. The edge's own cache still does not store static responses.
• Pin infrastructure modules to v0.23.0. The box role gains permission to list, read and delete object versions in its own data bucket. Nothing uses it yet, so applying it can wait. Check also that nothing in your policies denies s3:DeleteObject on the deployment bucket: purges, store teardown and mail claim release delete objects, and fail without it.
• Run carlos accounts migrate with a v0.23.0 CLI. Pointers are now signed for their account, and migrating re-signs them, which needs the root CARLOS_RELEASE_KEY. An older CLI copies them unchanged, and the moved app stops adopting releases.
• Existing data is left in place. Purging an app now also deletes its tokens, door keys and ledgers, but apps purged before this release keep theirs. Removing a sending domain that was added before this release leaves its SES identity in SES. Moving an app revokes its door keys, so moved apps need new ones.

Verify a download against SHA256SUMS.txt; SHA256SUMS.txt.sig is the ed25519 signature (base64) over that file, checked by carlos update against its embedded key.