+1 for Ubuntu server.
I am running an Ubuntu server minimal install VM dedicated to hassio.
This is on ESXi hypervisor on the Xeon version of the cheapo dell T20 server.
@MarkR - actually you make be surprised how simple hassio is.
There is a good discussion of hassio on ubuntu here including input on a minimal ubuntu deployment:
If you have docker on ubuntu then you have huge flexibility to deploy other things that are not yet supported as hassio addons (plex, pihole, openVPN etc etc)
For the first installation of HA I used, also on Ubuntu server 16.04
I’m running it via a Docker on a Synology DS918+ after upgrading from a rpi3 which should stand you in good stead to get started.
You say you want to steer clear of Docker but it really does make things extremely simple. I use a Chromebox flashed with a UEFI bios (basically turning into a Celeron NUC) and a minimal install of Debian Stretch. Then just installed Docker and Docker Compose, and once my docker-compose.yml file was written, getting everything up and running was as simple as docker-compose up -d.
When I need to upgrade, it’s just docker-compose pull to fetch updated images, then docker-compose down to bring down all containers and docker-compose up -d to restart them with their updated versions. Minimal downtime.
This setup is also completely portable between hosts/oses. If my Chromebox dies, I’d just order a new one or repurpose old hardware in the meantime, restore a backup of my /opt directory (where all my containers store their data), copy the Docker-compose.yml file over, and docker-compose up -d to get back up and running.
I run it now in a docker on my qnap and I’m having issues with the z wave etc hence why looking to move to a new system.
what benefit would i have running a docker on Ubuntu as apposed to Ubuntu in a virtual environment? I’m a windows tech (ok IT manager for years who WAS a windows engineer 
)who dabbles in unix via the qnap and raspbian only, so far
@MarkR Here’s my two cents on your question.
Don’t conflate a virtualized host and containerized apps: regardless whether you install Ubuntu on bare metal (like me with my Chromebox and Debian) or as a virtual machine in ESX, Proxmox, etc., you could (and I would say should) take advantage of Docker and containerized apps. So make the choice about bare metal vs virtualized os based on your own home IT setup and how complex you want that to be, it doesn’t have anything to do with whether you use Docker.
The real debate here is between the various ways to install Home Assistant, and I’ll use two examples for the sake of debate: 1) installing like a regular program directly on your OS vs 2) using a Docker container.
If you install like any other program, you need to install dependencies. HASS depends first and foremost on Python3 but has a lot of other dependencies, many of which are automatically installed by HASS based on the platforms you define in configuration.yaml. But that isn’t always the case: take the (still ongoing) example of the difficulties people have been having getting IKEA’s TRÅDFRI platform to work - because of issues with the dependencies that the HASS tradfri implementation has, users have had to figure out how to compile/install (among other things) aiocoap, tinydtls, and Cython to get tradfri talking to HASS. With a regular install, in other words, you need to worry about dependencies and installing programs on your OS. May not be a headache, but could be. If something gets messed up, it’s not uncommon to read about people blowing away their whole install and doing it again. Depending on your OS (take CentOS) as an example, you may also need to worry about manually updating Python3, since HASS has deprecated 3.4 and recommends running 3.6 moving forward. And if you use any companion programs to HASS (Homebridge, nginx for reverse proxy, Appdaemon) you need to worry about installing them and their dependencies too. If for some reason you need to reinstall your OS, you’ll need to spend a considerable amount of time reinstalling dependencies and tracking down configurations too.
With docker, you don’t have this problem. The HASS devs define a Docker image that contains all the required dependencies - Python3.6, the tradfri requirements, etc. So you just run one Docker command with a number of options, defining a directory where you want to store your configuration, ports, any devices you want to pass to the container (eg your zwave stick), and so on, and then it runs sandboxed from the rest of your system. Updating is as simple as docker pull imagename, deleting your container, and recreating it with the same options. There are containerized versions of most major software, including the HASS companion apps I mentioned earlier.
I could go on. The problem you are having with your Zwave stick is a QNAP problem, not a Docker problem. On a normal OS, you have access to more tools (including, on Linux, udev rules) to ensure that the naming of devices stays consistent between reboots.
HASS.io is a great step forward for the whole HASS project and is an easy way to get up and running fast with minimal under the hood configuration. It’s great for people who don’t want/need to tinker. I like more control so I ultimately went with my setup and am very happy.
Feel free to ask any questions you might have, I’m happy to share my config in more detail including my Docker specifics.
Superb summary
Totally agree with @hijinx brilliant repy thank you. Even though I use Docker on the QNAP I hadn’t really given it much thought that it is totally contained and I have blown it away several times and got it back in seconds. Hassio isn’t for me for the same reasons you state, I am a tinkerer and how I am learning being on the dark side of unix commands etc
So I have found 6GB ram, a 500GB disk and HP probook 6555b with AMD Turion II Dual-Core N530 / 2.5 GHz, Like I said I wish I hadn’t sold my NUC but hey ho, time to play with Ubuntu or maybe Debain (since I am used t it on the RPi) options options options!
Thanks a lot for this…
If you run hassio on your own linux platform (e.g. Ubuntu, centos etc) then its no different from a docker install of HA from a tinkering perspective. (I assume you’re not hacking your active docker container).
The “benefits” of hassio over docker install on your own linux install are:
stop giving me more of a headache with options!! 
Debian up and running on the laptop, now which way to turn
Edit, already switched to Ubuntu 16.04
well that was fairly painless (I know I should be working!!)
up and running in a docker on ubuntu
I always had issues on the qnap docker which I never really liked. So that test worked well and might have a play with HASS.io tonight
If I stick to a docker, is this command looking good to go? zwave stick still in the qnap as that is still live, but you get the idea.
docker run -d -p 8123:8123 --name home-assistant --restart=always --net=host --privileged -v /home/mark/homeassitant/:/config --device /dev/zwave homeassistant/home-assistant
Do you have a GUI version of docker or is there really no need for it? As I said I am a windows person trying to break free from guis
Cheers
Mark
I use unraid and its docker implementation. I have unraid installed on a liva-x mini pc and just have HA and Appdaemon running on it. Unraid complains that I only have one drive but essentially I am only using unraid for its docker portions and not its file server portions.
Unraid gives the most user friendly docker “gui” I have found so far (I’ve looked but everything else is for datacenters).
Your command looks good
I dont think you need --privileged AND --device but I dont think it harms.
For docker GUI install portainer.
Its a nice and light web GUI. Really helps find and clean up orphaned containers that wont show in docker -ps, and unused images.
I start it with:
docker run -d -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock
not worried about mapping a volume for persistence.
You don’t need privileged and device, only use one or the other. If you’re worried about devices changing names on reboot, use privileged and use the device under the path /dev/serial/by-id/, as it’s name won’t change on reboot.
HA can be installed virtually on anything these days… When I started, I used a Raspberry Pi3. I was surprised to get it up and running under 30 minutes. I then had to figure out how to set up groups, sensors, and automations…etc that took me a while
Over the period of time, the number of devices grew significantly, and Pi just couldn’t handle it any longer, I started seeing more crashes. I then moved on to Ubuntu 16.04 about 8 months back, and extremely stable since then. It now runs on a AMD 64 bit 8GB memory desktop, and he performance improved significantly. If you add SSD and newer hardware, it will literally fly!
I still have a few RPis that I have my Home Assistant running, it is a great way to get into the Home Automation space without spending too much. But once you start it, you can’t really help but spending money on it 
I never tried RPi since I have an ESXi server for NAS, Plex, Unifi controller plus a bunch of other microservices, of which HA became another member.
However I do remember back to the days where I ran Raspbmc (old kodi on RPi 1b setup) and the number of times I got a corrupted SD card was not anywhere close to funny. I changed to run the RPI to boot from USB stick and now years later it’s still going strong as a backup tvheadend server.
Cockpit is managment UI for Linux server
It include docker web UI as well
thanks for this!
I am basically up and running already, I switched over by accident while testing and every single thing works, so I stayed with it!
Wow this is fast…
I just tried that and it fails
so docker install is
docker run -d -p 8123:8123 --name Home-Assistant --restart=always --net=host --privileged -v /home/mark/HomeAssistant/:/config homeassistant/home-assistant
zwave:
usb_path: /dev/serial/by-id/usb-0658_0200-if00
i get Can’t find device /dev/serial/by-id/usb-0658_0200-if00
same is if put /dev/zwave (which is seen by ubuntu but i guess not the docker??) if I set it in 99-usb-serial.rules
any ideas please?
Must add --device=/dev/yourdevice to your docker run