Norish: a self-hosted recipe app built around a shared household

The household problem Norish is aimed at

Most recipe software is built for one person collecting links. Norish starts from the opposite assumption: a household or a group of friends that cooks from the same set of recipes and buys from the same grocery list. The README describes it as a "real-time, household-first recipe app for planning meals, sharing groceries, and cooking together."

The recent release names show where the effort has gone. v0.22.0-beta is titled "Cookbooks and user management", v0.23.0-beta is titled "Groceries". Those two areas, organising recipes into cookbooks and coordinating who buys what, are exactly the parts a single-user recipe manager tends to leave thin. If your household currently coordinates through a group chat plus a notes app, that is the gap this project targets.

The audience is narrower than "anyone who likes cooking". You need to be willing to run a server. There is no hosted tier mentioned in the README, and the only path it gives is Docker Compose. Someone who wants to install an app from a store and be done is not the reader this is written for.

How the four containers fit together

The Compose file in the README defines four services, and each one has a job that explains a design decision.

The norish service is the application itself, listening on port 3000, with an uploads volume mounted at /app/uploads and UPLOADS_DIR pointing at the same path. It needs DATABASE_URL, MASTER_KEY, OBSCURA_ENDPOINT and REDIS_URL. The healthcheck is a one-line Node script that requests http://localhost:3000/api/v1/health and exits non-zero unless the status is 200.

Postgres 17-alpine holds the data. Redis is present because, per the .env.example comment, REDIS_URL is the "Redis connection URL for real-time events and job queues". That single line explains the realtime claim: shared grocery state and live updates travel through Redis rather than through polling.

The fourth container is the interesting one. Obscura, image norishapp/obscura:0.2.0-norish.1, is described in the Compose comments as rendering "recipe pages for URL imports". The application talks to it over a CDP websocket at ws://obscura:9222. So importing a recipe from a URL is not a plain HTTP fetch and parse. A separate browser-rendering service loads the page, and the app reads the rendered result. That costs you a container and some memory, and it buys tolerance for sites that build their recipe markup in JavaScript.

The repository layout matches a monorepo: apps/, packages/, tooling/, a pnpm workspace and turbo.json. The package.json is private, version 0.23.1-beta, and pins [email protected].

Installing Norish with Docker Compose

The README points to norish.dev for the website and docs.norish.dev for documentation, and gives Docker Compose as the fastest way to try it. At minimum you need DATABASE_URL and MASTER_KEY. Generate the key first and keep it somewhere you will not lose it, because the README states that changing it later invalidates previously encrypted data.

openssl rand -base64 32

Paste the output into the MASTER_KEY value in your compose file. The README's example uses the image tag norishapp/norish:latest; the release list shows beta tags such as v0.23.0-beta, so pin a specific tag if you want a predictable upgrade. A trimmed version of the service definition, with the same keys the README uses:

services:
  norish:
    image: norishapp/norish:latest
    container_name: norish-app
    restart: always
    ports:
      - "3000:3000"
    user: "1000:1000"
    volumes:
      - norish_data:/app/uploads
    environment:
      AUTH_URL: http://localhost:3000
      DATABASE_URL: postgres://postgres:norish@db:5432/norish
      MASTER_KEY: <32-byte-base64-key>
      OBSCURA_ENDPOINT: ws://obscura:9222
      REDIS_URL: redis://redis:6379
      UPLOADS_DIR: /app/uploads

Bring the stack up with the compose file you wrote, then open http://localhost:3000. The first thing you will see is not a login form: the .env.example has a section headed FIRST USER SETUP which states that on first startup you configure one auth provider to create your admin account, and that after first login you use Settings, then Admin, to add more providers. Password auth is listed there as Option 1.

If you prefer to build from source rather than pull the image, the repository exposes pnpm scripts. The database schema is managed with drizzle-kit through the db:push and db:generate scripts in package.json, and there is a docker:up script that composes docker/compose.base.yaml with docker/compose.local.yaml.

Where Norish will frustrate you

The release history is the first thing to weigh. The three most recent releases are all marked beta, and the package version is 0.23.1-beta. Nothing in the README describes a stable release channel, a migration guide between versions, or a rollback procedure. The README does not document rollback. If you run this for a household that depends on the grocery list on a Saturday morning, you are the one who has to decide when to pull a new image.

The MASTER_KEY constraint is the sharpest edge. It derives the encryption keys, and the README says plainly that changing it later invalidates previously encrypted data. That is not a bug, it is how the encryption is designed, but it means the key belongs in your secret storage from day one, not in a compose file you rewrite while experimenting.

The four-container shape is a second cost. Postgres, Redis and Obscura all have to be running for the app to be fully functional. Obscura in particular exists only to render pages for URL imports; if you never import recipes from the web, you are carrying a container for a feature you do not use. There is no documented single-container or SQLite mode in the README.

Finally, access control is not something you can judge from the README. It mentions user management as a v0.22.0-beta theme and an admin settings area, but it does not describe roles, invitation flow or what a non-admin household member can see. If your group includes people who should not see everything, that is a question to answer before you migrate recipes into it.

Norish compared with Mealie

Mealie is the comparison people search for, and the difference is in the starting assumption rather than the feature list. Mealie is widely used as a personal recipe manager with a web UI and an API; the household, realtime and shared-grocery framing is not its organising idea.

Norish's architecture follows from that framing. Redis is in the stack specifically for real-time events and job queues, which is what lets two people see the same grocery list change without refreshing. The separate Obscura renderer is a deliberate choice to handle JavaScript-heavy recipe pages at import time instead of shipping a parser that only reads static HTML.

That said, the trade is real. A single-user setup gains nothing from the realtime layer and pays for it in an extra container and an extra moving part. If you are one person archiving recipes, the household machinery is overhead, and a simpler stack is the better fit. Norish earns its complexity only when more than one person is reading and editing the same data.

Licence and the cost of staying current

Norish is licensed under AGPL-3.0, and the LICENSE file sits at the repository root. For a self-hosted household instance this is unremarkable. The obligation that matters is the network one: if you modify Norish and let other people use it over a network, the AGPL expects you to offer them the corresponding source. Running an unmodified image for your family does not trigger anything unusual. This is a description of the licence text, not legal advice; read LICENSE yourself if you plan to redistribute or to build a service on top of it.

Upgrade cost is the practical question. The project ships beta releases on a roughly weekly cadence in the recent history, and the last push to the default branch was on 2026-09-10. There is no upgrade guide in the README and no documented schema migration path beyond the drizzle-kit scripts in package.json. In practice that means: back up the Postgres volume and the uploads volume before you change the image tag, and read the release title to see which area moved. A release titled "Cookbooks and user management" is more likely to touch your data than one titled "UI refresh, image generation".

Editorial conclusion

Adopt Norish if you want one shared recipe and grocery space that you host yourself and you are comfortable running a four-container Compose stack with Postgres, Redis and Obscura, and pinning a beta tag. Do not adopt it if you need a documented stable release, an upgrade path with rollback, or a single-binary install. Verify first that your chosen image tag exists on Docker Hub, that MASTER_KEY is generated once with openssl rand -base64 32 and stored outside the compose file, and that port 3000 is what you want to expose.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. norish-recipes/norish on GitHub
4. README
5. Releases