Build for GodspeedOS without learning its insides.

godspeed creates, builds, packages, signs and publishes software for GodspeedOS - for all four of its architectures at once - using only the OS's public contracts. You never touch the kernel, raw IPC or the supervisor.

$ godspeed new service hello
$ cd hello
$ godspeed build --all      # x86_64, aarch64, armv7, riscv64
$ godspeed publish          # signed, uploaded, installable as you/hello

Get started See what you can build

What you can build today

Godspeed has five kinds of project, and every one has a template. Each is a different answer to whose life the program lives; What you can make takes each kind from godspeed new to a Godspeed machine.

Service works

Kept running by the system: started at every boot, restarted if it dies, upgraded live if it declares handover.

godspeed new service clock

Utility works

Does one job when typed and ends with a status. It takes arguments and pipes like a built-in.

godspeed new utility greet

App works

Has the screen and the keyboard while it runs, and gives them back when it ends.

godspeed new app notes

Driver works

Drives one device, named by its PCI class or as a USB device, written on gs::driver like the OS's own drivers: its registers, its interrupt, DMA.

godspeed new driver sensor

Library works

Reusable no_std Rust for the others. Its tests run on your workstation.

godspeed new library parser

A service, a utility and an app build against GodspeedOS v0.29.0 or later; a driver against v0.30.0 or later for its registers, and the template, which uses its interrupt and DMA as well, against v0.31.0 or later. CI makes, checks and builds every kind for all four architectures, and the examples are built the same way.

Get started

Install Rust and the CLI

You need Rust - to build what you write - and this one binary:
```
# Linux or macOS
$ curl --proto '=https' --tlsv1.2 -sSf https://github.com/godspeedhq/godspeed-cli/releases/latest/download/install.sh | sh
# Windows (PowerShell)
> irm https://github.com/godspeedhq/godspeed-cli/releases/latest/download/install.ps1 | iex
```
Each installs a prebuilt binary for Linux, macOS or Windows (x86_64 or Arm64) to ~/.godspeed/bin, after checking it against the release's checksums - a mismatch installs nothing. godspeed self update updates it, with the same checks, and the CLI tells you, at most once a day, when there is a newer release. Or build it yourself: cargo install --git https://github.com/godspeedhq/godspeed-cli --tag cli-v0.4.0 --locked godspeed-cli.
Check your setup

No clone of the OS is needed. The CLI builds against a GodspeedOS release, and fetches the few small files that describe it - its pinned compiler, targets, linker script and contract schema - the first time, then keeps them.
```
$ godspeed doctor
Fetching the GodspeedOS 0.30.0 platform kit (once for each release)...
GodspeedOS                 ok       0.30.0 (platform kit from 9386b0aeb89f, cached in ~/.cache/godspeed/platform/0.30.0)
Rust toolchain             ok       nightly-2026-05-16
```
doctor checks the toolchain, all four targets and QEMU, and prints the command that fixes anything missing. Working on GodspeedOS itself? --os <path> builds against your checkout instead.

Create and build

$ godspeed new service hello
Created service hello in hello (GodspeedOS v0.30.0)
$ cd hello
$ godspeed check
service hello is valid against GodspeedOS v0.30.0.
$ godspeed build
Validating project...
Fetching dependencies...
Building hello for x86_64 (x86_64-unknown-none)...
Built x86_64 target/x86_64-unknown-none/release/hello
These are program binaries, not an OS image; nothing was installed or run.

It is an ordinary Rust project, so cargo fmt and cargo clippy work in it as usual, with the compiler the OS pins.

Package it, and look before anything leaves your machine

$ godspeed package
Verified alice/hello 0.1.0 (service), built against GodspeedOS 0.30.0
  contract.toml              sha256:762be027...
                 requests: log_write
  x86_64.elf        18952 B  sha256:2f3fa20d...
  aarch64.elf       78760 B  sha256:d0896436...
  armv7.elf         16644 B  sha256:b1443f11...
  riscv64.elf       30968 B  sha256:ba2ac5b2...
What the contract requests is not granted by installing it.

Publish

Make a signing key and a token once, then godspeed publish. Publishing walks through it.

What works, and what waits

The whole path works, from godspeed new to a program running on a Godspeed machine, against the live registry. What still waits needs something only the OS can provide, and the CLI will not paper over it.

Step	Status
Create, check, build every kind for every architecture	works
Test a library	works
Package, sign, verify; a `.gsp` file for a machine with no network	works
Publish, and fetch with every signature checked	works
A package that requires another (`[requires]`)	works the machine fetches, installs and starts what it needs first, on GodspeedOS v0.30.0 or later
`godspeed install` on a Godspeed machine	works at its `gsh>` prompt: the native package manager
Test a service, a utility, an app or a driver here	waits on the OS each runs only on a Godspeed machine
`godspeed run`	waits on the OS no public way yet to boot a machine with a program built outside the OS tree

Can I use C, C++ or Go?

Not yet. A Godspeed program today is Rust, because the only public way to talk to GodspeedOS is its Rust standard library, gs. Nothing else about the CLI is tied to Rust: a package is a contract plus one ELF per architecture, and the format does not care what compiled them.

C and C++ need a C interface to gs - a header and a library - and a freestanding compiler for each architecture. That is a plausible addition, and it is the OS's to define. Once it exists, the CLI gains a second way to build, and packaging and publishing stay exactly as they are.
Go needs much more: its runtime - scheduler, garbage collector, system interface - ported to GodspeedOS, which has no POSIX layer and no heap for services.

Until the OS defines one of those, the CLI does not offer a C, C++ or Go template: it would be one that cannot do what it promises.

How it behaves

Requests, never grants

A contract asks for authority. What a program is actually given is the operating system's decision, never the package's or the CLI's.

Every refusal is actionable

What failed, why, what was expected, and what to do next - with a distinct exit code for scripts and CI.

No invented certainty

If a publish times out, the CLI reads the registry and reports what it finds. "Outcome unknown" is an answer, not a failure.

No cloud lock-in

The CLI speaks the registry protocol, never a storage provider's API. A package can be hosted by any registry or mirror.