# Light Cloud + Claude Code: Deploy Your App by Asking ``` You: Deploy this folder to Light Cloud, behind a password. Claude: Which workspace: julias or prod-team? And the password? You: prod-team, "by-asking" Claude: Deployed. https://main-hello-claude-prod-team.light-cloud.io Password: by-asking ``` That is a real conversation, and that is a real page: open [main-hello-claude-prod-team.light-cloud.io](https://main-hello-claude-prod-team.light-cloud.io), type `by-asking`, and you are looking at the one HTML file I put in a folder for this post. One MCP server installed in Claude Code, one sentence, two answers, a URL. No account form, no dashboard, no build settings. Below is every step: what Claude asks, what comes back, and what to say next. Total time on a fresh machine is about two minutes, most of it the build. You need Node.js 18 or later (for `npx`) and Claude Code. A Light Cloud account is optional; Claude creates one if you have none. ## Step 1: install Light Cloud AI One command registers the server with Claude Code: ```bash claude mcp add light-cloud -- npx @light-cloud/mcp-server ``` Check it is connected: ```bash claude mcp list ``` Claude Code asks before each tool call. To approve the Light Cloud tools once, open `/permissions` and add `mcp__light-cloud` to the allow list. If you prefer Claude Desktop, download the `.mcpb` from the [releases page](https://github.com/light-cloud-com/mcp-server/releases/latest) and open it; no Node.js, no config file. GitHub Copilot in VS Code takes the same server through `.vscode/mcp.json`; the [docs](https://docs.light-cloud.com/deploy-with-ai/mcp-server) have that config. ## Step 2: ask Open Claude Code in your project folder and say: ``` Deploy this project to Light Cloud. ``` If you are not signed in, Claude shows an 8-character code and the address `console.light-cloud.com/device`. Open it on any device (a phone is fine), sign in or type your email, enter the code, approve. No account yet? Approving creates one on the free plan. No password is ever typed into the chat. Then Claude asks at most two things, in one message: 1. Which workspace, if you belong to more than one. 2. Public, or behind a password? It does not ask what kind of project this is. The folder is uploaded and read by the same detector the console uses for a connected repository, so Next.js becomes a server app (or a static site when `output: "export"` is set), Vite becomes a static site with the right output folder, a `requirements.txt` with FastAPI becomes a Python container on port 8000, and a Dockerfile is used as-is with its `EXPOSE` port. Forty-odd frameworks are recognised; the list is in the docs. ## Step 3: get the URL Claude packages the folder, uploads it, creates the app, and waits for the build. The reply is the live address, shaped `--.light-cloud.io`: ``` https://main-hello-claude-prod-team.light-cloud.io ``` If you asked for a password, it comes back on the next line, and the site asks visitors for it from the first request; the gate sits at the edge, in front of the app, so nothing is served without it. A small `.lightcloud` file is written to the folder. It records which app the folder belongs to, so from now on nothing needs arguments. ## Step 4: keep talking Everything you would otherwise do in a dashboard is a sentence. Copy any of these: ``` Redeploy. ``` ``` Show me the last 100 log lines. ``` ``` Why did the last deployment fail? Check the logs. ``` ``` Set STRIPE_KEY to sk_test_123 on production and redeploy. ``` ``` Add a Postgres database and set DATABASE_URL on production. ``` ``` Point shop.example.com at this app. ``` ``` Put a password on this site. ``` ``` Make the site public again. ``` ``` Keep this app always on. ``` ``` Roll back to the previous deployment. ``` Claude chains the tools itself: "why did it fail" looks up the deployment, reads the build log and the runtime log, and explains. The database request creates a PostgreSQL database on the shared pool (included in every plan), waits for it, fetches the connection string, and writes it into the variable, without printing the secret into the chat. ## Three kinds of project, three conversations **A frontend.** A Vite, Create React App, Astro, Hugo or plain HTML folder becomes a static site on the CDN. Next.js with `output: "export"` too. Free, fast, and it never sleeps. ``` Deploy this Vite app to Light Cloud. ``` ``` Point www.example.com at it. ``` ``` Put a password on it while the client reviews it. ``` **A backend.** Express, Fastify, NestJS, FastAPI, Flask, Django, Rails, Laravel, Go, Spring Boot, or anything with a Dockerfile becomes a container. The port comes from the framework or the Dockerfile; it scales to zero when idle. ``` Deploy this FastAPI service to Light Cloud. ``` ``` Set OPENAI_API_KEY and SENTRY_DSN on production from my .env, then redeploy. ``` ``` Show me errors in the last hour. ``` **A backend with a database.** Ask for both; Claude creates the database, waits for it, and wires the connection string into the app without printing the secret. ``` Deploy this Rails app and give it a Postgres database. ``` ``` What tables are in the database, and how many rows in users? ``` ``` Back up the database to ./backups before I run the migration. ``` ``` Rotate the database password and update production. ``` The database lives on a shared pool by default (included in every plan). A dedicated tier, more storage or high availability are one more sentence: "Move the database to a dedicated tier with 50 GB." If the plan does not include it, the answer names the plan that does, and nothing changes until you say so. ## A backend that needs to scale A container app (Express, FastAPI, Rails, Next.js with server rendering, anything with a Dockerfile) deploys the same way: the folder is read, the port is picked up from the framework or the Dockerfile's `EXPOSE`, and it starts on a small instance that scales to zero when idle. When traffic arrives, scaling is a sentence: ``` Keep this app always on. ``` ``` Allow production to scale up to 5 instances. ``` ``` Give production 1 GB of memory and 2 CPUs. ``` ``` How is production doing in the last 24 hours? ``` The first sets an instance floor of one, so the app never cold-starts. The second sets the ceiling; Light Cloud adds instances between floor and ceiling as requests come in and removes them when they stop. The third changes the size each instance runs on; the fourth reads requests, latency, errors, instances, cpu and memory for the range you name. Some of these cost more than the free plan includes: an always-on instance or a larger size are paid-plan features. Claude does not guess at that. It asks for the change, and if the plan does not cover it the platform refuses with the plan that would, so the next line from Claude is "this needs the Lite plan, want me to switch?" and, if you say yes, the card link. Nothing is charged without that yes. ## Step 5: from a repository instead If the project lives on GitHub, GitLab or Bitbucket, ask for that: ``` Create a Light Cloud app from acme/storefront and deploy the main branch. ``` For GitHub, Claude hands you the link to install the Light Cloud GitHub App if it is not installed yet. For GitLab or Bitbucket: ``` Connect my GitLab account. ``` One link, sign in, authorise, done. From then on every push to the branch deploys, and a pull request gets a check run and a comment with its preview URL. The MCP server sets it up; it is not in the path of your pushes. ## Plan and card, without leaving the chat The free plan needs no card, and Claude never brings up plans unless a tool refuses something the plan does not include (an always-on instance, a dedicated database tier). Then: ``` Show me the plans. Put the workspace on Pro. ``` ``` Add a card. ``` The card goes through a Stripe-hosted page Claude gives you a link to; the tools wait until it is saved. No card number passes through the assistant. Invoices, usage against the pool, and a spending limit are all askable: ``` What is using my pool this month? ``` ``` Cap this workspace at 50 dollars a month and warn me at 80 percent. ``` ## Prefer a shell? The same thing as commands ```bash npm install -g @light-cloud/cli lc login --device # a code you approve on any device lc init # link this folder to an app, or create one lc deploy # deploy and follow the build to the URL lc logs -f # tail runtime logs ``` `lc create --upload --password spring-preview` gates the site from the first deploy; `lc env password --off` opens it. Every command takes `--json`, so a pipeline or another agent can drive it like `git`. The full command reference, with a copy button on each, is at [docs.light-cloud.com/deploy-with-ai/cli](https://docs.light-cloud.com/deploy-with-ai/cli). ## The off switch Handing an assistant your account should come with a way to take it back. In the console, Settings, Security, **Agents & CLI**: one master switch refuses every request from Claude, Copilot, the CLI and the VS Code extension; below it, groups you can keep console-only (deploying, deleting, changing settings, databases, plan and payment, workspace members, API keys). Reading is always allowed. **Sign out all agents** ends every agent session at once. It is enforced on the backend from the session itself. A session issued to Claude Code carries that fact in its token from the moment it is created, so an agent cannot pass as the console, and the switch can only be changed from a console session. When Claude runs into it, it gets a refusal that names the setting and is told not to retry. Three things stay in the console on purpose: changing your password, two-factor settings, and that switch. The install is one line; the rest is asking.