Deployment/Providers/Gcp

guidedeploymentCARE 3.0+

Google Cloud Platform offers several paths for deploying Care, depending on what you need to run and how much you want automated. You can provision the whole platform from an infrastructure-as-code template, build it out by hand on a managed Kubernetes cluster, or host just the Care frontend as a globally distributed static site.

Deployment options

Infrastructure as code — the GCP template

The gcp_template repository provisions the entire GCP platform with OpenTofu and installs Care and its supporting services with Helm. It covers the VPC, the GKE cluster, Cloud SQL, Cloud Storage, KMS keys, Cloud Armor, and the Gateway API with cert-manager, alongside the Care backend and frontend, Redis, Metabase, and an optional DICOM stack.

This is the recommended path for new deployments. Environments are described entirely in a tfvars file held in Secret Manager, so a deployment is reproducible and a release is a configuration change rather than a manual pipeline run.

See Deploying Care with the GCP template for the full walkthrough.

Google Kubernetes Engine (GKE), configured by hand

Run the full Care application (backend and frontend) on a managed Kubernetes cluster built up through the Google Cloud Console. Container images are built with Cloud Build and stored in Artifact Registry, then deployed to GKE.

📝 Note

This is the earlier workflow. It provisions resources manually and depends on Cloud Source Repositories and the infra_template manifests. New deployments should use the GCP template above; this guide is retained for existing instances built this way.

See Deploy on GKE for the full walkthrough.

Google Cloud Storage (GCS)

Host the Care frontend as a static website backed by Cloud CDN and a global HTTP(S) load balancer. This gives you fast global content delivery and a simple, cost-effective deployment for static, single-page-application content.

📝 Note

GCS hosts only the frontend. The Care backend must be deployed elsewhere (for example, on GKE or another provider), and the frontend is configured to talk to that backend's API.

See Host the frontend on GCS for the full walkthrough.

Choosing between the options

Requirement	GCP template (IaC)	GKE by hand	GCS
Best for	Reproducible, version-controlled deployments of the full platform	Existing instances already built this way	Static websites, single-page applications, frontend-only hosting
Provisioning	OpenTofu, applied module by module	Manual, through the Cloud Console	Manual or scripted, minimal
Application install	Helm charts held in the repository	`kubectl apply` of the `infra_template` manifests	Static object upload
Releases	Change an image tag in tfvars, re-apply the deploy module	Trigger the Cloud Build webhook	Re-upload the built assets
Hosts	Full Care application and supporting services	Full Care application	Frontend only (backend lives elsewhere)
Deployment complexity	Moderate up front, low thereafter	Higher, and manual at every step	Lowest

Cost considerations

GKE (either path): higher cost, but more flexible and scalable. Suited to running the complete application with full Kubernetes capabilities.
GCS: lower cost, pay-per-use model. Ideal for serving static frontend content efficiently.

The GCP template does not change what you pay for — it provisions the same managed services. Cost is driven by your node_pools and Cloud SQL sizing.

Prerequisites

Before deploying with any option, make sure you have:

The Google Cloud SDK (gcloud) installed
A GCP project with billing enabled
Appropriate IAM permissions
A domain name (if using a custom domain)

The GCP template additionally requires OpenTofu and Helm locally, a GCS bucket for remote state, and access to Secret Manager for environment configuration.

Common configuration

Before deploying, ensure the following are in place:

Domain name configured in GCP DNS
SSL certificate (managed by GCP, or issued by cert-manager when using the template)
Appropriate IAM permissions
Billing enabled on the project