Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- Tailscale's October 14 changelog marks self-serve identity provider changes as generally available. The person making the change needs the Owner role.
- The documented list covers Google Workspace, Microsoft services using a custom domain, Okta, OneLogin and OIDC. Other providers require Support.
- Start on the admin console's User management page, open the Identity Provider menu and choose Switch identity provider, then authenticate with the selected service.
- The self-serve switch does not also change a tailnet's primary domain. Shared-domain tailnets, including those created with Gmail addresses, require Support too.
What exactly is generally available?
Tailscale announced general availability for self-serve identity provider changes in its October 14, 2026 changelog. An identity provider, or IdP, handles sign-in. A tailnet is the network you manage in Tailscale.
The feature lets an Owner switch a supported sign-in service in the admin console. It does not give every member that ability or include a primary-domain change in the same self-serve workflow. Treat the sign-in service and the primary domain as two separate decisions.
Check the Owner role and the provider list first
The official instructions require the Owner role. Before preparing a change, confirm that you are managing the intended tailnet and hold that role. Being able to open the admin console does not by itself establish permission to switch providers.
The documented self-serve list includes Google Workspace (G Suite), Okta, OneLogin and OpenID Connect (OIDC). The Microsoft entry includes Microsoft Accounts, Office 365, Active Directory and Microsoft Entra ID when a custom domain is used.
For other identity providers, Tailscale directs you to contact Support. General availability applies to this documented scope. Similar product names or support for enterprise sign-in do not establish that two services can be exchanged through the self-serve flow.
Changing the primary domain, or using Gmail?
You cannot also change the tailnet's primary domain while switching its IdP without contacting Support. Tailscale's example is a move from Entra ID with example.com as the primary domain to Okta with example.org. That combination needs Tailscale Support.
Shared-domain tailnets have a separate restriction. A network created with Gmail addresses, for example, needs Support to switch IdPs. Google Workspace appearing on the supported list does not put a personal Gmail shared-domain tailnet on the same self-serve path.
Consider a hypothetical preparation step, not a migration we performed: a team wants to move from Entra ID to Okta. Compare its current and intended primary domains first. If they differ, gather the details for Support instead of submitting the switch and trying to resolve the domain change afterward.
Where do eligible Owners make the change?
Step 1: As the Owner, open User management in the Tailscale admin console. In the Identity Provider section, open the menu and select Switch identity provider. These are the control names used in the official instructions.
Step 2: Select the IdP you want this tailnet to use and complete that provider's authentication flow. The documentation says authentication varies by provider. Use the matching tab in the original guide rather than applying Google's button names to Microsoft, Okta or OIDC.
Step 3: Confirm the switch as directed for that provider. The guide's default Google example says to select Sign in to Google under Authenticate, sign in with the email you use for Tailscale, and select Switch identity provider. The guide then says the chosen provider is ready to use.
What should you settle before submitting?
Write down the Owner identity, current primary domain, intended IdP and its domain, and whether the tailnet uses a shared domain. Then choose the self-serve or Support path. This short checklist distinguishes role, provider and domain issues instead of treating every missing control as a feature rollout problem.
The announcement and switching guide do not give a migration-by-migration guarantee for existing users, device sessions or access rules. They also do not provide a universal rollback procedure or promise zero interruption. If continuity matters to your team, confirm an appropriate plan with Support before making the change.
This article uses the published announcement and the guide last validated on October 14; we did not sign in to an account or perform a migration. Those two sources do not specify fees, plan eligibility or country coverage. They do not establish that the feature is free on every plan or available to every account in every region.
Sources
Frequently Asked Questions
Does switching the identity provider move my tailnet to another domain?
No. The IdP determines the sign-in service; the primary domain is a separate condition. Tailscale explicitly requires Support if you also need to change the primary domain while switching IdPs. A provider appearing on the list is not permission for a self-serve domain migration.
I can open the admin console but cannot find the switch. What next?
Check the selected tailnet and your Owner role, then compare your provider, custom-domain setup and shared-domain status with the documented limits. If your situation still does not match the instructions, contact Tailscale Support with the details. A missing control alone does not prove that the feature has not launched or that your plan is the reason.
Is this the same as adding a Tailscale connection to Codex Cloud?
They are separate operations. This article concerns which identity service handles sign-in to a tailnet. Connecting a remote development environment to Tailscale concerns how that environment joins the network. An existing successful connection does not prove an IdP migration is complete or that users and devices need no further attention.