Glazier: YAML-driven Windows imaging that pulls its instructions over HTTPS

Windows imaging as a fetch-and-apply loop

Glazier is a tool developed at Google for automating Windows operating system deployments, and the name comes from a glazier, a person who installs windows.

The mechanism is described in four steps. The system boots into the Windows Preinstallation Environment, WinPE. It reaches out to a web server for instructions over HTTPS. It applies a base operating system. It then installs applications and configurations to that operating system.

That order matters. The machine is not told what to do locally; it is told where to ask, and the answer arrives over the network. The consequence is that Glazier is not an imaging tool that runs on a build server and pushes images, it is an installer that pulls its instructions. A machine with no route to that web server cannot be imaged at all.

The HTTPS requirement is stated as non-negotiable, and it appears twice in the README, once in the scalability section. The reason follows from the architecture: the control plane is a web server, and the instructions it serves determine what gets installed and configured on an endpoint, so an unauthenticated path to that decision is a path to arbitrary configuration of your fleet.

The audience is an operations or imaging team at a company with a large Windows estate. For one laptop, this is absurd overkill. For a fleet that has to be rebuilt, reconfigured or audited regularly, the web-server-plus-config approach is the point.

YAML configs in source control, not scripts on a build box

The first of Glazier's three core principles is text-based and code-driven. Imaging is configured entirely via YAML files, and the stated benefit is that engineers can use source control systems to maintain and develop their imaging platform.

The argument in the README is worth reading in full because it is the actual justification for the project. By keeping imaging configs in source control, the team gains peer review, change history, rollback and forward, and all the other benefits normally reserved for writing code.

That framing is the interesting part. An imaging system written as scripts on a build server has no history, no review, and no diff. A YAML config in a git repository has all three, which means a change to what gets installed on a thousand machines goes through the same process as a change to a service.

Three mechanisms extend the config beyond a flat list. Reuse and templating allows config sharing across multiple image types. Configs can be consumed by unit tests, build simulators and other helper infrastructure to build an automated imaging pipeline, which is what separates a config format from a folder of scripts. And source controlled text makes it easy to integrate configs across multiple branches, which makes it easy to QA new changes before releasing them to the general population.

The final claim to test is the one about scale. A config format that has to be templated, branched and consumed by tests is a config format that has to be maintained, and the maintenance cost is in the number of images you support rather than the size of any one of them.

Actions are the extension point, Python and PowerShell

The third principle is extensibility, and it is the one that determines how you use the tool.

Glazier makes it simple to extend the installer by writing a bit of Python or PowerShell code, and the docs explain how to create new actions. Glazier's Actions are the core of the system's configuration language. The README notes that Glazier ships with some existing actions, but that for more custom functionality you can also create your own.

So a Glazier config is not a list of things to install. It is a sequence of actions, and the set of actions available is the set of things Glazier can do. Anything not covered by a shipped action needs code you write, and that code runs on the target machine during imaging.

The repository layout supports this reading. The Python package is in the glazier/ directory, and there is a separate go/ directory, and a top-level go.mod that declares the module github.com/google/glazier and requires Go 1.25.3. The Go dependencies are Windows-specific: StackExchange/wmi for WMI access, iamacarpet/go-win64api for the Win32 API, go-ole for COM, and google/deck. The Python side has its own requirements.txt with absl-py, backoff, mock, ntplib, PyYAML, requests and six, plus a git dependency on google/winops.

The examples directory makes the shape concrete: autobuild.ps1 for the PowerShell build step, winpeshl.ini for the WinPE shell initialisation, and a yaml/ folder with example configs. The split into a Python orchestrator and a Go imaging tool is a real architectural decision, and the README does not document how the two divide the work.

Distribution over HTTPS makes the scale story work

The second principle is scalability, and it is about where the data comes from rather than about the installer.

Glazier distributes all data over HTTPS, which the README says means you can use as simple or as advanced a distribution platform as you need. Run it from a simple free web server or a large cloud-based CDN. HTTPS is a requirement.

That is an unusually flexible claim, and it is the direct consequence of pulling the instructions rather than pushing an image. The server does not need to understand anything about the fleet. It serves files, and the machine fetches what it needs. A static file host can be the entire control plane, and the CDN is there for a fleet spread across many sites.

Proxies make it easy to accelerate image deployment to remote sites, so a site with poor connectivity can be given a local cache of the content rather than reaching back to the origin each time.

The limitation is worth naming, because it is a security property rather than a limitation. Everything the fleet runs is decided by what the server serves, and the server is a plain HTTPS endpoint. The README does not describe authentication of the endpoint, certificate pinning, or content signing, and the client authentication topic is left to the setup documentation. If you are putting this in front of a corporate network, that is the part to check, and it is the part a reader of this repository cannot answer from the files here.

Best effort support, and a large gap since 2.1.0

The disclaimer section is the most important paragraph in the README for anyone planning to depend on this.

Glazier is maintained by a small team at Google. Support for this repo is treated as best effort, and issues will be responded to as engineering time permits. The README also states that this is not an official Google product.

Both statements together are the honest summary: this is infrastructure that a small team maintains and publishes for free, without a support commitment, from a company that disclaims it as a product. That is a normal thing to know about a tool and a strange thing to find in a repository whose commit history suggests serious engineering.

The release history tells the rest of the story. v2.2.0 was tagged on 2026-08-06, and before it v2.1.0 dates from 2021-07-15 and v2.0 from 2019-10-10. There is a gap of nearly two years between 2.0 and 2.1.0, then a five year gap before 2.2.0 in the last couple of months. The last push was on 2026-10-19, so the tree is being worked on now.

What that means for an adopter is that Glazier is not a project with a predictable release rhythm you can plan against. There are also Python test and Go test workflows, which tells you both code bases are exercised.

The licence is Apache-2.0, which is permissive and carries no copyleft obligation, with the LICENSE file at the repository root.

Editorial conclusion

Glazier suits an organisation that images many Windows devices and wants the imaging configuration under source control with peer review and rollback, because the YAML config model gives you the same change history for an image build that you would expect from application code. It is the wrong tool for a handful of machines, where the built-in Windows install and a deployment tool will do, and it is the wrong choice if you cannot run an HTTPS web server that the target machines can reach, since that server is the control plane. Before you adopt it, read the setup docs at google.github.io/glazier, and look at the examples/ directory, where autobuild.ps1, winpeshl.ini and the yaml/ folder show the shape of a real configuration before you write your own.

Frequently asked questions

Official sources

1. google/glazier on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases