glucodroid.cloud : free, community sponsored Nightscout/Juggluco endpoint for followers

[robster7674]

@ctqvva, folks, have a look at https://glucodroid.cloud/ and let me know what you think please. The idea is to provide people who can't afford the (for some) fairly expensive (and often kinda complex) Nightscout setups for free, while people who have some money to spare can sponsor for our infrastructure cost and development/maintenance efforts.

Looking forward to feedback and thoughts. Useful? Feel free to share. For now I've capped signups to 50 to see how the infrastructure behaves under some load.

[ctqvva]

Sounds fun, a fair warning — running free* NS service will get expensive, that much I am certain.
Should also probably consider their new modern creation https://github.com/nightscout/nocturne (haven't tested it myself yet and I'm not a big NS user tbh, its licensing is a bit quirky as well)

There's also this sloppy mess I attempted a while back https://github.com/ctqvva/JugglucoNG-Hub (original mirror part there has few useful pieces like raw mode support for some of our sensors and half-baked calibration payload sharing).
But honesty the entire legacy juggluco mirror logic we have is a bit ugly atm, and it barely works with most of the new kotlin codebase. I was actually considering doing a leaner sync of some kind (might as well even reuse this new API destinations I did) with some proper cloud integration.

[robster7674]

Hah yeah, I thought about that... and this led me to see if the "social experiment" of solidarity pricing can work. I mean, there are projects doing this successfully, right? Besides that, I focused heavily on getting a lean e2e stack so that one vps can host quite a few users, dramatically reducing cost compared to full Nightscout. Happy to add you to the repo for it - I kept it private for now until I iron out security vulnerabilities and performance/scale testing. Wanna take a look? Perhaps you can set up a test account on glucodroid.cloud to see how/if it works as I expect it to?

Agreed that the mirror logic isn't beautiful, but it does the job so far I've been able to test. Have you found any specific issues yet that block it from working with the "modern" Juggluco variants?

Honestly, your Hub looks great, but still way too "techy" for non-tech savvy users like a Mom who just wants to monitor her kid. I wanted to have something for those people: non-tech savvy, non-developer, or people who just don't want to bother with the setup. I suppose the host-side of your Hub would be deployed on some vps?

"I was actually considering doing a leaner sync of some kind (might as well even reuse this new API destinations I did) with some proper cloud integration." - perhaps we can team up and work on something together? I'm curious to your ideas as you obviously have given this way more thought already than I did so far. ;)

[ctqvva]

Hah yeah, I thought about that... and this led me to see if the "social experiment" of solidarity pricing can work. I mean, there are projects doing this successfully, right? Besides that, I focused heavily on getting a lean e2e stack so that one vps can host quite a few users, dramatically reducing cost compared to full Nightscout. Happy to add you to the repo for it - I kept it private for now until I iron out security vulnerabilities and performance/scale testing. Wanna take a look? Perhaps you can set up a test account on glucodroid.cloud to see how/if it works as I expect it to?

Sure, you can add me if you want.
I did try it out actually, changed up port limits to allow 443 (probably shoudln't do it like this as original juggluco won't ever be compatible), but still ended up with failed to connect with "testsendmagic: Wrong magic"

Agreed that the mirror logic isn't beautiful, but it does the job so far I've been able to test. Have you found any specific issues yet that block it from working with the "modern" Juggluco variants?

It's just really fragile somehow, always breaks and it's very annoying to work with. Also its original concept (that I didn't go anywhere near in JugglucoNG, as we only really mirror sensors) is based upon mirroring the entire app with all its sensors, settings and data, which might be useful in certain edge cases, but a bit overkill in most scenarios, while just straight up problematic with some.

Honestly, your Hub looks great, but still way too "techy" for non-tech savvy users like a Mom who just wants to monitor her kid. I wanted to have something for those people: non-tech savvy, non-developer, or people who just don't want to bother with the setup. I suppose the host-side of your Hub would be deployed on some vps?

Yeah, it's meant to be more of a simplified one-click install onto a user-provide server, so certainly not for complete novice. At least that was the intention, but I haven't really finished it.

"I was actually considering doing a leaner sync of some kind (might as well even reuse this new API destinations I did) with some proper cloud integration." - perhaps we can team up and work on something together? I'm curious to your ideas as you obviously have given this way more thought already than I did so far. ;)

My initial thought was to do something around this new API destination thingy (that I added for chatbots integration recently) and perhaps Cloudflare workers. Mostly free at first, somewhat expensive at scale, but at least it can be scaled seamlessly and reliably.

[robster7674]

Hi @ctqvva , just added you to the repo, have a look at my spaghetti code. ;)

I gave this some more thought and yes, a modern api does seem to be the right way forward. But, do we really need a new api or could we simply use the Nightscout api? One objection I have is that a user-provided server, or something like CloudFlare Workers, still has the non-novice requirement and it basically locks out the "Mom-user". So, what if we combine the two: instead of the user needing to provide a server, we rearchitect glucodroid.cloud to be the relay for the new api, in a serverless fashion similar to how it would work with CloudFlare Workers. I see two big advantages that way:

1. removes the non-novice requirement/barrier
2. greatly increases scalability since the same vps now can serve many more users

Added benefit would be that we can completely leave the existing mirror code intact, but we would not need to work on any issues that might be remnants from the past anymore.

You mention "somewhat expensive at scale", what makes you say that?

[robster7674]

Seen https://getnocturne.dev/? Is that similar to glucodroid.cloud? Interesting. Edit: here's some analysis of my ai buddy:

Yes, almost certainly — and this reframes the whole comparison in a much more interesting way than "which one replaces the other."

Why it should just work

Nocturne lists Nightscout as one of its 22 connectors, with a described "two-way bridge." Your API is exactly what a Nightscout follower speaks:

• GET /api/v1/entries.json, /status.json, etc. — standard shape, standard auth (api-secret header, sha1 of the secret)
• A clinic or family running Nocturne would just add a "Nightscout" source per patient/family member, pointing at https://patientname.glucodroid.cloud, using the API secret they already have from their GlucoDroid setup

Nothing on your side needs to change. You're not a Nocturne-specific integration — you're a generic Nightscout-compatible endpoint, and that's precisely the point of building to the standard API rather than a custom one.

One real caveat worth flagging

Nocturne markets that connector as a "two-way bridge with Nightscout." Your PRD.md is explicit that your REST path is read-only at the application level for everything except /api/v1/entries — treatments, profile, and devicestatus writes get a 405 (@reject_writes). If Nocturne's bridge tries to push treatments or profile data back down to the source Nightscout instance (e.g. syncing a clinic-entered note or bolus back to the patient), those calls would bounce off your API. Pure read-aggregation (entries → reports/alarms) should be unaffected; anything relying on Nocturne writing back to you would need Nocturne to tolerate a 405 gracefully, which you can't control from your side.

Why this is actually the right shape of partnership, not competition

This is the complementary model, not the replacement model I was originally asking about:

• You stay the cheap, always-on, high-tenant-density ingestion/relay layer — the thing a person with a phone and a CGM points at with zero infra
• Nocturne becomes an optional presentation layer a clinic, household, or community group can self-host on top of multiple glucodroid.cloud subdomains, getting AGP/TIR/GRI reports and alarm rules they'd otherwise have to build themselves

You get the clinical/family aggregation use case without taking on Postgres, multitenancy-in-app, or WebSocket infra — someone else's project absorbs that complexity, funded by people who specifically want it. It's a much better fit than trying to make glucodroid.cloud itself into a dashboard product.

One thing I can't verify without live access: how aggressively Nocturne polls Nightscout-type sources by default. If it polls faster than a typical follower app (say, every 5–10s instead of 1–2min) to approximate its "real-time" promise, that could stress your subdomain-keyed rate limiter and 8s cache more than a normal follower would. Want me to search for whether Nocturne's docs specify a poll interval for generic Nightscout sources?

[ctqvva]

Seen https://getnocturne.dev/? Is that similar to glucodroid.cloud? Interesting. Edit: here's some analysis of my ai buddy:

:P

[robster7674]

LOL, totally didn't remember that... did you in the meantime have a look at the cloud repo yet? ;)

Nocturne seems an improvement, but it appears mostly moving away from mongodb to postgresdb, so still quite a bit of complexity to host, and wayyyy more expensive than glucodroid.cloud. :)