Connect Your Google Cloud Organisation

This integration is for Google Cloud organisations only. Connect your organisation to deploy environments into your own GCP account, billed to your own billing account, while continuing to build and deploy through platform201.

platform201 uses service accounts to manage infrastructure on your behalf. Linking grants access to existing platform201 service accounts; deploying an environment creates deployment and runtime service accounts inside its new GCP project. You can revoke the connection at any time, either in platform201 or directly in Google Cloud.

An organisation is required

You need a Google Cloud organisation. This flow creates new GCP projects inside a dedicated folder in that organisation; it does not connect an existing standalone GCP project.

Why connect your own organisation?

Keep your deployed infrastructure inside your own Google Cloud organisation.
Pay Google Cloud infrastructure charges through the billing account you choose for each environment.
Use the platform201 canvas and deployment workflow to manage that infrastructure.
Choose whether each new environment uses your linked organisation or platform201-managed hosting.

Before you start

A platform201 plan that includes the Google Cloud integration. If your plan does not include it, Project → Settings → Google Cloud shows Upgrade plan.
A Google account with access to your Google Cloud organisation.
An open Google Cloud billing account.
The permissions below, or an administrator who can grant them.

Where	Role for your Google account	Why it is needed
Organisation	Folder Admin (`roles/resourcemanager.folderAdmin`)	Find or create the platform201 folder and manage its access
Organisation	Organization Policy Viewer (`roles/orgpolicy.policyViewer`)	Check for policies that would block the connection
Organisation, when a policy exception is needed	Organization Policy Administrator (`roles/orgpolicy.policyAdmin`)	Set the folder exceptions described below
Selected billing account	Billing Account Administrator (`roles/billing.admin`)	Allow platform201 to attach the environment's GCP project to that billing account

platform201 checks the underlying permissions, so equivalent permissions from another role can also work. If your Google account can change organisation IAM policies, missing organisation roles can be granted to your account during linking. The screen tells you which grants will be automatic. These grants to your Google account are separate from the access granted to platform201.

1. Open the project's Google Cloud settings

Open your project, select Settings, and find the Google Cloud section. Click Connect Google Cloud.

Sign in with the Google account that has access to your organisation and approve the Google consent screen. If you chose the wrong account, use Use a different Google account.

2. Select and link your organisation

Choose your organisation from the Organisation list. platform201 checks your permissions before enabling Link organisation.

If roles are missing, the screen shows the role names and commands for an administrator to run. Copy those commands and ask your administrator to apply them, then click Check again. Allow time for Google's permission changes to take effect.

Click Link organisation. Once complete, the settings show Linked, your organisation, the folder ID, and the Google account used to link it.

3. Create an environment in your organisation

Create a new environment in the linked project and tick Deploy into your linked Google Cloud organisation. This option starts unticked, so select it explicitly for environments you want to host in your organisation.

Choose a Billing account. If your Google account has only one open billing account, it is selected automatically. Sign in again if prompted, and resolve any billing permission requirements shown on screen.

platform201 grants its deployer service account Billing Account User (roles/billing.user) on the selected account. Click Create, then open the environment and deploy using the normal application deployment workflow.

Linking an organisation does not migrate existing environments. The hosting option above applies when creating a new environment; the clone flow does not expose this choice.

What platform201 creates and changes

When you link the organisation

platform201 creates a folder named platform201 directly under your organisation, or reuses an active folder with that name. The folder is the parent for new linked environment projects.

It grants these roles to platform201-owned service accounts on that folder:

Service account purpose	Roles on the platform201 folder
Deployer	Editor (`roles/editor`) and Project Creator (`roles/resourcemanager.projectCreator`)
Cleanup service	Project Deleter (`roles/resourcemanager.projectDeleter`) and Browser (`roles/browser`)

These folder grants are inherited by its child projects. The cleanup service can delete projects inside the folder. Keep the folder dedicated to platform201 environments.

If organisation policies would block the connection, platform201 also sets these exceptions on the platform201 folder:

Policy	Folder exception
Domain restricted sharing (`iam.allowedPolicyMemberDomains`)	Adds the platform201 directory customer ID to allowed values while inheriting the parent's policy
Disable service account key creation (`iam.disableServiceAccountKeyCreation`)	Sets enforcement to false for the folder

The organisation's policies themselves are not changed. These exceptions are only written when the corresponding policy is detected as blocking the connection.

When a linked environment is provisioned

The environment receives a new GCP project with an ID in the form p201-<generated-id>, under the platform201 folder and attached to its selected billing account. The following resources and permissions are provisioned in that project:

Resource or change	Purpose
`platform201-deployer@<project-id>.iam.gserviceaccount.com`	Service account used to manage the environment's infrastructure
`platform201-runtime@<project-id>.iam.gserviceaccount.com`	Service account used by deployed workloads
Artifact Registry Docker repository	Stores workload container images, with cleanup policies for old images and build caches
`tenant-state-<generated-id>` Cloud Storage bucket in `europe-west2`	Stores infrastructure state, with uniform bucket access, public access prevention, and protection against destruction by the provisioning configuration
`cloudrun-to-pubsub` log sink	Forwards Cloud Run revision logs to a platform201 Pub/Sub topic so they are available in platform201
Google service identities	Supports enabled services, including Cloud Build and Cloud Logging
Project, service account, and bucket IAM grants	Lets platform201 deploy infrastructure, use service accounts, access state and secrets, and provide operational information

Provisioning enables the Service Usage, Cloud Resource Manager, Compute Engine, IAM Service Account Credentials, Secret Manager, Cloud Logging, Cloud Scheduler, Pub/Sub, Cloud Run, Cloud Functions, Artifact Registry, Cloud Billing, Cloud Build, and Cloud SQL Admin APIs. Linked projects are not attached to the platform201 shared VPC by this provisioning step.

The initial IAM grants are:

Principal	Project roles
Environment's `platform201-deployer`	`roles/editor`, `roles/cloudbuild.builds.editor`, `roles/run.admin`, `roles/cloudfunctions.admin`, `roles/secretmanager.admin`, `roles/pubsub.admin`, `roles/iam.serviceAccountAdmin`, `roles/cloudsql.admin`, `roles/storage.admin`, `roles/artifactregistry.editor`
Environment's `platform201-runtime`	`roles/run.invoker`, `roles/cloudfunctions.invoker`, `roles/cloudsql.client`
platform201's central deployer	`roles/editor`, `roles/iam.serviceAccountTokenCreator`, `roles/artifactregistry.writer`, `roles/run.admin`, `roles/cloudfunctions.admin`
platform201's core service identity	`roles/storage.objectAdmin`, `roles/iam.serviceAccountTokenCreator`, `roles/secretmanager.secretAccessor`, `roles/cloudsql.viewer`

The central deployer also receives Service Account Token Creator on the environment's deployer and runtime accounts, and Storage Object Admin on the state bucket. The environment deployer receives Storage Admin on that bucket and Service Account User on the runtime account. The Cloud Build service agent receives Service Account User on the deployer account.

Deploying your canvas creates the resources you select, such as Cloud Run services, functions, databases, VMs, buckets, queues, or schedules. Those resources can introduce additional service accounts and resource-specific IAM grants. The tables above describe the initial project setup; inspect the deployed project's IAM and resources for its complete current configuration.

Disconnect in platform201

Open Project → Settings → Google Cloud → Unlink and confirm. Sign in to Google again if prompted. Wait for any deployment in progress to finish first.

Unlinking removes the folder roles granted to the platform201 deployer and cleanup service when no other platform201 project still links to the same organisation. It also removes the deployer's Billing Account User role from billing accounts that are no longer used by other links.

Existing GCP projects are kept. Linked environments switch to platform201-managed hosting on their next deployment. Unlinking does not delete existing workloads, remove their billing attachment, remove project-level IAM grants, restore folder policy exceptions, or remove roles granted to your own Google account during setup.

Existing resources can still incur charges

Unlinking is not a resource cleanup or data migration. Review the old GCP projects, workloads, and data before your next deployment, and remove resources you no longer need separately.

Revoke the connection directly in Google Cloud

Your Google Cloud administrator can remove access without using platform201. For a planned disconnection, unlink in platform201 first, then review the remaining access below. If you revoke access in GCP first, deployments and the platform201 unlink operation can fail until an administrator resolves the permissions.

1. Remove folder access

In the Google Cloud console, open IAM & Admin → IAM and select the platform201 folder using the resource selector. Match its folder ID to the one shown in your platform201 project settings.

Find the platform201 deployer and cleanup service principals and remove their roles listed in the folder table above. Use the full principal email addresses shown in IAM to identify the accounts. These accounts belong to platform201; remove their access to your resources rather than trying to delete the accounts themselves.

If a role is inherited, remove it at the parent where it was granted. Older connections may have organisation-level grants, so also check the organisation IAM policy. Google's guide to revoking IAM access explains the console steps.

Removing shared folder access affects every environment and platform201 project using that folder.

2. Remove billing access

For each billing account used by linked environments, open Billing → Account management, find the platform201 deployer principal in the account permissions, and remove Billing Account User (roles/billing.user).

This revokes permission to associate projects with the account. Existing project billing attachments and charges remain until you change or remove the resources separately.

3. Remove access inside each environment project

Folder access is only part of the connection. In each p201-... project created for your linked environments:

Open IAM & Admin → IAM. Remove the direct project roles granted to platform201's central deployer and core service identities, using the project IAM table above as a checklist.
Open IAM & Admin → Service Accounts. For platform201-deployer and platform201-runtime, review their permissions and remove platform201 principals' Service Account Token Creator and any other access grants. Check any additional service accounts created for your deployed resources too.
Open the tenant-state-... bucket's Permissions tab and remove the central deployer's direct Storage Object Admin grant. Review other resource-level policies for direct grants to platform201 principals.
If you want to stop deployment access through the local deployer account as well, open platform201-deployer and choose Disable service account. Review its Keys tab and remove keys you no longer need. Disabling an account is reversible; see Google's service account instructions.
Review the cloudrun-to-pubsub sink in Logging → Log Router. Disable or delete it if you want to stop forwarding Cloud Run logs to platform201.

Runtime accounts are used by your workloads

Disabling platform201-runtime, or other service accounts used by running resources, can interrupt your applications. To keep workloads running independently, remove platform201's access to those accounts and retain the permissions your workloads need. Deleting a key alone does not revoke short-lived credentials already issued from it; see Google's key removal guidance.

4. Review setup permissions and policy exceptions

On the platform201 folder, open IAM & Admin → Organization Policies. Review any overrides for iam.allowedPolicyMemberDomains and iam.disableServiceAccountKeyCreation. If you no longer need an exception, open Manage policy and select Inherit parent's policy. Review the impact on workloads remaining in the folder before applying the change. See Google's policy inheritance instructions.

Also review the organisation roles granted to your own Google account during setup. An administrator can remove those grants if they are no longer needed for your other work.

Keep the folder, projects, and data you still need. Removing access does not require deleting them.

Troubleshooting

No organisations appear. Check that you signed in with the correct Google account and that it has access to a Google Cloud organisation. Use Use a different Google account to switch accounts.

Link organisation is disabled. Select an organisation and resolve the permissions marked as missing. Use Check again after an administrator applies the displayed commands.

No billing accounts appear. The environment dialog only lists open accounts accessible to the signed-in Google account. Check your account access and billing account status, then reconnect if needed.

The linked hosting option is missing. Check that your plan includes the integration, that the project is linked, and that you are creating a new environment rather than cloning one.