Merge to main.
It's live.

Every darting project can host its app itself — built from the default branch, served always-on with automatic HTTPS, redeployed on every merge. No pipeline to configure.

https://your-app.darting.app
  1. 01

    Merge

    Work ships from a thread as a pull request. When it lands on the default branch, the deploy kicks off on its own.

  2. 02

    Build

    darting builds the branch once in a fresh sandbox and stores the static output as an immutable artifact.

  3. 03

    Live

    Served always-on at your subdomain of darting.app — HTTPS automatic, zero cold start. Every later merge redeploys.

What runs on darting

Vite
SPA routes serve correctly
Astro
multi-page builds included
Create React App
classic React builds
Plain HTML
nested index.html pages too
Next.js
with output: 'export' only
worker/ backend
serves /api/* on the same host

SPA routes and multi-page builds with nested index.html files both serve correctly. App state lives in the browser, in a worker backend, or behind APIs the browser calls.

Small backends, included

Static isn't always enough. Give an app directory a worker/ folder and the deploy also ships a serverless backend answering every request under /api/* on the same host — no CORS, no separate service.

Hono-style fetch handler

worker/index.ts default-exports a Workers-runtime fetch handler — Hono works out of the box. Every request under /api/* on your host reaches it.

Durable state, no database to run

Declare a Durable Object in worker/wrangler.jsonc and it gets SQLite storage — small app state without provisioning anything.

Scheduled work

Declare cron triggers and export a scheduled() handler — darting fires it on schedule, even while nobody visits the app.

Backend secrets

API tokens the worker calls out with are set per-deployment and arrive as env bindings — never baked into the frontend bundle.

my-app/
├─ index.html static frontend
└─ worker/ optional backend
├─ index.ts fetch + scheduled handlers
└─ wrangler.jsonc Durable Objects, crons
GET https://my-app.darting.app → static files
ANY https://my-app.darting.app/api/* → worker

What it can't host

×Server-rendered frontends

Nuxt, Remix, SvelteKit without a static adapter — or Next.js without output: 'export'

×Node server processes

Express and friends — the backend lane is a Workers runtime, not Node

×External databases

no Postgres/MySQL — durable state lives in a Durable Object

×WebSockets

not yet supported through the deployed host — use fetch or SSE

The backend lane is a Workers runtime — when an app genuinely needs a Node server or a relational database, darting will say so before building, and you choose between rescoping and hosting elsewhere.

Good to know

Default branch only

Deploys build what has merged. Unmerged thread work doesn't ship until its PR lands.

Public env vars only

Only VITE_*, NEXT_PUBLIC_*, PUBLIC_* and REACT_APP_* reach the build. The output is world-readable — never bake a secret into the bundle.

Limits

5,000 files · 200 MB total · 25 MB per file

Ready when your work is

Ask your agent to deploy, or open Project Settings → Deployment and pick a subdomain. The first deploy takes one click; every one after that is just a merge.