u/JeroenPot

Managing baselines across multiple Microsoft 365 tenants usually sucks. You’re either stuck paying for an expensive SaaS tool, wrestling with an unmanageable spreadsheet, or clicking through admin centers doing things manually.

We built Config365 because we wanted a free, self-hosted GitOps workflow for M365 instead: JSON configs in Git, clear diffs before anything actually changes, and credentials that stay on our own infrastructure.

It’s packaged as a single Docker container containing the portal, Gitea, and runner. You point it at your tenants, set up a shared baseline, and deploy through review gates:

• Config-as-Code: Baseline and tenant-specific configs live in Git.
• Dry Runs: Every pipeline triggers a WhatIf preview showing exact creates, updates, and deletes.
• Human Approval: Nothing touches a tenant until someone approves it in the portal.
• Automatic Backups: After an apply, a fresh backup is committed straight back to Git.
• No Surprises: Drift shows up as a diff, eliminating silent writes.

Why build this? Mainly for MSPs, multi-tenant IT teams, or anyone who likes PR reviews and hates giving third-party SaaS platforms full admin access to their tenants.

• Site: https://config365.io
• GitHub: https://github.com/potsolutions/config365

It’s 100% open-source (MIT), self-hosted, and free. We’d love to hear what you think or get feedback on what we can improve!

-------------------------------------------------------------------------------------------

I just wanted to clarify; this is an entirely different product than CIPP or Inforcer. This is an Configuration as Code solution similar to simeoncloud and M365DSC. If you are allergic to json files, this is not the product for you.

For all the 'new open source and vibe code haters' - yes, I've used AI to develop this application, just like every developer is using AI these days. I do actually know how to code with a keyboard as well, and have developed applications 10 years before AI was even launched.

I've spent close to 8 months building config365, averaging 20 hours per week - this is not a little project build by someone who doesn't know what they're doing. I hope we can move past the negativity.

A couple of other notes:

GDAP has certain limitations such as Intune connector config limitations, it will not be adopted any time soon unless these are resolved.

There is a know bug This bug has been resolved in the latest version: entra id appreg in setup is broken, only easyauth on Azure works ok.

Hey r/mspjobs,

I'm looking to partner with MSPs who have a solid client base but are leaving technical work on the table — either because the expertise isn't in-house, the projects keep getting deprioritized, or you just don't have the bandwidth right now.

What I bring:

Close to 20 Years of experience working in complex multi-tenant enterprise environments up to 100.000 users. Deep hands-on experience across the Microsoft stack — from on-prem infrastructure through to cloud-native Azure deployments and modern workplace. I've also built a full M365 configuration management and automation platform for managing tenants at scale, so I can bring real tooling and engineering to the table, not just advice.

Where I can help:

Microsoft 365 / Modern Workplace

• Conditional Access, Intune, Entra ID, Exchange Online, Teams — structured deployments with my soon-to-be opensource orchestration platform, not ad-hoc
• Security hardening and compliance baselines across client tenants
• Autopilot, device management, app deployment
• Configuration management and automation at scale
• M365 migrations and onboarding projects

Server & Infrastructure

• Windows Server — design, deployment, hardening, migrations
• Active Directory, Group Policy, hybrid identity (AD Connect / Entra Connect)
• Virtualization (Hyper-V, VMware)
• On-prem to cloud migrations and hybrid infrastructure

Azure & Cloud

• Azure infrastructure design and deployment (VMs, networking, storage, security)
• Azure Virtual Desktop (AVD) — design, deployment, ongoing management
• Azure AD / Entra ID architecture
• Cost optimization and environment reviews
• Landing zone setup and governance

Automation & Development

• PowerShell scripting and pipeline development
• Microsoft Graph API integrations
• Custom tooling and automation for MSP workflows
• Configuration management platforms and desired-state infrastructure

Knowledge transfer — I'm happy to work alongside your team and build internal capability, not just deliver and disappear.

The kind of MSP I'm looking for:

• You have clients generating technical requirements you're not fully resourcing
• You want to expand what you offer without immediately hiring a full-time senior engineer
• You're open to a flexible arrangement — project-based, retainer, or longer-term partnership

Flexible on engagement model — happy to discuss what works for your business.

Drop a DM or comment below and let's have a conversation about what you're working with.

Hey r/Microsoft365,

I've spent the last while building something that scratches a very specific itch and I'd love some honest feedback — and ideally a few teams willing to kick the tires before I open source it.

What is it?

A self-hosted, Docker-based platform for managing Microsoft 365 configuration across multiple tenants at scale. The core idea: your tenant configurations live in Git as desired state, and the platform drives automated deployment, backup, and maintenance against those tenants using pipelines — all from a central web portal.

It's not a hosted SaaS. You host it. You own your data.

The problem it solves

Managing M365 configuration across multiple tenants is a mess. Everyone ends up with their own half-documented process, things drift from your intended baseline, someone makes a change manually and it never gets tracked, and auditing what was in place and when becomes nearly impossible.

I wanted something that treated M365 tenant config the way good engineering teams treat infrastructure — as code, versioned, reviewable, and deployable.

How the baseline and deployment model works

The platform is built around a shared baseline repository — a set of JSON config files representing your desired M365 state, organised by workload:

• conditional-access/ — Named Locations and CA policies
• intune/ — All Intune configurations
• exchange/ — Transport rules and mail settings
• authentication-policies/ — FIDO2, TAP, SMS, etc.
• groups/ — Security and M365 groups
• enterprise-apps/ — App registrations
• entra-id-consentpermissions/ — Consent policies and permission classifications
• sharepoint-settings/, teams/, custom-attributes/

There's also a baseline-remove/ folder — configs placed here get deleted from tenants on the next deploy run, after new configs are safely applied first.

When a deployment pipeline runs against a tenant, it:

1. Clones the shared baseline repo
2. Reads all JSON files from the relevant workload folders
3. Deploys them to the tenant via Microsoft Graph API (and Exchange/Intune APIs where needed)
4. Applies any removals from baseline-remove/

Resources deploy in dependency order — custom attributes and groups first, then Conditional Access, then Intune, then everything else — so you're never deploying a CA policy that references a named location that doesn't exist yet.

The result: update the baseline once, and every tenant gets the change on their next deploy. Tenant-specific overrides live in each tenant's own repo alongside the baseline clone.

Key platform capabilities

• Multi-tenant portal — manage any number of tenants from a single interface, with scoped access so different admins only see what they should
• Parameterized deployment pipelines — granularly choose which modules to deploy and whether the run can create, update, or delete resources
• WhatIf / plan phase — preview exactly what would change before anything is applied
• Automated backup pipelines — scheduled backups of tenant config committed back to Git; full audit trail
• Policy viewer & drift detection — browse and diff any tenant's config against desired state in the portal, with field-level normalization so cosmetic noise doesn't pollute the diff
• Approval workflows — deployments can require an explicit approval before they execute
• User compliance views — sign-in log analysis sourced from Git-backed daily exports, not live Graph API calls
• Intune tooling — app management (Chocolatey, WinGet, custom packages), ADMX files, OS version control for compliance policies
• Groups management — group config and sync integrated into pipelines and UI
• Delegated auth per tenant — device-code onboarding per tenant; refresh tokens managed internally, isolated from portal login
• Setup wizard — guided first-run covering Entra app registration, database config, blob backup, and platform bootstrap
• All-in-one container — single Docker image (portal + internal Git server + pipeline runner); deployable on-prem or to Azure App Services (reverse proxy with pre-authentication recommended)

Maintenance automation — and where I'd especially love your input

The platform can run scheduled or on-demand maintenance pipelines against any tenant, with a task picker UI and a WhatIf mode that previews changes without applying them. Current tasks:

• Group Split Rebalancing — rebalances members across split/overflow groups
• Exchange Default Font — enforces a standard default font across OWA/Outlook
• Exchange GAL Visibility — corrects Global Address List visibility flags across mailboxes
• Intune Device Auto-Rename — renames devices to match a naming convention
• Intune Primary User Assignment — assigns or corrects the primary user on managed devices
• Entra ID Device Cleanup — removes stale/inactive devices from Entra ID

This is the area I most want input on. What recurring M365 maintenance tasks do you find yourself scripting and running ad-hoc that you wish were automated, auditable, and triggerable from a central UI? What would you add to this list?

What it is NOT

• Not a SaaS product — no cloud offering, you host it
• Not an end-user tool — this is for admins and engineers managing tenants
• This post is about the platform; the baseline/policy content itself is a separate concern

Where it's at

It's working and running against real tenants, but it's pre-open-source. I want to clean things up, write proper docs, and get feedback from a handful of teams who would actually use something like this before publishing it publicly.

What I'm looking for

• Honest feedback — does this solve a real problem for you, or is this already solved by something I've missed?
• Maintenance task suggestions — what would you automate if you could?
• Early testers — if you manage multiple M365 tenants and would be willing to stand this up in a lab or test environment, I'd love to hear from you. I'll provide setup docs and direct support.

Drop a comment or DM me. Not selling anything — just trying to build something useful and get it into the world in a state worth sharing.

Happy to answer questions about the architecture, how auth works, the pipeline model, or anything else.