A self-hosted AD migration tool in your infrastructure.
Deploy the self-hosted AD migration tool in customer-managed Azure, Kubernetes, or Docker infrastructure and document who owns identity, secrets, backups, monitoring, updates, incident response, and egress.
Agree the responsibility model before installation.
A self-hosted deployment changes operational ownership. It does not by itself provide certification, eliminate cloud dependencies, or make every product capability available.
- Infrastructure subscription, cluster, host, and network ownership
- Identity provider, privileged roles, MFA, and break-glass access
- Secret store, key rotation, and credential recovery
- Database, backup, restore verification, and retention
- Observability, alert routing, and incident response
- Release promotion, update signing, and maintenance windows
- Agent-to-control-plane and agent-to-directory network paths
- Microsoft API endpoints required by approved cloud scope
Control plane
Portal, API, workers, database, message infrastructure, secrets, telemetry, and backups.
Execution agent
Outbound HTTPS to the control plane and approved LDAP access to domain controllers.
Microsoft APIs
Approved outbound TLS for Entra ID or enabled Microsoft 365 assessment operations.
Confirm these before a self-hosted deployment.
Self-hosted changes who operates the platform; it does not remove Microsoft API dependencies for cloud workloads or provide certification by itself.
| Area | Requirement | Owner |
|---|---|---|
| Infrastructure | Customer-managed Azure subscription, Kubernetes cluster, or Docker host meeting the documented sizing baseline. | Customer infrastructure |
| Identity and access | Identity provider integration, privileged roles, MFA, and break-glass access defined before go-live. | Customer security |
| Secrets and keys | A managed secret store with a documented rotation and credential-recovery procedure. | Customer security |
| Data protection | Database backup, verified restore, and retention aligned to the customer's compliance obligations. | Customer operations |
| Egress to Microsoft APIs | Approved outbound TLS to Entra ID and enabled Microsoft 365 API endpoints; self-hosted is not air-gapped for cloud scope. | Customer network |
| Operations | Observability, alert routing, incident response, release promotion, and maintenance windows. | Customer operations |
Common deployment questions.
Can BridgeAD run fully air-gapped?
No. Enabled cloud workloads require approved outbound access to Microsoft APIs. The directory-side agent path can operate in more restricted networks, but Microsoft 365 operations need their documented API endpoints.
What egress and firewall rules are required?
The control plane needs outbound HTTPS to the identity and messaging dependencies it uses, and agents need outbound HTTPS to the control plane plus approved LDAP access to domain controllers. The architecture review maps each required endpoint to your firewall policy.
Who owns updates and secret rotation?
The customer owns release promotion, update windows, and secret/key rotation in a self-hosted deployment. BridgeAD documents the update and signing process; your operations team executes it.
Does self-hosted change capability status?
No. Deployment model and capability status are independent. Supported, conditional, and controlled-pilot capabilities keep the same boundaries whether the platform is SaaS or self-hosted.
Bring the target hosting standard to the review.
We will map deployment assumptions to customer controls, operating owners, and current product status.