Centralising authentication for your deployment platform is one of those items that sits on an enterprise security checklist for a long time — quietly blocking procurement, slowing down SOC 2 evidence collection, and generating a steady trickle of can you remove this person who left in March?
tickets. Today we're closing that item for Enterprise customers on DeployHQ.
SAML 2.0 single sign-on is now available on the Enterprise plan, with support for Okta, Microsoft Entra ID (formerly Azure AD), Google Workspace, Auth0, and any generic SAML 2.0 identity provider. You can configure it yourself from account settings, test it on a single admin, then enforce it for the whole organisation when you're ready.
This puts DeployHQ alongside the shortlist of enterprise CI/CD platforms with native single sign-on support — without the usual enterprise-tier markup or a forced migration to a self-hosted runner.
Why we built SSO into DeployHQ
Deployment platforms sit in a sensitive spot. A DeployHQ project knows your SSH keys, your server IPs, your environment variables, the shape of your build pipeline, and — crucially — has permission to push code into production. When an engineer leaves an organisation, you don't want their access to that blast radius to depend on someone remembering to click remove user
in four different dashboards.
The fix is centralising authentication at the identity provider, so:
- Onboarding a new engineer means adding them to the right group in Okta / Entra ID / Google Workspace, and DeployHQ access flows from there automatically.
- Offboarding means one click in the IdP. Revoke there and DeployHQ access disappears the next time their session ends.
- Audit evidence becomes easier because all authentication events live in the same place as the rest of your identity audit trail — no separate export from every SaaS tool your team uses.
This sits alongside the work we've already shipped in the governance stack: teams management and granular access control, signed audit logs, deploying behind a firewall, and the broader SOC 2 compliance picture for deployment workflows. SSO was the last missing piece for most enterprise buyers.
What's supported
DeployHQ implements the SAML 2.0 SP-initiated flow and has been tested against:
| Identity provider | Notes |
|---|---|
| Okta | SAML 2.0 app integration, Name ID format EmailAddress |
| Microsoft Entra ID (Azure AD) | Enterprise Application, SAML-based sign-on |
| Google Workspace | Custom SAML App in the Admin Console |
| Auth0 | SAML 2.0 Web Addon on any Auth0 application |
| Generic SAML 2.0 | Anything that can sign an assertion and post to our ACS URL |
Two values you'll need when configuring your IdP:
- ACS (consumer) URL:
https://identity.deployhq.com/authentication/saml/acs - Entity ID / Audience URI:
deployhq
The full step-by-step configuration lives in our SAML single sign-on setup guide, with screenshots per provider.
How DeployHQ reads the assertion
To keep configuration minimal, DeployHQ only requires one piece of data from the SAML assertion: the user's email address.
- Email — the primary identifier. It must appear either in the
NameIDfield (common on Okta and Entra ID) or as a dedicated attribute. This is the value we match against existing DeployHQ accounts. - First name and last name — optional. If your IdP sends them, DeployHQ will keep the user's profile in sync on each sign-in. If it doesn't, nothing breaks.
Users are provisioned just-in-time. The first time someone signs in through your IdP with an email that matches an existing DeployHQ account, the accounts are linked. No separate SCIM directory to configure, no CSV imports to rerun.
Testing before enforcing
This is the part we spent the most time on, because it's the part most SSO rollouts get wrong.
After you've entered your IdP details (Entity ID, SSO URL, and X.509 signing certificate — including the BEGIN CERTIFICATE / END CERTIFICATE lines), save the configuration and sign out. Then, sign back in via your IdP as yourself. If that round-trip works, SSO is functional; if it doesn't, your existing password still works and you can fix the configuration without locking anyone out.
Once you've verified a round-trip, you can tick Enforce SSO (disable password login). A few important notes about enforcement mode:
- Password login is disabled organisation-wide. The only path into your accounts is via the IdP.
- Two-factor authentication and strong-password requirements inside DeployHQ are automatically disabled when enforcement is on, because your IdP becomes the source of truth for MFA. Turn on MFA at the IdP before you enforce, not after.
- Personal API tokens continue to work as expected — they're scoped to deployment automation, not human login.
If your signing certificate is within 30 days of expiry, DeployHQ will warn you in the settings screen and by email, so you can rotate it without triggering a 2am incident.
Where SSO fits in a deployment governance story
If you're building a case for your security team, SSO is one layer of a bigger picture. The deployment platform pattern we see working for Enterprise customers looks like this:
- Identity — SSO via your IdP, enforced. Group membership in the IdP drives who has access to DeployHQ at all.
- Authorisation inside DeployHQ — project-level roles and team membership map onto what each IdP group can actually do (deploy vs read-only vs admin).
- Network boundary — private servers accessed over SSH, with the option to deploy behind a firewall using fixed egress IPs or a private deployment zone.
- Change control — repeatable build pipelines that run the same steps every time, so audits don't depend on
what was running on the developer's laptop
. - Recovery — one-click rollback for the inevitable incident, with a complete trail of who did what and when.
- Evidence — the signed audit trail, plus the SOC 2 evidence patterns we linked above.
SSO doesn't replace any of these — it anchors them. Without centralised identity, each of the other controls has a gap where a departed user could still sign in with a cached password.
Getting started
If your team is on the Enterprise plan, SAML SSO is available right now in your account settings. Pick your provider from the dropdown, paste in the Entity ID, SSO URL and X.509 certificate, and test with your own account before flipping the enforcement switch.
If you're not on the Enterprise plan yet and need SSO for a procurement or security review, talk to our team about an Enterprise rollout — we're happy to walk through the configuration, your IdP's quirks, and how to sequence this alongside the rest of your deployment security controls. Agencies running deployments for multiple clients can use SSO in their Enterprise account and keep a clean audit trail per client.
New to the platform? You can create a DeployHQ account on a lower tier first, wire up a couple of deployments, and upgrade to Enterprise when you need SSO, higher project limits, and dedicated support.
Have a question about the SSO rollout, a specific IdP you'd like us to document more thoroughly, or a feature request for the governance side of DeployHQ? Email us at support@deployhq.com or ping us on @deployhq — we read everything that comes in and we'd rather hear about a rough edge from you than discover it ourselves later.