If you’ve got a slew of different applications running on your home network, it might be time to add a reverse proxy. What is a reverse proxy? It allows you to access your services at a nice easy to remember URL rather than an IP Address and port. For example, instead of accessing Home Assistant at http://192.168.1.2:8123 I can instead type https://homeassistant.example.com. On top of creating a reverse proxy in today’s article, we’ll also be adding HTTPS support via Let’s Encrypt. This will give us a secure connection on our LAN so that when we connect to the application we know there is no one listening while on our network. Maybe a bit overkill, but it does give you the nice green badge in your browser too.
Running your own private MQTT broker on your local network? This is great for all your local Home Automation devices but would about things that are outside your network? Apps like OwnTracks can communicate your GPS to an MQTT broker but you’ll need to open up your network to the outside.
Today’s article details a hybrid-cloud solution using an external MQTT broker in conjunction with a private MQTT broker running on your local network. Home Assistant (or any Home Automation platform) can subscribe to topics on your local MQTT broker while still receiving messages from the external one.
How do you start up your multi-container application? Lots of the time these multi-container setups have dependencies between them and you need to start them in a specific order? How can you get this done automatically on bootup? Today I’m going over how to use Docker Compose and systemd to automatically launch all your containers in the correct order on bootup leveraging systemd on a Debian host.
So if you’ve got an MQTT broker (or another service) that must start up before your Home Assistant service and you’re already using Docker Compose this is an article for you! This method works great on a Raspberry Pi but should also work on anything using systemd as the initilization system.