I’m missing the rpi1 in that list. Please fix ASAP.

I’e seen that some want it to host their own LLM. It’s far cheaper to buy DDR5 memory than somehow getting 100+ GB of VRAM. Whether or not this is a good idea is another question

The DNS record must point to cloudflare, not the instance IP

I’m glad that development is getting more stable, the regular updates with breaking changes were not so great.

That’s true, but might not really be a problem for most. Just set the jail time to something short (few minutes, maybe an hour).

There is no way to be 100% sure, but:

• bitwarden and ente have open source clients that ecrypt all data locally in a way that the provider can’t restore data
• nextcloud isn’t optimal, while you can encypt data at rest, the provider might be able to spy on you
• With mail providers it is difficult, but mailbox.org has my (personal) trust by building their business model on data protection and open source

I can and do self host, but I’m not willing to provide these services for free. I don’t want to be responsible for other peoples passwords or family photos.

Thats where good, privacy-respecting services come into play. Instead of hosting for my neighbours, I would recommend mailbox.org, bitwarden, ente or a hosted nextcloud.

The blog post contains an interesting tineline. Apparently, the first fix was not sufficient. So if you have updated Vaultwaren before November 18, update it again.

Copy of the timeline:

• End of October 2024: ERNW assesses Vaultwarden for the customer.
• November 08, 2024: ERNW discloses the vulnerabilities to the Vaultwarden team.
• November 10, 2024: Fix and release of Vaultwarden v1.32.4.
• November 11, 2024: ERNW retests the software and identifies that the fix is not sufficient.
• November 11, 2024: Public merge with fix and request for feedback by the Vaultwarden team.
• November 12, 2024: ERNW acknowledges that the fix is complete.
• November 18, 2024: Release of Vaultwarden v1.32.5.

My HP has a 65 watt CPU built in, when it’s running at full load it is quite loud.

Small, 10 inch rack, with some 3D printed rack mounts.

Maybe try some TLS-based VPN? This should work almost anywhere, because it looks like a standard HTTPS connection.

Wireguard - even on port 443 - is special as it uses UDP protocol and not the more widely used TCP protocol.

I like it :) Can you provide a link to the sensors you used?

You‘re supposed to host this yourself.

Set the DNS cache time to 60 seconds.

Set the script to run on every host delayed by some time to avoid simultaneously accessing the API (e.g. run the script every other minute).

With this approach, you get automatic failover in at most 3 minutes.

I’d host it on both webservers. The script sets the A record to all the servers that are online. Obviously, the script als has to check it’s own service.

It seems a little hacky though, for a business use case I would use another approach.

OP said that they have a static website, this eliminates the need for session sync.

Your challenge is that you need a loadbalancer. By hosting the loadbalancer yourself (e.g. on a VPS), you could also host your websites directly there…

My approach would be DNS-based. You can have multiple DNS A records, and the client picks one of them. With a little script you could remove one of the A Records of that server goes down. This way, you wouldn’t need a central hardware.

No, with these reasons:

• Bandwidth isn’t plenty
• My “uptime” at home isn’t great
• No redundant hardware, even a simple mainboard defect would take a while to replace

I have a VPS for these tasks, and I host a few sites for friends amd family.

It is good that they are easier to read, because they are about as long as the first book of The lord of the rings.

You’re right, Google released their vision in 2023, here is what it says regarding lifespan:

a reduction of TLS server authentication subscriber certificate maximum validity from 398 days to 90 days. Reducing certificate lifetime encourages automation and the adoption of practices that will drive the ecosystem away from baroque, time-consuming, and error-prone issuance processes. These changes will allow for faster adoption of emerging security capabilities and best practices, and promote the agility required to transition the ecosystem to quantum-resistant algorithms quickly. Decreasing certificate lifetime will also reduce ecosystem reliance on “broken” revocation checking solutions that cannot fail-closed and, in turn, offer incomplete protection. Additionally, shorter-lived certificates will decrease the impact of unexpected Certificate Transparency Log disqualifications.