Nextcloud Cookbook stores recipes as schema.org JSON you can edit by hand

The file format is the schema.org Recipe format

The Nextcloud Cookbook app describes itself as a library for all your recipes, and the design decision that matters is that recipes are not rows in a database. They are JSON files following the schema.org recipe format, stored in the folder you configure in the app settings. That single choice does most of the work. The recipes folder can live in your Nextcloud storage, so it is synced to your other devices and available to any other client that can read the files. It is also plain text, so you can edit a recipe with any editor, diff it in version control, or write a script that touches every file. The cost is that schema.org is a general vocabulary rather than a recipe specific one, so a file contains fields that a cooking app does not use and may omit fields you would expect.

Pasting a URL triggers the parse and download

Adding a recipe does not require filling in a form. You paste the URL of the recipe, and the provided web page is parsed and downloaded to whichever folder you specify in the app settings. The parsing lives in a service class, and the project documentation points readers at the parse() method in lib/Service/RecipeExtractionService.php when they want to contribute. That pointer comes with an honest caveat: the parser is far from perfect, and the documented instruction for a site that has correct schema.org markup but is still read incorrectly is to help by improving that method and opening a pull request. So the import path is a starting point rather than a guarantee. The application layer underneath it, which stores the file and indexes it, is the part that behaves predictably.

The database is an index, the files are the truth

The FAQ explains a failure mode that confuses new users. Recipes are only shown in the user interface if they are present in the database, and it is likely that you have recipes that have not been indexed or added to the database yet. The first remedy is a button: Settings, then Rescan library, which compares the database with what is in your recipes folder and applies any differences to the database. If that is not enough, the documentation describes a heavier approach, a full non-incremental resync. You set your recipes folder to a different, ideally empty, folder to clear the database, and then set it back to what it was, which causes all your recipes to sync again. That the maintainers had to document a folder swap as the recovery procedure says something about how the index and the files can drift apart, and it is worth understanding that model before you import hundreds of recipes.

The project calls its users testers

There is a section in the documentation headed with the question of whether the app is production ready, and the answer is a warning rather than a reassurance. It says that users of this app are practically testers, that the team is limited on resources and still working out how to make the app function the best it can, and that there will be regressions and bugs. Constructive feedback is welcome when users run into problems. For an evaluator this is unusually useful information, because it comes from the maintainers rather than from a review. It also sets the right frame for the rest of the project: a community app with a moving target, where the recipe files remain yours and portable even when the app is not. The release history supports that reading, with versions v0.11.11 on 2026-10-05 and v0.11.12 on 2026-10-13, and the last push on 2026-10-20.

Clients, converters and the app store entry

The app works generally in any modern browser, which is the least remarkable and most useful property for a Nextcloud app. Around it there is a set of specialised clients and community-created tools, including mobile apps for Android and iOS and third-party converters and scripts, and the project keeps an overview of them in its documentation under clients. That overview matters more than it sounds, because the clients and the converters exist to work around the two rough edges: a client that renders the JSON in a nicer way, and a converter that handles sites the built-in parser cannot read. The app itself is published in the Nextcloud app store, with the project homepage pointing at the store entry rather than at a marketing site, and the documentation pages are published separately on the project's own documentation site.

A community converter is the fallback for sites that do not comply

The clearest alternative to the built-in importer is a community converter. When a download fails with a could not load recipe message, the documented reason is that a lot of websites are unfortunately not following the schema.org/Recipe standard, which makes their recipes impossible to read by the app, and the documentation points to a third-party converter built by the community for exactly that case. The difference in approach is worth stating plainly. The built-in importer fetches a page and runs it through the parse() method, which is generic and works whenever the page happens to include the right structured data. A converter sits between the page and the app and produces the expected shape from sites that do not, at the cost of being a separate tool you have to find, install and keep current. For the many sites that do publish schema.org Recipe markup, the built-in path remains the simpler one.

AGPL-3.0, the licence a Nextcloud app carries

The licence is AGPL-3.0, and the files say so in the SPDX form: AGPL-3.0-only OR AGPL-3.0-or-later, with a COPYING file and a LICENSES directory at the repository root, and package.json declaring AGPL-3.0-or-later as the licence. The AGPL is a strong copyleft licence, and for a Nextcloud app the practical question is what you do with the code and whether you modify and serve it over a network, which is where the AGPL network clause bites. That is a description of how the licence is shaped rather than legal advice, and the correct step is to read the COPYING file with your own counsel if you plan to fork, rebrand or host a modified version. The repository also uses the REUSE tooling, with a REUSE.toml and per-file licence sidecars, which is a good sign about how carefully the licensing metadata is maintained.

A Nextcloud app built with vite, jest and release-please

If you want to work on the code rather than just use the app, the repository layout tells you what to expect: appinfo/ for the app metadata, lib/ for the PHP backend, src/ for the front end, templates/, l10n/ and translationfiles/ for localisation, tests/, docs/, and a Makefile described as a generic Makefile for building and packaging a Nextcloud app which uses npm and Composer. The front end is a modern one. package.json names the package cookbook at version 0.11.12, declares the module type, points at src/main.ts as the entry, and the scripts are the usual vite, jest, eslint, prettier and stylelint set:

  "name": "cookbook",
  "version": "0.11.12",

The build and test commands are plain enough to read in the manifest:

    "build": "vite build",
    "ci-test": "NODE_OPTIONS=\"$NODE_OPTIONS --experimental-vm-modules\" npx jest --ci",
    "type-check": "vue-tsc --noEmit",

The PHP side carries psalm and phpunit configurations, with separate phpunit.integration.xml and phpunit.migration.xml files, and releases are cut with release-please, whose configuration and manifest sit in the repository root alongside a CHANGELOG.md. Translations run through Transifex, and the FAQ invites readers to register there to help translate the app or report errors in existing translations, which is the usual way a community project keeps a dozen languages alive.

Editorial conclusion

Adopt Nextcloud Cookbook if you want recipes living in your own Nextcloud folder as plain JSON you can edit, sync and version, and you are willing to keep the schema.org data tidy. Do not adopt it if you need a recipe app that reliably scrapes arbitrary cooking websites, since the parser is described as far from perfect and many sites do not follow the schema.org Recipe standard. Before you install it, read the production readiness warning, plan how you will handle the database index versus the files, and check the AGPL-3.0 terms in the COPYING file against how you intend to run it.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. nextcloud/cookbook on GitHub
3. Project website
4. README
5. Releases