0.0.2-alpha.69

On MySQL, Single and field-group tables made before their tables came from the schema pipeline hold a text field as TEXT, where the schema declares VARCHAR(255). Every db:sync and dev reload asked to narrow them in a terminal, and failed without one.

• db:sync, the dev reload and an admin schema save now count the stored values longer than N before narrowing a string column to varchar(N). When there are none, the change loses nothing and applies without a prompt. When there are some, the apply stops before any DDL and names the table, the column and the number of rows; shorten those values, or give the field a type that holds them, and apply again.
• nextly migrate, migrate:down, migrate:resolve and plugin migrations run each migration not marked -- nextly:no-transaction on MySQL with STRICT_ALL_TABLES added to the session's mode, and puts the session's mode back afterwards. A file that would cut a value short — such as the MODIFY COLUMN … varchar(255) that migrate:create writes after migrate:baseline adopts one of these tables — now fails with "Data too long" at that statement, which changes nothing (schema statements before it in the same file stay applied, as MySQL commits them), where a server without strict mode used to truncate the value with only a warning. A hand-written migration that relied on MySQL's non-strict coercion now fails the same way.
• The MySQL adapter's transaction() takes a new strictSqlMode option, which does this for any transaction. PostgreSQL and SQLite ignore it.

One comparison bar above it says which version is shown, what it is compared with (the version before it in its language) and how many fields changed, with Previous and Next change. Each changed field is marked with what changed; unchanged fields fold behind "Show N unchanged fields". While a version is shown, Back to current and Restore… replace Save and Publish in the title bar, and on a phone they sit in a bar at the bottom. The banner above a past version is gone.

The admin's unused localStorage autosave and draft recovery (useAutoSave, useDraftRecovery, DraftRecoveryDialog) are removed. Nothing called them since autosave moved to the server, and none was exported from the package.

If GitHub has no template for that release, the run stops and names --branch; if GitHub cannot be reached, it names --local-template. A branch name with a / now downloads too. - Adding Nextly to an existing app installs its packages at exactly that version, recorded exactly, after the packages they require alongside them, so pnpm with strict peers accepts the install. An app that already has a Nextly package at another version stops before anything is written or installed, and is told what to set: one declared as a range or at another version in any dependency field, or one it loads at another version, from its own node_modules or a workspace folder above it. - --branch no longer defaults to main: given, it takes the template from that branch, and the packages from the alpha tag, as --local-template does. --use-yalc still links local builds.

A project made before this release is not changed by it, and keeps the versions it declares. Before adding Nextly to an existing app, set every Nextly package it has to exactly the CLI's version.

Adding Nextly to an existing app records it too, but only when the app chooses no package manager yet and isn't part of a workspace.

A refused request's error.message names the action and the thing as the site names them: "You can't edit this post.", "You can't create posts.", "You can't edit Site Settings.", "You can't see API keys." The thing is a collection's label (one entry of it where the request names one), a Single's label, or a system resource in words. It never names a permission as stored (update-posts), a role, a rule or which check refused, and never repeats a slug the site does not know, so a URL cannot make a refusal echo it. The REST route gate, the Direct API, plugin services and the routes built on them answer this way.

Which check refused, and on what grant, is logged on the server at info ([nextly] Refused a request, with the reason and the request id the caller was answered with), and never sent.

A request that is not signed in, or whose session has expired, or whose API key is not valid, is answered "Authentication required." in every case; the code still tells an expired session (TOKEN_EXPIRED) apart, so the admin refreshes it as before.

One status changes. The standalone route handlers exported from nextly/api/* now answer a request presenting an API key while the key service is unavailable with 503 SERVICE_UNAVAILABLE, as the main REST handler already did; they answered 403. Every other refusal keeps its status.

A client that matched the old wording ("You do not have permission to …", "Access denied: …") reads error.code instead, which is unchanged.

GET /api/releases/calendar and nextly.releases.calendar() take a window of days (from and to, at most six weeks) in a named time zone and answer every day of it with the complete count of its releases by state and its first three releases in time order, so a calendar's "+N more" is always true. Days follow the zone's own clock, daylight saving included: a release at 23:30 in New York is on the next day in London. The list gains a day filter (day and timezone over REST, day: { date, timezone } from the Direct API) that returns one such day in full, paged, in the same order. A published release is on the day it went out, any other release on the day of its scheduled time. Both are experimental.

The releases table gains two indexes, on scheduled_at and on published_at, which the calendar and the day filter read by. nextly migrate adds them to an existing database. Index only, no data change.

A renamed Single's document reads its new slug, and content cached under either slug is refreshed. A rename onto a slug that still holds an earlier entity's records, or onto one longer than 50 characters, is refused, and document locks, preview links and kept permission answers end with the old slug, as do any an earlier entity left under the new one.

0 waits without limit. - Where it shows: route handlers, server actions, sign-in and the REST dispatcher answer DATABASE_BUSY. Collection and Single entry reads and writes answer DATABASE_BUSY too. A few entry paths still answer 500 INTERNAL_ERROR when it is busy: publishing every language of a Single, duplicating an entry, and a read whose locale, component or media step is the one that waits. - The error: DATABASE_BUSY, status 503, with data.retryAfterSeconds of 5 and a Retry-After: 5 header on REST. The statement or transaction that waited did not run. Anything the request committed before it stays committed, so a request that writes in several steps is safe to repeat only where those steps are. A collection or Single write, or a registration, that committed and then hit a busy database in a later step answers that the change was saved, without a retry hint. - PostgreSQL: the timing is unchanged; the pool already gave up after 15 seconds. What changes is the answer: it was a 500 INTERNAL_ERROR, and is now DATABASE_BUSY. - MySQL (behaviour change): a request that found every connection in use used to wait in mysql2's queue without limit. It now fails after pool.connectionTimeoutMs, unless you raise it. The time a new connection gets to open (connectTimeout) also moves from 10 to 15 seconds, so it matches PostgreSQL; a connection that cannot open in time is still a connection error, not DATABASE_BUSY. - SQLite: a transaction waits at most pool.connectionTimeoutMs for the one connection behind the transactions ahead of it. A write blocked by another process holding the database file past busyTimeout (SQLITE_BUSY) is now DATABASE_BUSY too, where it was a 409 CONFLICT. SQLITE_LOCKED stays a CONFLICT. - Retry-After: it is now set for any error carrying data.retryAfterSeconds, not only RATE_LIMITED. - For adapter authors: the adapters raise the busy error with the code NEXTLY_POOL_WAIT_TIMEOUT, exported from @nextlyhq/adapter-drizzle/types as POOL_WAIT_TIMEOUT_CODE, with poolWaitTimeoutError() to raise it.

See When the database is busy in the production guide.

Each link records its account (a new user_id column on password_reset_tokens and email_verification_tokens, with a foreign key to users). Changing an account's address revokes its links, so one sent to the old address stays dead even after the account moves back. Deleting an account removes its links, whatever address they went to. Someone later given an address is never reset or verified by a link sent to an earlier holder.

Issuing a link, following one, changing an address and deleting an account each hold the account's row for their transaction, so a link issued or followed while the account moves or is deleted is either revoked afterwards or refused. Following a link now checks it, applies it and spends it in one transaction, so two redemptions of one reset link cannot both set a password.

nextly migrate adds the column and removes every outstanding password reset link: a reset link may have been given any lifetime, and its stored times cannot show reliably when it was issued. It ties each outstanding email verification link to the account holding its address when that account was created and last changed before the link was issued, so those links keep working. A verification link whose account was created or changed at or after the time it was issued (on MySQL and SQLite, which store whole seconds, also in the same second) is removed, since it may have been sent to an earlier holder of the address, and so are expired links and links to an address no account holds. Their owners request a new link.

The edit ran in a transaction the SQLite driver refuses for asynchronous work, so it failed there with a server error before changing anything, while PostgreSQL and MySQL were unaffected.

Every query against a collection resolved its schema through a lookup that logged three lines, one of them the name of every registered collection, so a busy app wrote thousands of identical lines to its server log per burst of requests. A lookup that has to build the schema, or finds none, still logs as before.

A save slower than the autosave debounce let the edit's recording fire while recording was off, where it was refused, and nothing asked again; when recording comes back on and the editor still holds unsaved changes, a recording is now asked for again.

Before, creating such a user took the refusal for a missing table: it created the user without any custom fields and stopped writing custom fields for the rest of the process, and an update logged it and carried on. On MySQL, a unique field of a plugin type stored as text with no maxLength is now a VARCHAR(255) column carrying its unique index, as a built-in text field is, rather than a TEXT column (which MySQL cannot index without a key length) that stopped nextly migrate. A value longer than such a column holds is refused, naming the field, before it is written: before, it failed at the database and was taken for a missing table. An install where that column is already TEXT keeps it, with every value whole: nextly migrate stops, naming the field, until the column is changed to VARCHAR(255) or unique is removed. A plugin type stored as long text or JSON cannot be unique: the config is refused at the field, as a textarea's is, including when the plugin declaring the type is in the same config.

Every change that affects access retires what was kept, in every instance sharing the database, so the next request reads afresh: editing a role's permissions, assigning or removing a role, changing role inheritance, deleting a role, deactivating or deleting a user, and a role assignment expiring. A request that asks about a user again reads only the role version, and a request that asks several permissions reads the user's roles once.

Permission answers are no longer stored in the user_permission_cache table, and the userPermissionCache schema export is deprecated; the table is removed in a later release. PERMISSION_CACHE_ENABLED, PERMISSION_CACHE_TTL_SECONDS and PERMISSION_CACHE_MEMORY_SIZE no longer change how access is cached, and a warning says so when one is set. PERMISSION_CACHE_ENABLED=false still tells Nextly that no instance reads the stored answers, so they are not emptied when access changes.

That covers every Direct API method and namespace method, and both collection and Single routes, including the reads their render and buildMetadata make. A 50-entry list read through the Direct API or a plugin service costs the same access queries as a 1-entry list. A call made inside a request shares that request's lookups.

A list read whose collection has field-level read rules no longer repeats those lookups for every row it returns; a 50-entry list costs the same access queries as a 1-entry list. Any role or permission change the request makes is seen by its later checks. Work outside a request, such as a job, looks the caller up as before.

On a collection's or a Single's own fields, a field rule written as false now withholds the field from every checked read, and keeps it from being written by a checked write, like a function returning false. A checked call is one made with overrideAccess: false, as every REST and admin request is. Trusted server code, the Direct API's default overrideAccess: true, skips field rules, whether they are written as booleans or as functions.

Breaking at startup: an access key that its kind doesn't have now stops an app from starting when the collection, Single or field group is defined with defineCollection, defineSingle or defineFieldGroup, and fails nextly build. Entities written as plain objects, and those the Schema Builder stores, are not checked. Before, such a key was accepted in silence and governed nothing: the operation it meant to rule fell back to stored permissions.

The keys each kind accepts:

• A collection: create, read, update, delete, publish, unpublish.
• A Single: read, update, publish, unpublish. A Single has no create or delete, so a Single carrying either now fails.
• A field, in a collection, a Single or a field group: create, read, update.

Any other key, such as a misspelt reed or a Single's delete, is refused when the collection, Single or field group is defined, with ACCESS_KEY_UNKNOWN naming the key, where it sits, and the keys that kind accepts. To fix it, remove the key, or correct its spelling if it was meant to be one of the keys above. A field's access must also be an object whose rules are functions or booleans; any other value is refused at definition in the same way.

A collection's, a Single's and a field's rule now get locale, the one language the operation is in, and locales, every language it involves:

• a read or a write in one language gets that language; a read with an unknown or missing ?locale= is judged as the default it resolves to, and a write naming an unknown language is judged as the default and then refused with 400; a read's locales also lists each language a missing value falls back to, in the order it tries them; a bulk or transactional create or update writes the default language, and gets it; a duplicate gets the default language and each it falls back to, since it copies what a read of the source shows;

• a read that also reads each language's translation state (?translation-status=1, or a _translated filter) gets every configured language, keeping its own as locale, and so does an autosave, or a working-draft discard, naming a language the site does not configure; a bulk update by query, whose filter may choose rows by any language, gets every configured language too;

• a read of every translation (locale=all), a write to every language (locale=*), and an operation on the whole entry (a delete, a bulk delete, publishing or unpublishing every language, a release) get every configured language, with no single locale;

• content a collection or Single stores the same in every language (it is not localized and has no localized field group) gets every configured language, with no single locale, whatever ?locale= names;

• a site with no languages gets none.

So a rule can answer by language, such as update: ({ locales }) => !locales.includes("fr"), and a rule that limits someone to some languages refuses an operation that reaches beyond them. Write language rules as restrictions like that one, not as admissions by inclusion (locales.includes("fr")): where the languages an operation involves can't be known exactly, such as an operation that names none or a collection built in the admin, the rule is told every configured language, which a restriction refuses and an admission would allow. Restrict with locales, not locale: locale is absent for an operation on every language, and leaves out the languages a read falls back to.

The REST route gate is told the same languages as the service gate, from the request's ?locale= for an operation on one language's content (a history list filtered to one language among them), the default for a bulk write, and every language for any other. It reads them from the parameters the request is dispatched with, so a language named twice is judged as dispatched.

A collection preview link names no language, so minting or opening one asks the read rule in every language: a collection whose read rule closes any language can't mint entry previews until the preview path binds the link's language.

A rule that does not read locale or locales answers as before. Code that builds a rule's context by hand, such as a unit test of a rule, now gives locales too: [] where the site has no languages.

Nextly's own integration suites fail on such a statement. Nothing changes in a running application; with no harness listening, the check is a single property read.

The route-table comment keeps the rule and the runtime answers without the record of what an older published bundle did. The settings-sync component's explanation of its sibling shape is stated once, on the component, where the layout points at it, and the component's file is named after what it exports.

Its published types and JavaScript are unchanged.

What the components render and accept is unchanged.

Four new widget conditions say so: create:available, attention:readable, releases:present and content:present. Each condition's reads happen at most once per request. - One Content card, core/content, lists both collections (with their entries and drafts) and Singles. It replaces the Collections and Singles cards. A saved Collections, Singles or per-Single card becomes Content, at the first one's place, and the per-Single cards are no longer offered. - system:content answers Singles too, after the collections, each row saying its kind. - Saved dashboards convert through one retirement map, which now also covers ids minted per Single (single/<slug>-status). - New, @experimental: ReleasesService.anyReadable, whether a release exists that a caller may read, one row read through the list's own rules.

When those could not be read, a rule was handed empty lists. It is now not run: the request is refused with DATABASE_BUSY (503, retryable) when the read waited out pool.connectionTimeoutMs, and an internal error otherwise. A field rule whose caller's grants cannot be read is denied. - listRoleSlugsForUser and listEffectiveGrants throw a NextlyError when the read fails, where they returned an empty list. A caller with no roles or permissions still gets an empty list.

The editor sees it as a "Restricted or missing item" with its id, which can be removed but not opened, as at the top level; before, a save removed such links. A read at depth=0 now returns a to-many relationship inside a field group as an array of ids, as for every other field, rather than as its stored JSON text when the field's name is camelCase.

The edit page shows it as a "Restricted or missing item" with its id, which can be removed but not opened; before, a save removed such links. Populated reads are unchanged.

A queued email is stored, sent right away, and retried through the job queue when the provider fails temporarily, with backoff for up to about three hours (15 attempts); a failure that is not temporary fails it at once. Every attempt sends with the caller's idempotencyKey, or with a key of the queued email's own, so a retry after a lost response is not delivered twice where the provider takes a key. A template is rendered at each attempt.

A plugin can pass its transaction as tx: the email is then stored in that transaction, exists only if it commits, and is attempted once it has. An email stored but never attempted, because the process stopped, is sent the next time the jobs trigger (/api/jobs/run) runs, and the server log warns at startup and on each queued send when a queued email is more than 15 minutes past due because the trigger isn't running.

The message is held in a new email_queue table, sealed under NEXTLY_SECRET; the job carries only its id. nextly migrate and boot add the table on all three databases. Sends that are not queued are unchanged.

from and a new replyTo take effect on every way of sending.

The limiter stops reading such a body early and the handler reads the rest, which the client could hold open, so these bodies escaped the bound on how many are read at once. A request the limit refuses still gives its place back at once.

A producer a plugin started in init() is not waited for, so it never holds the command open.

When that work is still running after 30 seconds, the command now stops instead of carrying on. An uninstall stops before any DOWN migration drops the plugin's tables, which that work may still be reading, and the plugin stays uninstalling, so running the command again finishes it. Before, it warned and dropped the tables anyway.

Emitting an event doesn't wait for its handlers, so another plugin's handler (removing what it kept about each account an uninstall reports deleted, for instance) could be stopped part way. The uninstall's DOWN migrations then dropped the tables that handler was still working through, leaving its cleanup unfinished.

The published types and JavaScript are unchanged.

The published types and JavaScript are unchanged.

Where branding sets the chart colours, the admin checks each against the card, a bar's track and the tooltip, in light and in dark, and moves the lightness of one below 3:1 until it reads, keeping the brand's hue and never refusing it. The chart colours are now written per mode. @nextlyhq/ui/color gains readableOn (@experimental), the adjustment itself, with the target ratio as a parameter.

The server-rendered branding stylesheet sits later on the page and wrote the unadjusted colours at the same specificity, so it won; the admin's per-mode chart rules now outrank it. The content status widget draws its Published segment and dot in the brand's chart slot, held to 3:1 on the card, rather than in the brand's primary as given.

What they publish is unchanged: the same entry points, exports conditions and declarations. The plugin template that create-nextly-app scaffolds now builds with tsdown too, through a tsdown.config.ts in place of the tsup config. A plugin project now declares engines.node as ^22.18.0 || ^24.11.0 || >=26.0.0, where both tsdown and Vitest run, and create-nextly-app --template plugin refuses to scaffold on an older Node, with a message naming the floor.

The published types and JavaScript are unchanged.

The Builder stores field names lowercased, and the database's columns are named from the stored name, but the tables the running process reads and writes through were built from the name as typed, so every write in a language other than the default one failed with an unknown column until a restart. They are now built from the stored names, as a restart builds them. Nothing stored was wrong, so existing installs need no change.

A read looked up its collection's registry row several times, each a query of its own. The row is now read once and reused for up to a second, so a read of one entry sends 4 statements instead of 11, and a page of entries 5 instead of 13. That is a few milliseconds off every read on PostgreSQL and MySQL.

Reads return exactly what they did before. A change to a collection made in this process is seen at once. Changes to a collection made elsewhere (another instance, nextly migrate, a direct database write) reach every instance within a second. A read inside a transaction always goes to the database.

create-next-app 16.4 turns Cache Components on by default (cacheComponents: true with partialPrefetching: true). - A project create-nextly-app creates sets cacheComponents: false in its next.config, with a comment saying why. - When create-nextly-app adds Nextly to an existing app, it turns Cache Components off in that app's config and removes partialPrefetching, which Next.js accepts only with Cache Components on. Its report says what it changed and why. A setting it cannot read safely is left as it was, with what to change by hand. - withNextly() and Nextly's start print a warning when Cache Components is on, with how to turn it off. They don't refuse: an app with it on is untested with Nextly, not known to be broken. The start check reads the setting from the app's instrumentation.ts, which now passes cacheComponents: process.env.__NEXT_CACHE_COMPONENTS to createRegister; createRegister takes it as an optional second argument.

Why, and the plan to support Cache Components before Next.js 17: https://nextlyhq.com/docs/getting-started/installation#cache-components

Every answer they give is unchanged: where one still answers differently from the decision, it keeps its answer through a named difference, so a later change can remove each one on its own.

The schema builder's collection list now reads the caller's access once for the whole list, rather than once for each collection.

Only that card is asked again, and the change is announced once the card shows it. Settings saved outside customise mode are now kept for a reader who has never arranged their dashboard, who goes on following the default. Changing one card's settings no longer reloads every card on the dashboard.

Registered widgets cannot declare these settings yet: a registered widget's query applies only limit, so registration refuses them, as before. A stored choice the reader can no longer make opens at its default, with a line saying so, and "Reset to defaults" leaves a card's Collection as it is. A widget may mark one setting as quick; the mark is validated now, and the card header that shows it comes later. The workspace payload gains widgetSources, and widget source fields gain an optional groupable: false mark. New experimental type exports on nextly/config: AnyWidgetSetting, ContentSetting and PublishedContentSource.

It takes one tab stop; the arrow keys move through its bars or intervals, a polite live region reads the current point, and a tooltip shows it. Escape dismisses the tooltip wherever focus is, and a tooltip stays while the pointer is over it.

Where today's gate still differs from that decision, a named deviation keeps today's answer, so nothing a caller is allowed or refused changes.

Their published types and JavaScript are unchanged. nextly migrate:create --plugin now writes the migrations index with its type stated (PluginMigration[]), so a plugin built the same way can publish it.

Before, PostgreSQL returned the list as a string, SQLite returned it as an undecoded JSON string, and MySQL refused a save of more than one id. The column is now the JSON list column a hasMany relationship uses (jsonb on PostgreSQL, json on MySQL, text on SQLite), on every route that creates a component table. A single stored id reads as a one-item list.

Existing installs: a PostgreSQL component table holding the many-to-many as uuid or text, or a MySQL one holding it as varchar(36), is offered a one-time conversion to the JSON list column on its next schema apply, and migrate:create writes the same conversion into a migration file. Every stored id is kept: a bare id becomes a one-item list, a PostgreSQL array literal becomes the list it holds, and a JSON list stays as it is. On PostgreSQL a value that cannot be read (a malformed array literal) refuses the conversion before anything changes. A generated DOWN reads each list back as its id, and refuses a row holding more than one id rather than drop any. Until the conversion is accepted, saves to such a column may be refused. SQLite needs no conversion.

Compatibility: a Postgres component table already created with uuid gets a one-time uuid-to-text change on its next preview. Converting existing data is a follow-up for Mobeen; this release does not convert it.

A component placed directly in another component's fields is not stored where the outer component is stored on its own (at the top level of a collection or Single, or under rows, tabs, collapsibles or an unnamed group), and since alpha.67 a value for it there was dropped without a word. Where the outer component is held in a named group or a repeater, its whole value, the directly placed component included, is stored there and validated. Where it is not stored, now: - the admin no longer shows such a field in its forms; - a write that carries a value for one is refused with NOT_STORED (only an empty value, null, {} or [], passes); - defineConfig warns about each such field; - the Schema Builder no longer offers one there, and names any an existing field group holds. Put such a component in a group or repeater instead, where it's stored and validated.

Addresses written with combining marks (Devanagari, for example) and punycode labels in upper case are masked too.

Past a hundred collections the two lists cover different collections, and a counted one used to be dropped.

The admin asks only the cells a card's tier draws, and asks the rest when the card widens. - A cell's when is judged by the collection that cell reads once the settings apply. - Each cell is keyed by its declared query, so changing one card's settings asks that card again alone. - The settings preview asks the cells under the sheet's values. - A component's settings are the ones its query was asked with. A stored Filter, Sort or Group by that the query set aside is not handed on. effectiveWidgetSettings gives that reading, and KnobField is exported beside KnobContext. - Registration refuses: - a custom card declaring both a query and cells; - a widget offered per collection with no Collection setting; - an offered value outside its closed list ("per-collection", "on-request"); - a content setting that no cell's source lets a knob drive. - A timeseries with until draws its intervals up to that boundary, where its rows end. - Whether a caller has a release to read is asked once per batch, not once per collection.

All of it is @experimental while the content widgets are built.

Before, only widgets in the registry were checked, so a direct layout write could store text of any length on a widget a plugin contributed through its manifest. The settings sheet already refused it. The bound now comes from either channel, and where a registration and a contribution share an id it follows the admin's rule: the registration's settings wherever it states any, else the contribution's.

person on nextly.email.send, sendWithTemplate and a plugin's ctx.services.email accepts a staff user as { kind: "staff", id } (experimental).

On "database", every instance of the site counts one budget, where each used to count its own. - Keys are stored only as keyed hashes in the selected store. Client addresses, account ids and API key ids no longer reach the memory store, the database store or an app's LimitStore as given. An app's store of the earlier RateLimitStore contract still receives them as before. - Counts roll in 32 buckets per window. An attempt counts for one window from when it was made, and can be forgotten up to 1/32 of the window early. The sign-in limit used to slide exactly, and the REST limit reset its whole window at once. - An app's store of the earlier RateLimitStore contract keeps serving core's own limits, as before.

A store outage after a good start now refuses core's sign-in requests (503, "Please try again shortly."), on core's /auth/* endpoints and on plugin routes with rateLimit: "auth", while the REST API, API key and other plugin route limits let requests through. A store call that takes more than 2 seconds counts as an outage, and a call that never settles stops holding a place after 20 seconds, so once the store answers again its limits count again without a restart. Each outage is logged once when it begins and once when the store answers again. Before, a store failure failed the request. With an app's own store, an outage stops staff sign-in until the store answers, so monitor that store.

Existing installs see one new production warning, until they select the database store (rateLimit.store: "database") or say they run one instance (rateLimit.singleInstance: true). With only a store of the earlier contract, the warning says that plugin limits count in memory.

The memory store holds at most 100,000 live entries (rateLimit.maxEntries). When it is full and nothing has expired, a new key is answered as unavailable, so a sign-in from a new address is refused and an API request is let through.

From medium width it adds the published and draft split, and what scheduled releases will publish; at large width, the last 30 days against the 30 before. Each part links to the list that holds exactly it. - Offered per collection: a widget may declare offered: "per-collection". It is then never placed on the default dashboard, and any number of its cards may be placed, each starting with its collection. - Its query may name no source when a Collection setting supplies one. A custom card may declare several keyed reads (cells), each answered on its own, and handed to its component as cells. - Content settings reach the card's query: Filter (joined with any condition the widget declares), Sort, Group by and a Date range (since), each on a collection source. A stored Filter, Sort or Group by naming a field the reader may no longer use is asked with its default instead. - Widget queries take since and until (spans from a closed list, measured in whole UTC days or months from the batch's one instant). On a collection source, they take the entry list's workflow conditions _pendingChange and _inRelease at the top level. A release condition is answered "not available" for a reader with no release to read.

All of it is @experimental while the content widgets are built.

The published types and JavaScript are unchanged.

It lists every widget you may add in core's groups (Overview, Team, Plugins), with the cards you removed first so they can be put back where they were. You can search it by name, description, category, group or plugin (a removed card by its name or by its Removed section's text), and add several cards in one visit: each new card goes to the end of the dashboard and is ringed so you can see where it landed. A one-card widget already placed shows as on the dashboard. At the card limit, adding is turned off and putting a removed card back still works. The panel announces search counts and each card it adds. When it closes, focus goes to the last card added, or back to Add widget.

The layout read now gives each widget the panel offers a rank, its place in that order, so the panel can list a placed widget where it would be offered.

A card whose data is slow, or fails, no longer holds back the cards that read other sources. - POST /api/dashboard/query streams its answer when the request sends Accept: application/x-ndjson: one {"index", "slot"} line per card, written as each settles. Cards one source answers with a single shared call arrive together, as that call ends. Each line is the slot exactly as the JSON answer holds it, with its dates formatted the same way. A request without that header gets the same JSON answer as before. Both responses now send Vary: Accept. Anything that fails the whole batch (authentication, the body, the caller) still answers with the usual error before the stream starts. If the reader leaves mid-stream, the cards still running are told to stop through their signal. - The admin dashboard asks for the stream and draws each card as its slot arrives. A refresh keeps each card's numbers until its new answer lands, and only the cards still waiting show as loading. - The "is there content" check behind the content:empty condition and the onboarding "first entry" step now counts at most 8 collections at once and stops at the first one with an entry. It has a 5-second budget. When the budget runs out it answers "unknown", which is never read as empty: the empty-install cards are not offered, and the first-entry step stays open. Counts already running when it stops cannot be cancelled; they finish and are ignored.

A card below 340 px is small and from 700 px large, and the dashboard predicts each card's tier from its own width and the card's span before the first query, so each card asks only for what its tier draws. - A list or table card draws three rows, titles only, when small; its number of items with a line of detail when medium; and a table with a heading per column when large. When its answer holds more rows than it draws, it says "More exist", and for a list from one collection that is a link to the collection's list view with the card's filter and sort. - A breakdown draws its 3, 5 or 8 largest groups and says how many more there are, or that more exist when the answer itself was cut short. - An over-time card shows the latest value and the total over its range when small, dates its line's two ends when medium, and adds dates between them when large. - The Create card offers 2, 3 or 6 shortcuts and the rest in a More menu; the Team card shows the number of people alone when small; the Collections and Singles tiles take as many columns as the card fits. - A card whose width grows into a tier that draws more asks again on its own; a card that shrinks asks nothing. Nothing in a card is clipped and nothing scrolls inside it. - The entry list honours a sort in its address for a column its sort menu can order by.

A chart over time labels its value axis at zero and its highest value on medium and large cards, circles its latest point at every size and labels its value from medium up, and names several series in a legend. A chart of groups orders its groups by count, ties by label in the admin's locale, before a card's size cuts them, and colours each bar by its group's value, so a status is the same colour on every card. Each chart's text alternative states its range, total, latest and highest values, or its groups, total and the group with the most, saying when counts are lower bounds. The light theme's third chart colour is a step darker, so every chart colour holds 3:1 on a bar's track and on a tooltip as well as on the card.

A reader whose only collection is mid-migration, and who may not read releases, is no longer given a card that can only say "not available". - Create is offered only when it would offer a collection: one the reader may create in that does not turn creating off (admin.disableCreate, as form submissions do). A site whose only writable collection is form submissions no longer gets an empty Create card. - system:content keeps each row's kind whatever a query selects, so a collection and a Single that share a slug always stay apart.

Resetting the dashboard to its default also clears the outline on the card placed last, so a card the default reuses no longer looks freshly placed.

While a card is held, the other cards stay where they are, the held card dims, and a line shows where it will land: beside the card it will follow, or across the dashboard where it will start a row. The order changes once, on release. The keyboard works the same way: Space or Enter picks a card up, the arrow keys move it one place at a time, Space or Enter puts it down, and Escape cancels. Each step is announced, and so is the move with both positions. A moved, resized, added or restored card is outlined until the next change, and without animation for anyone who asks for reduced motion. Customize is now offered at every width. Where the dashboard shows one column, the handles are hidden and the card menu moves, resizes and removes cards, and the bar fits a phone. A drag in progress when the dashboard narrows to one column is cancelled, and says so.

In the add panel, a removed card is found by its widget's description, category, group and plugin, as the widget's own row is, and each visit to the panel starts with nothing announced from the last one.

Widget settings gain an experimental textarea type with a maxLength counted in characters (code points) by one counter, textLength on nextly/config, used by the settings sheet and the layout write alike. offered gains an experimental "on-request": a card added from the add panel only, never placed by default. A dashboard over its size limit is told "This dashboard is full: remove a card or shorten a Note".

The code is unchanged, and a test holds it equal to the adapters'.

A filter on createdAt, updatedAt or a date field of the collection itself with an ISO 8601 value used to answer 500 on SQLite, the admin's Created and Updated filters on every list among them. It now narrows the list and its count, as it does on PostgreSQL and MySQL. A bound with a fraction of a second is compared exactly on SQLite, which used to floor it to the second. On PostgreSQL, an instant written with an offset other than Z is compared as the instant it names, where its offset used to be dropped.

A date is compared with an instant with its offset (2026-09-01T09:00:00Z) or a calendar date (2026-09-01, the start of that day in UTC), read the same way on every database. Any other value, including a time with no offset, is now refused with a 400 validation error (FILTER_INVALID_OPERAND in its field errors) on every database, where PostgreSQL and MySQL used to pass it to the database to interpret.

This release only declares, validates, registers and types a definition. Nothing enforces it yet: content is not tracked through stages, no step can be taken, and publishing works exactly as before.

defineWorkflow, from nextly/config or nextly, declares:

• stages, one or more of them allowing publishing, but never the first, nor one the system moves content to without an approval;
• steps between stages, of kind submit, approve, request-changes or move;
• settings kept for later use: what an edit to approved content does, where the next draft starts, where removed stages go and whether approvals stand.

reviewWorkflow() is a ready-made Drafting → In review → Approved definition. Each definition is checked when declared. An error names its place and the known names, for example `steps[1].to: aproved is not a stage. Known stages: drafting, inReview, approved.`. A misspelt stage in a step fails to compile.

The workflow option on a collection or Single attaches a definition. It needs status: true and drafts enabled. An attachment that cannot keep a draft beside the live version is refused at boot, before anything is written, on hot reload, and in nextly build and generate:types. The refusal says which condition is missing.

Each attached workflow is registered with:

• a definition hash: sha256 of its structure, which labels and attachments don't change;
• the path of its nextly.config.ts.

generate:types and nextly build add a <Name>WorkflowStage and <Name>WorkflowStep union for each attached collection and Single, and a workflows entry in Config.

An internal, never-exported defineWorkflow for content states in lib/content-states is renamed defineContentStates.

Privacy note. Until this release, deleting a media item left its upload-time thumbnail stored, on local disk under public/uploads and on S3 and Vercel Blob, where it stayed publicly reachable at its old URL. (UploadThing was not affected.) To find those thumbnails, run npx nextly media orphans: it lists them by stored path and changes nothing, and you remove them by hand from the folder, bucket or dashboard they are in. Run it again with --apply to have it remove the ones whose place shows they are media's: it asks about each batch of files just before removing it, keeps any an item has come to refer to, and stops if it cannot check. On S3 it matches keys as written, so /media/... or media//... keys are never taken for media/... ones. Run it from the project's own directory to remove files: with --cwd naming another project, --apply refuses, since the database settings were read before it. It lists a file as left behind only under a prefix the media collection has to itself, one no other collection on any storage shares, contains, sits inside or begins. Without one, as by default, another collection or upload can store a file of the same form in the same place, so it lists what it finds there as files nothing shows are media's, and names any collection that shares media's place: check those with more care. The command looks only under media's prefix as it is now set, so run it before you give media a prefix: the thumbnails earlier deletes left stay where they were, outside it. It looks only at the storage the media collection uses now. If your site used another adapter, bucket or folder before, point the media storage at that one and run the command there too. The command leaves out thumbnails stored in the last hour, which may belong to an upload still in progress: if you deleted, before upgrading, an item uploaded less than an hour before you run it, run it again an hour later. On UploadThing, whose apps can hold other uploaders' files, it lists what it finds by file key and uploaded name: remove the ones that are yours from the UploadThing dashboard. Run it again after a delete whose log names a file it could not remove, or whose process stopped before it finished.

• Deleting a folder with its contents removes every file of every item in it and in its subfolders, once their records are gone. It removed none before.
• A file the storage refuses to remove is logged with its path and the media item, so it can be found.
• @nextlyhq/storage-uploadthing: a delete UploadThing refuses (an outage, a refused token, a rate limit) now fails, so it is retried and logged like any other, rather than read as done while the file stays stored. A file already gone is still not an error.
• A crop inside a plugin's ctx.db.transaction on SQLite removes the sizes it replaced once that transaction commits. They were kept before, stored indefinitely.
• A crop or rotation whose new sizes include thumbnail removes the thumbnail made at upload, which nothing refers to any more.
• A crop on SQLite saves its regenerated sizes. It failed before, because the sizes were written as an object the driver cannot store.
• A delete and a crop of the same item at once leave no file of the item behind, and two crops at once leave no file behind that nothing refers to.
• Storage adapters can now list their files (list(), optional). @nextlyhq/storage-s3, @nextlyhq/storage-vercel-blob and @nextlyhq/storage-uploadthing implement it; an adapter without it is reported as one that cannot be searched.

A Single's uploads were populated at every depth, and a junction field had no value at depth=0. Populated reads are unchanged.

A key still shows only its prefix after it is created, so none can be copied. - A key's owner (name and email) is shown only to someone who may also read users. A person always sees themselves on their own keys, and the admin's key list says "Hidden" for an owner it may not show. - update-api-keys renames any key, and delete-api-keys (or update-api-keys) revokes any key. Creating a key is still only for yourself. - The dashboard's key count covers every key, as the list does.

The Direct API's apiKeys namespace now honours overrideAccess: false, set on the call or on the instance, and judges its user by these same rules. It is now on await getNextly()'s instance too, as on the module-level nextly.

• Making or changing keys as an API key is refused.
• A checked call that names no user is refused with AUTH_REQUIRED.
• A call that names a different user is judged as that person, not by the instance's API key.

Compatibility: over REST, a person holding read-api-keys but not super-admin now lists every key where they listed only their own. A holder of update-api-keys or delete-api-keys can now change or revoke keys they do not own, where before they got 404. Through the Direct API, only calls that ask to be checked change; trusted calls, the default, behave as before.

nextly.roles.create, update, delete and setPermissions, nextly.permissions.create and delete, and nextly.fieldGroups.create, update and delete ask the permission the matching route asks: - roles: create-roles, update-roles (also for setPermissions) or delete-roles; - permissions: their own action, or manage-permissions; - field groups: their own action on settings, or manage-settings.

A super-admin passes. An API key is judged by its own grants. A checked call that names no user is refused with AUTH_REQUIRED.

Compatibility: only calls that ask to be checked change. Trusted calls, the default, behave as before.

Each is checked as the named caller against the same permission the matching REST route asks for, and refused with FORBIDDEN when the caller lacks it, before anything is written. A checked call that names no user is refused with AUTH_REQUIRED. A role change made this way follows the same super-admin rule as REST: only a super-admin may give anyone a role that is, or inherits, super-admin. An API key is judged by its own grants. Trusted calls, the default, are unchanged.

Two cases change. On a Single with Draft/Published, Mod+S used to save without naming a status; it now saves a draft, or stores changes to a published Single the way Save changes does. Creating an entry, Mod+S now saves a draft, as the Save draft button does, instead of saving with no status.

Submitting the full-page entry or Single form with Enter now saves the way Mod+S does: a draft, or the change to a published document. It never publishes, even where Publish is the leading button; before, it saved without naming a status. Whether Enter submits in a given field is unchanged.

useDocumentStatus() now reports the document's status inside the full-page entry editor, including from a plugin's document view. It returned null there before; the quick-edit modal and the Single editor already reported it.

The header's save indicator now reports the document's save; recovery points move into its tooltip. A new entry shows 'Unsaved changes' once edited.

After a save, an entry or Single shows what the server stored, such as a trimmed title or a rewritten page layout, rather than what was sent. Anything typed while the save was in flight stays on screen, still unsaved. A save that sent a link the editor cannot see keeps showing the form as sent, so the link is not dropped from the next save.

The Page Builder's screen now offers the document's Save and Publish (or Save draft) in its own top bar, the same actions the editor's header offers. And a passage still being typed in the builder is finished before any save, whether it was started from the keyboard, a button or a menu; before, only Mod+S finished it. Once its page is saved, the builder shows it as saved, and leaving no longer warns, until it is edited again. Its Save and Publish wait for a change the page depends on that is still being written, as the header's do, instead of ignoring the press.

A failed save's Retry belongs to the document and language it failed in: switching language, or to another document, clears it, so it can never store or publish a different translation. The Discard draft confirmation can no longer be dismissed while the discard runs. Confirming it twice before the dialog updates discards once. After a save, the editor stops offering a recovery point from before it. A save waits for every change the page depends on, including one started while it waits, and says so if changes keep arriving. A change that failed to save names itself and where to make it again, rather than offering a Retry that would fail the same way. For plugins, useDocumentActions().run("delete") now resolves once the delete is answered, with what it came to, and useDocumentActions() reports storedAt, when the document was last stored in this session.

A line consoleLogger writes without fields no longer carries an empty trailing argument.

Search production logs by domain and first character instead of the full address.

Brand settings (a logo and its width, an accent colour, the background and content colours, a font from an email-safe list, and footer text and links) are stored by core and read by GET and PATCH /api/email-templates/brand, which take the permissions to read and to update email templates. Core's default layout is now written in them, the buttons of core's built-in emails take the accent, and every layout and template can read them as the brand variable (brand.html holds the logo, footer and link markup they make). A background or content colour a site chooses is kept in dark mode too, where the default layout used to swap in fixed dark colours.

Nothing changes for an existing site until someone changes a setting: each setting starts from what the default layout showed, which renders every email byte for byte as before. On upgrade, the default layout and built-in emails still as core shipped them move to the new versions; ones a site edited stay as they are, as do the site's own layouts. GET /api/email-templates/brand says which emails the settings reach and why the others are not reached. In a layout's data, brand is always the settings: a send's own brand value still reaches the template body, but no longer a layout, and a template whose send supplies no brand reads the settings. The settings are also always available as nextly_brand, which core's built-in emails read, so a send carrying a brand of its own changes nothing in them; a send's own nextly_brand value is ignored. A template kept on the engine before Liquid now writes HTML marked as trusted unescaped, as Liquid does.