Quick-start
This page takes you from a built static site to a live URL. First, install the yourspace CLI — one line, no toolchain:
curl -fsSL https://yo.urspace.net/install.sh | sh
It drops a single binary in a directory you own and never asks for sudo. Want per-platform downloads or to verify the checksum yourself? The install page has both. Once yourspace --version runs, you're ready.
From there, the fastest path is yourspace setup from your project directory. It walks the whole flow — scaffold a config, paste an API token, ship the first deploy — in one continuous, bail-at-any-step sequence:
- init scaffolds a
yourspace.yml(the site name + the directory to ship). - login prompts for an API token and saves it under
~/.yourspace/token. - deploy bundles your built site, uploads it, and prints the live URL.
The sample below is one setup run end to end. The same three steps are also available as separate commands when you'd rather drive them one at a time, or for re-deploys after setup — see Driving the steps separately.
Prefer to read shell before any binary?
The install page's shell-script reference covers the lifecycle primitives (login, init, deploy, ls, status) as a single readable file — narrower than the binary, but auditable before you run it.
Before you start
You'll need a built static site — the output of npm run build, hugo, or whatever emits HTML + assets into a folder, usually dist/ or public/. The setup walk will hand you off to api.yo.urspace.net/tokens to mint an API token mid-flow; you don't need to do anything in advance.
Getting a token
Tokens are minted on the API — open api.yo.urspace.net/tokens, create one, and paste it when setup (or login) asks. During the alpha that's the one manual step; self-serve token management from your account is planned.
The fast path: yourspace setup
Run from inside your project directory. Setup walks you through naming the site, choosing the build output directory, pasting an API token, and shipping the first deploy — bailing cleanly at any step you want to defer. Re-running setup on an already-configured project keeps your yourspace.yml and resumes at whichever step is next.
$ cd my-blog && yourspace setup
Welcome to YourSpace! Let's get your site to the edge.
this walk takes you through 3 steps:
1. write a yourspace.yml for this project
2. add an API token (mint one + paste it here)
3. deploy your built site to the platform
Step 1/3 — site config
$ yourspace init
site name [my-blog]:
static output [dist]:
✓ wrote yourspace.yml
Step 2/3 — API token
no token saved yet. let's add one.
1. open https://api.yo.urspace.net/tokens in your browser and mint a token
2. paste it at the prompt below
Mint a token at https://api.yo.urspace.net/tokens, then paste it.
token: ys_live_••••••••
saved → /home/me/.yourspace/token
Step 3/3 — deploy
ship it now? [Y/n]: y
deployed my-blog (v1) at https://my-blog.yo.urspace.net
Setup complete. Updates from here: just `yourspace deploy`.
The walk wrote a yourspace.yml like this:
# yourspace.yml — generated by `yourspace init` # docs: https://yo.urspace.net/docs name: my-blog build: dist: dist
After the first deploy, future updates are a single command — yourspace deploy from the same directory. Setup is a first-time convenience, not a steady-state path.
Driving the steps separately
If you'd rather walk each piece by hand — say you're scripting against the API, or already have a token from another machine — the same three subcommands are available individually.
yourspace login
Saves an API token under ~/.yourspace/token so every subsequent command can authenticate against api.yo.urspace.net. Set YOURSPACE_TOKEN in the environment to skip the file (handy for CI).
$ yourspace login Mint a token at https://api.yo.urspace.net/tokens, then paste it. token: ys_live_•••••••• saved → /home/me/.yourspace/token
yourspace init
Walks you through a yourspace.yml. The site name defaults to the current directory; if a token is already saved, the API is probed so a collision surfaces now instead of at deploy time. Press enter to accept the defaults.
$ cd my-blog && yourspace init site name [my-blog]: ✓ my-blog is available static output [dist]: ✓ wrote yourspace.yml next step: run `yourspace deploy` to ship it
yourspace deploy
Bundles the directory named by build.dist, streams it to the API with yourspace.yml, and prints the live URL. Repeat any time to ship a new version.
$ yourspace deploy deployed my-blog (v1) at https://my-blog.yo.urspace.net
What deploy did
deploy tarred the directory named by build.dist, POSTed the archive with yourspace.yml as a multipart upload, and the API assigned a version and routed my-blog.yo.urspace.net at the bundle. The next deploy replaces the bundle, bumps the version, and the subdomain stays stable.
yourspace.yml is the whole contract: a site name, a directory to ship, and optional declarations for custom domains, redirects, SPA fallback, and per-route headers. Add them to the file and re-run deploy — the API reconciles the edge to whatever the latest file says.
Bundle size has two caps — 10 MB compressed and 25 MB unpacked by default — and the server rejects oversize uploads with a clear message naming the limit. See the CLI reference's bundle size limits section for details and how per-site exemptions work.
From here
- Init & routing — the fields in
yourspace.ymland how paths resolve. - Static sites — pointing
dist:at the build output your framework emits. - DNS & certificates — bind a custom domain, TXT-verify once, TLS is automatic thereafter.
- CLI reference — every command, flag, and environment variable.
- API & MCP — deploy from CI or an agent without the CLI at all.
Prefer to read the wire calls before trusting the binary? The install page's shell-script reference is a single readable file covering the lifecycle primitives.
Endpoints and the config shape may still shift before 1.0.