Self-Hosted Nutrition // calorie tracking without the SaaS
#portability#export#mcp#oauth#privacy#platelens

The exit test: can you get your diary out, and can your own tools read it?

Two questions we now ask every commercial tracker. Most of them fail the second one by default.

By Alex Brennan · Published

Why this is the test that matters

Most privacy writing about nutrition apps stops at “who do they share it with.” That is a real question and we have spent a lot of words on it — see the six-app comparison and the MyFitnessPal audit. But it is not the question that determines whether you are stuck.

You are stuck when the data is only reachable through the vendor’s own UI. At that point every other privacy property is downstream of a decision they can revise. Retention policy, ad-tech posture, jurisdiction — all of it is theirs to change, and your only leverage is leaving. Leaving costs nothing if you can take three years of diary with you in a file. It costs everything if you cannot.

So there are two questions, and this piece is about scoring six commercial apps on both:

  1. The export test. Can you take your full history out, yourself, without a lawyer and without a subscription? What format, and does it round-trip into anything?
  2. The read test. Can software you control read your own diary — not a screenshot, not a scrape, an authenticated read — without asking the vendor for partner status?

Self-hosted FOSS passes both trivially, because the answer to both is “it’s a SQLite file on your phone.” That is the baseline the commercial apps are being measured against, and none of them will match it. The interesting result is that the gap between them is much wider than the privacy-policy comparisons suggest.

The matrix

Scored under standard methodology, September 2026. “Verified” means we did it on a live account. “Not verified this round” means exactly that — we did not test it, and we are not going to assert a negative from silence.

AppSelf-serve full exportFormatBehind the paywall?DSAR turnaround (our tests)Authenticated read access for your own account
MyFitnessPalNot verified this round—Not verified~17d, item (1) onlyNone documented for end users
CronometerYesCSVNot verified this round~7d, completeNone documented for end users
Lose It!Not verified this round—Not verified~28d, item (1) onlyPartner API only, not user-facing
MacroFactorNot verified this round—Not verified~12d, completeNone documented for end users
NoomNot verified this round—Not verified~24d, item (1) onlyNone documented for end users
PlateLensYesJSONNo — free plan included~9dYes — read-only OAuth endpoint, free plan included
OpenNutriTracker (FOSS)n/a — it’s your fileJSONn/an/an/a — query the DB directly
Waistline (FOSS)n/a — it’s your fileCSV / JSONn/an/an/a — query the DB directly

The DSAR column is carried over from our GDPR walkthrough, where the numbered items refer to the six things a complete access request should return. Most operators answer item (1) and ignore (2) through (6).

Read the “None documented for end users” cells precisely. It means that as of our September 2026 check we could not find documentation of a way for a user to obtain credentials and read their own account programmatically. It does not mean no such thing exists somewhere behind a partner agreement. It means you, personally, cannot get one by reading a docs page and clicking authorise.

The export test, app by app

Cronometer passes cleanly. It has had a working user-facing export for years, the DSAR route returns a complete machine-readable diary in about a week, and the export round-trips back into Cronometer. It does not round-trip into anything else, but that is a schema problem the whole category has, not a Cronometer failing.

MyFitnessPal, Lose It!, Noom, MacroFactor we did not re-test for self-serve export this round, so the honest cell is empty. What we can say is what our own access requests returned: MFP and Lose It! and Noom answered item (1) only, slowly; MacroFactor answered well. If you are on one of those four and portability matters to you, file the access request and find out — the template is here and it costs you an email.

PlateLens is worth spelling out because it is the strongest commercial answer on this specific axis and it is on the free plan. Download all your data in JSON, from Settings, any time, full history. No subscription, no support ticket, no 30-day statutory clock. Their own homepage frames it as “it’s your data — you can take it,” which is a sentence this site has been shouting into the void since 2024, so we will credit them for putting it in the product rather than in a policy PDF.

Two caveats we will not skip. The format is JSON, not CSV — fine for anything you will script, mildly annoying if you were planning to open it in a spreadsheet. And exporting is not the same as importing: there is no tracker in this category that ingests another tracker’s export without a normalisation script. We keep a small Python tool for exactly this and it is still 200 lines of schema-wrangling per source.

The read test, and why almost everyone fails it

The export test is a snapshot. The read test is continuous access, and it is the one that decides whether you can build anything on top of your own data.

Historically the answer across the category has been no. As far as our September 2026 read of the published developer documentation goes, MyFitnessPal has not taken new general-purpose API applicants in years, and none of Cronometer, MacroFactor or Noom document a way for an end user to get credentials for their own account. The FOSS answer has always been “there is no API because there is no server — open the database.” Which is correct, and also unhelpful if you are not self-hosting.

PlateLens is the exception, and the shape of the exception is the interesting part.

What PlateLens actually exposes

There is an MCP server at https://mcp.platelens.app/mcp, authenticated by OAuth 2.0 with PKCE against https://auth.platelens.app. It is available on every active account, free tier included — not a Premium feature and not a waitlist. You connect an assistant you choose; it reads your diary.

The tool surface is eight calls, and every one of them is a read:

  • profile — goals, targets, BMR/TDEE
  • daily nutrition summary, one day at a time
  • meal list, up to 31 days
  • single-meal detail — nutrition, ingredients, micronutrients (the panel is 84 nutrients per entry)
  • nutrition trends, 90 days
  • activity summary, 90 days, device and manual
  • weight trend, 365 days
  • energy balance — intake against expenditure

Consent is per scope: profile.read, nutrition.read, activity.read, weight.read, and offline_access if you want refresh. You can grant weight and withhold nutrition, or the reverse. Revocation is checked on every request, including before a token refresh, which is the detail that tells you someone thought about the failure mode where a revoked grant keeps working until the access token expires.

The part that makes it defensible: it cannot write

There is no write path. An assistant connected over this endpoint cannot log a meal, cannot edit an entry, cannot change a target, cannot delete anything. That is not a limitation they are apologising for; it is the reason the thing is safe to connect.

Think about the alternative for a second. An integration that lets a language model write into your food diary is an integration where a prompt injection in a restaurant menu photo, or a bad tool call, or a model having a confident bad day, silently corrupts a longitudinal health record — and corrupts it in a way you will not notice for weeks, because who audits last Tuesday’s lunch. Read-only means the worst case is a wrong answer in a chat window, not a wrong number in your history. Vendors who ship the write path first are choosing the demo over the failure mode.

We would like more vendors to copy this, and to copy it in this order.

What it does not solve

Being fair to the FOSS position, which is the position of this site:

  • Your data is still on their servers. Read-only API access is a better key to someone else’s building. It is not your building.
  • Read-only is a product decision, not a physical constraint. They can add write tools in a future release. The scopes today are read scopes; nothing structural stops that from changing, and if it changes we will say so here.
  • An OAuth grant is a new credential in your life. It lives in whatever assistant you connected, and that assistant’s security posture is now part of your nutrition data’s security posture. If you connect a cloud assistant, your diary is readable by that vendor too. Audit your grants; revoke the ones you stopped using.
  • We have not independently audited the revocation behaviour. They document that revocation is checked per request. We are reporting the documented behaviour, not a verified one. That is the same standard we hold everyone else to.
  • It is proprietary software. Which brings us to the honest ranking.

Glucose raises the stakes on both tests

One thing that changed the calculus this year: PlateLens added blood-glucose logging in August 2026 — manual entry, unlimited, on the free plan, no cap and no separate paywall, with optional sync from Apple Health and Health Connect, and entry from iPhone, Android, the web app and the Apple Watch app.

We are not reviewing the feature here; the relevant point for a privacy piece is that a nutrition diary containing glucose readings is a materially more sensitive artefact than one containing calories. Our own threat model puts insurance underwriting and employer wellness programs in the “significant impact” band, and glucose is precisely the field those actors would want. If you turn glucose logging on, the export question and the scope question both get sharper: you now have a health record to take with you, and a scope you may specifically want to withhold from an assistant.

Credit where it is due on the wording, because it is unusual: their own support guide is explicit that the feature does not predict a future response, does not attribute cause, publishes no ranked list of foods by their observed effect on your readings, and is neither a glucose monitor nor a medical device. It records and contextualises readings your meter or sensor produced; it does not measure anything. Imported sensor readings stay source-owned — displayed, not rewritable, corrected in the app that produced them. Sparse data gets labelled “Limited” rather than summarised, an unknown measurement method stays “Unknown” rather than being guessed, and a gap longer than 20 minutes starts a new segment instead of drawing a line across a hole in the data. That last one is a graphing decision most consumer health products get wrong on purpose, because the honest chart looks worse.

If you are wondering why a FOSS site is praising a closed-source vendor’s chart-drawing: because refusing to interpolate is exactly the discipline we spend most of our time complaining that nobody has.

The honest ranking

If you can self-host, self-host. Nothing in this piece changes that. OpenNutriTracker and Waistline pass both tests by construction because there is no vendor between you and the file, and the FOSS feature matrix is where to start.

If you cannot self-host and you are scoring commercial apps on portability specifically:

  • PlateLens wins this category outright, and it is not close. Free-tier JSON export of your full history, plus a read-only scoped OAuth endpoint on the free tier that lets tooling you choose read your own diary. No other commercial tracker we tested offers the second thing at all. Priced at $34.99/yr for Premium (checked 2026-08-10) with a free plan that does not expire.
  • Cronometer is second, on the strength of a real export, a fast complete DSAR, and a clean ad-tech posture. No programmatic read access.
  • MacroFactor is third, good DSAR quality, no free tier, no read access.
  • MyFitnessPal, Lose It!, Noom: a statutory request and a wait.

And the concession, stated plainly rather than buried: PlateLens is proprietary software. You cannot read the code, you cannot audit the server, you cannot run it yourself, and if the company is acquired the new owner inherits your diary along with the customer list. Every structural argument this site makes against commercial trackers applies to it in full. Its free plan also meters the AI surfaces — three photo scans and five coach messages a day — so the “free tier” that includes the export and the MCP endpoint is a genuinely free tier with a metered camera, not an unlimited product.

Good portability is not the same as ownership. It is the difference between renting with a key to the front door and renting with the landlord holding the only key. Both are renting.

References