For developers and publishers

Build, publish, and run space software.

Build an image and run it on your laptop — no backend, no account. When you need a machine you do not have, one command sends the very same run to a hosted one. Publish an app and it appears in the catalogue for buyers to order.

Release capsule

north-sea

One hosted deployment started from an OCI image.

Running

Image

ghcr.io/acme/payload:latest

Context

run.space

Status

healthy

Logs

streaming

space login run.spaceOIDC session active
space context use run.spaceHosted scheduler selected
space run --name north-seaWorkload instance created
space logs north-sea --followSSE stream attached
hosted run
$space login run.space
$space context use run.space
✓ Context saved
✓ Account portal@example.com
$space run --name north-sea ghcr.io/acme/payload:latest
✓ Deployment d-north-sea created
✓ Logs available in the portal
$space logs north-sea --follow
What it is

One CLI across laptop and hosted runners.

The local loop stays local: build an image, run it on your machine, read its logs, and stop it — no account, no backend, nothing to provision. When you need a machine you do not have, one command sends the very same run to a hosted one.

Everything the CLI creates — projects, images, workloads, logs, volumes, keys and builds — is there in the browser, for you and anyone you share the project with.

Developer laptop

Local context

Build and run without login, a backend, or extra credentials.

space

loginOIDC browser or device flow
contextlocal or hosted backend
runStart an OCI image
psList deployments
logsRead or follow output
buildInspect recorded builds

Hosted runner

Cloud context

Run exactly what you ran locally, on a machine your team can reach.

Local first

The laptop workflow needs no account and no backend.

One set of commands

Going hosted changes where the work runs, not how you run it.

Signed on the way out

Every build is signed and every run recorded, without being asked.

On your machine

Everything you need to build and try it.

  • Images, workloads and logs stay on the one machine that made them.
  • Nobody else can open the run you want a second opinion on.
  • The hardware you can reach is the hardware you own.
  • An order needs somewhere to live once it leaves your desk.
With run.space

The same commands, somewhere your team can reach.

  • Sign in once; the CLI gets a token scoped to what you chose.
  • Projects, images, builds, volumes and keys are shared with the people you work with.
  • Open any workload and read its output and logs as it runs.
  • A page with nothing to show says so, instead of showing you a sample.

Runner

Run the images you already build.

  • OCI images from any registry, public or private
  • Named workloads with their output and logs kept
  • Volumes and keys that belong to one project
  • Every build and image recorded, so you can go back

Dashboard

The same work, in a browser.

  • Your projects and what is running in each
  • Logs as they arrive, without tailing a file
  • Order from the catalogue and watch the run start
  • Only ever your own account's resources
Standards

The cloud surface follows the current SpaceOS contracts.

CapabilitySpecification
AuthenticationOIDC browser and device-code flows
Contextlocal plus hosted API bindings
RunnerOCI image execution
LogsSSE-backed deployment output
ImagesRegistry-backed image references
VolumesProject-scoped storage
KeysProject-scoped capability keys
BuildsRecorded build inventory
DashboardServer-rendered portal pages

Try it in five minutes.

Sign in, select the hosted context, start an image, and inspect the deployment from the portal.

Read the docs