Skip to content
docs

Quick-start

This page takes you from a built static site to a live URL. First, install the yourspace CLI — one line, no toolchain:

install
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.yml and 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.