Migrate from GCP

Most GCP production estates use four services in earnest: Compute Engine, Cloud Functions / Cloud Run, Cloud Storage, and Cloud SQL. Each maps onto a Joule Cloud equivalent. The migration shape is the same as migrate from AWS; this page covers the GCP-specific deltas.

Service map

GCP	Joule Cloud	Notes
Compute Engine VM	Compute	Containerize; deploy via `invisible.hcl`.
Cloud Run	Compute (scale-to-zero) or Functions	Cloud Run's container model maps cleanly onto Compute with scale_min=0.
Cloud Functions	Functions	Same handler shape; runtime list slightly different.
Cloud Storage	Object Store	GCS uses XML/JSON APIs; we expose the S3 API. Migration via `gsutil` + `aws-cli` or `rclone`.
Cloud SQL (Postgres)	JouleDB	Postgres wire-compatible.
BigQuery	JouleDB columnar surface	Limited SQL parity at launch. Bring schema + data; verify queries against the analytical surface.
Pub/Sub	Functions + queue trigger	Light queue at launch.
Vertex AI inference	Inference	OpenAI-shape; replace Vertex SDK calls with OpenAI SDK pointed at our endpoint.

Cloud Storage → Object Store

GCS doesn't natively speak S3 but most clients do. Use rclone as the bridge:

# Configure rclone: one remote for GCS, one for Joule Cloud
rclone copy gcs:/my-bucket jc:/my-bucket --transfers 32 --checksum --progress

For applications, swap the GCS SDK for boto3 (Python) / @aws-sdk/client-s3 (Node) pointed at our endpoint. See Migrate from AWS S3 for the SDK config snippets — the client code is identical.

Cloud Run → Compute

Cloud Run's "deploy a container, scale to zero, billed by request" model is exactly what Compute with scale { min = 0 } provides.

workload "myservice" {
  image = "gcr.io/my-project/myservice:abc123"
  region = "auto"
  cpu = "1 vCPU"
  memory = "512 MB"
  scale {
    min = 0
    max = 100
    on_metric = "requests_per_sec > 50"
  }
}

route "myservice.example.com" {
  to = workload.myservice
}

Cloud Run's per-request billing becomes per-joule billing. For request-heavy / low-compute services, similar cost. For CPU-heavy services, you'll typically pay less because Cloud Run rounds up to 100ms allocation; we measure the actual joules.

Cloud Functions → Functions

Handler signature differs slightly. GCP's Cloud Functions (gen 2, the modern one) use HTTP-style handlers; ours are Request / Response.

// GCP gen2
- functions.http("hello", (req, res) => {
-   res.json({ hello: req.body.name });
- });

// Joule Cloud Functions
+ export default async function (req) {
+   const body = await req.json();
+   return Response.json({ hello: body.name });
+ }

Cloud SQL → JouleDB

# Cloud SQL dump
gcloud sql export sql my-instance gs://my-bucket/backup.sql --database=main
gsutil cp gs://my-bucket/backup.sql ./backup.sql

# create JouleDB
jc db create main --region eu-fi --size 100GB

# restore
psql "postgresql://jc_…@db.greenjoules.cloud:5432/main" < backup.sql

What's different from GCP's model

Projects. GCP organizes resources into Projects; we use Accounts. One account can hold many workloads; resource isolation is by token scope, not by project boundary.
Billing. No per-second VM billing — per-joule. No SKU code lookup — the bill is the receipts.
IAM. No role hierarchy. Per-token scopes. Cleaner for small teams; coming-soon for enterprise team RBAC.
Networking. No VPC config. Workloads on the mesh share a private network automatically; outside access is via route blocks.

Why bother

For the typical Cloud Run + Cloud SQL + Cloud Storage stack, customers report 25-45% lower monthly bills (with the same redundancy posture), plus per-request joule + carbon attribution for ESG reporting that GCP's aggregated estimates can't match.