Cloud Exit Strategy, Part 1: Identity and Collaboration

This series outlines a practical strategy for moving from public cloud/SaaS back to on‑prem or self‑hosted providers like Vultr, Hetzner, or OVHcloud — with a focus on security, control, and predictable cost. We start with the keystone: identity. Then we layer in collaboration.

Why consider a cloud exit?

• Data sovereignty, residency, and regulatory clarity
• Predictable cost models and reduced vendor lock‑in
• Security posture tailored to your threat model (keys, logs, network)
• Operational independence and reversible choices

Guiding principles

• Identity first. Centralize authN/authZ and SSO before moving apps.
• Minimum viable surface area. Start small, segment networks, add only what you can keep patched.
• Automate and back up. IaC, repeatable deploys, tested backups, and documented restores.
• Prove with pilots. Run in parallel and cut over with rollback paths.

Phase 0: Discovery and prerequisites

• Inventory: users, groups, apps, auth methods, MFA, SCIM, SAML/OIDC mappings
• Compliance: retention, audit, encryption requirements
• Hosting: on‑prem vs self‑hosted providers (e.g., Vultr) and region selection
• Network: private subnets, WireGuard/Tailscale, reverse proxy, WAF/CDN plan
• Secrets: KMS or vaulting approach, key ownership, HSM/YubiHSM optional

Phase 1: Identity foundation (Authentik)

Authentik can serve as your IdP of record and SSO hub using OIDC/SAML, with directory sync and MFA. Establish it first and integrate target apps into it before migration.

Deployment blueprint

• Runtime: Docker Compose or Kubernetes; backends: Postgres + Redis
• Ingress: reverse proxy (Caddy/Traefik/Nginx) with ACME certificates
• Storage: encrypted volumes, scheduled snapshots, off‑site backups
• Network: management subnet, user subnet, and a DMZ for public endpoints

Identity design

• Authoritative directory: user schema, groups, attributes, lifecycle states
• Authentication: MFA (TOTP/WebAuthn), conditional access, session policies
• Federation: OIDC/SAML providers and outposts for legacy apps
• Provisioning: SCIM where supported; otherwise API/automation

Cutover plan

1. Stand up Authentik in a pilot environment, connect a few non‑critical apps
2. Mirror users/groups from your current IdP; validate attributes and MFA flows
3. Roll SSO to more apps in waves; keep old IdP as fallback during transition
4. Switch auth for admin tooling last; document break‑glass access

Operational checks

• Backup/restore of Authentik data, keys, and configuration
• Monitoring/alerts for auth failures, latency, and token errors
• Audit logs centralized (e.g., Loki/Elastic + SIEM rules)

Phase 2: Collaboration stack

Once SSO is reliable, move collaboration services one domain at a time. Recommended building blocks:

• Files & sync: Nextcloud (WebDAV/CalDAV/CardDAV) with SSO; versioning + retention
• Docs: OnlyOffice or Collabora integrated with Nextcloud
• Chat: Matrix/Element, Mattermost, or Rocket.Chat with OIDC
• Meetings: Jitsi (behind TURN) sized for your concurrency
• Email: Consider hosted email on your own domain or Mailcow/Poste.io if you accept the operational burden (deliverability, DMARC, anti‑abuse)
• Wiki/Knowledge: Outline or Wiki.js with SSO
• Git/Projects: Gitea/Forgejo; integrate runners and container registry later

SSO and authorization

• Map groups/roles from Authentik into each service
• Disable local users where possible; enforce MFA at the IdP
• Automate user provisioning/deprovisioning (SCIM/API)

Hosting patterns: on‑prem vs providers like Vultr

• On‑prem: full control and locality; plan for power, cooling, spares, and remote hands
• Self‑hosted providers: fast to start; choose regions, use private networking and encryption at rest
• Prefer immutable images, minimal base OS, automatic patch windows, and snapshots

Security & resilience

• Network segmentation, mTLS for service‑to‑service, and private ingress where possible
• Centralized logs/metrics, alerting, and periodic access reviews
• Backups with 3‑2‑1 rule, quarterly restore tests, and documented RTO/RPO
• Key management and HSM/YubiKey for admin access; break‑glass runbooks

Migrations: sequence and rollback

1. Stand up identity; integrate 2–3 low‑risk apps; test SSO, groups, MFA
2. Migrate chat or wiki; collect feedback; tune resource sizing
3. Move files/docs with phased team cutovers; keep read‑only access to the old system
4. Decide on email last (biggest operational load); consider partial exit first

What’s next

This is the first in our Cloud Exit Strategy series. Next up: Networking and Zero‑Trust access (WireGuard/Tailscale, reverse proxies, and segmentation), followed by Observability & Backups, and then Email strategy.