Features

Upload a Windows ISO and FluxDeploy detects the editions inside it. A four-step wizard builds a deployable image: apply the latest cumulative and .NET updates offline from the Microsoft Update Catalog, remove built-in Store apps you do not want, and enable optional features such as .NET Framework 3.5, Hyper-V or WSL. Each finished image is recorded with its SHA-256 hash, and the agent checks that hash before applying it. A mismatch stops the deployment.

Windows Server too. Server ISOs list every edition as Server Core and Desktop Experience, and the wizard picks Standard Desktop Experience unless you choose otherwise. Server images get updates from the Server product in the catalog, a separate Windows Server product key, and a first boot that runs your steps without anyone signing in.

A recipe ties together a Windows image, drivers, answer file settings and task steps, and it is reusable across your whole fleet. Templates get you started: a standard workstation, a laptop with BitLocker, and Autopilot variants. When one recipe is active and no boot password is set, a deployment needs no input at the machine.

Task steps run at the point you choose: before or after imaging, before or after driver injection, before or after the answer file is written, or at first boot in full Windows. Steps can run commands, PowerShell or batch scripts, copy files, edit the registry, set variables or restart the machine.

Browse the Dell, HP, Lenovo and Microsoft Surface driver catalogs from the console and download a pack in one click. FluxDeploy extracts it, tags it with the models it supports and registers it. Dell and HP packs are checked against the SHA-256 the vendor publishes before they are extracted, and downloads only come from the vendors' own domains.

Set a recipe to automatic driver selection and one recipe serves every model: each machine gets the packs for its make and model, applied in priority order (driver pack, storage, chipset, network, video, audio). Boot-time (WinPE) drivers come from the same catalogs and are built into the boot image.

PXE is built in on Core and on every relay. A ProxyDHCP server answers alongside your existing DHCP server on the same subnet, so nothing on your network has to change. For other VLANs, the documentation gives the DHCP options for Windows DHCP, ISC DHCP and Kea, and Cisco Meraki. Machines boot the Microsoft-signed boot manager, so Secure Boot stays on. FluxDeploy is UEFI only.

TFTP has three speed settings (High, Medium and Low) that can be set per site, and a PXE Activity view shows what happened during a boot. When a room of machines images at once, multicast sends the image once to all of them and falls back to normal downloads if your network does not carry it. Where network boot is not an option, boot from an ISO on a VM, a disc or a USB stick.

Core is the one place you manage everything. A relay is the same software in relay mode at another location: it keeps local copies of images and drivers, serves PXE and deployments on its own LAN, and keeps working from those copies when the link to Core drops. Relays run on Windows or on Linux (tested on Ubuntu and Rocky Linux), and upgrade from Core.

Each relay site belongs to a relay group, and the group decides what the site receives: its active recipes, the images and drivers those recipes use, and any extra drivers you add to the group. Every install has a Default group, so a new relay starts receiving content as soon as it is approved. Transfers resume where they stopped, and a site that receives nothing is flagged on the Dashboard. Core also warns when a relay's network setup will cause trouble, such as Wi-Fi and Ethernet both connected.

Microsoft has three ways to hand a device to Autopilot. You turn Autopilot on for a recipe; FluxDeploy works out which one the deployment can use and tells you what it picked and why. Device preparation is used for Windows 11 24H2 and later when your tenant has device preparation policies and the recipe does not join a domain. Autopilot for existing devices writes your tenant's profile into the image, adds no time at first boot and works on Windows 10, hybrid join and virtual machines. Classic Autopilot uploads the hardware hash and waits for the profile, and is still the right choice for pre-provisioning, self-deploying mode and co-management.

FluxDeploy only chooses the existing-devices path after confirming that your tenant converts those devices to Autopilot, so a device that is later wiped comes back under management. You can pin a recipe to a specific mechanism when you need to. Autopilot settings sync to relay sites, and Windows Server images never use Autopilot.

Connected Cache keeps Windows Update, Intune Win32 app and Microsoft Teams content on your network instead of every device downloading it from the internet. Running it the usual way means a separate server, a manual install and a certificate process you drive by hand. FluxDeploy deploys a cache node onto a relay you already run, on Windows (WSL2) or Linux (Docker), using your own Azure subscription.

Checked before and after. A pre-check runs on the relay and lists everything it is missing in one pass, and setup waits until it passes. After setup FluxDeploy checks the node on every relay check-in, repairs what it can on its own, and names the reason when it cannot.

Cache node certificates, handled. Intune Win32 app and Teams content is only served by a cache node over HTTPS, so each node needs a certificate your devices trust. The node creates its own key and signing request, FluxDeploy has it signed by your organization's ACME server, a CA under your own PKI, or FluxDeploy's own root, installs it on the node, and renews it about a month before it expires. You can also sign the requests yourself.

Proof it is actually serving. A cache node can look healthy and still serve nothing a device can use, and devices that cannot use it quietly download from Microsoft instead. FluxDeploy shows the certificate each node really presents, warns when nodes are signed by different CAs, and shows bytes served and hit ratio from Azure's own monitoring. Devices find their site's node through DHCP option 235 on your own DHCP server, so a laptop that moves between sites uses the cache where it is, not the one where it was imaged.

Sign in with SAML 2.0 through Microsoft Entra ID, Google Workspace, Duo or any SAML 2.0 identity provider, with roles mapped from your groups on every sign-in. Three roles (Admin, Operator and Read Only) are enforced by the server, not just hidden in the UI. Scripts use named API tokens with a scope and an optional expiry date instead of a shared password. Repeated failed sign-ins lock out the address for a while.

The audit log records sign-ins, settings changes, certificate events, updates and other administrative actions, with filters and CSV export.

Every connection between machines, relays and Core uses HTTPS with TLS 1.2 or later, served by FluxDeploy itself with no reverse proxy needed. Relays pin Core's certificate and Core pins each relay's, and every boot image carries the server's certificate thumbprint so the deployment agent trusts only that server. Each machine gets its own short-lived deployment token at check-in.

FluxDeploy can get its own HTTPS certificate from your organization's ACME server and renew it, and it switches to a new certificate only once every live relay has acknowledged it, so no relay is cut off by a renewal.

Updates. Core checks for new releases once a day and installs them in one click, in a maintenance window or automatically if you opt in. It installs only a release whose manifest is signed by the FluxDeploy release key, and checks the installer against it byte for byte. Relays upgrade from Core.

Database. Core installs with SQL Server Express by default or uses your existing SQL Server. Relays default to SQLite. An install on SQLite can move to SQL Server Express or SQL Server from the console, without a reinstall.

Backup and restore. A backup is two files: a small settings file signed with your passphrase, and an assets folder holding your ISOs, images and uploaded drivers with a SHA-256 for every file. A restore checks that the two belong together, verifies every file, and downloads catalog drivers again. Anything that cannot be restored is listed under Needs your attention.

Support and help. A support bundle collects logs, system details and read-only connectivity checks with credentials removed. The full documentation is built into the product and served by your own server, so it works on an isolated network, and is also at docs.fluxdeploy.app.

Send events to email, Slack, Microsoft Teams or any webhook. Each channel subscribes to the categories it cares about (deployments, relays, images, drivers, security, system) and can opt individual events in or out. A channel that keeps failing turns itself off and shows why, with a one-click re-enable.

The Dashboard shows a health score and anything that needs attention, deployments stream live progress and console output, and reports cover machines by make and model, storage on Core and relays, relay sites, Connected Cache and certificates.