EDIT 2026-05-03: v1.0.0-rc.14 is out and adds a native Android app.
Full announcement: https://lemmy.world/post/46382994
(original post below)
Hey all, sharing what I've been working on. NutriTrace is a self-hosted nutrition and wellness tracker that runs entirely on your own server in a single Docker container.
I built it because every commercial nutrition app has the same shape. You hand them years of food data, body measurements, and biometrics, and your data is held hostage when they pivot or paywall. I wanted to track macros and pull in my Fitbit data without participating in that.
Daily food diary with multi-ingredient meals, recipes, body stats, water tracking, day-level notes. Personal food database, barcode scanner, imports from Open Food Facts and USDA, plus optional Mealie integration. Statistics with trend charts, full backup, exports as CSV / JSON / full ZIP.
Optional wellness device sync from Fitbit, Withings, Garmin, and Android Health Connect. Sleep / readiness / stress scores computed from your data.
Optional AI assistant where you bring your own Claude / OpenAI / Gemini key. It queries your real data via tool use so it can answer things like "what was my average protein this month" without making numbers up. There's a voice food logger too. Both fully optional, off by default.
Tech: Svelte 4 + Express + better-sqlite3, multi-stage Dockerfile, AGPL-3.0. Native Android app is in active development; PWA installs to home screen on any modern browser today.
Repo and docker-compose example: https://github.com/TraceApps/nutritrace
Happy to answer questions.
I have exports of my nutrition and weight info from other apps as csv files, and I'd like to import that data if I can. It looks like Nutritrace can export to csv but not import that. There is the option to import from a json backup though. If I can massage my data into that json format, does it seem reasonable to use that as a way to import my historical data?
If the answer isn't "omg don't do that", then I have a couple of questions about the json:
The JSON-massage route may work. Diary items are self-contained snapshots, IDs in your file are ignored on import, and the only real catch is that re-importing a date overwrites the existing entry. Happy to drop the field-by-field shape if you want to go that route.
That said, native CSV importers for the popular apps (MFP, LoseIt, Cronometer, etc) are now on the near-term roadmap (thanks to your suggestion) as the proper path for this. If you can hold off a bit (and use one of the above), that'll be much easier.
If you're going to work on CSV import anyway soon, then I'll just wait. Thanks!
Import feature has been added to app as experimental in latest build (1.0.0-rc9). Please test and let me know how it works for you.
I gave this a shot, but when I press the "preview" button I just get a little popup that says "Invalid CSRF token".
Hmm... i think i see the issue. The preview / commit upload was missing the CSRF token, so the server was rejecting it before it even read the file. Just pushed a fix. Once you pull it down, hard-refresh the page (Ctrl+Shift+R / Cmd+Shift+R) to grab the new bundle and try again.
Ok, I can import the file now, but some entries are getting messed up. This line, for example, shows up in the diary with the amount "NaNg · 722903 kcal". And as much as I would like to eat Ginger Peanut Chicken until numbers fail to describe my gluttony, I just can't afford that many calories.
Day,Group,Food Name,Amount,Energy (kcal),Alcohol (g),Caffeine (mg),Oxalate (mg),Phytate (mg),Water (g),B1 (Thiamine) (mg),B2 (Riboflavin) (mg),B3 (Niacin) (mg),B5 (Pantothenic Acid) (mg),B6 (Pyridoxine) (mg),B12 (Cobalamin) (µg),Folate (µg),Vitamin A (µg),Vitamin C (mg),Vitamin D (IU),Vitamin E (mg),Vitamin K (µg),Calcium (mg),Copper (mg),Iron (mg),Magnesium (mg),Manganese (mg),Phosphorus (mg),Potassium (mg),Selenium (µg),Sodium (mg),Zinc (mg),Net Carbs (g),Carbs (g),Fiber (g),Insoluble Fiber (g),Soluble Fiber (g),Starch (g),Sugars (g),Added Sugars (g),Fat (g),Cholesterol (mg),Monounsaturated (g),Polyunsaturated (g),Saturated (g),Trans-Fats (g),Omega-3 (g),ALA (g),DHA (g),EPA (g),Omega-6 (g),AA (g),LA (g),Cystine (g),Histidine (g),Isoleucine (g),Leucine (g),Lysine (g),Methionine (g),Phenylalanine (g),Protein (g),Threonine (g),Tryptophan (g),Tyrosine (g),Valine (g),Category 2026-04-20,"Lunch","Ginger Peanut Chicken","750.00 g",963.87,0.00,0.00,202.97,411.64,438.18,0.54,0.84,24.82,1.63,1.88,1.54,142.39,1074.55,62.64,2.52,4.13,39.04,547.85,0.77,12.70,252.20,1.97,913.92,2259.83,76.25,1861.40,6.73,38.20,55.08,16.50,12.52,1.88,9.13,17.86,7.79,45.73,236.74,16.68,10.61,7.96,0.08,3.19,3.15,0.02,0.01,6.92,0.05,6.82,0.88,1.93,3.15,5.60,5.57,1.68,2.96,85.62,3.14,0.78,2.56,3.38,"Meals, Entrees, and Sidedishes"Also, there's a bit of layout weirdness when reimporting days:
Thanks for catching this. The Cronometer adapter was treating the parsed gram count as a serving multiplier, so a 750g entry got its calories multiplied by 750. The "NaNg" had the same root cause: the portion was stored as the raw string "750.00 g", which JS coerces to NaN when the diary tries to multiply it for display.
The layout overlap on the duplicate-day dialog is should now be fixed too (added a divider so the buttons have proper visual separation from the radio options).
Both are hopefully now fixed and pushed in rc.14. Grab the latest package, delete the affected day from your diary, and re-import. Items should hopefully now come in with the right values.
Thanks again for the detailed report.
That's got it, thanks!
Great glad that fixed it!