RaySpec v1.9.0

RaySpec 1.9.0 makes a RaySpec application something you can package, check, deploy, move and host
with others. An application becomes one signed-ready .ray bundle. You can inspect and verify the
bundle without running it, deploy it to a self-hosted target with a reviewed plan, export a whole
deployment as one encrypted file and import it somewhere new. The release also adds an opt-in
hardened posture for hosting a runtime that people you do not fully trust can reach.

If you only upgrade and set nothing new, your deployment keeps working as it did. Every new
protection is turned on by explicit configuration.

New commands

Command	What it does
rayspec pack	Builds a .ray application bundle from an application that is already built.
rayspec bundle inspect <file.ray>	Checks the archive and says what the bundle is. It runs nothing and writes nothing.
rayspec bundle verify <file.ray>	Everything inspect checks, plus the runtime, the target, the capabilities, the spec, a secret scan and the signature.
rayspec bundle sign <file.ray> --key-file <pem>	Writes the detached Ed25519 signature that bundle verify and deploy --require-signature check.
rayspec deploy <file.ray>	Deploys a bundle: a dry run prints a plan digest, and the deploy applies exactly that plan.
rayspec export	Moves a self-hosted deployment out as one encrypted migration bundle.
rayspec import	Restores a migration bundle into a new, empty target, with a private test period and a cutover.
rayspec resume	Lifts the source fence an interrupted export left.
rayspec tenant recover-owner	Gives an organization owner who has no password a one-time way back in.

Every existing command also accepts --json, which wraps its usual result in one envelope. Without
the flag the output is unchanged.

The hardened posture

Each part is off until you turn it on, and each can be turned on alone:

• Role separation and row-level security (RAYSPEC_MIGRATION_DATABASE_URL with the shipped role
  setup SQL). The process you start becomes a supervisor that alone holds the migration credential;
  the application is served by a child process that connects as a runtime role and cannot bypass
  the tenant policies.
• Single-tenant mode (RAYSPEC_SINGLE_TENANT=true). One organization per runtime; everyone else
  joins by invite.
• The managed posture (RAYSPEC_HOSTING_POSTURE=managed). Default execution bounds on every
  agent run, only the agent backend certified for public hosting (openai), required handler
  rights, no agent trace export by default, cross-process cancellation, and boot refusals for a
  host that would let the application reach the supervisor's credentials.
• Trusted proxies (RAYSPEC_TRUSTED_PROXIES).

A release carries a managed-posture receipt that names exactly which protections its certification
lane tested. It is evidence of tests, not a compliance certificate. The
threat model lists who
the posture defends against and every residual risk this release accepts.

Also in this release

• A release manifest, a release identity manifest and a CycloneDX SBOM of the published closure,
  attached to this release.
• A linux/amd64 runtime image definition, installed from a recorded lockfile. The image is built
  and tested for this release but not pushed to a registry yet.
• Three reference applications packed and deployed from their bundles, and a quickstart from
  npm install rayspec to a running application.
• A deterministic extraction provider for development and tests (not for production extraction).
• Log lines, error envelopes, receipts and traces are redacted.
• Node >=22.21.0.

Known limitations

• The runtime is not a sandbox. Handlers and extensions run inside the serving process and can
  read what it holds. Contain untrusted code with a VM or container boundary, its own databases and
  host egress rules.
• No egress enforcement and no encryption at rest in the runtime. Applications declare the hosts
  they call; the host network policy must enforce it. Disks and backups need their own encryption.
• A removed member keeps read access until their access token expires (480 seconds by
  default). Writes, run starts and administrative actions recheck at once.
• The workflow system database is outside row-level security.
• The anthropic, codex and pi backends are not certified for public hosting; the managed posture
  refuses them.
• The supervisor and the application run as the same OS user. On a managed host the boot refuses
  unless ptrace_scope is 1 or more, the hard core-file limit is 0 and the privileged connections
  are passed inline. Running the child as a separate user is not offered yet.
• Export refuses an application whose extension provides its own blob backend. An application
  with extensions exports after one bundle deploy with 1.9.0.
• Restoring a paired backup is a documented operator procedure, not a command.
• A stream ingest route has no body size cap of its own; cap request bodies at the reverse proxy.
• The image's third-party packages are resolved when the image is built, so their versions can
  differ from the workspace lockfile; the image SBOM lists what the image holds.
• A rebuild of the same commit is not byte-identical; verify a release against its own published
  tarballs and image archive.
• Advisories against three packages (undici, brace-expansion, protobufjs) pinned by the Pi agent
  SDK's own shrinkwrap remain open for consumers, 22 in all, recorded as dated scanner exceptions
  that expire on 2026-10-31.
• The bundle contract is revision 1.0.0-rc.2. It is frozen by the Core team; joint
  ratification with the Cloud team is still open, and a change they ask for would come as a new
  contract revision.

Upgrading

From 1.8.x, read
Upgrading to 1.9
and the
upgrade notes in the changelog.
In short: check Node is 22.21.0 or later, take a backup (the first boot runs six additive platform
migrations; going back to 1.8.x is unsupported and must start from that backup, because a 1.8.x
runtime does not detect a database 1.9.0 has migrated and boots on it), upgrade, and start as before. If you
deploy bundles, repack them with the new CLI.

Verifying this release

The 34 packages on npm are the tarballs attached here, byte for byte. Check them against the
attached identity manifest with scripts/release-identity.mjs --verify, as described in
Releasing → Verifying a release.
The attached release manifest names the same tarballs by digest. For this release it is not signed,
the packages carry no npm provenance attestation, and the runtime image is not published.