# FOG reimages Windows fleets by PXE, and its branch table is the manual > FOG is an open source computer imaging and inventory suite built on PXE, PartClone and a PHP web interface, with disk testing, wiping, scheduled tasks and remote OS deployment. It suits a lab or workshop that reimages machines in batches, and its four segment version number and five branch names are the thing to understand before installing anything. **FOGProject/fogproject** — An open source computer cloning & management system - Repository: https://github.com/FOGProject/fogproject - Website: https://fogproject.org - Stars: 1,686 · Forks: 288 - Language: PHP - License: GPL-3.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/fogproject-fogproject ## What FOG does once a machine has registered FOG is described as a cloning, imaging, rescue, suite and inventory management system. The imaging itself uses PXE to boot clients and PartClone to capture and restore partitions, and a web GUI ties the two together. The named operating systems are Windows XP, Vista, 7, 8, 8.1, 10 and 11. That list is itself a signal about the audience: FOG is a workshop tool for provisioning physical PCs, not a container or cloud image pipeline. The feature set beyond imaging is what makes it a suite rather than a ghost-imaging script. There is memory and disk testing, disk wipe, antivirus scanning, task scheduling, inventory management, remote deployment of operating systems, and remote installation of software packages. The crucial constraint the README states is that these are triggered through the web GUI once the client machine has registered with FOG. Nothing happens to a machine until it has been enrolled, which makes registration the first operational task rather than an afterthought. ## The version number has four segments and the branches have five names The versioning scheme is the most useful thing in this README, because getting it wrong means installing the wrong code. Versions use {CodeBaseMajor}.{Major}.{Minor}.{Patch}. CodeBaseMajor covers major code baseline changes and API breaking changes, and requires a formal release. Major covers major feature additions and UI changes with potential breaking changes inside the same code base, also a formal release. Minor is for non-breaking major feature enhancements. Patch is the only automated tier, covering ongoing bug fixes, security fixes and small enhancements. So a change from 1.5.10.41 to 1.6.0.x crosses three boundaries at once and can break your installation's API assumptions, while a patch bump within the same minor is routine maintenance you can take without planning. The branches mirror a production, staging, dev model. stable always carries the latest patch release and is what the README says most users should install from. master holds the baseline of the latest minor release but explicitly does not include security patches released since that baseline. dev-branch stages the latest patch changes for testing, and working-* and feature-named branches hold work toward the next major or minor release. FOG_VERSION and FOG_CHANNEL are kept in sync with the git state on each branch by automation documented separately. ## Installing the stable release takes a download and one script The first step is an updated Linux server distribution, which the README states as step zero for both install paths. Then you get the code, and three methods are offered. The archive routes download a branch snapshot: ```bash wget https://github.com/FOGProject/fogproject/archive/stable.tar.gz; tar xzf stable.tar.gz ``` The git route clones the repository and names the directory explicitly: ```bash git clone https://github.com/fogproject/fogproject.git fogproject-stable ``` Then the install runs as root, which is why the README has you escalate first: ```bash sudo -i cd /path/to/fogproject-stable/bin ./installfog.sh ``` The install is interactive and the README says to follow all prompts, which means your answers to those prompts become the server's configuration. There is no documented non-interactive mode, so an automated deployment of FOG has to work out how to answer the prompts itself. The development install is identical with the branch names swapped, using dev-branch and a directory called fogproject-dev-branch, and the README recommends that route only if you want to track current development. ## Where the code lives in the repository The top level layout is what you navigate after installing. bin/ holds installfog.sh and the other scripts, which is the directory the install step puts you in. lib/ is the library layer behind the web interface, packages/ holds the payloads FOG deploys to clients, and utils/ holds utility code. docs/ contains the new documentation, which the README marks as under construction, and it links that documentation at docs.fogproject.org separately from the legacy wiki at fogproject.org/wiki. Expect to be using both for a while, since the project explicitly labels one new and one legacy. tests/ is present, along with SELinux/ as a top level directory, which tells you SELinux policy is a supported configuration rather than an afterthought on a system using mandatory access control. Release Notes.MD sits at the root, and authors.txt lists contributors. The project files also include CLAUDE.md, CONTRIBUTING.md, SECURITY.md and a.githooks/ directory. ## Release pace, licence and where support lives The repository is not archived and the last push was on 2026-10-16. Tagged releases show the cadence clearly: 1.6.0-RC-11 on 2026-10-14, 1.6.0-RC-10 on 2026-10-12, and a stable release 1.5.10.2518 on 2026-10-11. Multiple release candidates within a few days of a stable tag is the 1.6.0 release cycle in progress, which matches the branch table where working-* branches carry Major and Minor work. The licence is GPL-3.0. That matters here more than for a library, because FOG is deployed as a service inside your organisation. If you distribute FOG, including a modified version, the GPL-3.0 terms apply. Support comes through four channels: documentation at docs.fogproject.org, which is new and under construction, the legacy wiki at fogproject.org/wiki, a forum at fogproject.org/forum, and direct email to a developer. The README notes the email route works if a developer permits the change, which is a candid description of how that channel actually behaves. There is also a CLAUDE.md in the repository root, which is a signal about how the project is currently developed. ## Conclusion Adopt FOG if you provision or repair Windows machines in volume and want an inventory database alongside the imaging, and install from the stable branch rather than master or dev-branch. Do not expect it to replace a Windows deployment service, a backup product or a vulnerability scanner, since the antivirus scan and disk tests are imaging-adjacent tasks rather than those products. Before installing, read the version format table so you know what a minor bump changes, run installfog.sh as root on an updated Linux server, and plan for the fact that a PXE server has to be reachable by every machine it serves. ## FAQ ### How do I install FOG Project? Update your Linux server, then get the code from the stable branch with a git clone, a ZIP or a TAR/GZ archive, then run the install script as root: sudo -i, cd into the bin directory and run ./installfog.sh, following the prompts. ### Which FOG branch should I install from? The stable branch, which the README says always carries the latest patch release and is where most users should install from. master holds only the latest minor release baseline without subsequent security patches, dev-branch stages patches for testing, and working-* branches carry work toward the next major or minor release. ### What do the four segments of a FOG version number mean? The format is {CodeBaseMajor}.{Major}.{Minor}.{Patch}. CodeBaseMajor covers API breaking baseline changes, Major covers major features and UI changes, Minor covers non-breaking feature enhancements, and Patch covers ongoing bug fixes and security fixes with automated releases. ### Can FOG deploy software packages and run tasks on client machines? Yes. The README lists remote installation of software packages, task scheduling, memory and disk testing, disk wipe, antivirus scanning and inventory management. These are triggered from the web GUI once the client machine has registered with FOG. ## Sources - [FOGProject/fogproject on GitHub](https://github.com/FOGProject/fogproject) - [License: GPL-3.0](https://github.com/FOGProject/fogproject/blob/stable/LICENSE) - [Project website](https://fogproject.org) - [README](https://github.com/FOGProject/fogproject/blob/stable/README.md) - [Releases](https://github.com/FOGProject/fogproject/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fogproject-fogproject