For Google Cloud users
You know Google Cloud. This page translates its vocabulary into Crusoe Agent Platform terms, tells you what will feel familiar, is honest about what GCP has that we don't, and points you at the exact docs pages to migrate each workload.
Of the three big clouds, GCP is the one whose vocabulary we borrowed most. "Project", "revision", "service account", "topic", and "subscription" all mean here roughly what they mean there.
Terminology map
| In GCP | Here | Notes |
|---|---|---|
| Organization and folders | Organization | One level, not two. Orgs own projects and users; only platform admins create them. |
| Project | Project | Same word, same job: an isolated workspace with its own resources, quota, members, and audit log. Everything you create lives in exactly one project. |
| Project ID and project number | Project slug and short | The slug is the readable name (ml-team). The short is a small immutable id that appears in namespaces and hostnames and never changes, even if you rename the project. |
gcloud services enable ... | Nothing to enable | There are no per-project API switches. Every service is available in every project from the moment it exists. |
IAM role binding (roles/run.admin) | Project role: member or admin | No policy language and no predefined-role catalog. A member uses the project's resources; an admin also does the irreversible things. Deliberately simpler, and deliberately less expressive. |
| IAM's single resource hierarchy | Two authority axes | Authority splits into metadata (rename, delete, manage members) and resource (agents, secrets, topics, indexes). A platform admin holds metadata authority everywhere and resource authority nowhere. See security overview. |
| Google Cloud console | Web console at https://console.codyhill.dev | The public front door. Sign-in is email and password; an admin creates your account or sends an invitation link — there is no sign-up page. See create an account. |
gcloud CLI | platformctl | One binary for agents, functions, services, data, and messaging. See install the CLI. |
Service account (sa@project.iam.gserviceaccount.com) | Service account (name@<project-short>.cai.local) | Modeled directly on GCP: a machine identity that belongs to one project and holds a role the way a person does. |
| Service account key (JSON) | API key (cai_<keyid>_<secret>) | Shown exactly once at creation, revocable instantly, with an optional expiry. A service-account key can never mint more credentials. See service accounts and API keys. |
| Cloud Run service | Serverless service | Container in, scale-to-zero HTTPS endpoint out. This is the closest one-to-one mapping on the whole page. |
| Cloud Run revision | Revision | Same word, same meaning: each deploy creates a new immutable revision, and you can shift traffic between them. See traffic and revisions. |
| Cloud Run min instances | Min instances | Same knob, same purpose — keep some capacity warm so requests skip the cold start. Not a separate paid tier. See autoscaling and scale to zero. |
https://<service>-<hash>.<region>.run.app | https://<name>-<project-short>.apps.codyhill.dev | Every workload gets a public address on deploy. Nothing extra to create. |
| Cloud Build + Artifact Registry | Nothing to configure | The platform builds your code and stores the image itself. There is no build service to grant roles to and no registry to create. |
| Cloud Run functions (formerly Cloud Functions, 1st and 2nd gen) | Function | One file exposing handle(event). Runtimes: Python, Node.js, Go, Ruby. One product name, one generation. |
| An HTTP function's entry point | def handle(event) in handler.py | The event is the parsed JSON request body. Return a dict; include statusCode to set the HTTP status. |
Vertex AI Agent Engine (the API path still says reasoningEngines) | Agent Engine | Upload agent code, get a scale-to-zero chat endpoint. The name in our docs, our CLI, and our API is the same word everywhere. |
| Agent Development Kit (ADK) | The same ADK | We run your unmodified ADK agent — agent.py exposing root_agent. LangGraph and CrewAI work the same way. See ADK. |
| Vertex AI Sessions | Sessions | Per-conversation history, replayed to the model each turn. Built into every agent, not a sub-product to enable. |
| Vertex AI Memory Bank | Memory | You decide when a conversation becomes long-term memory; agents search it with the built-in search_memory tool. |
Agent Engine Code Execution, or Gemini's code_execution tool | Code Sandbox | One HTTP call runs your code in a single-use pod that is destroyed afterward. You call it explicitly — it is not an implicit model behavior. |
| Vertex AI Vector Search index + deployed index endpoint | VectorDB collection | One object, not two. A collection is queryable the moment it exists — there is no separate "deploy the index to an endpoint" step and no idle endpoint to keep running. |
| Vector Search "restricts" and numeric restricts | Payload filters | Ordinary JSON match and range conditions on a point's payload. See search. |
| ScaNN | HNSW | A different approximate-nearest-neighbor algorithm doing the same job: trade a little accuracy for a lot of speed. You do not have to tune it. |
| Memorystore for Redis or Valkey | MemoryStore | Speaks the Redis and Valkey protocol, so your existing client libraries and redis-cli work unchanged. |
| Cloud Pub/Sub topic | Pub/Sub topic | Same noun, same job. |
| Cloud Pub/Sub subscription | Subscription | Same noun. Each subscription gets its own delivery cursor. |
| Eventarc | No direct equivalent | There is no managed event-routing layer that wires platform events to targets. You publish to a topic yourself. |
| Cloud Tasks | No direct equivalent | Use a Pub/Sub topic with one consumer for queue-style work. There is no managed rate-controlled task queue. |
| GCP Workflows (YAML state chain) | Durable workflow | Written in ordinary code. Branching, loops, and retries are language constructs and policies, not a YAML DSL. |
| Cloud Composer (managed Airflow) | No equivalent | There is no managed DAG/ETL orchestrator. |
| Secret Manager secret and versions | Secret and versions | Numbered versions, and writing again creates the next one. No replication policy to choose. |
| Secret Manager per-secret IAM | Project role | Secrets are scoped to the project; membership reads names, admin reveals values. Every reveal is audited. |
| Cloud Logging and Logs Explorer | Logs | Live tail plus persisted history that survives scale-to-zero. Default retention is 14 days, with no sinks, no export, and no query language. |
| Cloud Monitoring | Live counts only | There are no historical charts and no custom metrics. |
| Cloud Audit Logs | Per-project audit log | On by default, readable by every project member, nothing to configure. It also records any provider break-glass access. |
| Quotas page | Project quotas | A live view of instances, services, CPU, and memory against your project's caps. |
| Billing account and budgets | No metering today | There is no usage-based billing in alpha. Capacity is bounded by the quotas above. |
| No managed equivalent | MCP Servers | Publish Python tools as a hosted Model Context Protocol endpoint, with immutable versions and one-command rollback. |
What will feel familiar
- "Project" means what you think it means. It is the unit of isolation, membership, quota, and audit — exactly as on GCP. Resources belong to one project and cannot see across.
- "Revision" means what you think it means. Deploying creates a new immutable revision; you can shift traffic and roll back. Cloud Run muscle memory transfers directly.
- Scale-to-zero and cold starts. Idle workloads stop and the next request wakes them, for agents, services, and functions alike.
- Service accounts look like GCP service accounts. They live inside one project, they hold a role like a person, and their key is a credential you create and revoke.
- Secrets have version numbers. Writing a new value creates version 2 — there is no separate "rotate" verb, exactly as in Secret Manager.
- Pub/Sub uses the same two nouns. Topics and subscriptions, no renaming to learn.
- ADK is the same ADK. We run the framework Google publishes, not a reimplementation of it.
What is different
Simpler here
- One name per concept, permanently. Google renamed Reasoning Engine to Agent Engine and then folded it into the Gemini Enterprise Agent Platform, while the API paths still say
reasoningEngines; Cloud Functions became Cloud Run functions with 1st-gen and 2nd-gen docs living side by side. We promise the opposite: if we ever rename anything, the old identifier keeps working and the docs will say so. - Nothing to enable before you start. No
gcloud services enable, no Cloud Build service account to grant an extra role to, no Artifact Registry repository to create. Your first deploy is your first command. - A vector collection is live the moment you create it. GCP's Vector Search asks you to build an index and then deploy it to an endpoint whose replicas bill by the node-hour whether or not anyone queries them. Here, creating a collection is the whole setup.
- Sessions and memory come with the agent. On Vertex they are separately documented and separately billed sub-products. Here they are part of every deployed agent — see sessions and memory.
- One question, one line item. A single Vertex agent turn that retrieves, generates, writes a session, and writes a memory can appear as four separate billed SKUs. There is no usage metering here at all today; capacity is bounded by visible project quotas.
- Provider access is structural, not contractual. A platform admin gets
404 not foundon your agents and secrets — the same answer a stranger gets. The only way in is a break-glass grant that expires, shows up on your members list, and lands in your audit log. See break-glass and audit.
GCP has more
Be honest with yourself about these before you migrate. If any is a hard requirement today, GCP is the right choice, and we would rather say so here than have you find out later.
- Regions and zones. GCP runs dozens of regions with zonal redundancy and a region picker on every service. The platform runs in one place. There is no region to choose.
- SLAs and compliance. No uptime SLA. Nothing like VPC Service Controls, CMEK, data-residency commitments, or HIPAA coverage.
- Marketplace and catalog breadth. Google Cloud Marketplace and hundreds of adjacent services have no counterpart. We have the services in the table above, and that is all.
- Model catalog. Gemini and Model Garden expose a large first-party model catalog. Agents here talk to a single OpenAI-compatible Crusoe Managed Inference endpoint that your administrator configures.
- Vector search depth. Vertex AI Vector Search offers hybrid search, tuned ScaNN configurations, and proven very-large-index scale. Ours is a straightforward HNSW collection with payload filters.
- Event routing and orchestration breadth. Eventarc, Cloud Tasks, and Cloud Composer have no equivalent here.
- Secret lifecycle features. Secret Manager offers replication policies, per-secret IAM, and rotation schedules. Here there is no automatic rotation, and deletion destroys every version immediately.
- Observability. Logs Explorer's query language, log sinks, log-based metrics, and long retention beat 14 days of plain log history and live-only counts.
- Identity maturity. Google Workspace SSO, MFA, and Workload Identity Federation. Here: email and password, 12-hour sign-in tokens that cannot be revoked early, and no federation.
- GPU instance classes. GCP lets you pick specific accelerator types. There is no GPU instance-class selection here today.
- A public API hostname. There is no public API endpoint yet. The console is the front door; automation reaches the API through the
$CAI_APIaddress your administrator provides, often a port-forward. See API authentication.
Try the Cloud Run functions muscle memory
If you can write a GCP HTTP function, you already know our function contract. With the CLI installed and signed in:
mkdir hello-http && cat > hello-http/handler.py <<'EOF'
def handle(event):
who = event.get("name") or event.get("message") or "world"
return {"greeting": f"Hello, {who}!"}
EOF
platformctl functions deploy ./hello-http --name hello-http
You should see:
packaging ./hello-http...
uploading hello-http (0.3 KiB, framework=function)...
build 7c41d9e2-... accepted
status: -> building
status: building -> deploying
status: deploying -> ready
hello-http is ready at http://hello-http.cai-p-ab12cd.svc.cluster.local
Then call it:
platformctl invoke hello-http "ping"
You should see output containing:
{"greeting": "Hello, ping!"}
No APIs to enable, no Cloud Build role to grant, no Artifact Registry repository, and no separate URL resource. The full walkthrough is the functions quickstart.
Migration pointers
| Moving this from GCP | Start here |
|---|---|
| A Cloud Run service | Serverless overview, then autoscaling and scale to zero |
| A Cloud Run function | Functions quickstart, then runtimes |
| A Vertex AI Agent Engine deployment | Agent quickstart, then deploy and ADK |
| Agent tools you wrote for ADK | Tools — the same Python functions, no schema resource to author |
| A Vertex AI Vector Search index | VectorDB quickstart, then search and the RAG chatbot tutorial |
| A Memorystore instance | MemoryStore quickstart |
| Cloud Pub/Sub topics and subscriptions | Pub/Sub quickstart, then publish and consume |
| A GCP Workflows definition | Run a workflow and the durable agent pipeline tutorial |
| Secret Manager secrets | Manage secrets, then use in workloads |
| IAM bindings, service accounts, and CI keys | Projects and access and the CI/CD service account tutorial |
| Cloud Logging queries you rely on | Logs — read the retention note first |
Next steps
- Service mapping — every service side by side across all three clouds.
- For AWS users and for Azure users — the other two translation guides.
- Core concepts — the platform's own vocabulary, from scratch.