What Gardience is
Gardience is a web console for managing a mixed fleet of Windows and Linux machines from one place. You install it on your own Linux server. It runs on open-source Salt 3008.3 (an LTS release) and adds the controls a team needs on top of it: patch and compliance reporting, security baselines, approvals, change windows, a secrets vault and a tamper-evident audit log.
A few terms used across these docs:
- The console is the Gardience web UI that people sign in to.
- An agent is the Salt minion (the small Salt service) installed on each managed machine.
- A node is one managed machine, named by its agent ID.
- The Salt master is the Salt server that agents connect to. Gardience sends all work to machines through it.
What you can do with it
The console's menu shows what Gardience covers:
| Area | Pages |
|---|---|
| Fleet | Machines, Groups, Patch & compliance, Inventory, Add a node, Jobs |
| Automation | Command center, States, Runbooks, Workflows & approvals, Schedules, Change control, Event rules |
| Security | Drift report, Audit log, Reports & evidence, Secrets vault |
| Console | Agent keys, Live events, Settings |
Select any machine (on Machines, Patch & compliance or Inventory) to open its own page: pending updates, every baseline control, inventory facts and recent activity, with its fixes one click away. Select any job to see each machine's result.
Signing in opens the Gardience console. For Salt experts, Open fleet console at the top right opens the Salt view: raw Salt commands, job details, templates, reactors and nodegroups, under the same sign-in, roles and audit log. Its Gardience Portal button returns here.
Light or dark: open the menu under your name at the top right and choose Appearance: System (the default, which follows your computer's setting and changes with it), Light or Dark. The choice is kept in this browser and the Salt view follows it. Printed pages and exported reports are always light.
Every page also has the optional Ask Gardience button: ask about your fleet ("which servers are exposed to this CVE?") or say what you want done, and the AI assistant answers from your own data or proposes the exact runbook, command or state for you to review and run. See AI assistant. The optional Daily briefing sends the fleet's state and the top actions once a day.
Architecture
An all-in-one install runs four containers with Docker Compose on one Linux server:
| Part | What it does | Port |
|---|---|---|
nginx | The only published web entry point. Ends TLS, sends port 80 to HTTPS, and passes only the requests the console needs to the parts behind it. Sign-ins are rate limited. | 443 and 80 (published) |
salt-master | The Salt 3008.3 master that agents connect to, plus salt-api, which serves the console's base pages. It holds the agent keys. | 4505 and 4506 (published), 8000 (internal) |
gardience | The Gardience service (Python, FastAPI). Scans the fleet, enforces approvals, change windows and locks, keeps the audit log, vault and run history. Runs as an unprivileged user on a read-only file system. | 9400 (internal) |
runner | Runs Ansible playbooks away from Gardience's data and secrets. Each run gets its own unprivileged user and temporary folder, with a 2 GB memory limit for the container. | 9500 (internal) |
Agents run on the managed machines. They open connections out to the Salt master on ports 4505 and 4506, so managed machines need no inbound ports opened.
Ports 8000, 9400 and 9500 stay on Docker's internal network and are never published on the host.
Every open-source component is pinned to a tested version and listed in each release's software bill of materials.
Deployment modes
Gardience is one product with two ways to install it. A license sets how many nodes you can manage and until when; it does not change features.
| Mode | When to use it | What runs on the Gardience server |
|---|---|---|
| All-in-one (default) | You do not run Salt yet, or you want Gardience to provide the Salt master. | nginx, Salt master, Gardience service, runner |
| Attach | You already run a Salt master (3006.x, 3007.x or 3008.x) and want to keep it. | nginx, Gardience service, runner. Agents stay on your master. |
To choose attach mode, pass --attach to the installer. See Attach to an existing Salt master.
How it works
- Install. The installer creates the containers, a self-signed TLS certificate (or uses yours), the Salt master configuration, and three accounts:
adminfor you, plus two service accounts Gardience uses itself (gardience-scannerandgardience-automation). It prints a one-time admin password. - Add machines. An admin either creates an enrollment playbook and runs it with Ansible against an inventory, puts an enrollment's first-boot script in new machines' user data (or uses the Terraform provider), or runs a one-line installer on each machine. Agents from an open enrollment join on their own. Any other agent waits until someone approves its key under Machines > Add machines. Nothing joins the fleet without one of the two.
- First sync. When a new agent connects, Gardience pushes its Salt modules, grains (facts a machine reports about itself) and pillar (data the master sends to a machine) to it within seconds.
- Scan. Every 5 minutes Gardience asks every enrolled node for its OS facts, pending updates (Windows Update on Windows, the package manager on Linux), baseline check results and, on Windows, whether it needs a reboot. The results fill Overview > Dashboard. A node that is off keeps its last result, marked stale.
- Make changes under control. People with the operator, approver or help desk role cannot change machines through Salt directly. Their changes go through Gardience, which checks the license, system locks, change windows and approval rules first, then runs the work as its automation account. Admins keep full Salt rights as an audited break-glass account.
- Record everything. Every sign-in, change, approval and job lands in a hash-chained audit log, so a changed or deleted entry is detected when the chain is verified.
- Run playbooks without SSH or WinRM. Ansible playbooks run in the runner container and reach machines through Gardience and the Salt agent, so managed machines need no SSH or WinRM access from the server. Playbooks come from Git projects, any playbook can become a runbook with a form, and projects, job templates, schedules and inventory groups import from AWX or Ansible Automation Platform. See Ansible playbooks.
- Find exposure and measure against STIG. Look up any CVE across the fleet (Vulnerabilities) and scan RHEL-family machines against the DISA STIG profile (STIG compliance).
Without a valid license the console is read-only: viewing, scanning and reports keep working, and changes are refused. Salt itself is never affected. See the licensing section of Install on one server.