SecondBox v0.19.0

SecondBox v0.19.0

Deployment boundary

Sandboxes now survive releases that ship a new execution bundle. Profile revisions no longer name runtime and toolchain bundle digests; every Instance boots the signed bundle its home Runner verified at startup. This release keeps Runner protocol generation 5 and public API v1 and adds migration 0031_profile_execution_assets_unpinned to the v0.15.0 baseline. Deployments from v0.14.0 onward update in place, including across the v0.17.0 bundle change that previously required a clean reinstall. Existing Sandboxes keep their Workspaces and Profile revisions and start on the new bundle. The guided updater refuses sources older than the v0.14.0 migration baseline before activation.

Update the control plane and all Runners together. A v0.19.0 control plane sends default-image Assignments without asset references, which earlier Runners reject; a v0.19.0 Runner rejects the asset references earlier control planes send.

A bundle upgrade changes the guest software every Sandbox sees, as any base-image upgrade does. Workspace content built against the previous guest, such as virtual environments bound to an older interpreter, may need rebuilding.

Profiles and resources

• ProfileRevisionSpec no longer has runtimeBundleDigest or toolchainBundleDigest; requests that send them are rejected. The migration removes both fields from recorded revisions.
• Standard Profiles keep their revision numbers, and installed histories from v0.14.0 onward converge with the release lineage. Their spec digests change because the specs no longer contain bundle digests. Update pinned standard spec digests from this release's artifact manifest.
• Declarative resource documents written for earlier releases must drop both fields and recompute each revision's specDigest. secondbox resources check reports the computed digest of a mismatched revision; see declarative resources.
• Client-selected execution images keep their signed runtime and toolchain component identities.

Deployment configuration

The control plane no longer reads a signed-asset catalog. Remove deployment.signed_asset_catalog from secondbox.toml; the strict decoder rejects it. SECONDBOX_SIGNED_ASSET_CATALOG_PATH, the Compose catalog mount, and the installer-written secrets/signed-assets.json are gone. An updated guided installation leaves its previous catalog file for purge.

Placement and Runners

Placement requires a verified materialization for the Runner's backend rather than exact bundle digests, and no longer ranks Runners by cached artifacts or matches guest protocol generations. Firecracker, gVisor and Microsandbox boot their installed bundle for default-image Assignments and reject asset references unless the Assignment selects an image.

Firecracker bundle and trust anchor

The release retains the signed secondbox-0.17.0 Firecracker bundle and the v0.12.0 RSA trust anchor.

Distribution

The default lean release qualifies Firecracker and local gVisor and publishes Linux amd64 OCI images. CLI and deployment binaries ship for Linux and macOS on amd64 and arm64. Standard bundle documents use secondbox.standard-bundle/v4; release verification binds bundle documents by digest, so this updater still authenticates releases published with v3 documents. The public API remains v1 and the Runner protocol window remains [5,5].

Install the TypeScript SDK with npm install @secondstack-ai/secondbox@0.19.0.
The Go module is github.com/SecondStack-AI/SecondBox@v0.19.0.

Install

Guided Linux amd64 install:

curl -fsSL https://github.com/SecondStack-AI/SecondBox/releases/download/v0.19.0/install.sh | sh

SDKs: npm install @secondstack-ai/secondbox@0.19.0 and go get github.com/SecondStack-AI/SecondBox@v0.19.0

SecondBox v0.18.1

SecondBox v0.18.1

Deployment boundary

This release keeps Runner protocol generation 5, public API v1, the v0.15.0 database migration baseline, standard Profile revisions, and the signed secondbox-0.17.0 Firecracker bundle and RSA trust anchor unchanged. It adds one optional Runner capability field within the existing protocol generation. Deployments already on v0.18.0 can update the control plane and Runners in place; no data migration or Sandbox recreation is required. Update the control plane and all Runners to the same release before enabling physical storage admission. Existing Runner configurations remain in logical mode unless the operator explicitly selects physical. Deployments older than v0.18.0 must first cross the boundaries in the earlier release notes.

Physical storage admission

Firecracker and gVisor Runners, including the reference Kubernetes pod, can opt into physical storage admission. In this mode, the control plane no longer rejects home placement or assignments because the sum of logical Workspace limits exceeds a Runner's advertised aggregate disk capacity. The Runner probes actual usage of its Workspace filesystem and denies new Workspaces and starts at its configured threshold; admission reopens only at the lower recovery threshold, and probe failure denies admission. Per-Sandbox Workspace size, CPU, memory, instance, operation, and Tenant/Subject Sandbox-count limits remain active.

For a manifest-managed Firecracker Runner, set storage_admission_mode = 'physical' in its [[runners]] block. For a gVisor host or pod Runner, set SECONDBOX_RUNNER_STORAGE_ADMISSION_MODE=physical and explicitly set SECONDBOX_RUNNER_STORAGE_PRESSURE_RECOVERY_PERCENT, ..._WARNING_PERCENT, and ..._ADMISSION_DENY_PERCENT such that 0 < recovery < warning < deny < 100. The reference gVisor pod manifest contains these fields for the operator to fill. With logical, gVisor retains its previous aggregate disk reservation behavior. See Firecracker operations and gVisor operations.

This mode permits logical overcommit. A full filesystem can interrupt guest writes or cause Kubernetes storage pressure or eviction before a Sandbox reaches its own Workspace limit. Monitor the underlying Workspace volume and retain enough headroom for the workload.

Qualification

The scenario image fetcher now requires SECONDBOX_SCENARIO_IMAGE_FETCHER_DNS, an explicit DNS server address reachable from its isolated Docker network. Set it in the qualification or release operator environment when running the selected-image scenario. This changes qualification setup only; deployed Runner DNS settings are unchanged.

Firecracker bundle and trust anchor

The release retains the signed secondbox-0.17.0 Firecracker bundle, component identities, and RSA trust anchor from v0.18.0. Existing pinned Profiles remain valid; no replacement bundle is required.

Distribution

The default lean release qualifies Firecracker and local gVisor and publishes Linux amd64 OCI images. CLI and deployment binaries ship for Linux and macOS on amd64 and arm64. The public API remains v1 and the Runner protocol window remains [5,5]. The default tier does not claim Kubernetes pod scenario evidence.

Install the TypeScript SDK with npm install @secondstack-ai/secondbox@0.18.1.
The Go module is github.com/SecondStack-AI/SecondBox@v0.18.1.

Install

Guided Linux amd64 install:

curl -fsSL https://github.com/SecondStack-AI/SecondBox/releases/download/v0.18.1/install.sh | sh

SDKs: npm install @secondstack-ai/secondbox@0.18.1 and go get github.com/SecondStack-AI/SecondBox@v0.18.1

SecondBox v0.18.0

SecondBox v0.18.0

Deployment boundary

This release keeps Runner protocol generation 5, the public API v1, and the v0.15.0 database migration baseline.
It adds no migration, changes no standard Profile revision, and ships the signed secondbox-0.17.0 Firecracker bundle unchanged.
A v0.17.0 Firecracker deployment can update in place with the guided updater; no reinstall is necessary.
Stop active Sandboxes and take a coordinated database and Runner-storage backup before the update.
Update the control plane, every Runner, and the image fetchers to the same release.
Deployments older than v0.17.0 must first cross the boundaries in the v0.17.0 notes and the earlier release notes.

Breaking for gVisor operators. Every gVisor Runner now requires a running image fetcher, a reflink-capable execution image cache, per-Tenant registry configuration, and the execution image publisher key. A gVisor Runner started without them, or whose cache filesystem cannot reflink, refuses to start. Deploy the fetcher and configuration beside each gVisor Runner before updating it. There is no fixed-assets-only gVisor mode.

Firecracker bundle and trust anchor

This release ships the retained signed secondbox-0.17.0 Firecracker bundle, component identities, and RSA trust anchor without change.
The runtime and toolchain component-manifest digests that Profiles pin are the same as in v0.17.0 and are recorded in the v0.17.0 notes.

Client-selected execution images on gVisor

gVisor Runners now launch client-selected execution images.
An application that selects a signed image on every create and start, such as an agent platform, runs on Linux hosts and Kubernetes nodes without KVM.
The gVisor Runner consumes the same signed OCI artifact the Firecracker Runner boots, so an application publishes one image for both backends.

• Retrieval, the registry allowlist, per-Tenant registry authorization, and the publisher signature and fingerprint checks are the implementation Firecracker already uses.
• Only the image's signed rootfs.ext4 is used. The Runner reflinks it into an unnamed per-Instance clone and mounts it as the sandbox root. The Runner's pinned runsc and guest agent launch the Sandbox; the image's kernel, shared.img, and embedded agent are ignored. The materialization's agent must speak the image's guest protocol generation and every mandatory guest feature the image signs.
• As under Firecracker, guests may write anywhere in that root. The writes stay in runsc's in-memory overlay, count against the Instance memory limit, and vanish when the Instance stops. The cached image is never modified. The fixed flat root remains read-only to the guest.
• gVisor Runners report client-selected-image readiness, so they receive images:prepare targets and selected-image placement. The runner protocol and control plane are unchanged.

See client-selected execution images and gVisor runtime.

Required gVisor Runner settings

Every gVisor Runner states these values explicitly; they have no defaults:

Setting	Value
SECONDBOX_RUNNER_EXECUTION_IMAGE_CACHE_ROOT	Absolute cache directory shared with the fetcher, on a Btrfs or XFS filesystem with reflink support, disjoint from SECONDBOX_GVISOR_RUNTIME_DIR.
SECONDBOX_RUNNER_IMAGE_FETCHER_SOCKET	The fetcher's private Unix socket, in a directory shared only with the Runner.
SECONDBOX_RUNNER_EXECUTION_IMAGE_PUBLIC_KEY	The execution image publisher's PEM public key.
SECONDBOX_RUNNER_EXECUTION_IMAGE_PUBLIC_KEY_SHA256	The SHA-256 of that key's DER encoding, pinned independently.

Run secondbox-image-fetcher from the same runner-gvisor release image as a separate unprivileged process (UID 10002 in the reference pod), without Workspace mounts, host devices, or privileges. Configure its SECONDBOX_IMAGE_FETCHER_* inputs as for Firecracker: the socket, the cache root, the per-Tenant registry configuration (tenants.json, token or Docker login files, and optional certificates/<registry-host>/ca.crt), the registry allowlist, the publisher key and fingerprint, and the download, expanded, and cache byte limits. The fetcher refuses world-readable registry credentials. A cold retrieval reserves twice the download limit plus the expanded limit on the cache filesystem.

The reference pod runner/deploy/gvisor-runner-pod.yaml now runs an unprivileged image-fetcher container beside the runner, with a node-local cache hostPath, a pod-local socket emptyDir, the registry configuration as a Secret, the publisher key as a ConfigMap, and fsGroup: 10002.

Distribution

The runner-gvisor image now includes secondbox-image-fetcher and Skopeo.
The default release tier qualifies Firecracker, local gVisor, and the Btrfs-image installer guest and publishes Linux amd64 container images. This release's default tier carries no pod evidence. Before merge, the nightly tier qualified the gVisor host and the reference pod on a no-KVM K3s node, including a selected image, at #173 commit 7fbc893, whose tree is identical to the released merge. CLI and deployment binaries ship for Linux and macOS on amd64 and arm64. The public API remains v1; the Runner protocol window is [5,5].

Install the TypeScript SDK with npm install @secondstack-ai/secondbox@0.18.0.
The Go module is github.com/SecondStack-AI/SecondBox@v0.18.0.

Install

Guided Linux amd64 install:

curl -fsSL https://github.com/SecondStack-AI/SecondBox/releases/download/v0.18.0/install.sh | sh

SDKs: npm install @secondstack-ai/secondbox@0.18.0 and go get github.com/SecondStack-AI/SecondBox@v0.18.0

SecondBox v0.17.0

SecondBox v0.17.0

Deployment boundary

This release ships a new signed Firecracker bundle containing the guest file-error fix. Its runtime and toolchain component-manifest digests change. The guided updater refuses that change because existing Sandboxes remain pinned to immutable Profile revisions. Existing deployments must retire their Sandboxes, install this release with a fresh database and separate Runner storage root, then recreate resources. Do not overwrite an existing bundle or reconstruct Workspaces. Keep the previous deployment, database, storage, assets, and credentials together for rollback. See the deployment procedure.

The public API remains v1, Runner protocol generation remains 5, and the v0.15.0 database migration baseline is unchanged. The RSA trust anchor from v0.12.0 is retained; verify it independently against the fingerprint below before installing the new bundle. Update the control plane, every Runner, image fetchers, signed asset catalog, and standard resources together.

Firecracker bundle and trust anchor

The signed secondbox-0.17.0 bundle uses the retained 6.12.94 kernel and RSA trust anchor. It is built from source commit 5e3cf943e30b89db6e024278c8d795b0c35c33a5, which contains the guest change in #168. The canonical public-key DER SHA-256 remains:

59c127f459b8c93ca422f2f6c5bd43ff1e17d50309a262b7aff1b07bf59a5ced

The independently verified bundle identities (SHA-256) are:

Manifest	Digest
manifest.json	5c121ea4b4eadffe8e167a0ec2581387cf774ba3a67c937afca039acdd6245f3
Runtime component	abdfe1ff2e9a1752418868664dd23ddb1fd28f46fdbe3d89feb39ffb18e47b78
Toolchain component	6999b7927eb8e06f1b2a794e3619d19ad2267a035f2b96f7815c307cca6859ee

Component pins use the sha256: prefix. The release artifact manifest binds these identities to the packaged microvm-artifacts image. Operators must install the new bundle and apply the new signed asset catalog and standard Profile revisions as one coordinated step. Runners reject Assignments pinned to mismatched component digests.

Attributed connection policy

The latest standard agent-compartment Profile revision grants 128 simultaneous open TCP connections per attributed generation and permits a Subject controller to select a value up to 4096. Operators must explicitly apply the updated standard bundle; deploying code alone does not raise an operator-owned grant. Custom Profiles need their own explicit default and ceiling. A complete Subject policy PUT can include attributedExecution.maximumConnections, and policy reads project the default, effective value, and ceiling for the next Assignment.

The numeric limit resolves from the current Profile head on each new Assignment, including an existing Sandbox pinned to an older revision. An old two-connection pin inherits 128 after the standard revision is applied; a saved Subject selection is capped by the current ceiling. Active Assignments keep their admitted limit. Pinned gateway, other execution authority, and lifecycle policy do not change. At capacity, the forwarder closes newly accepted TCP sockets before contacting the gateway; existing streams stay open. See attributed connection policy and downstream adoption.

Workspace file errors

File mutations that encounter a full Workspace now return HTTP 507 workspace_full instead of a generic failure. This includes guest ENOSPC and quota exhaustion. Clients can delete files and retry. The Firecracker guest must come from this release's new signed bundle for the guest-side classification to work.

Distribution

The default release tier qualifies Firecracker, local gVisor, and the Btrfs-image installer guest and publishes Linux amd64 container images. CLI and deployment binaries ship for Linux and macOS on amd64 and arm64. The public API remains v1; the Runner protocol window is [5,5].

Install the TypeScript SDK with npm install @secondstack-ai/secondbox@0.17.0. The Go module is github.com/SecondStack-AI/SecondBox@v0.17.0.

Install

Guided Linux amd64 install:

curl -fsSL https://github.com/SecondStack-AI/SecondBox/releases/download/v0.17.0/install.sh | sh

SDKs: npm install @secondstack-ai/secondbox@0.17.0 and go get github.com/SecondStack-AI/SecondBox@v0.17.0

SecondBox v0.16.0

SecondBox v0.16.0

Deployment boundary

This release keeps Runner protocol generation 5, the public API v1, and the v0.15.0 database schema.
It adds no migration, and it does not change a standard Profile revision.
A v0.15.0 deployment can update in place with the guided updater, and no reinstall is necessary.
Stop active Sandboxes and take a coordinated database and Runner-storage backup before the update.
Update the control plane, every Runner, and the image fetchers to the same release.
Deployments older than v0.15.0 must first cross the boundaries in the v0.15.0 notes and the earlier release notes.

Firecracker bundle and trust anchor

This release ships the retained signed secondbox-0.12.0 Firecracker bundle, 6.12.94 kernel, component identities, and RSA trust anchor without change.
The bundle was not rebuilt, so the runtime and toolchain component-manifest digests that Profiles pin are the same as in v0.15.0.
Their identities are recorded in the v0.12.0 notes.

The microVM image pipeline no longer runs the rootfs secret scan, and a newly built bundle no longer records secretScanPolicySha256 in its rootfs contract.
The golden rootfs is built only from Docker layers and never receives per-Sandbox runtime secrets.
The installer continues to accept secretScanPolicySha256 in bundles signed before this change, including the shipped secondbox-0.12.0 bundle, and ignores its value.

Runner gateway endpoints for guest executions

Firecracker and gVisor Runners now publish the logical gateway endpoints that the Sandbox's pinned egress context resolves.
Every ordinary guest execution receives the reserved SECONDBOX_RUNNER_GATEWAYS environment variable.
Its value is a space-separated list of logicalName=address:port entries, sorted by logical name and then port.
An IPv6 address appears in brackets.
The variable is absent when the Profile resolves no logical gateway.

The entries are routing information only; they contain no credentials.
An application wrapper selects the entry it needs and sets its own proxy variables, so the application host no longer configures a Runner-host address.
Exec requests that supply SECONDBOX_RUNNER_GATEWAYS themselves are rejected before dispatch, as SECONDBOX_EXECUTION_GATEWAY already is.
Attributed generations resolve no logical gateway and continue to receive only SECONDBOX_EXECUTION_GATEWAY.
The experimental Microsandbox backend does not use the Runner guest protocol, so it neither publishes nor reserves the name.
See SDK, CLI, and Flue integration.

Distribution

The default release tier qualifies Firecracker, local gVisor, and the Btrfs-image installer guest and publishes Linux amd64 container images.
CLI and deployment binaries ship for Linux and macOS on amd64 and arm64.
The public API remains v1; the Runner protocol window is [5,5].

Install the TypeScript SDK with npm install @secondstack-ai/secondbox@0.16.0.
The Go module is github.com/SecondStack-AI/SecondBox@v0.16.0.

Install

Guided Linux amd64 install:

curl -fsSL https://github.com/SecondStack-AI/SecondBox/releases/download/v0.16.0/install.sh | sh

SDKs: npm install @secondstack-ai/secondbox@0.16.0 and go get github.com/SecondStack-AI/SecondBox@v0.16.0

SecondBox v0.15.0

SecondBox v0.15.0

Deployment boundary

This release upgrades the Runner protocol from generation 4 to generation 5.
Stop new application work, stop active Sandboxes, and take a coordinated database and Runner-storage backup before updating the control plane and every Runner together.
Generation 4 Runners cannot serve the generation 5 control plane.

Databases created by v0.14.0 can apply the forward migrations without recreating their resources or Workspaces.
The migration validator recognizes that release's exact retention-baseline checksum and preserves the recorded ledger.
Other checksum drift remains an error.
Rollback after migration uses the coordinated backup and its original software.

The signed secondbox-0.12.0 Firecracker bundle, 6.12.94 kernel, component identities, and RSA trust anchor remain unchanged.
Their identities are recorded in the v0.12.0 notes.
Existing fixed-Profile Sandboxes keep their assets when an application omits an image.

Application-selected execution images

Sandbox create and start accept an optional image.reference containing an OCI tag or digest.
The application builds and signs its userspace with the SecondBox image builder; the resulting bundle contains the guest agent and qualified kernel.
The Profile continues to control resources, placement, networking, and lifecycle policy.

An explicit tag resolves once per new Operation.
Starting with a changed digest boots the replacement image against the retained /workspace; a failed replacement does not overwrite the last successful image pin.
Omitting the image on start reuses the existing pin.
An explicit tag requires registry access even when its digest is cached.

POST /v1/images:prepare prepares the image on eligible Runners without starting compute and reports target and completion counts.
Firecracker on Linux amd64 supports selected images; Snapshot-resume Profiles, gVisor, and Microsandbox reject them.

Each Runner host needs an unprivileged image fetcher, independently provisioned publisher trust, and tenant-scoped registry configuration.
The fetcher has no Workspace mount, host devices, or Docker socket.
Registry credentials stay on the host and never enter lifecycle requests or guest files.
TLS verification is mandatory.
See client-selected execution images.

Lifecycle and image-cache corrections

• Warm starts reuse verified artifact identities instead of hashing the full bundle on every start.
• Cache reclamation protects the image being started and bounds resolution and lock metadata.
• Runner startup rejects a selected-image cache on a different filesystem from the reflink launch directory.
• Image preparation reports progress consistently and resolves on a compatible Runner.
• Lifecycle retries recover after terminal startup failure without unnecessary revision changes during unchanged waits.

Distribution

The default release tier qualifies Firecracker, local gVisor, and the Btrfs-image installer guest and publishes Linux amd64 container images.
CLI and deployment binaries ship for Linux and macOS on amd64 and arm64.
The public API remains v1; the Runner protocol window is [5,5].

Install the TypeScript SDK with npm install @secondstack-ai/secondbox@0.15.0.
The Go module is github.com/SecondStack-AI/SecondBox@v0.15.0.

Install

Guided Linux amd64 install:

curl -fsSL https://github.com/SecondStack-AI/SecondBox/releases/download/v0.15.0/install.sh | sh

SDKs: npm install @secondstack-ai/secondbox@0.15.0 and go get github.com/SecondStack-AI/SecondBox@v0.15.0

SecondBox v0.14.0

Deployment boundary

v0.14.0 requires a fresh database and a separate Runner storage root. The unlimited Snapshot retention fix changes the initial migration checksum, so existing installations, including v0.13.0, cannot upgrade in place. update --resume cannot repair the mismatch. Retain the previous deployment and its original state for rollback until its owners retire their Sandboxes.

The signed secondbox-0.12.0 Firecracker bundle and its trust anchor remain unchanged.

Changes

• Added optional exclusiveBytes to Workspace storage observations, measuring extents unshared with templates, Snapshots, or other Workspaces. Bounded background probes preserve heartbeat responsiveness; unsupported, incomplete, unstable, or encoded extents report an unavailable exclusive measurement with a distinct reason.
• Added Sandbox state and ID filters, intersecting with metadata and bound to pagination cursors, with Go and TypeScript options.
• Distinguished missing Workspace files (file_not_found) from missing Sandboxes, unavailable compute, and generation fencing.
• Added TypeScript Subject and ApplicationAuthority management helpers and tenant usage reads. Subject quota updates return an atomic quotaObservation, preserved on idempotent replay.
• Fixed unlimited Snapshot retention through persistence and reads/lists.

Full release notes and deployment guidance.

Qualification and distribution

Built and qualified from 1cda639f4641e041d9e1b688df10fdaf1a783e99. All ten local gates and GitHub CI passed. Firecracker and local gVisor scenarios passed; the disposable Btrfs-image installer passed 11 assertions, including reboot recovery and a real hello-world microVM. Qualification evidence is attached, including the existing scenario skips.

The default release tier ships Linux amd64 container images and Linux/macOS CLI and deployment binaries for amd64 and arm64. The full nightly/pod/arm64-image matrix was not run for this release.

TypeScript: npm install @secondstack-ai/secondbox@0.14.0

Go: go get github.com/SecondStack-AI/SecondBox@v0.14.0

For a fresh Linux amd64 deployment:

curl -fsSL https://github.com/SecondStack-AI/SecondBox/releases/download/v0.14.0/install.sh | sh

SecondBox v0.13.0

Added configurable finite-or-unlimited policy limits, delegated Subject lifecycle selection, Tenant quota updates, and retained Workspace storage observations.

Schema changes require a clean initialization; existing deployments and their Workspaces remain separate, with no state adoption. The tag was cut at 1645f10 on the branch of #141 before that branch was rebased onto main, so git log v0.13.0..main lists re-landed commits under different hashes; the tagged tree is identical to main's 24ac255. Release notes were written after the fact: see the v0.13.0 release notes.

Added

• Added application-scoped quota headroom and retained Workspace storage observations, including allocated image blocks and admission-pressure freshness without exposing host identities. Platform operators can raise existing Tenant quotas without recreating retained resources (#141).

Changed

• Changed policy ceilings and quota dimensions to explicit integer-or-null values, with complete-object validation and nullable admission headroom. Added delegated Subject lifecycle selection for future Sandboxes; fresh Agent Profiles use unlimited maximum runtime while finite workloads retain age-based termination (#141).

Full release notes · Full changelog

Install

Guided Linux amd64 install:

curl -fsSL https://github.com/SecondStack-AI/SecondBox/releases/download/v0.13.0/install.sh | sh

SDKs: npm install @secondstack-ai/secondbox@0.13.0 and go get github.com/SecondStack-AI/SecondBox@v0.13.0

SecondBox v0.12.0

Rotated the Firecracker microVM bundle and its signing authority so Firecracker guests receive the port-credit and streaming-exec fixes, and introduced the lean release tier.

Existing deployments must be reinstalled and their resources recreated; the guided updater refuses bundle digest changes. See the v0.12.0 release notes.

Changed

• Rotated the Firecracker microVM bundle to secondbox-0.12.0 with a new RSA-4096 trust anchor, shipping the guest port-credit and streaming-exec fixes from #127, #128, and #134. Existing deployments require reinstallation and resource recreation because the guided updater refuses bundle digest changes. See v0.12.0 release notes for the fingerprint and bundle identity.
• Added a lean release tier with sharded Firecracker and local gVisor qualification, amd64 images, and one installer guest. just nightly retains the full scenario matrix; just release VERSION --full also builds arm64 images and runs all installer modes. Manifests record built platforms and evidence remains commit-exact (#135).

Fixed

• Fixed queued streaming stdin blocking the guest connection after an exec terminates, preserved command exit status when a program stops reading stdin before exiting, and allowed deadline outcomes to reach the streaming client (#134).

Full release notes · Full changelog

Install

Guided Linux amd64 install:

curl -fsSL https://github.com/SecondStack-AI/SecondBox/releases/download/v0.12.0/install.sh | sh

SDKs: npm install @secondstack-ai/secondbox@0.12.0 and go get github.com/SecondStack-AI/SecondBox@v0.12.0

SecondBox v0.11.0

Added one command per Sandbox intent (friendly verbs, size presets, golden Snapshots, and a guided install that runs a hello-world microVM) and one-command qualification and release tooling.

The Firecracker bundle shipped with this release still predates the guest-side port-credit fixes below; they reach Firecracker guests with the v0.12.0 bundle. Release notes were written after the fact: see the v0.11.0 release notes.

Added

• Added friendly Sandbox lifecycle, file, port-forwarding, and Snapshot commands. run and create now accept size presets, explicit CPU/memory/Workspace requests bounded by optional Profile ceilings, quota, and Runner admission, and --from sandbox/snapshot-name or Snapshot identifiers. Memory and disk requests, Profile defaults, and finite ceilings require whole MiB. Requested disk capacity rounds up to a power of two, capped at a finite ceiling when the request fits; resume Profiles require their fixed size. An operator flexible-size Profile example removes CPU and memory ceilings while bounding disk at 256 GiB. Resolved resources appear in human Sandbox views, and an operator Profile example documents preparing dependencies with registry HTTPS access for golden Snapshots (#126).
• Added just qualify for concurrent PR and release gates and just release VERSION for local qualification, artifact building, memory-capped parallel installer guests, and final staging, with per-stage logs and timings. Releases retain commit-exact evidence and require explicit publication (#131).

Changed

• Required removal of duplicate ready Snapshot names per Sandbox before upgrading across migration 0024_snapshot_name_index.sql. On the source release, list Snapshots with snapshots list --path sandboxId=... and delete unwanted duplicates by Snapshot identifier; duplicates block control-plane startup. See the deployment and guided-update procedures (#126).
• Simplified deployment settings: removed the seven unused deployment-level Subject quota defaults and the unenforced RunnerPool capacityPolicy from the public API, SDKs, resource documents, the CLI --capacity option, and deployment pool declarations (max_sandboxes, max_vcpu_count, max_memory_bytes); a forward migration drops its column. Packaged listeners, catalog location, same-host Runner paths, and the jail policy are derived; polling intervals become optional [overrides]. Retired fields are rejected (#130).

Fixed

• Fixed port forwarding to bound every session by its granted Lease lifetime and keep individual connection failures from stopping other connections. Guided-install smoke runs now wait for Sandbox deletion to release capacity before starting the next run (#126).
• Guest port forwarding now returns unused byte credit after short socket reads, bounds Runner adapter credit and read sizes, and keeps granting credit to guests that discard short-read remainders, preventing forwarding stalls (#127, #128, #129).

Full release notes · Full changelog

Install

Guided Linux amd64 install:

curl -fsSL https://github.com/SecondStack-AI/SecondBox/releases/download/v0.11.0/install.sh | sh

SDKs: npm install @secondstack-ai/secondbox@0.11.0 and go get github.com/SecondStack-AI/SecondBox@v0.11.0