# Google Cloud > Run the Atlantic Agentic Engine on Google Cloud: the one-click stack, what it creates, the permissions it takes, regions, and deployment profiles. Draft: this page is being written, and what it says is not yet complete. The engine runs in a Google Cloud project of yours, as Terraform your own GitLab pipeline applies. Models are called through Vertex AI, in your project and region, by the gateway’s service account alone. ## The one-click stack In LightHouse, **Setup and admin → Where agents run**, choose **Google Cloud**, a region and a profile, then **Get my stack**. LightHouse gives you two Terraform files: 1. **`bootstrap.tf`**, which a person applies once. It creates a workload identity pool and provider for your GitLab project, and the service accounts your pipeline plans and applies with. No service account key is created. 2. **`main.tf`**, which calls Atlantic’s Google Cloud module at a pinned version. Your pipeline applies it from `main`, as a reviewed merge request. There is no console link for Google Cloud. ### What to have ready - A workload project, and a bootstrap project beside it. - A GitLab project whose CI runs with OIDC. - The app and gateway images, the gateway policy, an SSL certificate, the address ranges allowed in, your monthly budget and the billing account (with no billing account, no budget is created). ## What it creates | Area | Resources | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Bootstrap | A state bucket (regional, uniform access, public access prevented, versioned); the workload identity pool and provider; the plan and apply service accounts | | Network | A VPC with service and proxy subnets, a deny-ingress firewall, Private Service Connect, private DNS, Cloud Router and NAT | | Logs | A regional log bucket and sink, with the default bucket excluded | | Database | Cloud SQL for PostgreSQL with deletion protection; or SQLite on Filestore | | Budget | A billing budget alerting at 80% forecast and 100% | | Compute | Cloud Run services for the `gateway` and the `app`, behind a regional HTTPS load balancer with Cloud Armor; optional Cloud Run jobs with Cloud Scheduler, the relay, the reader and the command channel | | Models | Vertex AI access for the gateway, and Model Armor | | Secrets | Secret Manager, replicated within the region | | Sign-in | Optional Identity-Aware Proxy | ## Permissions | Identity | Holds | | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Plan service account | `roles/viewer` and `roles/iam.securityReviewer` on the workload project; usable from any branch of your GitLab project | | Apply service account | `roles/editor`, `roles/secretmanager.admin`, `roles/modelarmor.admin` and `roles/servicenetworking.networksAdmin`, and project IAM administration limited to granting four roles (Vertex AI user, Cloud SQL client and instance user, Model Armor user). Usable only from `main`, in your protected `production` environment | | Gateway (the only identity that may call a model) | `roles/aiplatform.user`, Cloud SQL client, Model Armor user, and its own secrets | | App | Its own secrets only | Turning `models_enabled` off removes the gateway’s Vertex AI role: a second kill switch. See [Suspension](/operations/suspension/). ## Regions LightHouse offers europe-west2 (the default), europe-west1, europe-west4, us-east4 and us-central1. Every resource is in the region you choose. Vertex AI regions must be named; there is no global endpoint. Model Armor’s location is set separately (europe-west4 by default). See [Regions](/data-sovereignty/regions/). ## Deployment profiles | | Always-on | Ephemeral | | ------------------------------------------------------------ | ---------------------------------- | ------------------------------------------------ | | Gateway | Cloud Run, at least two instances | No minimum instances; the first request wakes it | | Relay | One instance, CPU always allocated | Scales to zero | | Content reader, command channel | A worker pool | A Cloud Run job every minute | | Product | One minimum instance | One minimum instance | | Estimated cost a month (europe-west2, the lines that differ) | $293.74 | $39.64 | The estimated saving is $254.10 a month. A small Cloud SQL tier suits the ephemeral profile; SQLite on Filestore costs more than it saves at this size. Set `deployment_profile`, plan and apply. See [Deployment profiles](/concepts/deployment-profiles/). ## Upgrading and removing the stack - **Upgrade**: move the module’s pinned tag in a reviewed merge request. See [Upgrades](/operations/upgrades/). - **Remove**: Cloud SQL’s deletion protection refuses to destroy the instance until a person lifts it; the state bucket is never force-destroyed. Removal is not automated \[Coming]. Source: https://docs.atlanticagenticlabs.com/clouds/google-cloud/