DSCForge authors and proves DSC v3 configs, ConfigFabric assigns them by Entra device group and enforces state on endpoints, and RepoFabric delivers the apps those configs need over LAN peers. Three products, one Entra sign-in, one UPN-attributed audit ledger, one Gitea store, and one docker compose deployment.
*The loop is the differentiator. A config DSCForge publishes carries a metadata.configFabric block that declares the exact app builds it needs, and ConfigFabric records that as a version lock. Before RepoFabric prunes a build it asks ConfigFabric whether a live config still depends on it, and the gate fails closed. Standalone, with no peer configured, the gate is a clean no-op, so reverts are never blocked.
The forge. Turn natural language, GPO exports, and live system scans into schema-validated DSC v3 YAML across a pool of local or cloud models with failover and a side-by-side QA gate. Prove a draft on real Hyper-V, Proxmox, UNRAID, or physical targets that revert clean, then publish a ConfigFabric-ready document on the DSC v3 schema version you pin, anything from 3.0.0 to the latest.
The desired-state layer. Assign proven configs by transitive Entra device-group membership. Configs declare phase and prerequisites, the service emits a topologically ordered manifest, and endpoints apply with dsc config set in Detect or Apply mode. Triggers via Intune, scheduled task, or interactive SYSTEM, with no Windows service to install.
The delivery fabric. A private winget source that serves only vetted builds and advertises PeerDist hashes, so BranchCache and Delivery Optimization pull installers from a LAN peer. Curated auto-update syncs approved builds from public winget, with a one-click Intune policy export and a WAN-savings dashboard over 7 / 30 / 90 days.
The shared substrate, not glue. One Entra sign-in, one UPN-attributed audit ledger where publish, promote, and revert events are stamped by source fabric, one Gitea store, and one deployment. A version-lock ledger records the builds enforced state depends on, so cleanup cannot prune them. Run all three together, or stand one up at a time.
| Capability | Separate point tools, stitched by hand | The Fabric Suite |
|---|---|---|
| ★ Author straight to enforce | Author a config in one tool, then export and re-import it into a separate assignment system by hand. | DSCForge publishes a proven config as a ConfigFabric-ready document for Entra device-group assignment, with no re-keying. |
| ★ Lock the build a live config needs | A cleanup job prunes an installer a live policy still depends on, and the next remediation breaks silently. | Published configs register version locks, and RepoFabric asks the ledger before pruning. The gate fails closed. |
| ★ Catalog check at author time | You learn a required app is missing from the source only when the apply fails on the endpoint. | DSCForge checks each app against RepoFabric's catalog for presence, promotion stage, and repo coherence while you author. It degrades open and never blocks. |
| ★ One identity and one audit trail | Each tool has its own login and its own log, so reconstructing who changed what spans several systems. | One Entra sign-in and one UPN-attributed ledger span authoring, assignment, and delivery, events tagged by source fabric. |
| Serve only vetted, and prove it | Policy export from one product, app curation from another, with nothing tying the two together. | RepoFabric curates vetted builds and exports the policy to block the public repo, while ConfigFabric enforces the state that consumes them. |
| Proven before enforced | Configs go live untested, or you stand up and tear down your own test VMs by hand. | DSCForge proves a draft on real Hyper-V, Proxmox, UNRAID, or physical targets that revert clean before ConfigFabric ever assigns it. |
| Reaches the endpoint | Triggered by whichever agent each tool ships, often a service per product to install and patch. | ConfigFabric runs via Intune Proactive Remediation, scheduled task, or interactive SYSTEM with no service installed, and reports to Log Analytics and the client event log. |
| One deployment, shared store | Stand up and maintain three stacks with their own installers, ports, and backing stores. | One docker compose deployment on a shared Gitea store. ConfigFabric bolts on as a sidecar, RepoFabric allocates ports and brings missing supporting services. |