Mealie fork
A fork of Mealie, the self-hosted recipe manager (12.7k stars upstream), that I build, deploy, and extend for a nutrition-tracking pipeline. I ship the images, run them in the homelab, and send the generic fixes back upstream.
Why it exists
I wanted nutrition data as a first-class part of my recipe workflow, and I wanted to run my own build rather than wait on a release. Forking meant I also had to make the upstream CI actually work for someone who isn't the upstream maintainer.
What I built
- Repaired the fork's CI. Upstream's pipeline was hard-gated to its own repo, built on a paid service I don't have, and pushed to a namespace I can't write to. I rewrote it: stock buildx, GHCR publishing, a lowercased namespace, and a dispatch trigger.
- Nightly images to ghcr.io, deployed to the homelab through Portainer.
- Backend. Added nutrition to the recipe list schema with a batched eager-load instead of an N+1 query.
- Frontend. A full editorial redesign of the recipe UI: image-forward tiles, a real typographic hierarchy, colored taxonomy tags, dark and light.
- Upstream fix (PR #7881). The recipe yield display emitted "0.0" into the schema.org JSON-LD for servings-only recipes, poisoning per-serving data for anything that consumed it. I fixed it and added parametrized tests.
The discipline
Upstream the generic, fork-carry the opinionated. Generic fixes go upstream so they're maintained forever at no cost to me. Opinionated features stay small and rebasable, so pulling in upstream changes never turns into a merge fight.
what it demonstrates
CI/CD surgery, Docker and GHCR pipelines, Python and Vue across the full stack, upstream open-source contribution, and the discipline of running what you build.