Cloud Anywhere — Quickstart Guide
For customer cloud & infrastructure teams · What to expect, what to prepare, and how the operating model works.
What is Cloud Anywhere? Cloud Anywhere is a fully managed dotCMS hosting model where dotCMS deploys, operates, and maintains your dotCMS infrastructure inside your own cloud account. Your data never leaves your cloud. You retain full ownership, audit visibility, and override control — while dotCMS handles the day-to-day operations through automation and Infrastructure as Code (IaC).
How It Works#
Cloud Anywhere uses your cloud provider's native delegation mechanism to grant dotCMS scoped, auditable access to a dedicated area of your cloud account. dotCMS does not require employee-level access, VPN credentials, physical or virtual desktops, or manual provisioning. All operations are performed by automated systems (CI/CD pipelines, Terraform, monitoring agents) — with dotCMS engineers at the helm directing these systems.
Cloud Anywhere Operating Principles#
These are non-negotiable for dotCMS to deliver Cloud Anywhere. If your organization cannot meet these requirements, we offer a self-hosted model where your team manages the infrastructure directly with dotCMS guidance and support.
1. Dedicated Subscription / Account#
You create a dedicated subscription (Azure), account (AWS), or project (GCP) specifically for the dotCMS workload. This isolates dotCMS resources from your other workloads while keeping everything inside your cloud tenant.
2. Delegated Access via Native Mechanism#
You delegate management of that subscription to dotCMS using your cloud provider's native cross-tenant management feature. This is not "unregulated access" — it is your cloud provider's recommended pattern for managed service providers, with full audit trails and customer-controlled RBAC at every layer.
Note: These delegation mechanisms have built-in security restrictions. For example, they typically prevent the service provider from holding Owner-level roles or escalating their own permissions. The customer retains override control and can revoke delegation at any time.
| Cloud Provider | Delegation Mechanism | Microsoft / Provider Docs |
|---|---|---|
| Azure | Azure Lighthouse | Managed Services delegation |
| AWS | AWS Organizations + Cross-Account Roles | IAM cross-account access |
| GCP | Domain-Wide Delegation + Shared VPC | Cross-project service accounts |
3. Infrastructure as Code (Terraform) Execution#
dotCMS must be able to execute Terraform plans against the dedicated subscription from our CI/CD pipelines. This means API-level access through service principals — not manual execution by your cloud team on our behalf. Automated execution is what enables consistent environments, drift detection, and rapid incident response.
4. You Retain Full Control#
At no point do you lose visibility or override capability. You can apply Azure Policy / AWS SCPs / GCP Org Policies to constrain what can be created. You set budget alerts. You retain a super-admin account that can revoke dotCMS access at any time. Every action dotCMS takes is logged in your cloud's native audit system.
Responsibility Matrix#
| Area | Responsible Party | Details |
|---|---|---|
| Create cloud account / subscription | Customer | Dedicated subscription/account for dotCMS workload |
| Delegate access to dotCMS | Customer | Using cloud-native delegation (e.g., Lighthouse) |
| Define policy guardrails | Customer | Budget limits, allowed resource types, region restrictions |
| Provision infrastructure | dotCMS | Via Terraform, automated through CI/CD pipelines |
| Deploy & update dotCMS | dotCMS | Application deployment, dotEvergreen updates, patches |
| Monitor & alert | dotCMS | 24/7 monitoring with automated incident response |
| Incident response | dotCMS | SLA-backed response via automated systems |
| Networking / DNS integration | Shared | dotCMS configures, customer provides DNS and any VNet peering |
| Security & compliance audit | Shared | Customer audits via native tools; dotCMS provides architecture docs |
| Revoke access | Customer | Customer can revoke delegation at any time — no dotCMS approval needed |
What Won't Work (and Why)#
We sometimes encounter alternative proposals from customer IT teams. Here's why these don't satisfy the Cloud Anywhere requirements:
"We'll give your engineers remote desktop / VDI access" Cloud Anywhere is not a staffing model — it's a managed-service operating model. Our systems (CI/CD, monitoring, Terraform) need API-level access, not a human sitting at a desktop. Remote desktops create a single point of failure: if VDI is down, if credentials expire, if VPN changes — dotCMS cannot operate. Incident response at 2am cannot depend on an engineer logging into a remote desktop and waiting for it to load.
"Send us your Terraform configs and we'll run them" If your team executes our Terraform, that's a consulting engagement, not a managed service. Every infrastructure change becomes a support ticket. Automated drift detection stops working. Continuous deployment breaks. dotCMS cannot guarantee SLAs when we don't control the execution of our own infrastructure code.
"We'll give you access to specific resources, not the subscription" Partial delegation (resource-group-level instead of subscription-level) means dotCMS cannot create new resource groups, manage networking holistically, or respond to infrastructure-level incidents without filing tickets. The correct approach is: delegate the subscription, then use your cloud's policy engine to set guardrails on what can be created.
"Our policy doesn't allow third-party delegation mechanisms" Azure Lighthouse, AWS cross-account roles, and GCP service-account delegation are first-party features built by the cloud provider specifically for this use case. They are not third-party tools. They come with full audit logging, customer-controlled RBAC, and instant revocation. These are the standard patterns that cloud providers recommend for managed service provider engagements across regulated industries.
Customer Pre-Setup Checklist#
- Identify the cloud provider contact who will provision the dedicated subscription/account
- Create a dedicated subscription/account for the dotCMS workload
- Confirm which delegation mechanism will be used (e.g., Azure Lighthouse)
- Define any policy guardrails you want in place (budget, region, resource types)
- Provide dotCMS with the tenant/account ID and subscription/account ID
- Accept the Lighthouse/delegation registration from dotCMS
- Identify domains and DNS administrative access
- Identify networking requirements (VNet peering, private endpoints)
- Designate a technical contact for the setup phase
- Schedule a kickoff call between your cloud team and dotCMS engineering
Frequently Asked Questions#
Does dotCMS have access to our other workloads? No. dotCMS only has access to the dedicated subscription/account you create for us. Your other workloads are completely isolated.
Can we see everything dotCMS does? Yes. Every API call dotCMS makes is logged in your cloud's native audit system (Azure Activity Log, AWS CloudTrail, GCP Cloud Audit Logs). You have complete visibility.
Can we revoke access immediately if needed? Yes. You can remove the delegation at any time from your cloud console. No dotCMS approval is required. Revocation is immediate.
Do dotCMS employees need to pass background checks? dotCMS engineers do not access your environment as individuals. Access is through service principals and automated pipelines. If your compliance team requires background checks on the engineering team, we can discuss that separately, but it is not a prerequisite for the technical setup.
What if Cloud Anywhere doesn't work for our organization? We also offer a self-hosted model where your team manages the infrastructure and dotCMS provides guidance, support, and the software. This changes the support model, SLAs, and pricing — your account team can walk through the differences.
dotCMS Cloud Anywhere Quickstart Guide · For customer cloud & infrastructure teams · v1.0