indi-allsky comes with everything you need to always provide the latest image or video from the Allsky camera via redirect. This means that websites, blogs or dashboards can be provided with “live” views of the camera without much tinkering.
I use the whole thing on this page:
Live image from the Allsky camera in Rodgau-Weiskirchen
I’ve been using the Brave browser for some time now, but when setting up the SSL certificate for my Allsky camera (see instructions), the browser was really bitchy. While Chrome and Safari accepted my Let’s Encrypt certificate immediately, Brave continued to display “Broken HTTPS” – even though the server was configured correctly and openssl confirmed a clean TLS chain. And this is how to solve the problem!
*** Note: A friendly reader pointed out to me that sometimes a restart of Brave is sufficient. However, I was unable to verify this. But maybe try it first before following the steps below! ***
Since my Allsky camera has been publicly accessible via its own subdomain, I regularly see access attempts from certain countries. IPs from Russia (RU) and China (CN) in particular appear disproportionately often in the log files – mostly automated scanners, bots or credential stuffing attempts.
Of course, a hardened system (firewall, Fail2Ban, rate limits, HTTPS) already provides pretty good protection. But: I wouldn’t have to pull many of these requests into my system in the first place. That’s why I also use geo-blocking: the Raspberry Pi simply rejects TCP connections from certain countries before the web server reaches them.
If you run an indi-allsky installation on a Raspberry Pi and want to make it publicly accessible via your own domain, you will quickly encounter two typical challenges:
In this article, I will show you the complete, working solution: A Let’s-Encrypt certificate for a subdomain such as access.allsky-rodgau.de, delivered via Apache as a reverse proxy, including a functioning auto-renewal routine via HTTP-01 challenge.
***This guide was updated in December 2025 and works perfectly for me***
While IPv4 is structurally protected by NAT, IPv6 is always globally accessible without a firewall – completely without port sharing. This is precisely why an IPv6 firewall is not a “nice to have”, but a must.
I was surprised that my Raspberry Pi was immediately given a global IPv6 address. This means that it can be reached from outside without NAT. Without ip6tables, all IPv6 services are open – often without you even noticing.
The solution is an IPv6 firewall similar to the IPv4 configuration, but with one important difference: ICMPv6 should not be blocked, as otherwise functions such as neighbor discovery, router advertisements or MTU detection will no longer work reliably.