# Gladys documents a privileged, host-networked install and invites agent-written pull requests

> Gladys Assistant is an open source home assistant whose readme gives you one command to run it. That command asks for more than most software needs: privileged mode, the host network namespace, the container runtime's own socket, the whole device tree, and a writable data directory, with the application's port bound straight onto the host. The rest of the page is a contributor invitation that explicitly welcomes work produced with an AI agent.

**GladysAssistant/Gladys** — A privacy-first, open-source home assistant

- Repository: https://github.com/GladysAssistant/Gladys
- Website: https://gladysassistant.com
- Stars: 3,222 · Forks: 324
- Language: JavaScript
- License: Apache-2.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/gladysassistant-gladys

## The one-line install grants a lot, and the page prints the whole command

The readme's install section is a single command, run with elevated privileges, and it is worth reading as a list of grants rather than as a copy-paste.

```bash
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
```

Four of those lines decide what a compromise of the application means. Privileged mode plus the host control group namespace removes most of what container isolation normally provides. The container runtime's socket is bind-mounted, which is the standard way to let a container ask the host to start other containers, and it is equivalent to handing over control of the machine. The whole device tree is mounted read-write, which is how a container reaches hardware directly. And the host network namespace, combined with the application listening on port 80, puts the interface directly on the local network with no proxy in between.

None of that is wrong for a home assistant, which needs device access and is often the thing managing other containers. It is a wide grant, and it is printed in full rather than hidden in a script, which is more than most projects manage.

## Three logs of restraint sit inside that same command

It would be unfair to stop at the grants, because the same command contains three decisions that are the opposite of casual.

The log driver is switched to a size-capped rotating file with a ten megabyte ceiling, rather than the default unbounded driver. A long-running home assistant on a small machine will fill a disk eventually, and this is the line that says someone thought about it.

The system bus and the device event daemon are mounted read-only. They are there because hardware discovery needs them, and read-only is the difference between listening and being able to reconfigure the host.

And the database path is an explicit named file rather than a default, with the data directory mounted at a fixed host path, so a backup is a directory copy and a restore is the same operation in reverse.

What is not constrained is the network side. There is no port mapping in the command because the container shares the host's network, the application is told to listen on port 80, and nothing in the documented path puts a proxy, a certificate or a password in front of it. So the restrained file and the exposed port are in the same fifteen lines, which is the honest summary of this project: careful about the disk, unguarded about the network.

## The production build compiles the interface into the server's static directory

The manifest explains why the install command can serve everything from one process on one port.

The repository has two packages, one for the front end and one for the server, and the scripts address them by changing into each directory. There are matching development, test and installation scripts for both, and the two test suites and the two development servers are run in parallel by a task runner rather than one after the other.

The production path is three steps: clean a directory inside the server package, build the front end, and copy the built front end into that directory. So the image contains a server that also serves the compiled interface, which is why one port and the host network are sufficient and why there is no separate static server in the command.

Two other details are worth noting. The engine constraints are pinned to exact major versions of both the runtime and the package manager, so an older toolchain fails at install rather than warning later. And the documentation generator is configured in the manifest itself, pointing at the server's route directory, with a public URL field left as a placeholder that still reads as an unfilled template.

## The contributor invitation is explicit about agents

The contribution section has three numbered steps, and the third is the unusual one.

The first two are ordinary: set up a development environment with one of two guides, one for macOS and Linux and one for Windows, then read the guide to developing a service to understand the project structure, how to build features and how to open a pull request.

The third says the project uses AI extensively to build itself and is favourable to AI-assisted contributions, points at a section of the contributing guide about exactly that, and tells contributors to point their agent at a file in the repository root that contains everything needed to work on the codebase.

So this is a project that has answered the question most projects leave open. It is not asking for the model's output to be ignored, and it is not asking for a disclosure form. It is shipping an agent instruction file in the root and telling contributors to use it.

The repository listing backs that up: the agent instruction file sits beside the security policy, the change log, a dev container definition and a contributors configuration, so the agent file is maintained with the same seriousness as the rest of the project's tooling.

## A contributor table with roles attached to names

The last third of the readme is a generated contributor table, and it is larger than the documentation.

Each cell carries a name, a link, and a set of role links filtered to that person: code contributions, business development, infrastructure and build tooling, documentation, ideas and feedback, and translation. The table is produced from a contributors configuration file in the repository root, between explicit comment markers that tell tooling not to modify the section, and a formatting exemption is marked inside it.

Two things are readable from it. The roles are not all code: the table assigns business development, documentation, ideas and translation as first-class categories, which tells you what the project needs help with. And the visible names overlap with the rest of the repository: the package author is also the first entry in the table.

For a project whose entire premise is that your home data stays at home, having the contributor record be the largest thing on the readme page is a slightly odd balance, and it is the clearest example of what this repository optimises for.

## Patch releases, a floating container tag, and a compose alternative

Three small facts close out the picture.

The release history is a tight patch line, with two of the three most recent versions published on the same afternoon about an hour apart. Nothing about the release shape suggests instability.

The container example, though, pins a floating major tag rather than a full version, while the manifest carries the full version. So the documented install tracks whatever the current five series is at the moment you run it, which for a service holding a database and device access is a different risk profile from a library dependency.

And the page is aware of that. Immediately after the command it asks whether you would rather use Compose and links a Compose installation guide, which is where a deployment that does not need host networking or a container socket can be written. The one-liner is the fast path, not the only path, and the project points at the other one.

Which is the fairest summary of this readme: it hands you the widest possible privileges in the shortest possible command, and then links you to a guide for doing it more carefully.

## Conclusion

Gladys suits someone who wants their own home automation stack rather than a hosted one, and who is comfortable running a container with wide host access on a machine they control. Two things to weigh before you follow the one-liner. The documented install grants the container the container runtime's socket and the device tree, which means a compromise of the application is a compromise of the host, so the compose guide the page links is worth reading instead. And note that it serves on port 80 of the host network with no proxy in the documented path, so the interface is on the local network the moment you start it.

## FAQ

### what is gladys

Gladys Assistant is a privacy-first, open-source home assistant. The repository holds a Node server package and a front-end package, installs as a container, and the production build compiles the front end into the server's static directory so one process serves everything.

### how to install Gladys Assistant

The repository gives one container command, run with elevated privileges, and links a Compose installation guide as the alternative. For step-by-step instructions the page sends you to the project site, which covers a mini-PC, a NAS and a single-board computer.

### what does the Gladys Docker install grant the container?

Privileged mode, the host control group namespace, the host network namespace, the container runtime's socket bind-mounted, the whole device tree bind-mounted read-write, and a writable data directory. The application listens on port 80 of the host network, with no proxy in the documented path.

### Does Gladys support machine-assisted contributions?

Yes, and the page says so directly: the project uses AI extensively to build itself and is favourable to contributions written with it. It points at a section of the contributing guide on the subject and tells contributors to point their agent at the agent instruction file in the repository root, which it says contains everything needed to work on the codebase.

### What runtime does Gladys need?

The manifest pins the runtime and the package manager to exact major versions, currently the 24.x line of Node and the 11.x line of the package manager, so an older toolchain fails at install rather than warning later. The container example pins a floating major tag while the manifest carries the full version.

### How is Gladys licensed and supported?

Apache version two. Support runs through the project's community forum for everyone, with GitHub issues for the open source build and the vendor's technical support route for customers of a commercial edition, and a security policy file in the repository root.

## Sources

- [GladysAssistant/Gladys on GitHub](https://github.com/GladysAssistant/Gladys)
- [License: Apache-2.0](https://github.com/GladysAssistant/Gladys/blob/master/LICENSE)
- [Project website](https://gladysassistant.com)
- [README](https://github.com/GladysAssistant/Gladys/blob/master/README.md)
- [Releases](https://github.com/GladysAssistant/Gladys/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gladysassistant-gladys