Self-hosted recipe management, honestly reviewed. No meal kit ads, no affiliate links — just what you actually get when you run this on your own hardware.

TL;DR

What it is: A MIT-licensed command-line tool that reads recipes written in the Cooklang plain-text format, generates shopping lists, plans weekly menus, and runs a local web server so any device on your network can browse your cookbook [1][4].
Who it’s for: Developers, Linux power users, and home cooks who want recipes stored as plain files they own forever — not inside a proprietary app that can disappear, raise prices, or refuse to export your data.
Cost: $0 for the software. The only spend is whatever hardware you already have — a Raspberry Pi, a spare laptop, or a $5 VPS [4][README].
Key strength: Single binary, no database, no accounts, no subscription. Recipes are plain .cook text files that work with grep, git, rsync, or any other UNIX tool you already know [1][README].
Key weakness: Niche audience. The Cooklang format has a learning curve, the community is small (1,164 GitHub stars), and the web UI is functional but spartan. If you want a polished consumer recipe app, this isn’t it.

What is CookCLI

CookCLI is a command-line program built around the Cooklang recipe markup language. Cooklang is a plain-text format for writing recipes — ingredients are tagged with @, cookware with #, timers with ~, and quantities go in {} braces. A recipe file looks like a human-readable cooking note, not a database export.

What CookCLI adds on top of the format itself is a set of commands: read a recipe and print it formatted, combine multiple recipe files into a merged shopping list, run a week’s meal plan, or start an embedded web server that serves your entire recipe directory to any browser on your local network [1][README].

The GitHub description is honest about the scope: “Recipe Management CLI + embedded web-server in one binary.” That’s exactly what it is — no more, no less. There’s no cloud sync, no user accounts, no subscription tier, no AI suggestions. Your recipes live in a folder as .cook files. The program reads them [README].

The Cooklang project overall is maintained by Alexey Dubovskoy. CookCLI is the reference implementation, written in Rust, with a Node.js/npm frontend powering the web UI [README]. There are companion mobile apps listed in the README for iOS and Android, which means the same recipe files can be read on your phone through official Cooklang apps — a genuine advantage of building on an open format rather than a proprietary database.

As of this review, the repository sits at 1,164 GitHub stars [merged profile]. Small by automation-platform standards, but for a niche CLI recipe tool the number reflects a real committed community rather than hype.

Why people choose it

The choice for CookCLI almost always comes down to one thing: ownership of the data format. The competition in recipe management is either proprietary apps (Paprika, Mela, Whisk) that export in their own formats or not at all, or self-hosted apps (Mealie, Tandoor) that use databases you don’t directly read or edit. Cooklang files are plain text. You can open them in vim. You can version them in git. You can sync them with rsync [1][README].

The LinuxLinks review [1] summarizes the appeal cleanly: it’s “designed to be simple and useful for automating your cooking and shopping routine with existing UNIX command line and scripting tools.” That’s the whole pitch — not replacing your existing workflow, fitting into it.

The Raspberry Pi community picked up on this angle directly. The Awesome Raspberry Pi list [4] describes it as: “Turn your Raspberry Pi into a self-hosted recipe server. Manage recipes in plain-text Cooklang format with web UI, shopping lists, and meal planning.” That framing — Pi as household recipe server — is probably the most common deployment scenario: a device that’s always on, costs nothing to run, and serves your cookbook to every device in the house.

The comparison to Grocy is worth making explicitly. Grocy [2] is the power-user’s household management system — it tracks inventory, barcodes, expiration dates, chores, and runs a full ERP-style dashboard. It’s excellent but heavy. LinuxLinks calls it “a self-hosted household management system that lets you track food stock, shopping lists, recipes, meal plans, chores, batteries, equipment.” CookCLI is the opposite: it does one thing (recipes and shopping lists from plain files) and does it without a database or configuration ceremony.

Features: what it actually does

Core recipe handling:

Read any .cook file and print a formatted view with ingredients grouped, quantities scaled, and steps numbered [README][1]
Scale servings up or down (the format supports fractional quantities) [README]
Seed a sample recipe collection to test against immediately after install [README]

Shopping lists:

Combine any number of recipe files into a single shopping list with quantities summed and ingredients grouped [1][README]
Pass flags for verbose output (-v) to see which recipe each item comes from [README]

Meal planning:

.menu files let you lay out a week’s worth of meals by day and meal slot [README]
Menu files can reference full recipe files (@./Neapolitan Pizza{}) or inline one-off ingredients
Generate a combined shopping list from the full week’s plan in a single command [README]

Web server:

cook server --open starts an embedded HTTP server on port 9080 and opens your browser [README]
Serves a recipe list, individual recipe pages, menu views, and a pantry tracker
Any device on the same network can browse the full cookbook — no separate app install needed [1][README]

Pantry tracking:

Basic inventory management via the web UI [README]
Track what you have on hand; the interface shows a pantry view alongside recipes

Reports:

Custom report generation for evaluating recipes or menus [README]
The specifics depend on configuration — not as heavily documented as core features

Integration:

Because recipes are plain text files, they work with any file-level tool: git for versioning, Dropbox/Syncthing for sync, grep for searching [1][README]
The UNIX philosophy is explicit in the README: “Integrate your Cooklang recipes with other tools” [README]

Pricing: the actual cost structure

There are no tiers, no SaaS plans, no freemium gates. CookCLI is MIT-licensed software and the binary is free [README]. The only real cost is infrastructure.

Running locally (most common):

Install via Homebrew on macOS/Linux: brew install cookcli — $0 beyond your existing machine [README]
Run the web server on your laptop or desktop and access it from your phone on the same WiFi

Running on a Raspberry Pi (popular option):

Pi Zero 2 W: ~$15 hardware (one-time)
Pi 4 (2GB): ~$45 hardware (one-time)
Power: ~$2–3/month electricity at typical rates
No monthly software cost [4]

Running on a VPS:

Smallest Hetzner or Contabo instance: $4–6/month
CookCLI has no database, so the binary and your recipe folder fit on any spec
Overkill for a personal recipe server unless you’re already paying for a VPS for other reasons

What you’re replacing:

Paprika Recipe Manager: $4.99 on Mac, $4.99 on iOS (separate purchases, no family sharing, no web access)
Mela: subscription-based on iOS
Whisk: free with proprietary cloud storage you don’t control
Tandoor Recipes: self-hosted, requires PostgreSQL and Docker, more complex setup

For a solo user, the “savings” argument is weaker than it is for something like Zapier vs. Activepieces — recipe apps are cheap or free. The argument for CookCLI isn’t cost, it’s data portability and longevity. A .cook file you write today will still be readable in ten years. A Paprika database might not be.

Deployment reality check

CookCLI is a single binary. There is no database to configure, no environment variables to set, no Docker Compose file to understand. Installation on macOS or Linux is one command: brew install cookcli [README].

Building from source does require Rust and Node.js — Rust for the CLI binary and Node for the web UI CSS pipeline. The README is clear about this dependency chain: install Rust, install Node, run npm install && npm run build-css, then cargo build --release [README]. For most users, the Homebrew path or a prebuilt binary download avoids this entirely.

Serving to other devices over a local network is trivial — cook server binds to 127.0.0.1:9080 by default, which means it’s only reachable from localhost. To serve your phone on the same WiFi you need to bind to your LAN IP or 0.0.0.0 — the README doesn’t spell this out prominently, but it’s a standard networking step [README].

Raspberry Pi deployment [4] is well-supported — the project appears on the Awesome Raspberry Pi list specifically because the binary is lightweight enough to run on Pi hardware with minimal overhead.

What can go sideways:

The LinuxLinks article [1] describes CookCLI as written in Swift — this contradicts the current README, which is entirely Rust-based (Cargo build toolchain, cargo install cookcli). Either the project was rewritten between that review and now, or LinuxLinks had incorrect information. Verify against the current README before assuming language-specific deployment constraints.

There’s no TLS out of the box. Serving over HTTPS requires putting a reverse proxy (Caddy, nginx) in front of the server — standard practice but extra steps for non-technical users.

The Cooklang format itself is the real adoption barrier. You have to write or convert your recipes into .cook files. There’s no import-from-Paprika button, no URL-to-recipe scraper built in, no OCR for your handwritten index cards. You start from zero or you find community tools for conversion. This is the friction that limits who CookCLI is actually for.

Realistic setup time: 10 minutes for a technical user installing via Homebrew and running locally. 1–2 hours to set up on a Pi with LAN access and your first handful of recipes converted to Cooklang format.

Pros and cons

Pros

Zero infrastructure complexity. Single binary, no database, no configuration ceremony. Install and run [README][1].
True data ownership. Recipes are plain .cook text files you can edit in any text editor, sync with any tool, version in git [1][README].
MIT license. No commercial restrictions, no “fair-code” ambiguity. Fork it, embed it, modify it [README].
Shopping list generation is genuinely useful. Combining multiple recipes into a merged, quantity-summed shopping list in one command is the killer feature for anyone who actually meal-preps [1][README].
Meal planning via menu files. The .menu format lets you plan a week and generate one combined shopping list — a workflow most dedicated recipe apps don’t handle cleanly [README].
Built-in web server. No separate install to browse recipes on your phone [1][README].
Companion mobile apps exist. The Cooklang format has iOS and Android apps, so the same files work on mobile [README].
Raspberry Pi-native. Lightweight enough to run on minimal hardware permanently [4].

Cons

The format is the barrier. You must write recipes in Cooklang. No import wizard, no web scraper, no bridge from existing recipe apps. This is the biggest adoption obstacle for non-technical users.
Small community. 1,164 stars [merged profile] means a limited pool of community-contributed recipes, tools, and troubleshooting resources compared to mainstream alternatives.
Web UI is basic. Functional but not polished. The demo at demo.cooklang.org [website] shows a clean but minimal interface — no visual search, no nutritional data, no smart recommendations.
No HTTPS out of the box. External access requires a reverse proxy setup.
No mobile-native app bundled. The web UI works on mobile via browser but isn’t optimized for it; official Cooklang mobile apps are separate downloads [README].
Documentation is thin in places. The reports and pantry features exist but aren’t as thoroughly documented as the core recipe and shopping list commands.
No collaborative features. Shared household use over the web UI is read-only browsing — there’s no multi-user editing, no comment system, no family sharing model.

Who should use this / who shouldn’t

Use CookCLI if:

You’re comfortable in a terminal and want recipes to live as plain files alongside your other data.
You already have a Raspberry Pi or home server running and want to add a recipe browser that any device in the house can reach.
You’ve been burned by a recipe app shutting down or refusing to export your data.
You want shopping lists that actually combine ingredient quantities across multiple recipes in one step.
You care about being able to version-control, sync, and back up your cookbook with the same tools you use for everything else.

Skip it if:

You want to clip recipes from websites with one click — CookCLI has no web clipper.
You’re not willing to write or convert recipes into the Cooklang format.
You want nutritional tracking, calorie counts, or dietary tagging — none of that is built in.
You need a family-friendly UI that a non-technical partner or child can use without coaching.
Mobile is your primary cooking interface — the web UI works on phones but isn’t native-app smooth.

Consider Mealie instead if:

You want a polished self-hosted recipe app with web scraping, nutritional info, and a more complete UI — at the cost of Docker and a database [3].

Alternatives worth considering

Mealie — the most direct alternative for self-hosting. REST API backend, Vue.js frontend, Docker-based, actively maintained. More complex to deploy than CookCLI but covers nutritional data, URL import, and multi-user households [3].
Tandoor Recipes — Django-based, PostgreSQL-backed, more mature feature set. Requires more infrastructure than either CookCLI or Mealie.
Grocy — if you want recipe management embedded in a full household ERP: pantry stock, expiration tracking, shopping, chores. Significantly more complex setup and ongoing data entry discipline [2].
Paprika Recipe Manager — best proprietary option if you don’t want to self-host. One-time purchase per platform, no subscription, good UI. The trade-off is lock-in and separate purchases for Mac, iOS, and Android.
Mela / Whisk — subscription or cloud-dependent apps. Easier onboarding, less ownership.
Cooklang ecosystem tools — the Cooklang format has parsers in multiple languages and community-built utilities beyond CookCLI itself (iOS app, Android app, editor plugins). Worth exploring if you like the format but want a different front-end.

Bottom line

CookCLI is a well-built tool solving a specific problem for a specific audience: people who want their recipe collection to be plain files they own, not data trapped in a proprietary app. The value proposition isn’t “better than Paprika” on features — it’s “your recipes in a format that survives any app dying, any subscription ending, any company pivoting.” The shopping list generation and meal planning via .menu files are genuinely useful additions on top of the format itself, and the embedded web server means it functions as a household recipe browser without installing anything on anyone’s phone. The friction is real — you’re committing to the Cooklang format, and building that recipe library takes work. If that trade-off sounds right for how you think about your data, CookCLI is exactly what it says it is and does it well.

Sources

LinuxLinks — “CookCLI - suite of tools to create shopping lists and maintain recipes”. https://www.linuxlinks.com/cookcli-suite-tools-create-shopping-lists-maintain-recipes/
LinuxLinks — “Grocy - ERP beyond your fridge”. https://www.linuxlinks.com/grocy-erp-beyond-fridge/
LinuxLinks — “food Archives” (Mealie and other food software roundup). https://www.linuxlinks.com/tag/food/
Track Awesome List — “Track Awesome Raspberry Pi (thibmaek/awesome-raspberry-pi) Updates Daily” (Nov 2025 entry for CookCLI). https://www.trackawesomelist.com/thibmaek/awesome-raspberry-pi/