Krantho is in active development and not yet published to npm. Read what that means today.
krantho
Get started
esc

Search the documentation and product pages. Type “theme” to switch themes.

Changelog

Changelog

What changed in krantho, month by month, while it is in development.

Krantho has not had its first release yet. Until it does, each month of development has one entry here: what was added, what changed and what was fixed, starting with what it means for a site built with krantho.

  1. v0.13.1

    Krantho 0.13.1

    Security updates for dependencies, Next.js included.

    • Next.js 16.3.8, with fixes for critical and high advisories
    • Updated image, HTML sanitising and SvelteKit packages
    Release notes

    This release updates dependencies that had known security advisories. It changes nothing in how you use krantho, with one exception for pages on Next.js.

    Changed

    • Next.js 16.3.8. krantho.com and the Next.js examples move from 16.2.10, which had critical advisories in image handling and in next/og, and high ones in server actions, rewrites and middleware. @krantho/server-next now needs next 16.3.8 or later.
    • A page whose tags were marked stale is rendered before it is served. With Next.js 16.3, a page that an edit made stale is not served once from the cache while it re-renders in the background. The first request after an edit waits for the render, and no visitor gets a page older than the edit.

    Fixed

    • Updated packages sharp (image processing), dompurify, @sveltejs/kit and their dependencies, to releases that fix their advisories.
  2. v0.13.0

    Krantho 0.13.0

    Edits made in production come back to git between releases, and the API answers signed-in people only on krantho.com.

    • Production edits come back to your repository as a branch you merge
    • CI jobs call the API with their platform identity, no stored secret
    • The API no longer answers anonymous reads of drafts, data and settings on krantho.com
    Release notes

    Content that editors change in production now has a way back to git, so the repository stays the durable copy. This release also closes anonymous reads of drafts and settings on krantho.com.

    Added

    • Production edits back to git. GET /api/changes lists the published pages editors changed since the last import, as the files that belong in the repository. krantho pull writes them on a new branch, cut from the commit the last import came from. You merge the branch with git, and the next deploy finds nothing to resolve. The guide is Bring production edits back to git.
    • A baseline commit with every import. A build writes the git commit into the content manifest, and the import stores it.
    • Sign-in for CI without a secret. A job presents the identity token its platform issues. The site trusts one issuer, one audience and the subjects you list in auth.workload, and the token can read GET /api/changes and nothing else.
    • A release check. Before a production deploy, the site's workflow checks that production's edits are in the files being released. KRANTHO_CONTENT_GATE sets fail, warn or off.

    Changed

    • A merged pull is not a conflict. A file that holds what production already has counts as unchanged, so a page edited in production and merged back through git imports without a conflict.
    • Exporting a collection's drafts needs an editor. Published export stays public.

    Fixed

    • Anonymous reads on krantho.com. The API answers signed-in people only. Crawlers keep robots.txt, the sitemap, llms.txt and the IndexNow key.
  3. v0.12.0

    Krantho 0.12.0

    Pages carry versioned metadata, Live mode is simpler, and enrichment writes only what a page says.

    • A page's metadata is saved and versioned with the page
    • A simpler Live mode, with Search and sharing in one block
    • AI enrichment writes only what the page states, and reports its tokens
    • Field types and SEO uses read in plain words
    Release notes

    This release gives pages metadata that is saved and versioned with them, simplifies Live editing, and makes AI enrichment more careful about what it writes.

    Added

    • Metadata with the page. The groups a collection declares are saved and versioned with each page. The editor's Metadata block shows them, with a read-only System line for status, version, language and who saved.
    • Search and sharing in one block. The side panel shows the search and sharing text of a page with each text's length under its field, measured against the site's limits.
    • Live editing with formatting and tables, and readable YAML in exported Markdown.
    • Panels that hide and resize. The side panel hides, both panels resize, and their widths are remembered. A site can keep its "Previewing drafts" notice out of the Live frame with showPreviewBanner() from @krantho/server-next.
    • Tokens and model for an enrichment job. The job's status, and Studio's run report, show the tokens used and the model that served it.
    • Enrichment on serverless hosts. A running job is saved, so any instance answers for it, and a job whose function stopped goes on from the pages it had not reached.
    • Structured data in new projects. create-krantho pages declare a structured data group when SEO is chosen.

    Changed

    • A page's own SEO is saved in its versioned metadata. It follows the page's draft and publish, and every language version of a page now shares it, because the old records had no language. The first request after the deploy moves existing SEO over.
    • Dates in metadata are UTC timestamps with a Z. A date alone is midnight UTC, an offset becomes UTC, and Studio shows the time on your clock. Runtime date fields are unchanged.
    • A status field no longer mirrors publication state. Status is a system field.
    • Enrichment writes only what the page says. For Schema.org properties, the model quotes the passage that supports each value, and a value the page does not support is left empty.
    • The enrichment skip list names kinds of field. By default it skips description, meta-description, meta-description-*, nav-*, footer-* and form-*.
    • OpenAI, Gemini, OpenRouter and Ollama take the schema as response_format, and fall back to the schema in the prompt for a model that refuses it.
    • Field types and SEO uses in plain words. The editor says "text", "yes/no", "image or file" and "sharing image" where it said string, boolean, media and og:image.
    • A simpler Live mode. The content list, Page & sections and Reach are no longer in Live, where the page and the header hold them.

    Fixed

    • Replacing a media file updates the pages that use it, including their sharing image, and says which pages it could not update.
    • An uploaded file reaches the API byte for byte on @krantho/server-node.
    • A saved light or dark theme is applied before the first paint in the example sites.
    • A new project serves the admin at /admin.
    • The site tree stops refreshing after ten minutes without interaction.
    • IndexNow announces a page only from a production server, and Studio's screens read summaries instead of whole documents.
  4. v0.11.0

    Krantho 0.11.0

    The assistant is complete, every AI provider has its own key and is on when it has one, and a quiet site no longer spends the database's transfer.

    • The assistant opens a chat beside any page, on the language model you configure
    • Every AI provider has its own key, and a provider is on when it has one
    • A key pasted in Setup is sealed before it is stored
    • Studio's site tree, the sitemap and llms.txt read far less from the database
    Release notes

    This release finishes the Studio assistant and makes the AI provider settings plain: add a key and the provider is ready. It also fixes why a site nobody was visiting could spend a database's monthly transfer.

    Added

    • The assistant. A chat opens beside any page. Ask it to find a page, draft one from a brief, rewrite a title or check a page's structured data. It works through krantho's own API as the person using it, so it can do nothing that person could not do. The Studio assistant covers turning it on, who can use it and what it sends to the model.
    • A provider of its own for the assistant. The assistant can use a different provider from the one enrichment uses, and its dialog lets you pick between the providers that are ready.
    • SEO findings at publish. Publishing a page checks its findability and structured data, and says what is missing.
    • Default request profiles. OpenAI's gpt-5, gpt-6 and o-series models, and Gemini, OpenRouter and Ollama models, work for enrichment and the assistant with settings taken from each provider's documentation. A site can override them, and a setting a provider refuses is dropped.
    • A secret vault for saved keys. A key pasted in Setup is sealed before it is stored. A key your deployment injects through the environment is never copied into the database.

    Changed

    • A provider is on when it has a key. Setup › AI provider shows what is ready and what a key would turn on. Each provider keeps its own model and base URL.
    • Every provider has its own credential, such as KRANTHO_LLM_ANTHROPIC_API_KEY or KRANTHO_LLM_OPENAI_API_KEY. The shared KRANTHO_LLM_API_KEY, CLAUDE_CODE_OAUTH_TOKEN and the saved llm.apiKey setting are no longer read. A key saved in Setup before this release must be entered again, and a deployment that sets KRANTHO_LLM_API_KEY needs the provider's own variable instead.
    • The sitemap and llms.txt are kept by a CDN for an hour and refreshed in the background, so crawlers do not wake the database.
    • .env.example names each provider's own credential.

    Fixed

    • A quiet site no longer spends the database's transfer. Studio's site tree read every document in full, body included, on each visit and once a minute while Studio was open. It now reads each page's metadata alone, about 40 KB where it was about 1.8 MB, and refreshes only while the tab is in view. The sitemap and llms.txt read no bodies, and the version history reads metadata.
    • The assistant's requests are accepted by Gemini, OpenRouter and Ollama.
    • The assistant's model picker and the model name share a row, so the name is not cut off.
    • Examples and the site are type-checked, and the errors that surfaced are fixed.
  5. v0.10.0

    Krantho 0.10.0

    Studio, the redesigned admin at /admin, with Live mode for editing on the page itself. Saving no longer changes the live page; publishing does.

    • Studio, the redesigned admin, with Pulse, Site, Structure, Media and Setup
    • Live mode edits a page as the site renders it
    • Saving keeps the live page; publishing promotes the saved version
    • Webhooks are configured in krantho.config.ts and retried on SQLite and Postgres
    • krantho.com shows Studio and how content moves between your repository and your database
    Release notes

    The admin your app serves at /admin is rebuilt as Studio, with the content model it needs underneath. Read the Studio page for a tour.

    Added

    • Studio. A new admin with five destinations:

      • Pulse shows what needs attention and the site's state.
      • Site lists every page of every collection, with its status, findability and locales.
      • Structure covers the site's structured data: each page's graph, rich-result checks and enrichment.
      • Media holds the library.
      • Setup holds collections, locales, the AI provider, webhooks, checkpoints and people.

      It has light, dark and system themes, and a command palette (Ctrl K or ⌘ K). It works the same on Next.js, SvelteKit and Express.

    • The editor's three modes.

      • Live mode shows the page as your site renders it. A text field is edited in the page itself, and a section opens in a markdown editor as wide as the section.
      • Structure mode is a form made from the collection's schema.
      • Data mode shows the search and social previews, the page's JSON-LD graph with where each value comes from, and the version history.

    • Live marks. The server packages, UI libraries and examples mark the elements a page renders, in previews only, so Live mode knows which element is which field. Live editing explains how to mark your own templates. Visitors get the same pages as before.

    • Publishing and edit locks. Saving keeps what visitors see, and publishing promotes the saved version. Edit locks are enforced on save. Collections can declare their designed sections.

    • On krantho.com. A Studio page with screenshots of each part of the admin, and a fifth How it works step on the home page and a section on the Deploy page showing how content moves between your repository and your database, with diagrams.

    • Webhooks in krantho.config.ts. Failed deliveries are retried on a schedule, and each send has a timeout. Delivery logging and retries work on Postgres as on SQLite.

    Changed

    • The default locale comes from the configuration. site.defaultLocale (or site.language) is the default in every store and in Studio. Setup › Locales chooses which of the configured locales are active.
    • The example apps render every published page through a general page template. Their shared content, Acme Consulting, names no real companies or people.

    Fixed

    • Media upload, register and delete now require the editor role.
    • Creating a document whose slug already exists in that locale answers 409, instead of saving over the existing document.
    • A runtime field is saved only when its definition is valid. A pattern that does not compile, or an enum with fewer than two values, is refused with a 400.
    • seo config set and set-site keep the scope's field mappings and page structure.
    • The home page's structured-data ids have one slash: https://example.com/#article.
    • The media library reads its references and figures in one request each.
  6. v0.9.4

    Krantho 0.9.4

    On Next.js sites, the breadcrumb trail a page passes to its structured data now reaches it, so the structured data states the trail the page shows.

    • Breadcrumbs in the structured data match the page on Next.js sites
    Release notes

    A fix to 0.9.3's page structure, found when checking the release on krantho.com.

    Fixed

    • Page structure on Next.js sites. In the Next.js adapter (@krantho/server-next, included in @krantho/next), the trail, sequence and kind a page passed to <SeoJsonLd structure> did not reach its structured data, which kept the Home › page breadcrumb. They now do, and each cached graph is kept per structure.
  7. v0.9.3

    Krantho 0.9.3

    Structured data is now checked against Schema.org and the rules search engines publish, every value has one source, and a page's structured data states the breadcrumb trail it shows.

    • Structured data checked against Schema.org and each search engine's rules
    • The SEO editor shows every value and where it comes from
    • Breadcrumbs in the structured data match the page
    Release notes

    Structured data should describe a page correctly, not only be present. This release checks every graph krantho composes, and fixes what the checks found.

    Added

    • Checked against Schema.org. Every structured-data graph is checked against a pinned Schema.org release: references that point nowhere, duplicate identifiers, unknown or retired types and properties, and values a property does not accept. Moving to a newer release is one command, which lists what changed.
    • Search engines' rules, with their sources. Google's and Bing's rules are kept as data, each rule with a link to the documentation it comes from and the date it was checked. Findings say which search engine they come from. seo.readers in krantho.config.ts chooses which ones a site is checked against.
    • Values and their sources in the admin. The document SEO editor shows each structured-data value and where it comes from — the SEO settings, a content field, the page itself or the site's configuration — and the page's own address as the default canonical URL.
    • Page structure. A page can pass the breadcrumb trail, the set it belongs to and its kind to <SeoJsonLd structure>, and its structured data states the same. A collection can give its pages a default trail in _structure.yaml.
    • A check before start and before a build. The server refuses to start when the SEO configuration names a type it cannot use, and says which setting to change. pnpm run seo validate --config runs the same check before a build; pnpm run seo validate --all checks every published page and fails on an error.
    • A site's own types, search engine rules and page structures, registered with defineSeo.

    Changed

    • Site identity in one place. The organization's logo, description, alternate name and profile links are set in the site section of krantho.config.ts, and every entity that needs them takes them from there.
    • One set of length limits. The meta description and title limits come from the configuration, and the admin's editor, its score and the server's checks use the same numbers. The search result previews cut text where it overflows, as a results page does.
    • Retired search features are no longer offered. Types whose search feature Google has retired, such as FAQ and HowTo, no longer appear in the admin's type pickers. They remain valid Schema.org markup.
    • <SEOGraph> and composeGraph() take structure in place of breadcrumbs, and validateGraph() replaces validateRichResult().

    Fixed

    • An article's author pointed to a person that no page defined; it is now the site's person, or the organization when none is configured.
    • Articles now carry dateModified and their image, and the organization carries its configured logo.
    • The Next.js examples and the krantho.com site start again on Node 26, which refused the flag their dev scripts used to load .env.
  8. v0.9.2

    Krantho 0.9.2

    Every release now has its entry on this page, including 0.9.0 and 0.9.1, which went out without one. The published packages are unchanged.

    • The changelog covers 0.9.0 and 0.9.1
    • A release without a changelog entry no longer deploys
    Release notes

    The published packages are the same as in 0.9.1.

    Changed

    • Every release on the changelog. 0.9.0 and 0.9.1 were released without an entry here, so this page still showed 0.8.2 as the latest release. Both entries are now in place, and the release check refuses a version that has no entry, so the changelog keeps up with the releases.
  9. v0.9.1

    Krantho 0.9.1

    Image variants render on Vercel when the app is installed with pnpm. The deploy guide shows the one line of Next.js configuration it takes.

    • Crops, sizes and WebP or AVIF versions of media images render on Vercel with pnpm
    • The deploy guide shows the file tracing include they need
    Release notes

    Fixed

    • Image variants on Vercel with pnpm. The media library renders its crops, sizes and formats with sharp in the API function. Sharp loads its image library, libvips, by file path rather than with require, so with pnpm's layout Next.js left it out of the function, and every variant answered 500 with libvips-cpp.so…: cannot open shared object file. krantho.com now includes the library with outputFileTracingIncludes, and Deploy to Vercel shows the same line for your own app. The published packages are unchanged.
  10. v0.9.0

    Krantho 0.9.0

    krantho.com keeps its media library in Vercel Blob, so uploaded images survive every deploy. The published packages are unchanged.

    • krantho.com stores uploaded images in a Vercel Blob store
    • The Vercel deploy guide describes the Blob setup the site uses
    Release notes

    The published packages are the same as in 0.8.2. This release changes how krantho.com itself runs.

    Changed

    • krantho.com's media library on Vercel Blob. Uploads used to land on a function's own disk and were gone after the next deploy. The site now uses @krantho/media-vercel-blob with a public Blob store next to its functions, as described in Deploy to Vercel. Its infrastructure code sets the store and the three media settings; nothing else on the project changed.
  11. v0.8.2

    Krantho 0.8.2

    The SEO package ships with every deployment, so pages carry their full structured data and the admin's SEO tools work on hosts that deploy only traced files.

    • Pages carry their composed structured data on Vercel and other hosts that ship traced files
    • The admin's SEO catalog, preview and enrichment work there too
    Release notes

    Fixed

    • Structured data on Vercel. The server loaded @krantho/seo in a way the bundler skipped, so a deployment that ships only traced files left the package out. Pages then carried a plain WebPage instead of the site and collection entities configured for them, and the admin's SEO catalog, preview, validation and enrichment failed with "Cannot find package '@krantho/seo'". The package is now bundled with the server code.
  12. v0.8.1

    Krantho 0.8.1

    On Postgres, SEO configurations and the content import's record of files are stored as JSON objects again, so the SEO overview opens and pages carry their configured structured data.

    • The SEO overview in the admin opens on Postgres
    • Pages carry the site and collection structured data configured for them
    Release notes

    Fixed

    • SEO configurations on Postgres. A saved configuration was stored as a JSON string instead of an object. The SEO overview in the admin failed to open, and pages left out the site and collection entities configured for them.
    • The content import's record on Postgres. The files a deploy imported were stored the same way, so the next deploy could not tell a page an editor kept from one it should import. The record is now stored as an object.

    Changed

    • Converting data saved before this release. On a Postgres database that ran an earlier version, run these once after deploying 0.8.1. They convert each stored string back to its object and leave the rest alone:
    UPDATE seo_config SET config = (config #>> '{}')::jsonb WHERE jsonb_typeof(config) = 'string';
UPDATE content_manifest SET file_checksums = (file_checksums #>> '{}')::jsonb WHERE jsonb_typeof(file_checksums) = 'string';
  13. v0.8.0

    Krantho 0.8.0

    Content files that ship with a deploy reach the site's database without a reset, editors' changes stay as they saved them, and every part of the site has an address to share.

    • A deploy imports new and changed content files into a database that already has content
    • Pages an editor changed in the admin keep the editor's version
    • Cached pages refresh once after a deploy brings new content
    • The landing page opens with the install commands, the Claude Code plugin first
    • Every section of the landing page, docs and changelog has an address to share
    Release notes

    Added

    • Content changes ship with a deploy. The build writes content/manifest.json with generateManifest(contentDir, version), versioned by contentVersion(contentDir): the last commit that touched the content. When a deployment's version is newer than the database's, startup compares each file with its document and imports the new and changed ones. A checkpoint is taken first.
    • Install commands on the landing page. The page opens with how to get krantho: the krantho plugin for Claude Code, then the packages for Next.js, SvelteKit or Express. The packages reach npm with the first release.
    • Addresses to share. Every landing section, docs heading and changelog entry has its own address, and the address bar follows the part you are reading, so it can be copied as it stands. The docs' On this page marks the current heading.
    • Editors' changes are kept. A page an editor changed in the admin keeps the editor's version. When its file changed as well, the difference is recorded as a conflict, listed by GET /api/migrations/conflicts. A page deleted in the admin stays deleted.

    Changed

    • One announcement per content version. When the API handler starts, it announces a site-wide change once for each content version it has not announced, also when a page request imported the content first, so cached pages refresh.
    • The changelog is one page. Every release is an entry on /changelog, with its notes inline. Links to the former release pages lead to the entry.

    Fixed

    • Changed content files are imported. A deploy that shipped a newer manifest treated every changed file as a conflict and kept the old content, because the file and the database were compared by different checksums.
  14. v0.7.7

    Krantho 0.7.2 – 0.7.7

    Sitemaps dated by each page's own history, IndexNow notifications, the standard session flow for the admin, and one semver version for the whole repository.

    • Each page in the sitemap carries its own last-modified date
    • Search engines that use IndexNow hear about a page when it is published
    • The admin renews an expired session without a new sign-in
    • One semver version for every package, released as vX.Y.Z
    Release notes

    Released as v0.7.2 to v0.7.7 on 1 October.

    Added

    • IndexNow. With seo.indexNow.key set, the site serves its key at /<key>.txt and notifies IndexNow (Bing and the other participating engines) when a page is published, unpublished or deleted. A deploy can submit every page in the sitemap with submitIndexNow. Each submission is logged with the URLs it sent and IndexNow's answer.
    • One version for the repository. Releases are tagged vMAJOR.MINOR.PATCH, and every package, the krantho plugin and its skills carry the release version. create-krantho scaffolds the @krantho/* packages at its own version.

    Changed

    • The sitemap's dates are each page's own. A page's lastmod is when an editor last published it, or, for a page imported from a file and never edited, the file's last git commit (generateContentDates). It is written as a full UTC W3C Datetime, as the sitemap protocol defines it.
    • One sitemap builder. POST /api/seo/generate writes the same sitemap the site serves.
    • The admin's session flow. A visitor with a valid access token gets the admin. One whose access token has expired but who still holds a refresh token is sent through GET /api/auth/refresh, which renews the session and returns them to the page they asked for. Anyone else signs in.

    Fixed

    • HEAD requests. Every GET route of the API answers HEAD with the same status and headers and no body. /sitemap.xml and /robots.txt answered HEAD with 404 before.
    • robots.txt names the sitemap at /sitemap.xml, and the sitemap includes the home page.
    • The admin no longer answers 404 to a sign-in still in progress.

  15. September 2026

    Pages cached until their content changes, on Next.js, SvelteKit and Express; media on object storage; drafts previewed on the site; one typed configuration.

    • Next.js pages stay cached until a change in the admin invalidates them
    • SvelteKit and Express pages cached at CloudFront, Cloud CDN or Vercel, purged by tag
    • Media on Vercel Blob, S3-compatible storage or Google Cloud Storage
    • Editors preview a draft on the page itself
    • Pages render only the published version of a document
    • One typed configuration, from krantho.config.ts and the environment
    Release notes

    Development notes for September. These changes were released as v0.1.0 to v0.7.1 on 29 and 30 September; the packages are not on npm yet.

    Added

    • Typed configuration. @krantho/config resolves one configuration tree at startup: defaults, then krantho.config.ts, then the environment. Every problem is reported at once, naming the variable and the path. Secret values accept a _FILE variant and never reach the browser.
    • Pages cached until changed (Next.js). With cache.pages: 'next-isr', each page renders on its first request and stays in Next's cache until a change in the admin invalidates what it shows. The build never reads the database.
    • A shared page cache. With cache.shared: 'database', several Next.js instances keep one page cache in the site's own SQLite or Postgres database, through the cache handler in @krantho/server-next.
    • Pages cached at a CDN (SvelteKit and Express). With cache.pages: 'cdn', each page carries CDN cache headers and a tag for every read it made, and every live change purges those tags at Amazon CloudFront, Google Cloud CDN or Vercel. Next.js behind CloudFront or Cloud CDN purges /* after Next's own invalidation.
    • Preview on site. Editors open a draft on the page itself: through draft mode on Next.js, and through a signed link valid for ten minutes on SvelteKit and Express. Visitors keep the published page.
    • Media on object storage. Besides local disk, uploads can go to Vercel Blob, an S3-compatible bucket (AWS S3, Cloudflare R2, MinIO) or Google Cloud Storage, chosen by media.provider. Media metadata and folders work on SQLite and Postgres.
    • Content change events. Every committed write announces what it changed through onContentChange: publishing, unpublishing, bulk operations, restores, imports, media and SEO configuration.
    • Admin behind sign-in. With auth.oidc.adminEntry: 'redirect', /admin sends a visitor without a session to the OIDC provider and answers 404 to anyone refused.
    • Postgres settings for serverless hosts. Pool size, prepared statements and idle timeout are configurable, for deployments behind a transaction pooler.
    • Startup warnings. In production the server warns when the admin has no sign-in, or when sign-in is on without a shared signing secret.

    Changed

    • Pages read in-process. Page templates read content, SEO properties and JSON-LD through the content loader, from the database the API opens, instead of calling the site's own API. createContentLoader takes { config, collections } and imports the content on first open, whichever a fresh deployment serves first.
    • Sign-in on serverless hosts. The pending OIDC sign-in lives in an encrypted cookie instead of server memory, so the login and the callback may land on different instances. The authorization request carries a nonce, a confidential client can send its secret, and with sign-up closed, an address listed in adminEmails can still create the first account.
    • Enrichment defaults. Claude Haiku 4.5 is the default model for AI enrichment, and the Anthropic adapter accepts an effort setting.
    • Server-only code has its own entry. createContentResolver moves to @krantho/core/content, so the main @krantho/core entry no longer pulls node:fs into browser bundles.

    Fixed

    • A saved draft no longer replaces the live page. Pages read the version that is live; publishing moves it, and unpublishing, archiving or deleting takes the page offline. The same slug in two collections or locales is no longer ambiguous.
    • Concurrent cold starts on Postgres. Migrations are serialized with an advisory lock, so instances starting together on a fresh database no longer race to create the same tables.
    • A failed start is retried. An instance that met an unreachable database at startup retries on the next request instead of answering 500 until it is recycled.
    • The admin after a session expires. The admin's build files are served outside the sign-in gate, so a lazily loaded screen no longer fails once the access cookie has expired.
    • Server-rendered pages honor content.cache instead of a fixed five-minute cache.
    • Current Anthropic models. Structured output uses the API's native JSON schema support, requests no longer send temperature, and refusals are reported with their category.
    • SQLite-only features on Postgres fail loudly. Webhooks configured over Postgres are rejected at startup instead of failing on the first content event.
    • Preview redirects stay on the site when entering and leaving Next.js draft mode.

  16. July 2026

    One install per framework, a command-line client for content and SEO, and a fix that keeps admin sessions alive.

    • One package per framework to install
    • A command-line client for content, schema, SEO and snapshots
    • Media renames confirm and report the references they update
    • Admin sessions refresh as intended
    Release notes

    Development notes for July. Krantho has not published a release yet; these changes are on the main branch of the repository.

    Added

    • One install per framework. @krantho/next, @krantho/sveltekit and @krantho/node each pull in the server adapter, the admin, the local media store and the SEO package. They contain no code of their own; your files import from the packages they bring in.
    • A command-line client. The krantho CLI, written in Go, signs in to a site and works with its content from the terminal: list, read, create, update, publish and search documents; inspect the schema and add or remove runtime fields; export and import collections; check and run SEO generation and enrichment; manage snapshots; and edit a document in a terminal editor with vim-style modes.
    • Media renames in the admin ask for confirmation and report which documents had their references updated.
    • Sign-in with Zitadel for local development. A setup script provisions Zitadel as the OIDC sign-in provider; users and roles stay in krantho's own database.

    Changed

    • The admin moves to React Router 8, and the Material UI example to MUI 9.

    Fixed

    • Admin sessions refresh. The access and refresh cookies were folded into one Set-Cookie header, so browsers kept only the first and a session ended when the access token expired. Each cookie is now its own header, in every server adapter.
    • Saving a document with an empty body clears the body, and the editor keeps the document's locale on save.

  17. April 2026

    The media library, users and roles, version history with locking and webhooks, and the Schema.org archetype system with its graph browser in the admin.

    • A media library with folders, tags, crop, hotspots and an image optimizer
    • Users, roles and sign-in with sessions or OIDC
    • Append-only version history, content locking and webhooks
    • Schema.org archetypes at site, collection, route and document level
    • A JSON-LD graph browser and editor in the admin
    • create-krantho, plugins and localization
    Release notes

    Development notes for April. Krantho has not published a release yet; these changes are on the main branch of the repository.

    Added

    • Media library. Upload, browse and pick media in the admin, with folders, tags, bulk operations, replace, duplicate, usage tracking, renaming, and drag and drop into folders. An image editor sets a crop and a hotspot that aspect-ratio crops center on.
    • Image optimizer. /api/media/:id/image serves resized variants by preset, negotiates the image format, and caches the results.
    • Users and roles. Sign-in issues a session with refresh-token rotation; OIDC sign-in uses PKCE. Roles are admin, editor and viewer, enforced on every write, with user management in the admin.
    • Version history. Every save appends a version. Documents can be locked while edited, compared side by side with an earlier version, restored, exported and imported, with checkpoints, references between documents, locale fallback and translations.
    • Webhooks notify other systems when content changes.
    • Database migrations and content sync. SQLite and Postgres run numbered migrations. On startup, a content manifest imports changed files and records a conflict instead of overwriting an edit made in the admin.
    • Schema.org archetypes. Structured data is configured at four levels — site, collection, route and document — and composed into one JSON-LD @graph per page.
    • SEO in the admin. An SEO dashboard with a JSON-LD preview and the sitemap; a graph browser and canvas to inspect and edit the site's entities; JSON-LD import with a diff and the collections it affects; and a type detail view showing each type's properties and rich result status.
    • @krantho/ai, a dependency-free LLM client used by AI enrichment.
    • OpenAPI. The API describes itself at /api/openapi.json, with interactive docs at /api/docs.
    • create-krantho, a scaffolder for new projects.
    • Plugins add API routes under /api/plugins/<name>/ and hooks on content events.
    • Localization. Content is locale-aware, and the API filters by locale.
    • Runtime fields. A schema editor in the admin adds fields to a collection beside the ones defined in code.
    • Admin themes, light, dark or following the system, with a redesigned sidebar.

    Changed

    • UI packages renamed to @krantho/ui-react, @krantho/ui-svelte, @krantho/ui-mui and @krantho/ui-tailwind.
    • Standard fields. Pages use title; meta-description is a separate SEO field that falls back to description.
    • SEO configuration is stored as a list of structured entities, with one set of types shared across packages.
    • File watching moves into the server's development mode, and the separate hybrid persistence package is removed.

    Fixed

    • JSON-LD graph edits keep a stable identity while editing, and nested @id values are no longer saved into configured properties.
    • Pagination in collection lists counts documents correctly.

  18. March 2026

    The start of krantho — collections with Zod schemas, a REST API, a schema-driven admin, SQLite and Postgres persistence, server adapters for three stacks, and Schema.org archetypes.

    • Collections defined in code with Zod schemas
    • A framework-agnostic REST API and a schema-driven admin
    • SQLite by default, with markdown imported on first start, and a Postgres adapter
    • Server adapters for Next.js, SvelteKit and Node
    • Schema.org archetypes for JSON-LD
    Release notes

    Development notes for March, when the work began. Krantho has not published a release yet; these changes are on the main branch of the repository.

    Added

    • A workspace of packages. Krantho is a set of @krantho/* packages, each with its own dependencies so it can be published on its own.
    • Collections. defineCollection in @krantho/schema describes a collection with a Zod schema, and content is validated against it.
    • A REST API. @krantho/api handles listing, reading, creating, updating, deleting, publishing and validating content, independent of any framework.
    • Authentication modes — none, token and OIDC — and a version history API with restore.
    • The admin. @krantho/admin, a React application whose forms are generated from each collection's schema.
    • Persistence. SQLite is the default store, in .krantho/content.db; on first start, the markdown files of each collection are imported into an empty database. A Postgres adapter serves production deployments.
    • Server adapters. @krantho/server bridges the API to HTTP, with @krantho/server-next, @krantho/server-sveltekit and @krantho/server-node for each stack. Every example app serves the API and the admin.
    • Schema.org archetypes compose JSON-LD per page type.
    • SEO building blocks: a sitemap generator, Svelte components for JSON-LD, breadcrumbs and FAQ markup, and robots.txt and llms.txt in the examples.
    • AI enrichment with your own provider. The SEO tools call Anthropic, OpenAI or Ollama through one adapter.
    • Example apps for Next.js (Tailwind and Material UI), SvelteKit (two styles), React with server rendering, and a React single-page app, sharing one content set.

    Changed

    • No adapter layer. Components render plain HTML with semantic CSS classes, styled by the site.
    • Node ESM. Package imports carry .js extensions, so the packages load under Node's ES module resolution.

    Fixed

    • Svelte components CMSText, CMSMarkdown and CMSImage render content instead of placeholders.
    • Errors are logged where packages used to swallow them silently.