Version control of Home Assistant confirguration

Configuration
1

Hi all,

running HA Core I have my Home Assistant configuration directory under version control and tried to keep everything within yaml files as much as possible.

With the urge from the product development to shift from yaml to clicking on the web UI and storing configurations and non-config files within .storage mixed, I was wondering how the community members solve the version control of their HA configuration?

More over those having several HA instances how do they solve the HA configuration deployment for the different instances? Manually setting them up one by one? Some automated solution (e.g. ansible)?

Thanks.

2

Hi Atticus Maximus,

I just mirror everything I want to save to GitHub. I have one HA instance as public, see my message footer, and I have another HA instance in GitHub as private.

Sharing your configuration on GitHub.

3

Hi @Sir_Goodenough ,

I have my local git server storing the yaml part of my Home Assistant configuration.
My question was rather on how people store in version contolled way whatever is in .storage where confgrations of custom integrations configured on UI mix with non-configuration file (states, etc.), some of these files store password in clear text, etc.

4

I only use the UI to configure what can only be configured from there - like integrations. Everything else I use YAML and use GitHub as version control. I extensively use packages - so that all the template, automations and YAML displays are together for a specific thing (like living room light control)

I do store the .storage directory also. I really don’t like that credentials are in there. Changing that starts with an architectural discussion. There’s likely a git precommit action that could created ro strip these fields out or encrypt / decrypt with a private key. If you make one, post it here.

5

Use .gitignore
I use .gitignore to exclude EVERYTHING atthe top of the file, then specifically allow stuff. It’s a bit much but the safer way to go if you are leaving your repo public like I am. You can see what this ends up as using my ha config link in my message footer.
I add the failsave at the bottom for files that under no circumstances should be shared. They should already be excluded, but sometimes accidents happen in the allow part in the middle, so this is the safety deny.
Example:

s -lovelace
## Ignore all
*
**

## Allow folders
# !*/
!/automation2/
!/automation2/*.yaml
...  and more stuff, one of those for every folder basically

## Allow files
!alert.yaml
!automations.yaml
!.HA_VERSION
!.gitkeep
!README.md
!LICENSE
... And more stuff, one for every .yaml file basically.

############# Failsafe  \/ \/ \/ \/ \/ #############

# File Ignores
home-assistant.log.*
remote_cmd.yaml
**secrets.yaml
shell_command.yaml
**/test.yaml
/zigbee2mqtt/*.yaml

# Generic ignores
*.log
*.db
*.db-shm
*.db-wal
*.pyc
._*
__pycache__

# Directory (contents) ignores
/blueprints/automation/test**
/blueprints/script/test**
/Purgatory**
/scripts/
/themes**
/www**
/.storage/auth**
/.storage/cloud**
/.storage/core**
/.storage/hacs**
/.storage/http
*/deps**
*/image**
*/pop.git**
*test**

# Ignore files created by IDE's
*&/.vscode**
*/.theia**
*/.Trash**
6

@Sir_Goodenough I use .gitignore to ignore among other things the .storage directory altogether.

Thanks for the hint, I started now to review what files have changed after the last Home Assistant restart and list in .gitignore those storing non-configuration related stuff.

I wish the .storage content were split into UI configured integrations related configuration files separated from *.registry files and other non-configuration related operational files (repair.issue_registry, core.restore_state, etc.). That would be another level in product design achieved with a minimal effort.

1 Like