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 front end: the built HTML, CSS, and JavaScript of a web app, served from LingCode's edge at a real URL. 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 — deploy a static front end here, and (optionally) point it at a managed backend for data.

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 what it deliberately doesn't (server-side code)
• 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: static hosting, one button

LingCode Cloud apps serve pre-built static files. Whatever your project compiles down to — a single index.html, or a Vite/React/Svelte/Vue build that emits an HTML file plus JS/CSS chunks and assets — those files are what get hosted. There is no server process running your code on the other side; requests are answered by serving files, with a single-page-app fallback (unknown paths serve index.html so client-side routing works). That's the right model for landing pages, docs, dashboards, games, and SPAs. It is not the model for an Express/Next-SSR server that needs to run Node per request — for that you either deploy the server elsewhere or give the static front end a managed backend for its data.

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 ("LingCode Cloud hosts static web apps"), a Node server/SSR project gets a heads-up that only its static build can be hosted, and a missing index.html in the 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>/ — 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 — it checks the output directory has an index.html at its root, then tars + gzips the contents of that directory.
• Upload — the archive is sent to LingCode Cloud, unpacked, and each file is stored and served from the edge. The new version is swapped in atomically, so visitors never catch a half-deployed site.

The result is a versioned, public app. Because hosting is file-based, what you see locally after a successful build 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.
• Static only — no server-side execution. If your app needs server logic, give it a managed backend rather than expecting Node to run here.

What's next