Thanks! and a couple suggestions...

[el-abcd]

I just readup on HeathLog yesterday, and was able to get it running via docker / tailscale / ios app today.
I'm looking forward to using it! (I want to get my untidy drive folder with misc medical tests / stats finally cleaned up and organized).

A couple thoughts / notes (not sure if these rise to the level of "issues", so leaving them as a discussion...)

• For the ios app, perhaps "HealthLogger" instead of "HealthLoger"?

  • i.e. a double g. In testflight the name shown was "View HealthLoger Beta" although the app itself shows up as HealthLog.

• Perhaps mention tailscale (tailscale serve or tailscale funnel) as an option for the "reverse proxy"?

  • I wasn't immediately sure how to configure Caddy/Trefik/Nginx/Coolify with the local docker instance (I suspect by setting up another docker container, etc). And perhaps some monthly fee is needed?
  • But, I had some familiarity with tailscale (for my home assistant server remotely on my iphone), so I gave that a try.
  • My understanding is that one can use "tailscale serve" to generate a https: address usable on the local tailnet (i.e. if have installed tailscale on the iphone already (which I had)).
  • OR, one can use "tailscale funnel" to generate a public facing https: address accessible from the public internet (if you don't want to install tailscale on the iphone).
  • So far I am using the "free" tailscale login, and that seems to be working fine, so $0 cost.

Some tailscale tutorials / info:

• https://www.reddit.com/r/Tailscale/comments/1bbkvel/so_what_exactly_is_tailscale_serve/
• https://youtu.be/MpxmfpCl20c?si=ULNNUOQzaTcMG3dy
• https://tailscale.com/blog/how-tailscale-works

Rough list of instructions:

• Install tailscale app on the macbook (where the HealthLog docker container is running). It seems like downloading the mac app from tailscale is a bit more full-featured than from the app store / cli install. There are some system permissions to enable, for it to setup networking, etc.
  • If you haven't used tailscale before I think you need to create a login / do some initial config. I think it was fairly simple, if memory serves...

Then, to run "tailscale serve" with the docker container...

• tailscale serve --bg localhost:3000
  • Copy the https URL output from the command.
  • NOTE: I first had to visit a tailscale admin webpage to enable serve (https), which the cli output explained…
  • NOTE: --bg makes the Serve configuration persistent across Tailscale restarts/reboots.
• Then the "usual / documented" .env updates to NEXT_PUBLIC_APP_URL and APP_URL and restarting the docker container got it running and talking to Apple Health on my iphone!

[MBombeck]

Welcome, and thank you for writing this up so carefully. This is exactly the kind of field report I hoped the discussions section would collect.

On Tailscale: agreed. The reverse-proxy guide currently assumes you already run Caddy, Traefik or something similar, and for a single Docker box on a tailnet that is a lot of ceremony for little gain. tailscale serve hands you a trusted HTTPS endpoint with no extra containers and no cost, which honestly makes it a better first rung than any of the proxies we document. I am adding a Tailscale section to the self-hosting docs now, covering serve for tailnet-only access and funnel for a public address, plus the APP_URL / NEXT_PUBLIC_APP_URL step you mention. Your step list is the skeleton for it.

On the TestFlight name: good catch, and thank you. The double g clearly reads better. The honest answer is that the app's public name is still unsettled, because "HealthLog" is already taken by another app on the App Store, and I have not decided what the final title should be. The misspelled beta label gets fixed with one of the next TestFlight builds either way.

Enjoy the app, and if the cleanup of that drive folder surfaces anything the document import handles badly, I would like to hear about it.

[el-abcd]

I saw the updates, and they looked good.

Two more (optional) notes...
I sometimes do some hobby programming projects, and some of the web ones also default to port 3000 for the local dev server.
I had stopped the HealthLog docker container (which was serving to localhost:3000) to prevent conflicts.

1. But, I realized that the "tailscale serve --bg localhost:3000" command would then ALSO share my hobby dev server to my local tailnet (not useful, as the web page was not designed for mobile use).

• I looked a bit, and I THINK it is possible to directly connect a particular docker container to the local tailnet. Then I think only that docker container is shared, and the sharing is started / stopped as that docker container is started / stopped.
• https://tailscale.com/docs/features/containers/docker
• Perhaps the "docker compose" example is simplest, if HealthLog already uses docker compose? I think you need to tweak your Tailscale account to be able to generate an auth key, and then copying that unique auth key into the docker compose is the main "user specific step".

2. Even after I had stopped the HealthLog Docker container, there was STILL some HealthLog landing page showing up at localhost:3000 (if I used the SAME chrome profile I had used before). If I used a different chrome profile that wasn't seen. AND it was somehow caching MY hobby server code (so I was NOT seeing updates that I made, even when stopping / restarting my hobby server).
   Claude Code narrowed it down to : a healthlog PWA service worker (v1.37.31) registered at scope http://localhost:3000/, serving this tool's pages out of its own offline cache.

I was able to remove it by running this (in the chrome developer console):

(async () => {
  for (const r of await navigator.serviceWorker.getRegistrations()) await r.unregister();
  for (const k of await caches.keys()) await caches.delete(k);
  location.reload();
})()

I think this will happen again if I run HealthLog again, though... Per Claude Code...

But it will recur. That SW claims scope http://localhost:3000/ — the whole origin — so it hijacks whatever you serve there next. Every future port-3000 project on this profile inherits the same ghost, and the failure mode is hard for a user to understand: the server looks healthy, the code on disk is correct, and restarting proves nothing.

MAYBE the service worker can be scoped / limited more? Perhaps to something like "http://localhost:3000/HealthLog" or "http://localhost:3000/HealthLog_vX.Y.Z"
Or perhaps it clears the serviceWorker as the server is shut down? But I guess if the process is killed it will still happen. Or maybe there is some option for the serviceWorker to expire after 12hr / 24hr (so it would automatically "clean itself up"), etc.

Regards,
Eric