How do I deploy my app to LingCode Cloud?

It helps to be precise about what "LingCode Cloud" hosting is, because the name covers two independent things. This tutorial is about Cloud apps — hosting the app you build: either a static front end (built HTML/CSS/JS, served from LingCode's edge) or a full-stack SSR app that renders and routes on the server. The deploy auto-detects which one you have. That is separate from a managed backend (a per-project Postgres with auth, storage, and realtime), which is its own feature with its own tutorial. You can use either alone or both together. (Full hosting reference, including the Worker runtime, is in App hosting on LingCode Cloud.)

The reason it's one click is that the IDE already has everything it needs: it knows your project folder, it can run your build, and you're already signed into your LingCode account. So instead of asking you to create a Netlify/Vercel/AWS account and paste a token, it builds locally, packages the output, and uploads it straight to LingCode-operated hosting. No third-party credential ever enters the picture.

What you'll learn

• What the Cloud button hosts (static front ends and full-stack SSR apps) — and the one thing it can't run (a long-running Node process)
• The three fields that matter: app name, build command, output directory
• What happens between clicking Deploy and getting a URL
• How re-deploying works, and how a custom domain and a backend fit in
• The limits and the common "why won't it deploy" cases

The mental model: one button, two kinds of app

The deploy looks at your project and picks the right target automatically:

• Static front end → served as pre-built files at https://lingcode.dev/apps/<id>/ with a single-page-app fallback. Whatever your project compiles to — a single index.html, or a Vite/React/Svelte/Vue build — those files are what get hosted. The right model for landing pages, docs, dashboards, games, and SPAs.
• Full-stack SSR app → built for and run as a Cloudflare Worker at https://<id>.run.lingcode.dev/, so server-side rendering, API routes, and server actions all run. Next.js (via the OpenNext adapter), SvelteKit, Nuxt, Astro, Remix/React Router 7, and TanStack Start are auto-detected and built.

The one constraint worth understanding: the Worker runtime is a Cloudflare V8 isolate, not Node.js. The supported frameworks are auto-adapted to it, but a hand-rolled plain Express/Node server (or a non-JS backend) won't run as-is — that, plus anything long-running or over ~30s per request, is what belongs on a server you run. See App hosting for the full runtime detail.

Deploy it, step by step

1. Sign in to your LingCode account in the Mac IDE. The app is published under this account; if you're signed out the Cloud popover just shows "Sign in to LingCode Cloud to deploy" with an Open Account… button.
2. Open the project folder you want to ship, then click the Cloud button in the toolbar (the bolt-in-a-cloud icon — its tooltip reads "Deploy this project to LingCode Cloud"). A popover opens, titled Deploy to LingCode Cloud.
3. Name the app (required) — e.g. Orbit Dodge. This is just a label you'll recognize later; the public URL is still an id.
4. Set the build command — for a framework project, something like npm install && npm run build. Leave it blank if the project is already plain static files (an index.html you can open directly).
5. Set the output directory — where the build writes its static files (dist for Vite, build for Create React App, etc.). For a blank build command, this is just the folder that contains your index.html (often the project root).
6. Watch the preflight notes. They're advisory and live: a native project (an .xcodeproj) is flagged as incompatible, an SSR framework is detected and built for the Worker tier, and a missing build output is a blocking error. The Deploy button stays disabled until the name is filled and no blocking issue remains.
7. Click Deploy. You'll see it move through detecting → building → packaging → uploading (with an upload percentage). On success the popover shows your live URL — https://lingcode.dev/apps/<id>/ for a static app, or https://<id>.run.lingcode.dev/ for a Worker/SSR app — with Copy and Open.

What happens under the hood

Knowing the pipeline makes failures obvious instead of mysterious:

• Build — if you gave a build command, the IDE runs it in your project folder (up to a 10-minute timeout) and streams the output. A non-zero exit stops here and shows the tail of the log, so a broken build never ships.
• Package — for a static app it checks the output has an index.html and tars + gzips its contents; for an SSR app it packages the Worker build (the framework's Cloudflare/OpenNext output).
• Upload — the archive is sent to LingCode Cloud. A static app's files are stored and served from the edge; a Worker/SSR app is deployed to Cloudflare's Workers-for-Platforms and its <id>.run.lingcode.dev hostname attached, HTTPS automatic. The new version is swapped in atomically, so visitors never catch a half-deployed site.

The result is a versioned, public app — what you build locally is what goes live.

Re-deploying, domains, and data

Re-deploy by clicking Cloud again on the same project and hitting Deploy — it updates the same app (same id, same URL), bumps the version, and keeps any attached domains. There's nothing to "promote"; the live URL always reflects your latest deploy.

Custom domain: right in the deploy popover there's a Custom domain section. Attach app.yourdomain.com (and optionally its www counterpart), point one DNS record at LingCode, and HTTPS is issued automatically. The full walkthrough — apex vs www, the exact records, and the Cloudflare proxy gotcha — is in Connect a custom domain to your Cloud app.

Data: a hosted front end that needs accounts or storage can be wired to a managed backend — the two compose cleanly.

Limits worth knowing

• 100 MB per app, 25 MB per file, 2,000 files max — generous for a built front end; if you blow past it you're probably shipping unoptimized media or a stray node_modules in the output dir.
• 25 apps per account and 12 deploys per hour — plenty for normal iteration; the rate limit just stops a runaway loop.
• Cloudflare V8 isolate, not Node — SSR apps run as Workers, so server-side rendering and API routes work, but a plain Express/Node server, a non-JS backend, long-running processes, or a single request over ~30s belong on a server you run (or move that logic into a managed backend + functions).

What's next