Skip to content

What's new in 0.6.1

Published on 2026-10-04: Python SDK rayito 0.6.1, TypeScript SDK rayito 0.6.1 and rayd 0.6.1.

A fixes release on top of 0.6.0. None of them changes the public API, but three change a behavior worth knowing about: redeploying a stack, reincarnate() and processes that daemonize inside the sandbox. Upgrading is recommended for anyone using a 0.6.0 feature.

Redeploying a stack keeps its parameters

OptionalStacks.deploy() (and rayito stack deploy) on a stack that already exists updates it. Up to 0.6.0, each parameter you did not repeat went back to its catalog default: redeploying s3-mounts without Prefixes reopened the whole bucket, metadata-index without TableName replaced (and deleted) the table and secrets-access without KmsKeyArn removed kms:Decrypt.

Since 0.6.1, defaults only apply when the stack is created. When updating it, each parameter you do not pass and the stack already has is sent with CloudFormation's UsePreviousValue: it keeps the deployed value. To see what would change before deploying, parameter_changes() (TypeScript: parameterChanges()) does only a DescribeStacks:

from rayito import OptionalStacks

stacks = OptionalStacks(region="us-east-1")
for change in stacks.parameter_changes("s3-mounts", parameters={"ReadOnly": "false"}):
    print(change.name, change.before, "->", change.after)  # only ReadOnly
stacks.deploy("s3-mounts", parameters={"ReadOnly": "false"})  # Prefixes is kept
import { OptionalStacks } from "rayito";

const stacks = new OptionalStacks({ region: "us-east-1" });
const changes = await stacks.parameterChanges("s3-mounts", {
  parameters: { ReadOnly: "false" },
});
for (const change of changes) console.log(change.name, change.before, "->", change.after);
await stacks.deploy("s3-mounts", { parameters: { ReadOnly: "false" } });
rayito stack deploy s3-mounts --param ReadOnly=false
# prints the parameters that change (here only ReadOnly) before asking for confirmation

If you redeployed a stack with 0.6.0 without repeating all its parameters, review its configuration with rayito stack status <component> and deploy it again with the values you want.

reincarnate() reapplies all the 0.6 options

reincarnate() launches a successor with the same HOME when a sandbox approaches its 8 h cap (Persistence). In 0.6.0 it only forwarded gateways=, so the successor silently lost mounts=, events= and telemetry=. Since 0.6.1, create() remembers its 0.6 options and reincarnate() applies them in the successor's single ConfigureSandbox, resolved with the new sandbox's data:

Option In the successor
mounts= mounts each bucket again; reincarnate() does not return until all are mounted
events= derives a new events key from the new sandbox_id; it never reuses the original's
telemetry= uses the successor's image and memory in the resource attributes
gateways= rereads each Secrets Manager header; it never forwards an already-read value
size= not repeated: the size is already in the ARN of the image being relaunched

If a section fails in the successor, it is terminated (unless keep_on_failure) and the original sandbox stays alive, as with any other create() failure. No code to change: it is the same reincarnate().

rayd reaps zombie processes

rayd is the sandbox's PID 1. Up to 0.6.0, a process that daemonizes (double fork, nohup … & inside a subshell, a server that moves itself to the background) was left as <defunct> hanging off rayd for the whole life of the sandbox. With rayd 0.6.1, rayd reaps them as soon as they finish.

What this does not change:

  • The exit codes of your commands, terminals, kernels and mounts are never lost: rayd registers each of its own children before the reaper can see it, and the reaper only collects orphan processes that are not its own.
  • There is no new option and no cost: the reaper activates itself only when rayd is PID 1, on each SIGCHLD and every 5 s.

It needs an image with rayd 0.6.1: republish it (Images). With an earlier image, zombies use no CPU or memory, only an entry in the process table (Troubleshooting).

Other fixes

  • Webhooks: the deliverer's SSRF guard classifies an IPv6 that encapsulates an IPv4 (::ffff:100.64.0.1, from an AAAA record) as that IPv4, so the CGNAT range is blocked through that route too. To get it, redeploy the stack: rayito events deploy uploads the Lambdas' new code.
  • Messages: volumes= and domain= raise UnimplementedError with "todavía no disponible" ("not yet available"; it used to say "llega en 0.6", "arrives in 0.6"). rayito domain no longer appears in rayito --help, and rayito template, rayito stack and rayito events have help text on each subcommand.
  • TypeScript for CommonJS: "rayito" and "rayito/e2b" declare the types of each condition (import → .d.mts, require → .d.cts), so a CommonJS project with moduleResolution: node16 receives the types of the file it actually loads. Same files at runtime.
  • TypeScript: WorkdirStep is exported from rayito, as in Python.
  • Documentation: complete "Cost and activation" blocks for mounts/S3Mount and size, also in the IDE hover in TypeScript.

How to upgrade from 0.6.0

pip install -U "rayito[cli]"
pnpm add rayito@latest

Republish your image for rayd 0.6.1's reaper and redeploy the events-webhooks stack if you use it. Nothing else: the compatibility series is still 0.6 and a 0.6.1 SDK works with a rayd 0.6.0 image.

Full details: Changelog.