Installed and upgraded as one folder. Nibble lives in vendor/nibble and loads as a Rails engine; an upgrade replaces that folder and leaves the rest to the site.

What’s new

• bin/rails nibble:version prints the release a site runs, and says so when the install record in config/nibble.yml names another, as an upgrade that didn’t finish leaves it. It answers without booting the site.
• bin/rails nibble lists every Nibble command, the grouped ones (nibble:admin:*, nibble:schema:* and the rest) included, with their full descriptions, under a header naming the release, the site’s install record, its theme, the release whose behaviour it has switched on (load_defaults), the Ruby, Rails and Node it runs on, and the theme, schema and content format versions.

What’s fixed

• The release feed carries every release, not the latest 25, so the oldest releases keep their notes and their pages on the documentation site.
• The asset build bundles the theme NIBBLE_THEME names, as the server renders it. The build read config/nibble.yml first and the server read the environment first, so a site choosing its theme by environment served one theme’s pages with another’s assets. An image build takes the theme as the NIBBLE_THEME build argument. Upgrade: if your theme comes from NIBBLE_THEME, re-render Dockerfile when the upgrade offers it and pass the theme under builder: args: in config/deploy.yml.
• Tests follow config/nibble.yml, whatever NIBBLE_THEME a shell exports for running the site.
• bin/dev renders pages on the server with the theme you are working on. It rendered them with the last production build in public/vite-ssr instead, whichever theme that was built for, so a view that build lacked failed with “Page not found” and the rest showed stale markup until the browser replaced it. Server rendering now goes through the Vite dev server whenever it is running.

Changed

• Nibble lives in vendor/nibble/. What was under lib/nibble/, lib/commands/ and lib/middleware/ moved there, and loads as a Rails engine: the Gemfile evaluates vendor/nibble/Gemfile. config/application.rb is plain Rails, config/initializers/nibble.rb is gone, and lib/ is yours. Ejected screens are copied from vendor/nibble/frontend/. Upgrade: re-render Dockerfile when the upgrade offers it — the old one copies vendor/ in a way that no longer installs Nibble’s gems.
• Everything of a site’s own that Nibble reads lives in site/. schema/ is site/schema/, content/ is site/content/, a site’s theme is site/themes/<name>/, and control panel overrides are site/cp/pages/ and site/cp/slots/. crumbs ships in vendor/nibble/themes/ and is used from there unless site/themes/crumbs/ exists; nibble:generate:theme copies it into site/themes/. Upgrade: git mv schema site/schema, git mv content site/content, git mv site/pages site/cp/pages, git mv site/slots site/cp/slots, and git mv themes/<yours> site/themes/<yours> for a theme of your own.
• Generated types are site/types.d.ts, imported as @site/types, rather than a file inside the active theme, so a theme that ships with Nibble is never written to. Upgrade: in your theme, replace imports from '../.nibble/types' (at any depth) with '@site/types', delete its .nibble/ folder and run bin/rails nibble:schema:types.
• What Nibble needs from Rails’ configuration comes with Nibble. Its initializers (Inertia, WebAuthn, the media inflection, the assets prefix, the baseline content security policy) and its production settings (storage service, Solid Cache and Solid Queue, mail from SITE_URL and SMTP) are part of the engine, and its recurring jobs are read from vendor/nibble/config/recurring.yml. A site’s own config/ holds Rails’ defaults, which it can change and which win over Nibble’s. Upgrade: re-render CLAUDE.md when the upgrade offers it. If you changed any of the moved initializers, put your change in an initializer of your own.
• Taking a release is bin/rails nibble:upgrade; bringing a database up to it is bin/rails nibble:prepare. The first was bin/nibble-upgrade, a script beside yours; it is now a command that ships with Nibble. The second was called nibble:upgrade, and is named after Rails’ db:prepare, which it stands in for when a server starts. Upgrade: in bin/docker-entrypoint, or wherever your deploy runs it, change nibble:upgrade to nibble:prepare, and take releases from now on with bin/rails nibble:upgrade.
• A site is installed from a release, not a clone. curl -fsSL nibble.ink/install.sh | bash asks for the site’s name and makes its folder from it, downloads the release’s archive, checks it against the published checksum, unpacks it into vendor/nibble and writes every other file from its templates, starting from the gem and npm versions that release was tested with. It works from any shell, fish included, and no longer needs git.
• An upgrade replaces vendor/nibble with the next release. bin/rails nibble:upgrade downloads the release and checks it against its published checksum, then hands over to that release’s own upgrader, so a fix to upgrading applies in the release that ships it. It refuses if Nibble’s files were changed in place (eject what you need to change), checks the release’s Ruby, Node and theme requirements, snapshots the database, swaps the folders (the old one stays in tmp/), migrates, offers the site files whose templates moved on and reports ejected screens whose originals changed. It no longer needs git, and no longer merges anything. Upgrade: a site installed by cloning has no vendor/nibble/MANIFEST, so it can’t take releases this way. Install a fresh site from this release and move your site/, app/, db/migrate and settings into it.
• A new site’s credentials include a secret_key_base. Without one, production refused to boot. Upgrade: if bin/rails runner 'p Rails.application.credentials.secret_key_base.present?' prints false, add secret_key_base: <the output of bin/rails secret> with bin/rails credentials:edit.
• Installing with --defaults records the answers it used, so later upgrades can offer the files rendered from them.
• A site’s own Ruby and tests live where Rails puts them. site/initializers/ and site/test/ are gone, and so is Gemfile.local: a site’s config/initializers/, test/ and Gemfile are its own now, and a new site starts with Rails’ test/test_helper.rb. The notes that were in site/schema/README.md and site/content/README.md are in site/README.md. Upgrade: move site/initializers/*.rb into config/initializers/, site/test/ into test/, and the gems in Gemfile.local into Gemfile.
• Nibble’s files changed in place are found by checksum. bin/rails nibble:check compares vendor/nibble with the release’s MANIFEST and names any file changed there, which the next upgrade would refuse to replace. The install record no longer holds a git commit, and nothing in Nibble needs git.
• Nibble’s record of a site lives at the end of config/nibble.yml, below a line that says so: the release it is on, the install’s answers and what it ejected. Only that part is ever rewritten, so your settings and comments above it stay as you wrote them. .nibble/ is gone. Upgrade: add # Written by Nibble from here to the end of the file. Your settings go above this line. as the last line of config/nibble.yml; under it, install: with the keys of .nibble/install.yml indented beneath, then the ejected: section of .nibble/ejected.yml if you have one. Then delete .nibble/.