Gladys Assistant: a self-hosted home assistant you run from a Docker command

The problem Gladys solves, and the household it fits

Most consumer smart home hubs route your sensor history, your schedules and your presence data through a vendor cloud. Gladys Assistant takes the opposite position: the README calls it a "privacy-first, open-source smart home assistant", and the deployment model backs that up. You run the whole thing on your own machine, and the repository is licensed Apache-2.0 with the source on GitHub.

The target user is someone with a mixed house. The topics listed on the repository include raspberry-pi, iot and smarthome, and the official site describes installation guides for a mini-PC, a NAS or a Raspberry Pi. That is the profile: a person who already has a small always-on box, has some Zigbee or Wi-Fi devices from more than one brand, and would rather not hand a third party a log of when everyone is home.

It is not aimed at someone who wants a phone app and a plug-in hub with no server. There is no managed Gladys cloud described in the README. The instance is yours to host, back up and patch.

How the server, the front end and the SQLite file fit together

The repository is split into two application directories, server/ and front/, plus a docker/ directory and a docs/ directory. The root package.json runs them together in development with run-p start-server:dev start-front:dev, and it declares Node 24.x and npm 11.x as the engine requirements. So the running system is a Node server with a separate front-end build, not a single bundled binary.

The production image is built differently. The root scripts show build:clean removing server/static, build-front running the front-end build, and copy-front copying front/build into server/static. In the shipped container the Node server serves the compiled front end from that static directory, which is why one port is enough.

Persistence is SQLite. The docker run example passes SQLITE_FILE_PATH=/var/lib/gladysassistant/gladys-production.db and mounts the host directory /var/lib/gladysassistant into the container at the same path. That mount is the whole of your state: devices, history, configuration. Copy that directory and you have a backup; lose it and you have a fresh install. The README does not document an external database option.

The container is also given the host Docker socket, /dev, /run/udev and /run/dbus. That is how it reaches hardware and how it can run things on the host, and it is the single most important thing to understand before you paste the command.

Installing Gladys Assistant with Docker and reaching the dashboard

The README's Try Gladys Assistant section gives one command. It runs detached, restarts always, uses host networking and privileged mode, and pins the image tag to v5:

sudo docker run -d \
  --log-driver json-file \
  --log-opt max-size=10m \
  --cgroupns=host \
  --restart=always \
  --privileged \
  --network=host \
  --name gladys \
  -e NODE_ENV=production \
  -e SERVER_PORT=80 \
  -e TZ=Europe/Paris \
  -e SQLITE_FILE_PATH=/var/lib/gladysassistant/gladys-production.db \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /var/lib/gladysassistant:/var/lib/gladysassistant \
  -v /dev:/dev \
  -v /run/udev:/run/udev:ro \
  -v /run/dbus:/run/dbus:ro \
  gladysassistant/gladys:v5

Two environment variables are worth changing before you run it. SERVER_PORT=80 puts the interface on port 80, and TZ=Europe/Paris sets the container timezone, which matters for any schedule you build later. Set TZ to your own zone. Because the command uses --network=host, the port is bound on the host directly.

After the container starts, open the host's address in a browser on that port and you should get the Gladys setup flow. The README does not describe the first-run screens, so treat anything past the login as something to read on the official site rather than guess at.

If you would rather not keep a long docker run line in your shell history, the README points to a separate Docker Compose installation guide at gladysassistant.com/docs/installation/docker-compose/. The Compose route is the one to prefer if you already manage other services that way, since the volume and device mappings above are exactly the kind of thing you want in a file under version control.

The privileged container is the real adoption cost

Look again at the flags: --privileged, --network=host, the Docker socket, /dev, udev and dbus. Gladys needs them to discover USB radios, talk to hardware and manage containers on the host. The trade-off is that a compromised Gladys instance is not a contained problem. Anything that can reach the Docker socket can generally reach the host.

That is a design decision, not an oversight, and it is the same decision every local-first hub makes when it wants to control real radios. But it means you should not expose this instance to the open internet without thinking carefully, and you should not run it on a machine that also holds data you care about for other reasons. A dedicated mini-PC or a NAS volume is the sane placement.

There is a second, quieter cost: the pinned tag is gladysassistant/gladys:v5. That follows the v5 line automatically, which is convenient, but it also means an unattended restart can pull a new minor version. The release list shows v5.0.4, then v5.1.0 and v5.1.1 within weeks of each other. If you want reproducibility, pin the exact version instead of the major tag and upgrade deliberately.

Where Gladys is the wrong tool

Gladys is a general automation server, not a Zigbee coordinator or a Z-Wave stack in itself. If your devices are all from one vendor and that vendor's app already does what you need, adding Gladys buys you a server to patch and a database to back up in exchange for control you may not want.

The README does not enumerate supported integrations. It links to the official website for installation and to a contributing guide for developing a service, which tells you integrations are a first-class extension point, but it does not tell you whether your specific thermostat or doorbell is covered. That is the first thing to check, and it is checkable only on the project's own site or in its community forum, which the README links at community.gladysassistant.com.

Also note the platform floor. The repository declares Node 24.x and npm 11.x for development, and the documented deployment targets are a mini-PC, a NAS or a Raspberry Pi. If you wanted to run this on a shared web host or a serverless platform, the architecture does not fit: it is a long-lived process with a local SQLite file and host device access.

Home Assistant and the difference in approach

The obvious comparison is Home Assistant, the other large open-source home automation project. The difference that matters here is packaging and scope.

Gladys ships as a single container image, gladysassistant/gladys, with the front end compiled into the same process and SQLite as the only datastore. You mount one directory and you are done. The README's install is one command, and the project's own alternative is a Compose file that wraps the same image.

Home Assistant's ecosystem is broader and its integration catalogue is larger, which is exactly why its installation surface is larger too: more moving parts, more configuration files, more ways to run it. If your house has an obscure device, that breadth is the reason to pick it. If your house has mainstream devices and you want the smallest possible thing to operate, Gladys' single-image model is the argument in its favour.

Both are self-hosted and both keep your data local, so the choice is not about privacy. It is about how much integration coverage you need versus how much operational surface you are willing to carry.

Licence, releases and what an upgrade actually costs

Gladys is Apache-2.0, stated in the README badge, in the repository package.json and in the LICENSE file at the root. Apache-2.0 permits commercial use and modification and includes an explicit patent grant. It also requires that you keep the licence and notice files when you redistribute. If you are embedding Gladys in a product you sell, read the licence text yourself rather than relying on a summary; this is a description of the file, not legal advice.

The release cadence visible in the repository is fast. v5.0.4 landed on 2026-09-04, v5.1.0 on 2026-09-21 and v5.1.1 on 2026-09-22. The last push to the repository was on 2026-09-23.

For an operator, that cadence sets the upgrade cost. Because state lives in one SQLite file under /var/lib/gladysassistant, an upgrade is: stop the container, back up that directory, pull the new image, start it again. The README does not document a rollback path, so the backup is your rollback. If you pin gladysassistant/gladys:v5 you will get these updates on restart whether or not you planned for them, which is why pinning an exact version is the safer default on a house you do not want to debug on a Sunday evening.

Editorial conclusion

Adopt Gladys if you already run Docker on a mini-PC, NAS or Raspberry Pi and you want the automation logic and the database on hardware you own. Skip it if your house depends on a device ecosystem that has no Gladys integration, or if you are not willing to give a container privileged access and the host Docker socket. Before committing, check the integrations list on gladysassistant.com against your actual devices, and confirm the host directory you mount matches the path you pass in SQLITE_FILE_PATH.

Frequently asked questions

Official sources

1. GladysAssistant/Gladys on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases