📘 Reference ● Deploy Updated 2026-06-11

App hosting

TL;DR: LingCode Cloud hosts the apps you build, so there's no server to run. Two kinds of deploy: static frontends (a built Vite/React bundle) served at https://lingcode.dev/apps/<app-id>/, and full-stack Worker/SSR apps served at https://<app-id>.run.lingcode.dev/. Both ship from the IDE with one click — Deploy to LingCode Cloud. The Worker runtime is a Cloudflare V8 isolate, not Node.js, which is the one constraint worth understanding before you start.

This page is about where your built app lives once it's done — the frontend you ship to users and, when you need it, the server that renders or routes requests for them. It is not about the managed backend (database, auth, storage, functions); that's a separate, complementary thing, and most server work belongs there. We'll cover both deploy targets, the runtime constraint that trips people up, custom domains, and — honestly — what hosting is not for.

Why host it here at all

When you build an app in LingCode, the output is files: an index.html with some hashed JS/CSS, maybe a server bundle. Those files have to live somewhere with a public URL and HTTPS before anyone else can use them. The usual answer — rent a box, install a runtime, configure a web server, renew certificates — is a lot of undifferentiated work for "put my app on the internet."

LingCode Cloud collapses that into a single action. You click Deploy to LingCode Cloud, the IDE builds and uploads the app, and the server publishes it behind automatic HTTPS. You get back a live URL. There's no server for you to keep patched and no certificate to renew.

Two kinds of deploy

LingCode looks at what you built and picks the right target. The difference comes down to one question: does your app need to run code on the server for each request?

	Static frontend	Full-stack Worker / SSR app
What it is	A built Vite/React (or similar) bundle — `index.html` plus hashed assets. No server-side rendering.	A TanStack Start, OpenNext, or Cloudflare Workers app that renders or routes on the server.
Served at	`https://lingcode.dev/apps/<app-id>/` — path-based, with SPA fallback.	`https://<app-id>.run.lingcode.dev/` — its own subdomain.
Runtime	None — files served straight from the edge.	A Cloudflare Worker (V8 isolate), not Node.js.
Limits	≤100 MB total, ≤25 MB per file, ≤2000 files. 12 deploys/hour.	≤60 MB bundle. 12 deploys/hour. Up to 10 worker apps.
Custom domains	—	Supported, with full automatic TLS.
Reach for it when	Your app is a single-page app that talks to the backend (or third-party APIs) from the browser.	You need server-side rendering or a custom server route at request time.

For a static frontend, the rate limit is 12 deploys per hour per user, and the bundle must stay under 100 MB total, 25 MB per file, and 2000 files. For a Worker app, you also get 12 deploys per hour, the bundle must stay under 60 MB, and you can run up to 10 worker apps at once — try to publish an eleventh and the deploy returns cap_reached.

The runtime constraint that matters

This is the single biggest gotcha, so it's worth being precise. A full-stack app on LingCode Cloud runs as a Cloudflare Worker — a V8 isolate, not a Node.js process. A V8 isolate is a sandboxed JavaScript runtime that starts in milliseconds and has no operating system underneath it. That makes it fast and cheap to run at the edge, but it also means a chunk of the Node standard library simply isn't there.

In practice, inside a Worker you do not have:

fs — no reading or writing files on a local disk (there is no disk).
path — the filesystem-path helpers aren't available.
child_process — you can't spawn subprocesses or shell out.
Native modules — anything compiled against Node's C++ ABI won't load.

The concrete consequence: a plain Express/Node server will not run as-is. If your full-stack app is "an Express app," it has to be ported to something that targets the Worker runtime — Hono, TanStack Start, or a framework wired through an OpenNext adapter. These give you the same request/response handler model without depending on Node-only APIs.

The mental model: requests in, responses out

A Worker is a function that takes a Request and returns a Response. That's the whole shape. Anything that fits that shape — render a page, handle a form POST, verify a webhook — works beautifully. Anything that doesn't fit it (hold a connection open, run a loop in the background, touch the disk) belongs somewhere else. Hold that picture and most of the constraints below stop being surprises.

How you deploy

Deploying is a Mac-app action, not an agent or MCP tool — you don't ask the agent to do it, you click a button. In the LingCode IDE, open the app you've built and click Deploy to LingCode Cloud. From there the IDE:

Builds the app (runs your production build).
Uploads the output to the LingCode Cloud server.
Publishes it. For a static app that means serving the files at /apps/<app-id>/. For a Worker app, the server runs the deploy to Cloudflare's Workers-for-Platforms and attaches the <app-id>.run.lingcode.dev hostname, with HTTPS provisioned automatically.

When it finishes, you get back a live URL you can open or share. For a full walkthrough with screenshots, see Deploy to LingCode Cloud.

What the build must produce

The deploy publishes your build output, so the output has to be in the shape each tier expects. You rarely hand-write this — a standard Vite/framework config produces it — but knowing the shape is how you read a failed deploy.

Static apps

A normal production build into a dist/ folder: an index.html plus hashed assets under dist/assets/. Single-page apps work — unknown paths fall back to index.html. Stay under the caps (100 MB total, 25 MB per file, 2000 files). Nothing special is required; vite build or your framework's static export is enough.

dist/
  index.html
  assets/
    index-a1b2c3.js
    index-d4e5f6.css

Full-stack Worker / SSR apps

A Worker deploy expects the Cloudflare build layout — a dist/server/ with a wrangler.json next to the server entry. That file is emitted by the Cloudflare Vite plugin; if it's missing, the deploy fails with no_build_config (see Troubleshooting). A minimal Vite config that produces it:

// vite.config.ts
import { defineConfig } from 'vite';
import { cloudflare } from '@cloudflare/vite-plugin';

export default defineConfig({
  plugins: [cloudflare()],
});

The build then emits both halves — the client assets and the server bundle plus its wrangler.json:

dist/
  client/        # static assets, served from the edge
  server/
    index.js     # your Worker (V8 isolate — NOT Node)
    wrangler.json

For Next.js, use the OpenNext Cloudflare adapter (@opennextjs/cloudflare) rather than the Node output — it produces the same Worker-shaped build that the deploy understands. Either way the rule from the section above still holds: it runs as a V8 isolate, so no fs, path, or native modules.

Reading a failed deploy

no_build_config means the Worker layout wasn't produced — your build ran as a plain Node/static build, so add the Cloudflare plugin (or the OpenNext adapter) and rebuild. bundle_too_large means the server bundle is over 60 MB — trim dependencies. cap_reached / rate_limited are account limits (10 apps, 12 deploys/hour). Full list in Troubleshooting.

Custom domains

You can put your own domain in front of a hosted app instead of the default *.run.lingcode.dev URL. The setup is a single DNS change pointed at the LingCode edge:

A CNAME record to apps.lingcode.dev, or
An A record to 138.197.107.228.

Keep the record DNS-only / unproxied (if your DNS provider offers a proxy toggle, leave it off) so the edge can complete the TLS handshake. Certificates are then issued automatically, on-demand — there's nothing to upload or renew. Step-by-step instructions are in Connect a custom domain.

What hosting is not for. The Worker model is request/response, and it has real edges. Hosting is the wrong home for: long-running processes, background job queues, persistent WebSocket servers, or any single request that runs longer than ~30 seconds. Those need a server you run yourself. For everything else, the request/response Worker — combined with the managed backend for data, functions, and storage — covers it.

Where server logic should go

Prefer the backend; reach for a Worker only when you must

For most server work, the managed backend is the better home: keep secrets in the vault, put vendor calls and trusted logic in functions, and keep data in the database. That covers the large majority of "I need this to run on a server, not in the browser" cases without you owning any infrastructure.

Reach for a full-stack Worker app specifically when you need request-time server rendering or a custom server route. For example: a Stripe webhook handler that must verify a raw request body belongs as a route inside your hosted Worker app — it needs the unparsed request that a builtin function doesn't hand you. That's the line. Server rendering and custom request handling → Worker app; secrets, vendor calls, and data access → backend.

Putting it together

A typical shipped LingCode app uses both halves of the platform. The frontend — whether a static SPA at /apps/<id>/ or a server-rendered app at <id>.run.lingcode.dev — is what users load. Behind it, the database, functions, and storage do the data and trusted work. Hosting puts your app on the internet; the backend gives it something to do. Build, click Deploy to LingCode Cloud, and (optionally) point a domain at it — that's the whole loop.

Compute