Deploy from the CLI

Point the CLI at your build output and give the site a name with --site. The site name is a DNS label — lowercase letters, digits and hyphens, 1–63 characters — and it becomes your subdomain.

$ one9x pages release ./dist --site mysite --deployhashing ./dist … 248 filesuploading … 41 changed, 207 unchanged✓ v8 live in 1.4s→ https://mysite.one9x.app/

The CLI hashes your files locally and uploads only the ones that actually changed since your last release, so the first push is quick and every push after is quicker — an unchanged re-release uploads nothing. The new version goes live in a single atomic flip: visitors are served either the old version or the new one, never a half-uploaded mix. The full mechanics are in How deploys work.

--deploy is what makes it live. Leave it off and you get a staged release with a preview URL instead.

What gets uploaded

Everything in the directory except dot-paths — .git, .env and anything else beginning with a dot stays on your machine. .well-known is the one exception, because it’s a reserved public path: assetlinks.json and apple-app-site-association only work at that exact URL, so Android App Links and iOS universal links verify.

To hold anything else back, pass --exclude with a glob. It repeats, and each pattern is matched against the path relative to your directory and against the file name — so '*.map' catches source maps at any depth, while 'admin/*' stays where you wrote it. Excluding a directory drops everything under it. Quote the pattern, or your shell will expand it first.

$ one9x pages release ./dist --site mysite --deploy \  --exclude '*.map' --exclude admin12 path(s) excluded✓ v9 live

Patterns are single-segment path.Match globs. ** is not supported — a pattern like 'admin/**/*.map' matches nothing rather than erroring. Match on the file name ('*.map') or exclude the directory (admin) instead.

Choosing the site

--site accepts more than the subdomain: a site name, a full platform host, a custom domain you have linked, or a numeric id all resolve to the same site. Use whichever you have to hand.

If the site does not exist yet, create it first — one9x pages create mysite — or make one in the dashboard. A release will not conjure a site, because a typo in --site would then silently publish your build to a brand-new address instead of the one you meant.

Deploying the same content twice

Re-releasing a folder that has not changed is free and safe: the version id is the content hash, so an identical build produces an identical version and nothing is uploaded. That matters most in CI, where a README-only commit still triggers the job.

Build your command

There is an interactive builder for one9x pages release on the HTML version of this page — tick what you need and copy the result. Every flag it offers is in the CLI reference, which is the complete list either way.