Deploying Home Assistant with balena

Hi there!
I got into Home Assistant recently and of course I wanted to have my HA deployed with balena. Surprisingly I found little information or previous user experiences, and the process of setting it up was more challenging than I anticipated. So I documented the issues I had and wanted to share them.

If you have suggestions, alternatives or any comments please let me know!

1 Like

Hey @tmigone,

thank you very much for your medium post, we really appreciate the time you took to write it.
I will share it on our social media and I would also like to send you our swag pack as a thank you!

I will contact you privately,

Cheers :tada:

Hi @dansku, that is awesome, thank you! I’ll get back to you via pm.

Sorry it’s an old thread but I didn’t quite understand the Medium post that you sent. I feel that it’s a bit hard to follow for someone who’s new and working with Balena Cloud. If you could have a step-by-step guide or any other docs then that would be helpful.

What part are you having trouble with? Maybe we can help…
Maybe you also want to check out the projects here: they will generally have a more detailed step-by-step guide on how to deploy them and you can then take the knowledge for this one :slight_smile:

I got it to work! Thank you for your time. I just followed the Medium post carefully.

@tmigone Thanks for the detailed post on Medium – I definitely found it helpful, and believe it speaks to some of the issues I’m currently facing with regard to running Home Assistant on Balena. My current challenge is that I’m a total N00b to Home Assistant, Balena, and containerized applications – so there’s just a lot of surface area / learning curve – and often, it’s not immediately obvious which curve I’m on.

Case in point: Having completed virtually my entire migration from a SmartThings v1 hub (4 days until it implodes), I’m left with only some of my more complex automations - which may have used custom device handlers, or other automation (“mirroring” devices, such that all lamps in a fixture, for example, can be controlled as a single device). Clearly - that is a Home Assistant topic / question. But…

What about the task (as described in the Medium post, and still just beyond my grasp on a couple of points) is the management of my Config file for Home Assistant – and, the next great hurdle – Lovelace dashboards. As I’m working within HA, clearly by config is being updated - and persisted, outside the container – but… where / how would I do UI development? I certainly want to be keeping the config under source control - and am at least comfortable with “balena push” – but… ?

One clear / obvious question for @tmigone : When you speak of development vs. production – I assume this means you have two entirely different devices (but under a single application - or two distiinct ones?) within Balena. I love the idea of a dev environment, and have plenty of Pis to go around - but a dev device wouldn’t have all my Zigbee and ZWave devices plumbed to it, of course - making testing certain things challenging. I guess I could at least be doing UI work there, testing upgrades, new integrations and config changes.

Thanks again for the post, and thanks in advance to the community for any additional insights, #ProTips or hand-holding.



I have pinged Tomas, but I’d like to take a shot at your dev and prod device question. In balena terminology, we use development and production devices to indicate devices that are running the development and production version of the balenaOS. These are 2 separate images, that have some differences - for example support for local device development exists in the developer image. You can read more about this on our docs for the same

There’s nothing stopping you from having the a production device (i.e. a device running production variant of balenaOS) along side a development device(i.e. a device running a development version of balenaOS) in the same app. In fact that’s exactly how I do my app development. I develop locally on my dev device, and then push to the balenaCloud when my app is ready to be distributed to my other devices.

If you don’t want to enable certain services on your development device, you can either maintain 2 separate docker compose files, or structure your app such that your services check for a local variable to start or stop. So if you have an env variable that prohibits your zigbee service from running, that can be something you use to distinguish between your prod and dev devices (env variables can be set either fleet wide or per device)

1 Like

Thank you, @anujdeshpande ! I’ve been chipping away at some of the masterclasses and doing a bit of balena push via the CLI for some projects – and I’m totally following what your describing, and appreciate the feedback.

I guess my question is less Balena-centric, and more about Home Assistant - so perhaps (at least part of) my question belongs over there (e.g. How to do development on devices that can only be connected to one “network”. I know, I know - with stubs, or ‘digital shadows’ of devices. :smiley: But applying that, for example, to the Zigbee or ZWave “Integrations” and device registration, grouping, automations, scenes, triggers… it seems the only place I can do development about “Grouping my 3 dining room lights together and controlling them as a single unit” will be in my prod, RUNNING device. Then, any successful changes would need to be ‘back-ported’ to the repo – YIKES! This doesn’t sound like the right workflow… :slight_smile:

That’s the part of Tomas’ post, right at the fringes of my Docker and Balenu understanding, is the description of the mount vs, the bind mount, the timing of same and copying of files into the image.

I’m gonna give it another read - and go hands-on (on a development build :)) and see what I can figure out.

Thanks again for the insights!

hey @snowake, I’m glad you found the post useful!

Let me clarify the “prod” vs “dev” conundrum. What both you and Anuj describe is correct. balenaOS offers two flavours (“Production” and “Development”) with some differences, the main one being that the development version provides tools that aid you if you want to develop your code on your device (see this blog post for more context on that).

However, in my HomeAssistant blogpost I was not referring to balenaOS flavours when talking about prod and dev but rather:

  • “production” is my Raspberry Pi that actually runs HomeAssistant 24x7
  • “development” is my development machine, my laptop computer where I do all my work.

This setup has an obvious drawback and it’s the one you already found, if you are working with hardware that connects to your Home Assistant device you need to have it connect to both your dev and prod devices. At the time I wrote the blogpost I only had some Philips Hue lights and a couple of sonoff devices, both of which I had connected to my Raspberry Pi for prod but also to my computer for development. If you have a bigger setup this is not scalable at all and it might not even work. I’m not sure how the HomeAssistant devs do actual development maybe as you say it’s worth bringing this issue to their forums/GitHub as they might have some tips.

Since then I’ve moved away from the workflow I talk about in the blogpost for this reason, moreover with recent (last 1.5 years) HA changes they are moving more and more into the direction of storing configuration in database-y files and not YAML files. So it become harder and harder to use this workflow I describe. What I’m currently running is a modified version of GitHub - balenalabs-incubator/balena-homeassistant: Raspberry Pi + Home Assistant + balenaSense which is just a HA instance (you can ignore/remove the balenaSense stuff). This approach has a couple notable drawbacks that I have to live with:

  • I have no “development” environment anymore, so every time I upgrade stuff breaks.
  • I need to manually backup the “config” volume. This ties in to point #3 on my blogpost (Source control with GitHub: Backup HA configuration and rules to a git repository.). As I mentioned before HA nowadays relies more in database files than YAML so I had to give up on this. Now if for some reason I have to re-flash my Raspberry Pi I need to import my HA config backup.

Those are my 2c, other than that I’ll ask a colleague that’s much more experienced with Home Assistant to chime in if he’s got anything else to add.

Thanks, @tmigone - for the detailed response! I feel like I’m at a decision point - and need to either go all-in on figuring out Home Assistant in the context and deployment model of Balena – or just go with a more vanilla, HomeAssistantOS running on a RPi4 sort of deployment architecture - at least for my ‘Production’ use case (which is subject so significant WAF pressures). Case in point: The fact that:

Alexa- turn on dining room light

no longer behaves as expected desired – and that is one frequently-invoked home automation routine. So - I’m struggling on a variety of fronts – from ZWave integrations (and the proposal, from this thread, that in order to migrate to the newer ZWave-js integration - I’d need to install an “js2MQTT” or some such container, along side my HomeAssistant, to facility the configuration (but, apparently, not the actual integration?

I guess one specific question I can appropriately ask here (it feels like the answer can be found in your Medium post - but I’m not finding it where expected).

Where would I find my config files? I do see the /config directory, as mounted in the homeassistant container – but not finding the corresponding ‘persistent’ version of it in the Host OS? I suspect I’m missing some key concept :slight_smile:

My goal, currently, is to delete an ‘orphaned’ ZWave device which didn’t seem to add properly (with both of the required entities) - so I was unable to control it. I’ve tried removing (ZWave exclusion) – and can get rid of the associated entities, but not the actual device.

I know, I know: That’s a question for the HA forums. I asked it, here:

At any rate - for today, my goal is just to get the current Balena-deployed HA up and operational, and achieving full WAF. Going forward, I hope to detangle some of the various pros and cons and make an informed decision about my target state deployment - for both “production” and development environments (noting the hardware constraints discussed above). Perhaps an additional Zigbee / ZWave stick, and a few devices confined to just my office… :slight_smile:

Thanks again for your detailed write-up. I’m off to read it carefully a third time, while referencing the Dockerfile and docker-compose files - to see if I can enhance my understanding.


where / how would I do UI development? I certainly want to be keeping the config under source control - and am at least comfortable with “balena push” – but… ?

You can simply use a (private) GitHub repo for source control and continue using balena push. There is even a GitHub action to automatically push to balena. For UI development I’d recommend using what is called “multi-stage docker files”. This basically means, you write multiple docker containers (for different purposes) in one file.
So your UI container’s Dockerfile might look something like this

FROM node as build
COPY . .
RUN npm ci && npm run build
# final image, which will get actually deployed
FROM ngix
COPY --from=build . /var/usr/www # you'd better check if that path is correct

Where would I find my config files? I do see the /config directory, as mounted in the homeassistant container – but not finding the corresponding ‘persistent’ version of it in the Host OS? I suspect I’m missing some key concept

Volumes in compose are an abstraction of storage that can be mounted. The default (like in your compose file) is using “Docker Volumes” which are like containers without running processes, just an empty filesystem.
You can list them with `balena volume ls. There are similar commands to extract the data as well.

Hope this helps as entrypoint to your further research

1 Like