# Light Cloud · medium context bundle

Light Cloud, Inc. builds two things, and the website is organized around them. The **Platform** is a managed way to ship web apps: push to a GitHub repository and every commit builds and deploys, with a database, preview environments, custom domains, and observability in one place. **Labs** is the company's open-source work, home to ICE, a visual editor for cloud infrastructure that deploys to your own cloud accounts. This bundle covers the Platform first, then Labs / ICE in depth.

## Platform

Push to Git and get a live URL. Light Cloud reads your repo, builds the commit, and rolls it out: static sites to a global CDN, containers to Cloud Run, with managed PostgreSQL provisioned alongside. Every branch gets a preview environment, custom domains get automatic SSL, and logs and metrics live in the same console you deploy from. You can deploy from Claude or GitHub Copilot instead of a dashboard. Billing is usage-based and hourly, and idle apps scale to zero. The platform runs on Google Cloud (Cloud Build, Artifact Registry, Cloud Run) with a Cloudflare CDN. Start on a 30-day free trial at https://console.light-cloud.com.

### Deployments

Connect a GitHub repository and every push builds and deploys on its own — no manual build step, no separate CI to wire up. Light Cloud installs a GitHub App, reads the repo, and detects the framework, package manager, build command, and output directory (override any of them). A push to a connected branch triggers a build on Cloud Build; you watch the logs stream, then static assets land on a global CDN and containers roll out on Cloud Run. Every deploy keeps its commit, message, author, duration, status, and full build log, so you can see what shipped and redeploy any earlier commit to roll back. No Dockerfile in the repo? One is generated for your framework; bring your own and it wins. You can also push a local folder straight from the VS Code extension or the MCP server before a repo is set up. https://light-cloud.com/deployments

### Preview environments

Every branch gets its own environment with its own URL, built from that branch and nothing else. Open a pull request and the preview builds automatically, so reviewers click a link instead of pulling the branch. Delete the branch and its environment is removed — stale previews do not pile up. Production is a separate, protected environment that branch activity never touches. Container previews scale to zero when idle, so review apps cost nothing overnight, and a preview is built the same way production is, so what a reviewer sees is what ships. Auto-deploy on push and automatic cleanup are on by default, per-application. https://light-cloud.com/previews

### Databases

Provision managed PostgreSQL on Cloud SQL from the same project you deploy from — no servers to patch or back up by hand. Pick a tier, region, and storage size at creation and change them as the app grows; turn on high availability for workloads that cannot take downtime. The admin password is encrypted at rest and connection details are wired into your app as environment variables, so the backend reaches the database in the same project without extra setup. Frontend, backend, and database live together: one place to deploy, one place to manage. https://light-cloud.com/databases

### Custom domains

Point a domain at any app or environment. Add the domain, add the one DNS record Light Cloud gives you at your registrar (the only manual step), and an SSL certificate is issued automatically. Traffic reaches the right environment over HTTPS, encrypted end to end. Certificates are issued and renewed for you, DNS mapping is handled, and you can attach a domain to production or give a staging environment its own hostname. https://light-cloud.com/domains

### Observability

Watch a build stream live, then follow the running service — logs and metrics for every environment sit in the same console you shipped from, next to the environment they belong to. Build logs stream as the build runs and stay on the deploy record afterwards; runtime logs stream from the running service, filtered to the environment; metrics show how a service is doing without setting up a monitoring stack first. Production and every preview keep their own logs and metrics, kept separate. No second dashboard, no switching tools to find out how a deploy is doing. https://light-cloud.com/observability

### Deploy with AI

Ship from Claude or GitHub Copilot without leaving your chat or your editor. The Light Cloud MCP server lets Claude create apps, deploy them, manage environments, and read logs from a conversation after a one-time browser sign-in, with credentials stored locally. The VS Code extension adds @lightcloud to GitHub Copilot Chat with /deploy, /redeploy, /status, /list, /plan (preview config before shipping), and /destroy; a small project config file means follow-up commands need no arguments. Framework detection and .env parsing happen for you, and deploys come back with a live URL and a link to the console. https://light-cloud.com/deploy-with-ai

### Frameworks

Light Cloud reads your repo and picks the right build. Static and frontend stacks — React (Vite, CRA), Vue, Angular, Svelte and SvelteKit static, Next.js static export, and plain HTML — go to the global CDN. Backends run as containers on Cloud Run: Next.js SSR, Node (Express, Fastify, NestJS, Koa), Python (FastAPI, Flask, Django), Go, Java (Spring Boot), Ruby, PHP, and .NET. Framework, runtime, package manager (npm, yarn, pnpm, pip, poetry), and output directory are detected from the files in the project; a Dockerfile in the repo is used as-is and the app runs as a container. Detection, not configuration. https://light-cloud.com/frameworks

### Pricing

A 30-day free trial ($0, no card for the first two weeks, up to three resources, static sites and containers, one managed Postgres database, preview environments and custom domains), then usage-based hourly billing. You pay for what runs: compute per instance-hour (scale to zero means an idle app costs nothing), managed Postgres for the tier and storage provisioned, object storage for what you keep, bandwidth served (static sites go out over a CDN), and build minutes. No per-project fees; add team members at a flat $9 per user each month. https://light-cloud.com/pricing

## Labs (open source)

Labs is Light Cloud's open-source side: the code you run yourself, deploying to your own cloud accounts, Apache 2.0 with no telemetry and no license keys. ICE is the flagship project; blocks are its building units and templates are ready-made compositions. The rest of this bundle documents ICE. https://light-cloud.com/labs

### ICE

ICE (Integrated Cloud Environment) is an open-source visual editor for cloud infrastructure, Apache 2.0 licensed, version 0.1.50. Tagline: "Visual Studio for Cloud." Drag provider-neutral concept blocks onto a canvas, connect them, click Deploy. The engine compiles the canvas into a typed graph, diffs it against the last-applied state, computes a plan (create / update / delete / no-op), and applies it through per-cloud deployers that wrap real SDK calls. GCP is stable; AWS and Azure are experimental; Kubernetes, Alibaba, Oracle Cloud, DigitalOcean, and Tencent render on the canvas with deployers in design. An optional AI assistant (Claude with BYO key, or any OpenAI-compatible endpoint) reads the canvas as context and emits canvas mutations as ghost suggestions. https://light-cloud.com/labs/ice

ICE runs as a web app (`pnpm dev:all`) or a fully self-contained Electron desktop app (`pnpm dev:desktop`, or installers built with electron-builder). Either way, the embedded Express gateway, six in-process services, Prisma over SQLite (or Postgres for self-hosted production), Redis-backed BullMQ workers (prod only), and Socket.IO are all part of one process. No Docker is required for the default setup. No login screen exists in Community Edition: the gateway auto-seeds a single "desktop user" and every authenticated route resolves to them. Multi-user (presence, comments, RBAC, OIDC SSO) is reserved for the planned Team and Cloud editions.

### Why ICE exists

Cloud infrastructure has the worst developer ergonomics in the stack: every team rebuilds the same shape (web service + database + queue + bucket + secrets) in Terraform or Pulumi, then duplicates it for staging, then again for a second cloud, then again as a CI/CD pipeline, then again as a cost dashboard. ICE makes the canvas the source of truth: the same drag-and-drop document describes the architecture, plans the deploy, projects the cost, drives CI/CD, surfaces logs, and accepts AI edits. Provider-agnostic at the top, real cloud below. Apache 2.0, runs offline, no telemetry, no license keys: your canvas, your cloud, your data.

### How the pieces fit (one-minute model)

Web app (React + custom SVG canvas) talks to a single Express gateway over REST + Server-Sent Events + Socket.IO. The gateway composes six in-process service routers: **canvas** (CanvasProject + environments CRUD), **deploy** (plan, apply, pipelines, GitHub webhooks, queue workers, drift), **ai** (Claude integration, SSE streaming, deploy-failure diagnosis), **iam** (users, orgs, onboarding, profile), **credentials** (encrypted provider + GitHub credentials), and **engine** (schema + resource metadata API), and adds Helmet, CORS, cookie-parser, rate limiting, and Socket.IO around them. All six write through Prisma to one DB (SQLite in dev/desktop, Postgres in prod). The provider-neutral brain (`packages/core/`) is pure logic: no UI, no network. Per-cloud deployers (`packages/providers/<cloud>/`) own all SDK calls. The dependency rule is strict: nothing in `packages/` depends on `services/` or `apps/`; services depend on packages; apps depend on everything. Desktop is the same gateway compiled into the Electron main process; the renderer never imports Node and everything is HTTP to a local port, so the web build is the only UI surface.

### Blocks — 28 concepts across 8 categories

The canvas palette is provider-neutral; each concept compiles to a per-cloud primitive at deploy time.

- **Compute**: Scalable Backend (Cloud Run / ECS Fargate / Container Apps), Worker, Serverless Function (Cloud Functions / Lambda / Functions), SSR Site, Static Site (Cloud Storage+CDN / S3+CloudFront / Storage+CDN)
- **Data**: Postgres (Cloud SQL / RDS / Database for PostgreSQL), MySQL, MongoDB (Firestore / DocumentDB / Cosmos DB), Redis Cache (Memorystore / ElastiCache / Cache for Redis), Object Storage, Vector DB (Vertex AI Vector Search / OpenSearch / AI Search)
- **Messaging**: Message Queue (Pub/Sub / SQS / Service Bus), Event Stream (Pub/Sub / Kinesis / Event Hubs)
- **AI**: LLM Gateway (Vertex AI endpoints / Bedrock / Azure OpenAI), Private AI Service (GKE / EKS / AKS), Vector DB (shared with Data)
- **Networking**: Public Traffic (Load Balancer / ALB+CloudFront / Front Door), Private Network (VPC / VPC / VNet), API Gateway, Custom Domain (Cloud DNS+LB / Route 53 / DNS Zone)
- **Observability**: Observability (Cloud Logging / CloudWatch / Monitor)
- **Security**: Secret Store (Secret Manager / Secrets Manager / Key Vault), Env Config
- **Integration**: GitHub Repo (wire a repo to a service, auto-deploy on push), Email Service, Scheduled Task (Cloud Scheduler / EventBridge / Logic Apps)

Concepts advertise *requirements* enforced by the validator: a Scalable Backend needs either a GitHub Repo or an Object Storage for code plus a Public Traffic upstream, etc. Unmet hard requirements block the deploy; soft requirements warn.

### Templates — 13 that ship today

Pre-built canvas compositions, every block of which is one a user could drop individually: SaaS Starter (static + backend + Postgres + auth + custom domain), Full-Stack (SSR + backend + Postgres + storage), RAG Chatbot (static + LLM + vector DB + backend), Backend API (backend + Postgres + observability), Microservices, Serverless API, Event-Driven Serverless, Secure API, AI/ML, EU Compliance (region-locked), SaaS Multi-Tenant, SaaS Analytics Dashboard, and Budget Web App. Quick-Starts (single function, container+DB, worker+queue, static site) are on the next-up list.

### Providers

`PROVIDER_READINESS` in the constants package is the truth-source.

- **GCP: stable.** 20+ handlers across compute (Cloud Run services + jobs, Cloud Functions, GKE), database (Cloud SQL PostgreSQL + MySQL, Firestore, Memorystore Redis), storage, messaging (Pub/Sub, Cloud Scheduler), AI/ML (Vertex AI + Vector Search), analytics (BigQuery), security (Secret Manager, Identity Platform), networking (API Gateway, Load Balancer), observability. Full create/update/destroy with live progress. Importer covers 45+ resource kinds via Cloud Asset Inventory.
- **AWS: experimental.** EC2 instance, S3 bucket, Lambda function ship end-to-end; other categories surface "unsupported on AWS" in the plan modal. Importer not implemented.
- **Azure: experimental.** Virtual Machine, Storage Account, Web App ship end-to-end; other categories surface "unsupported on Azure". Importer not implemented.
- **Kubernetes: design-only.** 13 blocks render on canvas; deployer not wired.
- **Alibaba Cloud / Oracle Cloud / DigitalOcean / Tencent Cloud: design-only.** Block stubs only.

Adding a provider is well-scoped contributor work: register in the constants, implement a `ProviderDeployer`, add an auth adapter, add provider variants to the relevant concept blueprints, then wire tests and docs.

### Plan and apply

The deploy engine is provider-agnostic at the top, per-cloud at the handler level. A typical apply cycle: validate the canvas (cycles, references, type compatibility, connectivity, soft + hard requirements); translate UI cards into provider-neutral graph nodes; diff against last-applied state to produce `CREATE / UPDATE / DELETE / NO_OP` per resource plus a monthly cost projection; run a bounded worker-pool scheduler over the per-node DAG (per-handler caps reserve one concurrent Cloud SQL and one Redis create so fan-outs do not trip GCP quotas). Failure isolates to descendants only — siblings and unrelated branches keep running, so a canvas that loses one Cloud SQL still completes the rest and surfaces a partial-success rollup. Handlers report sub-step progress, and new state is written back on success while partial failures persist state-so-far so the next plan resumes from the exact spot. The live wire is a single Socket.IO channel carrying a discriminated `DeployEvent` union (`node_status`, `node_progress`, `log`, `complete`, `requirement_verified`).

### Cost prediction

Per-canvas monthly projection before apply. Each block contributes a line item from public pricing data plus its configured parameters (instance class, region, replicas, storage size, scaling profile). Variable costs (egress, per-request) are estimated against modelled traffic and surfaced separately; free tiers and committed-use discounts are subtracted. Tied to the provider: a multi-cloud migration shows the projected bill on the target cloud before commit. Projected-vs-actual dashboards, drift alerts, and per-environment budgets are on the roadmap.

### Import and export

The GCP importer is the most mature: it walks Cloud Asset Inventory plus service-specific APIs and produces a canvas representing what it found (45+ resource kinds). Terraform-state-JSON and Pulumi-checkpoint-JSON importers work today; AWS and Azure importers are partial; Docker Compose import is on the roadmap. Importing is the read-only inverse of deploy and reuses the same graph model. Export goes the other way: a graph turns back into Terraform HCL or Pulumi TypeScript, so a team that wants to drop ICE for plain IaC has a clean exit. AWS CDK and Kubernetes manifest exports are on the roadmap.

### Migration

Switch the canvas provider and ICE remaps every block to the equivalent service on the new cloud, reprojects cost, and flags untranslatable details (region availability, IAM shape, network constructs) before apply. Data movement and DNS cut-over are explicitly out of scope.

### CI/CD

Connect a GitHub repo to a canvas node. The deploy service listens for push events on a watched branch, HMAC-verifies the payload against the repo's secret, and triggers a deploy on the configured environment. Pipelines are stored per-project; environments (production, staging, preview branches) each carry their own deploy state and credentials.

### AI assistant

Optional, off by default. Set `ANTHROPIC_API_KEY` (or an `ICE_AI_URL` + model for an OpenAI-compatible backend) and the chat panel activates; Anthropic is picked first if both are set.

- **Chat over the canvas.** The system prompt is built from a project-agnostic preamble, a serialized summary of the current canvas (blocks, edges, provider, environment, validation state), and a deployment-state summary. Streaming via Server-Sent Events.
- **Ghost mode proposals.** Tool calls (today `add_block` and `connect_blocks`) render as dashed-outline reduced-opacity nodes/edges and wait for the user to accept or reject; accepting converts them into real state and triggers validation. More tool types (delete, rename, modify, group) are coming.
- **Deploy diagnosis.** On a failure, "Explain" forwards the error payload plus relevant graph context to Claude for a plain-English diagnosis and suggested fix.
- **Bring your own key, no autonomous apply.** Every proposal goes through explicit user approval, and the API key stays server-side; the browser never sees it. Point the OpenAI-compatible URL at a local Ollama / LM Studio / vLLM if you prefer.

### Desktop app

Cross-platform Electron, built with electron-builder for macOS (ARM64 `.dmg` + `.zip`; Intel a config flip away), Windows (NSIS `.exe`, x64), and Linux (`.AppImage` x64+ARM64 and `.deb` x64), and distributed through GitHub Releases. The main process runs the embedded gateway and a `BrowserWindow` loads the same web bundle `packages/web` produces; all DB writes land in a local SQLite file under the platform's app-data directory (delete it to reset). Security model: `nodeIntegration: false`, `contextIsolation: true`, `sandbox: true` where possible, with a typed, deliberate preload IPC surface. v0.1 binaries are not yet code-signed (macOS "right-click → Open", Windows "More info → Run anyway"); Apple notarization, Windows EV signing, and auto-update against GitHub Releases are on the v0.2 plan.

### Frontend

React 18 + Vite. The canvas is a custom SVG renderer (chosen over React Flow for predictable pan/zoom math at 1000-node scale). Redux Toolkit with 17 slices whose boundaries match feature folders; Tailwind for layout, Radix UI for accessible primitives, custom `ice-*` design tokens. Internationalisation is hand-rolled with two complete locales today (English and Mandarin).

### Database

Two SQLite databases play different roles. Runtime state (canvases, environments, deployments, encrypted provider credentials, deploy event log, pipelines) is a small, growing, gitignored DB that moves to Postgres for production self-hosting and ICE Cloud on the same Prisma schema. The provider schema catalog (`packages/core/data/ice-schemas.db`, ~36 MB, committed, read-only) is generated by `pnpm schemas:build` from the Terraform and Pulumi provider registries and powers the properties panel, autocomplete, and validation; it stays SQLite even when the runtime DB is Postgres. Provider credentials are AES-256-GCM ciphertext at rest, GitHub webhook payloads are HMAC-verified, CORS is restricted to the frontend origin, and rate limits sit in front of every API route.

### Editions

- **Community Edition**: this repo. Single user, Apache 2.0, no telemetry, no license keys.
- **Team Edition**: planned. Self-hosted, multi-user with invites, OIDC SSO, RBAC (editor / viewer / owner), shared template libraries, comments + mentions, real-time presence + cursors with CRDT/OT locking, audit log.
- **Cloud Edition**: planned. Managed by Light Cloud, usage-based billing, SLA, support, per-org token tracking for AI.

Multi-user features (presence, comments, RBAC) ship in Team and Cloud only.

### Tech stack at a glance

- Frontend: React 18, Vite, Redux Toolkit, Tailwind CSS, Radix UI, custom SVG canvas
- Backend: Express, Prisma 6, PostgreSQL 16 / SQLite, Redis (prod only), BullMQ, Socket.IO
- AI: Anthropic Claude (streaming SSE), OpenAI-compatible fallback for Ollama / LM Studio / vLLM
- Desktop: Electron, electron-vite, embedded gateway, electron-builder, electron-updater
- Cloud SDKs: Google Cloud (20 services), AWS SDK, Azure SDK
- Testing: Vitest (unit + integration), Playwright (E2E), Playwright-driven GCP scenario dashboard
- Languages: TypeScript everywhere. Package manager: pnpm 10 + workspaces, Node 22+

### Roadmap (live)

AI (live telemetry context, multi-step tool use, full mutation surface, proactive suggestions), Providers (AWS + Azure parity, Alibaba/OCI/DigitalOcean/Tencent/Kubernetes deployers), Blocks (networking primitives, managed K8s, more data, auth + analytics), Observability (in-canvas live logs, per-block sparklines, projected-vs-actual cost dashboards, alerts from the canvas), Security (secret rotation, audit log, pre-deploy vuln + IAM + region checks, SBOM, signed/notarized builds), Import/Export/Migration (Docker Compose to canvas, provider-to-provider plans, export to Terraform / Pulumi / CDK / K8s), Collaboration (presence, comments, RBAC, Team Edition), Templates (more patterns, quick-starts, industry templates), Deploy (CI/CD workflow templates, full AWS + Azure apply parity), Frontend (design-system refresh, canvas search + export), Desktop (auto-update + signed builds). Long tail: block/template marketplace, policy-as-code (OPA/Rego), in-app learning.

## Company

- About: https://light-cloud.com/about
- Team: https://light-cloud.com/team
- Careers: https://light-cloud.com/careers
- Contact: https://light-cloud.com/contact
- Roadmap: https://light-cloud.com/roadmap
- Community: https://light-cloud.com/community

## Key links

- Platform console: https://console.light-cloud.com
- Short index: https://light-cloud.com/llms.txt
- Long-form bundle: https://light-cloud.com/llms-full.txt
- ICE repository: https://github.com/light-cloud-com/ice
- Docs: https://github.com/light-cloud-com/ice/tree/main/docs
- Roadmap: https://github.com/light-cloud-com/ice/blob/main/ROADMAP.md
- License: Apache 2.0
- Issues: https://github.com/light-cloud-com/ice/issues
- Discussions: https://github.com/light-cloud-com/ice/discussions