Home / Inforcer alternative
An Inforcer alternative built for GitOps
CONFIG365 is a self-hosted Microsoft 365 orchestrator for MSPs and IT teams who want baseline management, drift detection, and multi-tenant deploy — without handing credentials to a SaaS control plane.
Why teams look for an Inforcer alternative
Inforcer is a capable SaaS for MSP baselines, drift alerts, and multi-tenant push. Overlap on that job is real. The split is operating model: CONFIG365 is GitOps you host. Inforcer is a vendor dashboard you subscribe to.
Self-hosted by design
Deploy one container on Azure Container Apps, App Service, or any Docker host. Portal, Gitea, and runner ship together — no separate SaaS control plane.
True Configuration-as-Code
Baselines and tenant configs live in Git as JSON. Every deploy is a diff you can review, approve, and roll back from history.
Built for MSPs
Shared baseline, per-tenant overrides, nightly backups, conflict viewer, and unlimited clients without per-seat SaaS pricing models.
Approval-gated GitOps
Mandatory WhatIf, portal approval, then apply — with an immediate post-deploy backup committed to Git.
Functions CONFIG365 has that Inforcer does not
Inforcer already does standards, drift, backup/restore, and bulk deploy from a cloud console. These are the pieces that only exist if the orchestrator is Git-native and running on your own host.
Config is JSON in Git you own
Baselines, tenant backups, and assignments are files in your Gitea. You can diff them, PR them, grep them, and keep them after you stop using the portal. Inforcer stores policy state in their SaaS — you work the dashboard, not a repo.
Mandatory WhatIf before any write
Every run prints create / update / delete first. Nothing hits Graph until someone approves that diff in the portal. Inforcer’s model is set-the-standard-and-push; there is no GitOps WhatIf gate as the system of record.
Self-hosted Git + runner + portal
One OCI container: Next.js portal, Gitea, act_runner, token-api. No vendor control plane. Inforcer is a cloud app you log into; tenant access is delegated to them.
The deploy engine runs on your host
The PowerShell that talks to Graph, Exchange, SharePoint, and Purview executes inside your own container against your own tenants — nothing routes through a vendor control plane. New policy coverage arrives as a container update, and we take coverage requests directly.
{{GROUP:name}} resolved at deploy
One baseline, many tenants: group names in JSON become tenant-specific object IDs at apply time. Policy files and assignment files are split, so you change who gets a policy without rewriting the policy.
Per-tenant opt-out without forking the baseline
.baseline-ignore in the tenant repo skips named policies. CONFIG365:IGNORE in a resource description locks a client customization so the next deploy will not overwrite it.
License-based baseline groups
groups-config.json can attach extra folders (e.g. enterprise CA) when a tenant’s backed-up SKUs match SPE_E3 / SPE_E5 / etc. Membership updates on the next deploy — no manual tenant list.
Promote a live backup into the shared baseline
Policy viewer searches 2000+ backup files, then one-click promote into baseline. Conflict viewer shows tenant-only overrides vs the shared standard. That Git round-trip is the workflow; it is not a SaaS snapshot restore.
Win32 apps as Chocolatey / WinGet JSON
Win32 LOB packages, Intune mobile apps, and enterprise app registrations live next to the rest of the baseline. Deploy them through the same WhatIf → approve → apply path.
OS version control across all tenants
Set minimum Android / iOS / Windows / macOS once. Latest versions are fetched automatically; one operation updates compliance and app-protection targets everywhere.
Git timeline restore
Nightly (and post-deploy) backups are commits. Restore a resource from any date in history from the timeline UI — the history is Git, not a vendor snapshot store you lose if you leave.
GCC High, same container
Point the same workflows and baselines at government-cloud endpoints. No separate SaaS SKU for the orchestrator itself.
CONFIG365 vs Inforcer
Side-by-side on how the same MSP job actually runs — not a claim that Inforcer lacks Intune or Conditional Access.
| Capability | CONFIG365 | Inforcer |
|---|---|---|
| Hosting model | Self-hosted single OCI container (portal, Gitea, and runner bundled). Your infra, your data. | Vendor-hosted SaaS. Credentials and policy state live in Inforcer’s cloud. |
| Data ownership | Baselines, backups, and deploy history are files in your own Gitea — yours to keep, with or without us. | Policy state and history live inside the vendor platform. |
| System of record | Git. JSON files, commits, diffs, and Gitea Actions are the audit trail. | The Inforcer dashboard. Backups exist inside the product, not as a repo you own. |
| Change control | Mandatory WhatIf (create / update / delete), then human approval, then apply. | Set a standard and push across selected tenants from the UI. |
| Credential boundary | App registration secrets stay encrypted in your container. No third-party SaaS holds tenant creds. | Tenant access is delegated to the vendor platform. |
| Portable config | {{GROUP:name}} placeholders, split assignment files, .baseline-ignore, CONFIG365:IGNORE. | Client deviations are modeled inside their product, not as files in your Git. |
| Baseline membership | Named policy groups plus license-SKU rules (e.g. only E3/E5 tenants get enterprise CA). | Select tenants in the dashboard and push the standard. |
| App packaging | Win32 via Chocolatey or WinGet JSON, plus Intune mobile apps, in the same pipeline. | Intune policy lifecycle in the SaaS; WinGet/Choco-as-code is not the product model. |
| History & restore | Every backup is a Git commit. Timeline restore from any date; you keep the repo if you leave. | Nightly/manual snapshots and restore inside Inforcer. History stays with the vendor. |
| Government cloud | GCC High with the same workflows and baselines. | Depends on vendor SKU and region support. |
| Pricing model | You host the container. Unlimited tenants, no per-seat SaaS for the orchestrator. | Commercial MSP subscription for the platform. |
Competitor product names are used for comparison context only. Features of third-party products can change; verify current capabilities with each vendor.
What you get with CONFIG365
The same core outcomes MSPs expect from an M365 baseline platform — delivered as Configuration-as-Code.
Shared enterprise baseline
Conditional Access, Intune, Defender, identity, and more.
GitOps orchestrator
WhatIf → approve → apply → backup, on your Gitea.
Management portal
Tenants, diffs, policy viewer, and deploy from the browser.
Nightly backups
Full tenant config exported to Git every night.
Per-client flexibility
.baseline-ignore and separate assignment files.
Docs & quickstart
Onboard tenants and ship your first baseline deploy.
Frequently asked questions
Common questions from teams searching for an Inforcer alternative.
Is CONFIG365 an Inforcer alternative?
Yes, for the core job: Microsoft 365 baselines, drift, and multi-tenant deploy. Inforcer does that as SaaS with PSA alerts and framework reports. CONFIG365 does it as GitOps you host — JSON in Git, WhatIf, approval, apply, backup commit.
What does CONFIG365 have that Inforcer does not?
A self-hosted Git server and runner, mandatory WhatIf approval, portable JSON (group placeholders, split assignments, .baseline-ignore, CONFIG365:IGNORE), license-based baseline groups, promote-from-backup, WinGet/Chocolatey as code, OS version control, and GCC High on the same container. Credentials never leave your host.
How is CONFIG365 different from Inforcer?
CONFIG365 runs as a single self-hosted container with your own Gitea instance. Changes go through GitOps WhatIf and approval gates. Tenant credentials stay in your environment rather than a third-party SaaS.
How do I get CONFIG365?
CONFIG365 is a commercial product delivered as a container image you run on your own infrastructure. Email [email protected] and we will cover licensing, pricing, and access to the image.
Can MSPs manage many Microsoft 365 tenants with CONFIG365?
Yes. One baseline repository deploys to unlimited tenants, with separate assignments, per-client ignore files, and nightly configuration backups into Git.
Does CONFIG365 support GCC High?
Yes. The same GitOps workflows and baselines work with Government Cloud environments — point the platform at the correct cloud endpoints.
Try the self-hosted Inforcer alternative
Spin up CONFIG365, connect tenants, and run your first WhatIf — all from a single self-hosted container. Get in touch and we'll walk you through licensing and onboarding.