# Cloud providers · Light Cloud Labs

> One canvas, swap the target cloud. ICE is built around a graph engine that does not know about specific clouds. Each provider has its own deployer.

## Status matrix

- **Google Cloud**: Usable. Most mature deployer. 20 service handlers. 45+ importers. Create, update, delete with live progress.
- **Amazon Web Services**: In progress. Major primitives deploy today. Parity with GCP is the next push.
- **Microsoft Azure**: In progress. Major primitives ship. AWS-parity gaps next.
- **Alibaba Cloud**: Design only. Blocks render on the canvas. Deployer is the next slice.
- **DigitalOcean**: Planned. Droplets, App Platform, managed DBs, Spaces.
- **Oracle Cloud Infrastructure**: Planned. OCI compute, OKE, autonomous DB.
- **Tencent Cloud**: Planned. CVM, TKE, COS, Pulsar.
- **Kubernetes (any cluster)**: Planned. Helm charts and raw manifests as a deployer target.

## GCP, what ships today

- Compute: Cloud Run (services and jobs), Cloud Functions, GKE
- Database: Cloud SQL (PostgreSQL, MySQL), Firestore, Memorystore Redis
- Storage: Cloud Storage
- Messaging: Pub/Sub, Cloud Scheduler
- AI / ML: Vertex AI (LLM endpoints, Vector Search, ML models)
- Analytics: BigQuery, Discovery Engine
- Security: Secret Manager, Identity Platform
- Networking: API Gateway, Load Balancer, Domain Mapping
- Observability: Cloud Logging

Every handler supports create, update, and delete, with live progress streamed back to the canvas.

## How the deployer works

Concepts compile to high-level resources, then per-provider handlers translate those into native SDK calls. The graph engine never imports a cloud SDK. That separation is what makes provider migration mechanical instead of a rewrite.

## Add a provider

Implement the deployer interface in `packages/providers/<cloud>` with create / update / delete handlers per service. The blocks layer is shared. https://github.com/light-cloud-com/ice/tree/main/packages/providers