Deploy from the dashboard

You can deploy an app without installing anything. Open the app in the dashboard, then Deploy, then Upload. It’s on every plan, for anyone who can edit the app: its editors and owners, and the workspace’s owners and admins.

An upload always goes live. To try a version first at an address of its own, put up a preview with jiayang deploy --preview instead.

A static site

Choose a folder, or a .zip of one, with an index.html at the top. It’s served as it is, and nothing is built: if your site has a build step, run it first and upload what it writes, such as dist.

The browser does what jiayang deploy does with a static site:

• It leaves out hidden files and folders (apart from .well-known), node_modules, and names other hosts read as settings, such as _worker.js and _routes.json.
• It leaves out what an .assetsignore file at the top of the site lists, such as drafts or *.psd. Nothing it lists is read or uploaded.
• It stops the deploy at a file that looks like a credential, by its name (.env, *.pem, *.key, id_rsa and the like) or by what’s in it. Everything in a site is served to everyone who can open the app.
• It names each file by the SHA-256 of its bytes, asks which ones the app doesn’t have yet, and uploads only those. A redeploy of a big site sends what changed.
• It sends the lock files and the .jiayang-allow at the top of the folder for the deploy’s scan, and says what the scan found once the version is live.
• A top-level 404.html is the site’s page for a missing path, unless it’s a copy of index.html.

When you pick a folder, the folder’s own name isn’t part of the paths. A .zip made from a folder usually has that folder inside it, and that comes off too.

A browser hands over a folder’s files without saying which were symbolic links. Chrome and Edge leave links out, as the CLI does. Other browsers may follow a link to the file it points at, wherever that is on your computer, and upload it. For a folder with links in it, choose a .zip of it instead, which is refused if it holds a link, or deploy it with the CLI.

What a .zip may hold

The .zip is read in the browser before anything is uploaded, and refused whole if:

• a path in it climbs out with .., starts with / or a drive letter, or has a backslash or a control character in it,
• it holds a symbolic link,
• it is encrypted, split across files, in the ZIP64 format, or compressed with anything but ordinary deflate, or
• it would unzip to more than a site may be: 20,000 files, 25 MiB for one file, or 256 MiB in all.

Those sizes are checked from what the .zip says about itself, before a byte of it is unzipped, and a file that unzips to more than it said is stopped there. If yours is refused for its format, zip the folder again with your system’s own zip, or deploy it with the CLI.

A Worker you built

For a Worker, choose the bundled entry module your build wrote, a .js or .mjs file, and any modules it imports beside it: .mjs, .wasm, or text such as .html and .json. Each goes up under its file name, which is how the entry imports it. They can come to 32 MiB.

Nothing is bundled or built in the browser. If the entry imports a package that isn’t one of the modules you picked, the version fails as it goes live and says which. For a Worker that needs a build, use jiayang deploy, which runs wrangler for you.

Container apps can’t be uploaded from the browser, since they are an image built with Docker. Deploy them from a terminal or an agent.

When it goes live

The tab shows each step as it goes: reading and checking the files, uploading, then the new version going live. When it’s live it says which version, with a link to it in Versions. A version that fails says why, the same as the CLI would, and the version before stays live.

Deploys from the dashboard are logged under your name, like any other deploy, and can be rolled back the same way.