_Chief

low risk, do this. Keys (ed25519,4096 rsa) are impractical to brute force. However I'd also recommend:

- use a different port than 22 (add your .ssh/config for easier UX if needed) - port 22 can get incredibly noisy with tons of bots probing

- disable passwordAuth, disable PermitRootLogin - use a normal user with sudo for your ssh

- consider a vpn please - I use tailscale, but I hear headscale is good - then use UFW to only allow SSH from the tailscale network (I generally allow all network on tailscale). Tailscale wrote a guide on this here [1]

- do not add and forget authorized_keys from machines you arent using

- I'm especially worried about how people keep giving Clawdbot/Openclaw access to all their machines, key auth means the machine is authorized on your server

- For new servers I often just add all my public keys to them (github lists all your keys at github.com/GH_USERNAME.keys

I wrote an MCP server directory-indexer[1] for this (self-hosted indexing mcp server). The goal being indexing any directories you want your AI to know about and gives the it MCP tools to search through the embeddings etc. While an agentic grep may be valuable, when working with tons of files with similar topics (like customer cases, technical docs), pre-processed embeddings have proven valuable for me. One reason I really like it is that it democratizes my data and documents: giving consistent results when working with different AI assistants - the alternative being vastly different results based on the in-built capabilities of the coding assistants. Another being having access to you "knowledge" from any project you're on. Though since this is selfhosted, I use nomic-embed-text for the embedding which has been sufficient for most use cases.

I had a lot of success with Juggluco[1] which is available on the Play Store and provides easy to use APIs to interact with supported CGM readings. Juggluco has an inbuilt xdrip web server but I haven't tried it yet.

Will definitely look into xdrip+ further.

Decided to port the backend to Go + postgres (on a Hetzner VPS), and retain the frontend on Nextjs - A lighter weight client, moving most of the compute to the backend API. Few reasons for the port: I've had a lot more success/stability with Go backends, Turso pulled multi-tenant dbs which is what I mostly wanted them for, Nextjs is getting too hard for me.

Go backend is just the std lib (1.22+ server with the nice routing) - I mostly write all the lines in this

If this truly is the only cookie you store, then you may not need the cookie banner, you can explain the cookie usage in your Privacy Policy.

For gdpr[1], strictly necessary cookies, like for login as you describe, do not require consent to be obtain as long as their usage is explained like in your privacy policy.

That's not what I expect from a "demo" of a captcha.

A recommendation would be; please use mcaptcha on the mcaptcha account sign up page at the least. It'd then provide an instant user UX demo which is one of the major pains of captchas.

Or at least provide a link to the widget[1] for UX demo, where inspecting networks calls also shows the api calls in action