How Coldsea Deploy works
This page explains how the parts of Coldsea Deploy relate to each other. It is background rather than instructions. If you want to build something, start with your first deployment.
Two halves, different jobs
Coldsea Deploy is a web app and a desktop agent, and they do different things.
The web app is where you author. You build workflows, publish them, manage your organization, and watch results arrive. It never touches a machine directly.
The desktop agent runs on the Windows machine being worked on. It fetches published workflows, executes them step by step, and reports back as it goes.
Everything you see under Deployments is a report from an agent. The web app records what it is told.
Why there is no run button
New users look for a control that says run, deploy, or launch, and there isn't one. That is the design, not an omission.
Work starts at the machine, not at the browser. A Windows deployment reboots the target repeatedly, runs before the operating system is fully up, and often happens on hardware that has nothing installed on it yet. Something has to be present on the machine to carry that through, and once something is present, it is better placed to decide when to begin than a browser tab somewhere else.
So publishing is the handoff. When you publish a workflow you make it available to your agents. Which machine runs it, and when, is settled at the machine.
This is why a draft is not enough. An unpublished workflow is invisible to every agent, however finished it looks in the editor.
How the agent reaches a machine
There are two routes, and which one applies depends on what state the machine is in.
Imaging from bootable media. A media creation tool bundles the agent and a Windows image onto a USB drive or external disk. Booting the target from that medium images the machine and starts the agent once the image is ready. This is the route for a machine that has no usable operating system on it yet, or one you are rebuilding from scratch.
Installing on a machine that already runs Windows. Download the agent and install it. This is the route when the operating system is fine and you want the machine under management as it stands.
Both end in the same place: an agent on the machine, associated with your organization, able to pick up the workflows you publish.
Step-by-step instructions for both routes are not written yet. See what is not here yet.
What a run looks like from the web app
Once an agent starts executing, it reports as it goes, and those reports are what the Deployments view shows. Progress through the steps, reboots, blocks, and the final outcome all arrive the same way.
This is also why the web app can be uncertain about a machine. If an agent stops reporting, the app knows only that it has heard nothing, not why. A run sitting silent gets flagged as possibly needing attention rather than declared broken, because from the outside those two look identical. See Deployment states.
The same holds for stopping a run. Abort is a request the agent picks up on its next report, not a switch the web app throws.
Where your organization fits
An organization owns the workflows, the machines, and the results. Publishing makes a workflow available to that organization's agents and no one else's.
Your plan sets how much of it you can have, and your role sets what you can do with it. See Plan limits and usage and Roles and permissions.
What is not here yet
Two things this page describes have no instructions to point you at.
Creating bootable media, and installing the agent on an existing Windows machine, are both undocumented. So is what a machine needs in order to be a valid target.
They are being written. This page exists partly so the shape of the product is clear before those arrive, because the missing pieces are easier to place once you know what they connect to.