# RecipeSage: a recipe keeper, meal planner and shopping list in one app

> RecipeSage is a progressive web app for storing recipes, planning meals with a shared calendar and organising shopping lists, and it is one of the few self-hostable recipe managers that will import your collection from the apps you already used. The commercial and self-hosting arrangements are unusual, and so is the project's stated policy on generated code.

**julianpoy/RecipeSage** — A Collaborative Recipe Keeper, Meal Planner, and Shopping List Organizer in PWA form.

- Repository: https://github.com/julianpoy/RecipeSage
- Website: https://recipesage.com
- Stars: 977 · Forks: 111
- Language: TypeScript
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/julianpoy-recipesage

## Three jobs in one application

The description covers more ground than a recipe box, and the three parts are what a household actually needs.

The first is the recipe collection, with the promise of sharing and collaborating on recipes. The second is meal planning, with a drag and drop planner that can be printed and shared with family. The third is the shopping list, with automatic categorisation and intelligent grouping, so that adding a recipe to a list combines the similar items rather than producing a list with six kinds of milk.

The project describes itself as a collaborative recipe keeper, meal planner and shopping list organiser in progressive web app form, and the readme adds that you can import recipes from anywhere on the web instantly.

The collaborative angle is the part that distinguishes it from a personal collection. Meal plans and shopping lists can be shared between multiple people, and there are public profiles for sharing a recipe collection. For a household that means one person plans the week and the shopping list appears on somebody else's phone, which is the workflow that made the dedicated apps in this category worth the subscription in the first place.

The progressive web app form is a deliberate choice. The app feels native on every device and can be installed to the home screen, and the readme's own screenshots show the mobile view, so it is not a website that happens to work on a phone. The technical detail is in the dependencies, which include Capacitor for the native shell and Firebase messaging for push, and a store server library, so the same codebase ships as an installable application as well as a web app.

## The import list is the migration story

The import support is the longest feature in the readme, and it is the reason to look at this project at all if your recipes are somewhere else already.

The list covers a lot of ground. Dedicated recipe managers including Paprika, Mela, Crouton, Recipe Keeper, CopyMeThat, Cookmate, CookBookManager, Flavorish, Pepperplate, Living Cookbook, Plan to Eat, MyRecipeBox, Evernote and Tandoor. Then notes apps and document formats, which is a surprisingly useful category: Apple Notes, Google Keep, Google Docs, Microsoft Word, Obsidian, Notion, Joplin, Bear, Logseq and Simplenote. Then the interchange formats, JSON-LD and CSV.

That last group of notes apps is worth pausing on, because it covers the common case that dedicated recipe apps miss. Plenty of people keep recipes in a notes application or a document, and a tool that reads those is more useful than one that reads a rival recipe manager.

The other direction is handled too. Recipes can be created from any URL, an image, a PDF or plain text, and the automatic import from a website is delegated to a separate project called RecipeClipper, which is linked from the readme for the details of how it works. The extractors in the container image back this up: mdbtools for Access databases, poppler for text extraction from PDFs, and pandoc for the rich document formats.

Export goes to PDF, JSON-LD or text, and the readme frames that as data portability, which is the right framing for a project that wants you to be able to leave.

## The features that go past storing text

A recipe manager's usefulness depends on what it does with the recipe once it has it, and several of these features address real friction.

Nutrition tracking records calories, macros, vitamins and minerals per serving, and it will auto-fill by pasting a nutrition label. That is a genuinely clever shortcut: the label is already a table, and pasting it saves typing the numbers in.

The built-in AI cooking assistant answers questions about substitutions, techniques, conversions and recipe ideas. The dependency list shows three model provider SDKs in use, which means the provider is a deployment choice rather than a hard commitment, and the project is a hosted service as well as something you can run, so the feature is available either way.

Recipe scaling and unit conversion scale a recipe up or down and convert between metric and imperial, and the readme highlights that the conversion happens within the instructions as well as in the ingredient list, which is the part that matters, because a converted quantity in the list with a stale quantity in the text is worse than no conversion at all.

Search covers every field in every recipe and tolerates misspellings and similar words, which is what you need when you half remember a dish and not its name. Rich text is supported in the ingredients, the instructions and the notes, with bold, italic, underline, tables and embedded images, and there is a labelling and categorisation system for filtering.

There is also dark mode, and the readme makes a joke about it. The joke is the point: a kitchen app used at night is the normal case, not an edge case.

## Self-hosting lives in a different repository

The self-hosting story is worth reading carefully, because the two repositories have different purposes.

The readme recommends using the preconfigured docker compose files from a separate self-host repository, and is explicit about the distinction. You are welcome to configure or set up your own self-host config based on the main repository, but you may run into complications. The self-host repository is set up to be easy to spin up, while the main repository is oriented towards development.

That is a good structure, and it is also a warning. If you want to run RecipeSage, you are not running the application repository, you are running a deployment configuration that somebody else assembled for you.

The compose file in the main repository shows the shape of a deployment even so, and it is a substantial one. There is an nginx proxy in front of the frontend, the web app, the backend and pushpin. There is a PostgreSQL database, a Valkey instance for the job queue, and a separate grocery categoriser service, which is a small HTTP service on its own port. The environment block shows the rest: object storage buckets for recipe images, profile images, import data and data exports, a storage type setting, a database URL, the queue host, a Firebase credentials path, and an OpenTelemetry log level.

The presence of a dedicated categorisation service, a push notification service and a proxy means this is not a single container application. It is a small distributed system, and running it well is real work.

## The licensing is unusual in two ways

The licence section is short and it is the first thing to read.

RecipeSage is dual-licensed. For all non-commercial usage, RecipeSage is available for use under the terms of the AGPL-3.0 licence. For all commercial usage, RecipeSage is only available for licensing upon request, with an email address given for the request. The readme adds that pricing for commercial licences depends on usage, and that all associated fees and proceeds are intended to support the project and the community as a whole.

So the open source licence is not the whole licence, and the boundary is commercial use rather than a feature tier. If you run this at work, or in a business, you need a licence, and the readme is clear that a commercial licence is not something you can self-serve.

The second unusual element is the contributor licence agreement, and the readme explains why it exists. It allows RecipeSage to continue to provide the hosted instance, as well as to license the API to other projects that may not have licences compatible with the AGPL. And when you contribute or suggest code, you irrevocably grant the project all rights to that code.

That combination, an AGPL core with a commercial licence on top and a CLA for inbound contributions, is a coherent setup for a project that wants to keep a hosted service running while remaining open. It is also a setup with consequences for a company, and any commercial user should read the licence file rather than the summary.

The repository listing does not state a licence, and the package manifest for the workspace points at the readme instead, so the terms live in the readme and the CLA document in the docs directory.

## A stated refusal of generated contributions

The contribution guide contains a policy that is unusual enough to be worth quoting, and it has two halves.

The first half is about code. The maintainer states that he does not accept any AI-assisted code or pull requests, gives three reasons, and says again that he is very open to collaborating, just not with generated code. The reasons are practical rather than ideological. Generated pull requests almost always require significant changes, which costs him a lot of time. They effectively make him act through the contributor as a proxy for prompting, because he is feeding his own comments back through the contributor's prompt. And if he has not tackled something yet, it is probably because it is not trivial and needs thought and design.

The second half is about translations, where the rule is different and more interesting. Translations are contributed through a Weblate instance that syncs to the repository, and entirely generated translations are not accepted because they very frequently produce low quality and inaccurate results. But when using AI to assist with translations, the readme asks you to use DeepL or Google Translate and explicitly not to translate using ChatGPT.

That is a curious line to draw, and it is drawn deliberately: a translation tool is a translator, a code generator is a proposer of design. The readme's reasoning about code is about design decisions, and it is a reasonable argument that the person who writes the patch should be the person who thought about it.

The repository supports the policy with tooling rather than goodwill alone. There are husky hooks installed on prepare, an editor configuration, a prettier configuration, an ESLint configuration in the modern flat form, a Nx workspace configuration, Vitest workspace configuration, a Prisma configuration, and a CircleCI directory.

## The stack and the release line

The implementation is a modern TypeScript monorepo, and the dependency list is where the architecture is visible.

The front end is Angular 21, the back end is a Node service, and the native shells are Capacitor for Android and iOS. The database is PostgreSQL through Prisma, with the schema generated as a postinstall step when it is present. Object storage goes through the AWS SDK, with separate clients for S3, the library storage helper and a request presigner, plus the SES client for email. The AI features go through the Vercel AI SDK with provider packages for Anthropic, Google and OpenAI, which is what makes the model provider a configuration choice.

The workspace tooling is pnpm with a pinned package manager version, Nx for the build graph, Vitest for the tests, Husky for the git hooks, and the container image is built on an Alpine Node image with the system packages the importers need: openssl, the Access database tools, the PDF text tools, pandoc, the HEIF tools and inotify for the development watch script.

The release line is on version 4, with v4.0.15 in September 2026, v4.0.16 a few days later and v4.0.17 on 2026-10-10, and the last push on 2026-10-18. The engine requirement is a specific Node patch version, and the lockfile is committed with a frozen install in the image, so a build is reproducible.

There is also a hosted version, a documentation site, a security policy and a separate self-hosting repository, which is the shape of a project that has decided to be both a service and a piece of software you can run yourself.

## Conclusion

RecipeSage suits a household or a group of friends who want to share recipes, meal plans and shopping lists without handing their data to a commercial service, and its import coverage makes it a good migration path from Paprika, Cookmate or Tandoor. It is a poor fit for commercial use without a licence negotiation, since the AGPL covers only non-commercial use, and it is a poor fit if you want a repository that accepts generated contributions, because the maintainer refuses them explicitly. Before you plan around it, read the licensing section carefully, decide whether the self-hosting repository or the development one suits you, and check the import list against the app your recipes are currently in.

## FAQ

### Can I import my recipes from another app into RecipeSage?

Yes. The readme lists importers for Paprika, Mela, Crouton, Recipe Keeper, CopyMeThat, Cookmate, CookBookManager, Flavorish, Pepperplate, Living Cookbook, Plan to Eat, MyRecipeBox, Evernote and Tandoor, plus notes apps and documents including Apple Notes, Google Keep, Google Docs, Microsoft Word, Obsidian, Notion, Joplin, Bear, Logseq and Simplenote, and the JSON-LD and CSV interchange formats. Recipes can also be created from a URL, an image, a PDF or plain text.

### Is RecipeSage free for commercial use?

No. The project is dual-licensed, with the AGPL-3.0 licence covering all non-commercial usage, and commercial usage only available for licensing on request, with pricing depending on usage. The maintainer states that the fees are intended to support the project and the community.

### How do I self-host RecipeSage?

The readme recommends the preconfigured docker compose files in the separate self-host repository, and warns that the main repository is oriented towards development, so configuring your own from it may lead to complications. The compose stack in the main repository shows the shape: an nginx proxy, the frontend, the backend, pushpin, PostgreSQL, a Valkey job queue and a separate grocery categoriser service.

### Does RecipeSage accept AI-generated contributions?

No. The maintainer states that he does not accept AI-assisted code or pull requests, giving reasons about the time cost of reviewing them and about design ownership. Translations are handled differently: entirely generated translations are not accepted, but assisted translation with DeepL or Google Translate is, and the readme asks people not to translate using ChatGPT.

## Sources

- [Issues](https://github.com/julianpoy/RecipeSage/issues)
- [julianpoy/RecipeSage on GitHub](https://github.com/julianpoy/RecipeSage)
- [Project website](https://recipesage.com)
- [README](https://github.com/julianpoy/RecipeSage/blob/master/README.md)
- [Releases](https://github.com/julianpoy/RecipeSage/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/julianpoy-recipesage