Co-Managed Infrastructure

Your customers deploy.
You stay in control.

Share your verified Bicep, Terraform, and PowerShell packages with customers so they can deploy their own Azure resources — while you track every deployment and stay on top of day-two operations.

Book a Demo Start Free Trial →
✓ No credit card required ✓ Setup in minutes ✓ Customer access managed by you
Live — Package Distribution
MSP Organization
acme-msp
azure-landing-zone network-baseline keyvault-policy monitoring-stack
↓ Controlled sharing · IPM authorized access
customer-a Tracked Workspace
azure-landing-zone 2.1.0 · network-baseline 1.3.0
customer-b Up to date
azure-landing-zone 2.1.0 · keyvault-policy 1.0.2
customer-c Update available
azure-landing-zone 2.0.3 · network-baseline 1.2.1
1 cmd
Customer gets all packages they're authorized for
100%
Visibility into which version is running at every customer
0 repos
No shared Git repos — customers pull from your registry
Verified
Packages malware-scanned before customers can consume them
The reality for MSPs today

Your customers want to self-deploy. That's not a problem. Yet.

More customers want to own their own Azure deployments. They bring their own engineers, run their own pipelines, and deploy on their own schedule. That's fine — until they go rogue with their own scripts, drift from your standards, or you lose visibility into what's actually running.

01
They use their own code, not yours
Without a structured way to share your IaC, customers write their own Bicep or find something on GitHub. Your standards go out the window the moment they're out of your sight.
02
No visibility into what's deployed
Once a customer deploys independently, you have no idea which version of what is running where. Day-two operations — patching, upgrading, auditing — become guesswork.
03
Contract ends, handover is a disaster
When a customer leaves, figuring out what they have and handing it over cleanly is a multi-week project. If it doesn't go well, you're liable for whatever breaks.
04
Security patches land in the dark
A vulnerability in one of your modules means nothing if you can't see which customers are running it. You're fixing the code while flying blind on exposure.
How it works

You publish once. They deploy themselves.
You see everything.

IPMHub gives customers authorized access to your packages, tracks every workspace they create, and keeps the relationship clean when the contract ends.

01 — Publish your packages
Build once, distribute to many
Package your verified Bicep, Terraform, and PowerShell into versioned artifacts in your IPMHub organization. Malware-scanned, signed, ready to share.
➜ ipm publish -p acme-msp/azure-landing-zone -f ./ -v 2.1.0Publishing version 2.1.0 for package acme-msp/azure-landing-zone completed successfully.
02 — Invite the customer
You control what they can see
Create a relationship with the customer's IPMHub organization. Define which packages they get access to. They authenticate with their own credentials — you manage the scope.
# Portal: Organizations → Relationships Customer: customer-a Access: azure-landing-zone network-baseline ✓ Invite sent
03 — Customer deploys
They pull, you track
The customer uses IPM CLI to add your packages to their workspace. Every install, update, and sync can be recorded in a Tracked Workspace visible to both sides.
➜ ipm add --package acme-msp/azure-landing-zonePackage 🛡 acme-msp/azure-landing-zone version 2.1.0 was added to the workspace and is synchronized.
The relationship model

Clean terms from day one.
No surprise divorces.

When you set up a co-managed relationship, you define upfront what happens when it ends. Either way, the outcome is predictable and clean.

✓ Soft separation
Customer keeps what they had

At the moment the relationship ends, the customer retains access to all package versions that were shared with them up to that point. No new versions, but no sudden loss of working code.

✓
All versions shared during the contract remain available
✓
Customer can continue deploying from their local copies
✗
No access to new versions published after separation
✗
Tracked Workspace visibility ends
Hard separation
Access revoked immediately

The relationship ends and all access is revoked. The customer loses the ability to download any packages from your organization going forward.

✗
No access to any packages — including versions already shared
✗
Download access revoked immediately
✓
Local copies already in their repo still work — no runtime dependency on IPMHub
✓
You define which separation model applies before the relationship starts
Built for this model

Everything you need to offer co-managed
infrastructure at scale.

Cross-org package sharing
Share specific packages from your organization with a customer's organization. They pull using IPM CLI with their own credentials — no shared secrets, no shared repos.
Full deployment visibility
Tracked Workspaces give you a live view of what the customer is running — package versions, last sync, revision history. Know before they call you.
Verified, scanned packages
Every package version is malware-scanned before it becomes available. Customers get code you can stand behind — and you have the audit trail to prove it.
Per-customer access control
Each customer only sees the packages you've granted them. Add or revoke access per package, per organization. No broad sharing, no accidental exposure.
Immutable audit trail
Every revision, every version update, every install is logged. When a customer asks "what version was running on March 15th?" — you have the answer in seconds.
White-label portal (optional)
Offer the whole experience under your own domain and branding. Customers onboard to your portal — not IPMHub's. Your brand, your relationship, your control.
Case study · InSpark

From scattered customer repos
to a single managed registry.

InSpark · Dutch Azure MSP · 50+ enterprise clients
75% faster customer onboarding

InSpark uses IPMHub to distribute verified infrastructure packages to customers and track deployment state across their entire portfolio. Customers get working infrastructure from day one — built on code the team has already tested and verified. No shared repos, no shared credentials, full visibility.

75%
Faster customer onboarding
1 source
Single package registry for all customers
Live
Workspace visibility across all deployments
0
Shared credentials
"We onboard customers significantly faster since using IPMHub. They get working infrastructure from day one — built on code we've already tested and verified." — Technical Lead, InSpark
Major Dutch Azure MSP · 40+ clients · 700+ subscriptions
Per-customer versioning changed everything

All 700+ Azure subscriptions were previously forced to use identical versions. A single deployment failure triggered complete rollbacks affecting every customer. IPMHub enabled per-customer version control from a single repository — canary releases for major changes, instant rollbacks for individual customers without touching the others.

8h → 1h
Deployment window
Minutes
Per-customer rollback
"We went from monthly deployment trauma to weekly releases. Customer-specific versioning changed everything." — Senior Platform Engineer, MSP

Ready to offer co-managed
infrastructure to your customers?

Set up your first customer relationship in a morning. We'll help you package your first set of modules and walk through the access model together.

Book a Demo Start Free Trial
➜ ipm add --package acme-msp/azure-landing-zoneIPMHub Cli v0.14.0Adding package acme-msp/azure-landing-zone to the workspace...Package 🛡 acme-msp/azure-landing-zone version 2.1.0 was added to the workspace and is synchronized. ➜ ipm status -p acme-msp/azure-landing-zone└── Package acme-msp/azure-landing-zone └── Version 2.0.3 Hub: 🔼 New version available: 2.1.0