OpenEats is a self-hosted recipe site for a household, not a platform

One admin, a few invited users, no sign-ups

OpenEats is a recipe management site that allows users to create, share and store their personal collection of recipes, and the README is unusually clear about its intended scale. The usage for the app is intended for a single user or a small group. For the author's personal use, they would be an admin user and a few, about five or six, friends and family would be normal users. Admin users can add other users to the project, and there are no open sign-ups, they can make changes to the available Cuisines and Courses, and they can add to the homepage banner. Normal users just have the ability to add recipes. That is a coherent product definition, and it explains the feature list, because features that only matter at scale, like public profiles or social discovery, are absent. The fork uses Django Rest Framework as a backend and React with flux as a front end, and the primary language listed for the repository is Dockerfile, which reflects that the distribution story matters more here than the code does.

The feature list is short and practical

The core features are listed in the README and each one is small and concrete. You can create, view, share and edit recipes. You can update serving information on the fly, which is the difference between a recipe box and a document, since doubling a dish should change the ingredient quantities rather than just the note. You can browse and search for recipes. You can create grocery lists, and you can automatically add recipes to those lists, which is the feature that turns a collection into something you use on a shopping trip. You can quickly print a recipe, and you can link recipes and do ingredient grouping, so the shopping list is organised by aisle rather than by the order the recipes happen to be in. Comments and ratings were added in version 1.4.0 in November 2018, and version 1.5.0 in March 2019 added support for displaying recipe data as fractions, which is a small feature that tells you about the audience, since cooking quantities are fractions far more often than they are decimals.

Docker Compose is the main deployment path

The docker-compose.yml in the repository shows the shape of the deployment, and it is a three service stack. The api service builds from an openeats-api/ directory, runs the Django development server with a command of python manage.py runserver 0.0.0.0:8000, reads its configuration from an env_file called env_dev.list, and mounts the source at /code along with named volumes for static files and site media. The web service builds from openeats-web/, runs yarn dev, shares the same env file, and depends on the api. The db service is a mariadb image with the same env file, a named volume for /var/lib/mysql, and port 3306 published. Three named volumes carry the state, database, static-files and site-media. The api depends on the db and the web depends on the api, so the ordering is handled by compose. The api is published on 8000 and the web on 8080, and there are separate compose files for the other environments, docker-prod.yml and docker-stage.yml, with matching environment lists env_dev.list and env_stg.list.

Running it without Docker, and the documentation layout

If you would rather not use Docker, the README points to a second guide, docs/Running_the_App_Without_Docker.md, and also to an external wiki page for installing without Docker and running on Apache2. The documentation set in the repository is worth knowing about by name, because it tells you what the project expects you to do. docs/Running_the_App.md is the getting started guide. docs/Updating_the_App.md is the update guide, and given the age of the releases in this fork, reading it before you change anything is the sensible move. docs/Running_the_App_in_dev.md is the development environment setup guide, and CONTRIBUTING.md holds the contribution guidelines, with MAINTAINERS.md alongside it for who looks after what. There is a SECURITY.md for disclosure. The repository also carries a quick-start.py and a release.py at the top level, with a releases/ directory and a commits.py, which suggests the release process is scripted rather than manual.

What the fork history means for anyone picking this up

The release history here is the part that deserves attention. The recent releases are 1.5.1 on 2019-03-12, described as preventing logged out users from being redirected on the homepage, 1.5.0 on 2019-03-08, adding support for displaying recipe data as fractions, and 1.4.0 on 2018-11-24, adding support for comments and ratings. The last push was on 2026-09-09, so the tree is being touched, but the tagged history stops in 2019. That gap tells you what you are adopting. This is a fork that took a larger upstream project and trimmed it to a small group use case, which is a reasonable thing to want and a reasonable thing to inherit, but it means the upstream feature set, and the upstream's own assumptions about scale, are not all present. The other thing to check is the primary language field saying Dockerfile, which points at a deployment-heavy repository where the container and environment configuration carry as much of the design as the application code does.

Editorial conclusion

Adopt OpenEats when you want a private recipe collection you host yourself, with grocery lists and sharing built in, and when a handful of invited accounts is the right size for it. Do not adopt it for a public recipe site, because the project is explicitly built around an admin user adding other users rather than open sign-ups. Verify first which fork state you are taking, since the last tagged releases here are from 2019, that the Docker path works on your hardware, and that you read the update guide in docs before changing versions, since the environment is split across several list files.

Frequently asked questions

Official sources

1. License: MIT
2. open-eats/OpenEats on GitHub
3. Project website
4. README
5. Releases