Tandoor Recipes: a self-hosted recipe manager for people with too many recipes

The problem Tandoor Recipes solves for people with a growing recipe collection

Recipes accumulate in incompatible places: browser bookmarks, screenshots, a notes app, email threads from relatives, and a stack of cookbooks nobody indexes. Tandoor Recipes exists to put that collection in one database you control. The README describes it as "the recipe manager that allows you to manage your ever growing collection of digital recipes", and the stated audience is people who want to share recipes with family and friends or simply store them in an organized way.

That framing matters because it sets the scope. This is not a publishing platform for a food blog, and it is not a social network. A basic permission system exists, but the README is explicit that the application is not meant to be run as a public page. If your goal is anonymous traffic and ad impressions, the project tells you to look elsewhere. If your goal is a private, searchable, shared-with-four-people cookbook, that is the target case.

The feature list reads like a list of the chores that follow a large collection. Meal planning across multiple meals per day. Shopping lists generated from the meal plan or straight from a recipe. Cookbooks that group recipes into collections. Tags you can assign in bulk to everything matching a filter. Merge and rename operations for ingredients, tags and units, which is the unglamorous work that keeps a collection usable after a few years of inconsistent entry.

How Tandoor Recipes works: Django, PostgreSQL and recipe-scrapers

The repository is a Django project. The top-level layout contains manage.py, a recipes/ application directory, a cookbook/ directory, a vue3/ frontend, an nginx/ directory and a Dockerfile. Dependencies in requirements.txt confirm the shape: Django 5.2.16, djangorestframework, psycopg2-binary for PostgreSQL, gunicorn as the application server, whitenoise for static files, and django-vite to build the Vue 3 frontend.

Import is the mechanism worth understanding. The README states that Tandoor imports recipes from thousands of websites supporting ld+json or microdata, the schema.org Recipe markup. The dependency list backs this up with recipe-scrapers, beautifulsoup4 and microdata, plus lxml for parsing and requests for fetching. So the flow is: you paste a URL, the server fetches the page, extracts the structured recipe data, and creates a record. Sites that do not expose structured markup are the ones that will fail.

Search is the other architectural choice. The README advertises fulltext search with TrigramSimilarity, a PostgreSQL feature, which is one reason the database is not swappable for SQLite in a serious deployment. redis and hiredis appear in the dependency list, and the project also ships django-prometheus for metrics, django-storages with boto3 for object storage, and optional integrations including django-auth-ldap, python3-saml, django-allauth with MFA and social accounts, and litellm for the AI features the README mentions.

That dependency list is long, and it is the honest measure of what you are operating. This is a full web application with background concerns, not a single binary.

Installing Tandoor Recipes with Docker and importing your first recipe

The README points installation at the Docker guide under docs.tandoor.dev/install/docker/, and the repository ships a Dockerfile plus a .env.template at the top level. The Dockerfile builds from python:3.13-alpine3.23, exposes ports 80 and 8080, and sets DOCKER=true in the environment. It also installs nginx inside the image and symlinks Tandoor's http.d configuration directory into nginx's config path, so the container serves the application itself.

The repository does not contain a complete docker-compose file in what is available, so the exact compose service definitions come from the documentation rather than from this article. What the repository does give you is the environment template. Copy it before starting anything:

cp .env.template .env

The Dockerfile removes development dependencies by truncating requirements.txt at the "# Development" marker, so the image does not carry pytest, flake8 or yapf. That is a deliberate build step, not an accident, and it means the production image is smaller than a naive install of the full requirements file.

For a non-Docker path, the repository exposes manage.py and a boot.sh script at the top level. A Django deployment of this kind normally runs migrations and then gunicorn, and boot.sh plus the nginx configuration in http.d/ are where the container wires that together. The documentation is the authority on the migration command for your setup; the repository layout shows the pieces but not the sequence.

Once the instance is up, the first real use is import. Paste a recipe URL into the importer and the server fetches the page and extracts ld+json or microdata. If the site publishes schema.org Recipe markup, you should see a populated recipe with ingredients and steps; if it does not, the import will not produce a usable record. The README also lists import from other recipe managers, which is the path for migrating an existing collection rather than rebuilding it link by link.

Where Tandoor Recipes stops being the right tool

The public-page limitation is the first real boundary, and the README states it plainly rather than burying it. If you want a food blog with search engine traffic, this is the wrong application, and the permission model is not a substitute for a publishing platform.

The second limitation is import coverage. The claim is thousands of websites supporting ld+json or microdata. That qualifier does the work. A recipe written as prose in a forum post, a scanned card, or a page whose markup has drifted will not import cleanly, and you will be typing ingredients by hand. The project gives you merge and rename tools for exactly this cleanup, which is an admission that messy data is the normal case.

The third is operational weight. PostgreSQL is effectively required for the advertised search behaviour, and the dependency list includes Redis, an nginx layer inside the container, and a Vue 3 build step. A single-user instance on a small VPS is workable, but this is not a static site you drop on shared hosting. The Dockerfile's HEALTHCHECK is commented out with a link to issue 3478, so container orchestration will not get a built-in health signal from the image as shipped.

Finally, the licence is not a clean open source grant. The README states that from version 0.10.0 the code is under GNU AGPL v3 with a common clause selling exception, and it adds a note that the maintainer sees legal issues with licensing anything other than standard open licenses and is seeking professional legal advice. That is unusual candour, and it means the terms deserve your own reading rather than a summary.

Tandoor Recipes compared with plain Markdown recipe files

The obvious alternative for a technical user is keeping recipes as Markdown files in a Git repository. The README lists Markdown among the project's topics, which suggests the maintainers know that audience exists. The difference in approach is real and worth stating precisely.

Markdown files give you diffable history, no database, no server, and no upgrade path to manage. What they do not give you is the relational layer Tandoor is built around. A meal plan that references recipes across days, a shopping list generated from that plan with quantities combined, tags assigned in bulk by filter, and ingredient records you can merge and rename globally: those are database operations. In a folder of files, the shopping list is something you assemble by hand.

Search is the second divergence. Grep over Markdown is exact and fast. TrigramSimilarity in PostgreSQL tolerates near-misses, which matters when you half-remember an ingredient name or a recipe title. If your collection is under a hundred recipes and you never plan meals, files win on simplicity. Past that point, the planning and list features are the reason the application exists, and a file tree cannot reproduce them without you writing the tool yourself.

Maintenance, releases and what the licence means for a self-hosted instance

The repository is not archived, and the last push was on 2026-09-16. Releases are frequent: 2.6.15 on 2026-09-07, 2.6.14 on 2026-09-06, and 2.6.13 on 2026-07-05. The default branch is develop, which is where the README's own image links point, so the documentation and the code you would track both live on a development branch rather than a frozen stable line.

Upgrade cost is a function of the deployment style. Docker users pull a new image tag and restart, then run whatever migration step the documentation specifies for that release. Source users deal with requirements.txt, the Vue 3 build, and the same migrations. The dependency list is broad enough that a major Django or Python version bump will touch several packages at once; the pinned versions in requirements.txt are the project's defence against that, and they also mean you should not casually float them.

The licence position is the part to verify personally. The README declares GNU AGPL v3 with a common clause selling exception from version 0.10.0, points at LICENSE.md for details, and then notes that the maintainer is in the process of getting professional legal advice about licensing issues and references issue 238 for the reasoning. The stated intent is that all features remain free to use, and that a paid hosted version with an identical codebase may be released. The repository metadata reports the licence as NOASSERTION, which is consistent with a modified licence rather than a standard SPDX identifier. If you plan to run a modified Tandoor for other people, or to build a commercial service on it, read LICENSE.md and get your own advice. This article is not legal advice.

Editorial conclusion

Adopt Tandoor Recipes if you already run Docker or Kubernetes, keep a growing personal recipe collection, and want meal planning and shopping lists tied to it. Do not adopt it as a public recipe site: the README states a basic permission system exists but the application is not meant to be run as a public page. Before committing, verify the licence terms in LICENSE.md yourself, since the repository declares AGPL v3 with a common clause selling exception and the README notes the maintainer is seeking legal advice on that arrangement.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. TandoorRecipes/recipes on GitHub