Edge nodes
Serving winget clients at a remote location from a local cache of your origin.
Why an edge node
Without one, every install at a remote location crosses the link back to your origin. An edge node serves the winget API and installer downloads on the local network at that location, and fetches from the origin only on demand.
What runs where
| Runs on the origin (part of the application you already have) | Runs at the location (Enterprise edition) |
|---|---|
| Enroll and revoke nodes, issue enrollment keys | The edge node itself — serves the winget API and installer downloads on the local network |
| Health and heartbeat, node status | Caches from the origin on first request |
| Package and tag scope per node | Serves every request after that locally |
| Installer filters (architecture, scope) | |
| Push, pre-stage, evict |
Node management — enrollment, scope, filters, push/pre-stage, eviction and health — is part of the application you already run.
Enterprise
The edge node itself — the part that runs at the location and answers clients there — is part of the Enterprise edition and is deployed separately at each site. It connects back to your origin using an enrollment key you generate in the same screen.
Enrolling a node
Admin → Edge nodes → create one, which issues a one-time enrollment key. Run the node at the location with that key; it exchanges it for a durable token on first contact, optionally with a client certificate issued by the origin's own CA for mutual TLS on later requests.
Scope and control
For each node you set which packages or tags it carries, and filter installers by architecture and scope, so a small site doesn't cache more than it needs. Caching otherwise happens lazily: a node fetches on first request and serves every client after that from its own cache. Pre-staging skips that first slow request — push a version ahead of a rollout so the first client at that site is already served locally. Eviction forces a re-fetch — use it after replacing an installer file at the same URL, or to reclaim space on a node with a tight disk. You can see a node's last-seen status on the dashboard.
On the client side
Clients at that location add the node's own source URL, the same way they'd add the origin's:
winget source add --name kvellman --type Microsoft.Rest --arg "https://node.example-site.internal/api/<site-token>"
Requirements at the location
A host that can run a container, outbound reachability to the origin, and a trusted HTTPS certificate for the node's own URL — winget's HTTPS requirement applies to a node exactly as it does to the origin.