Skip to content

add computesdk image to hub#178

Open
kisernl wants to merge 1 commit into
blaxel-ai:mainfrom
computesdk:main
Open

add computesdk image to hub#178
kisernl wants to merge 1 commit into
blaxel-ai:mainfrom
computesdk:main

Conversation

@kisernl
Copy link
Copy Markdown

@kisernl kisernl commented Mar 16, 2026

Add ComputeSDK sandbox image template

Adds a new hub template for ComputeSDK, a free and open-source toolkit for running code in remote sandboxes.

What's included

  • Dockerfile — Based on computesdk/compute:latest (Debian Bookworm), includes Node.js, Bun, and the ComputeSDK self-hosted compute runtime at /app/compute. Copies in the Blaxel sandbox-api binary.
  • entrypoint.sh — Starts the Blaxel sandbox-api, then launches the ComputeSDK compute daemon (/app/compute serve-daemon) as a managed process. Supports credential injection via COMPUTESDK_API_KEY or COMPUTESDK_ACCESS_TOKEN env vars at sandbox creation time.
  • template.json — Hub metadata with 4096MB memory and ports for the sandbox-api (8080) and compute daemon (18080).

How it works

The template normalizes credential env vars (COMPUTESDK_API_KEYAPI_KEY) before any processes start, so the compute binary finds them in its environment. If no credentials are provided, the sandbox-api still starts and the compute daemon can be launched manually later.

Tested

  • Built and ran locally via Docker
  • Deployed as a private template via bl deploy and verified sandbox creation
  • Compute daemon successfully authorized and created an initial sandbox

Note

Low Risk
Low risk and purely additive (new hub template files), with the main risk being runtime startup/health-check behavior in the new entrypoint.sh and reliance on external base images.

Overview
Introduces a new ComputeSDK hub template that builds from computesdk/compute:latest, layers in the required sandbox-api binary, and installs netcat for readiness checks.

Adds an entrypoint.sh that starts sandbox-api, waits for port 8080, and then conditionally launches the ComputeSDK daemon via a local /process API call when COMPUTESDK_API_KEY/COMPUTESDK_ACCESS_TOKEN (or normalized API_KEY/ACCESS_TOKEN) are present; otherwise it logs manual-start instructions.

Registers the template in template.json with 4GB memory and exposes ports 8080 (sandbox API) and 18080 (compute daemon).

Written by Cursor Bugbot for commit 4237516. This will update automatically on new commits. Configure here.


Note

Adds a new hub template for ComputeSDK, a self-hosted compute runtime. Includes a Dockerfile based on computesdk/compute:latest, an entrypoint script that starts the Blaxel sandbox-api and optionally launches the ComputeSDK daemon, and template metadata.

Written by Mendral for commit 4237516.

Copy link
Copy Markdown
Contributor

@mendral-app mendral-app Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs attention — 2 issues across 2 files

The computesdk/compute:latest base image is an unversioned, unverified external image — this is a supply chain risk. The entrypoint also has a correctness issue: wait with no arguments waits for all background jobs, but sandbox-api is the only backgrounded process; if it exits, the container silently dies without the compute daemon being restarted or any error surfaced.

Prompt for AI agents (all issues)
Check if these issues are valid — if so, understand the root cause of each and fix them.

<assessment>
The `computesdk/compute:latest` base image is an unversioned, unverified external image — this is a supply chain risk. The entrypoint also has a correctness issue: `wait` with no arguments waits for all background jobs, but `sandbox-api` is the only backgrounded process; if it exits, the container silently dies without the compute daemon being restarted or any error surfaced.
</assessment>

<file name="hub/computesdk/Dockerfile">
<issue location="hub/computesdk/Dockerfile:5">
Unpinned external base image `computesdk/compute:latest` is a supply chain risk. Any upstream change or compromise is silently pulled in on every build. Pin to a specific digest or version tag.
</issue>
</file>

<file name="hub/computesdk/entrypoint.sh">
<issue location="hub/computesdk/entrypoint.sh:37">
`wait` with no PID argument waits for all background jobs, but only `sandbox-api` is backgrounded. If `sandbox-api` crashes, the container exits silently with code 0. Capture the PID and wait on it explicitly so a crash propagates correctly.
</issue>
</file>

Tag @mendral-app with feedback or questions. View session

Comment thread hub/computesdk/Dockerfile
FROM --platform=linux/amd64 ghcr.io/blaxel-ai/sandbox:${SANDBOX_VERSION} AS blaxel

# Use ComputeSDK self-hosted compute runtime as base (Debian Bookworm)
FROM --platform=linux/amd64 computesdk/compute:latest
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

security (P1): Unpinned external base image computesdk/compute:latest is a supply chain risk. Any upstream change or compromise is silently pulled in on every build. Pin to a specific digest or version tag.

Suggested change
Suggested change
FROM --platform=linux/amd64 computesdk/compute:latest
FROM --platform=linux/amd64 computesdk/compute:<specific-version-or-digest>
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At hub/computesdk/Dockerfile, line 5:

<issue>
Unpinned external base image `computesdk/compute:latest` is a supply chain risk. Any upstream change or compromise is silently pulled in on every build. Pin to a specific digest or version tag.
</issue>


echo "ComputeSDK sandbox ready"

# Keep the container running
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bug (P1): wait with no PID argument waits for all background jobs, but only sandbox-api is backgrounded. If sandbox-api crashes, the container exits silently with code 0. Capture the PID and wait on it explicitly so a crash propagates correctly.

Suggested change
Suggested change
# Keep the container running
SANDBOX_PID=$!
# Keep the container running; exit if sandbox-api dies
wait $SANDBOX_PID
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At hub/computesdk/entrypoint.sh, line 37:

<issue>
`wait` with no PID argument waits for all background jobs, but only `sandbox-api` is backgrounded. If `sandbox-api` crashes, the container exits silently with code 0. Capture the PID and wait on it explicitly so a crash propagates correctly.
</issue>

Copy link
Copy Markdown

@cursor cursor Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 2 potential issues.

Fix All in Cursor

Bugbot Autofix is kicking off a free cloud agent to fix these issues. This run is complimentary, but you can enable autofix for all future PRs in the Cursor dashboard.

echo "Waiting for sandbox API..."
while ! nc -z 127.0.0.1 8080; do
sleep 0.1
done
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Health-check loop lacks timeout, may hang forever

Medium Severity

The nc -z health-check loop waiting for the sandbox API on port 8080 has no timeout, unlike every other hub template that uses this pattern (astro, expo, nextjs, vite, jupyter-notebook), which all implement a 30-second timeout with a counter. If sandbox-api fails to start or crashes immediately, this loop will spin forever, leaving the container hung with no error message and no way to diagnose the failure.

Fix in Cursor Fix in Web

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bugbot Autofix determined this is a false positive.

The referenced file hub/computesdk/entrypoint.sh does not exist in this branch, so this health-check loop is not present to fix.

This Bugbot Autofix run was free. To enable autofix for future PRs, go to the Cursor dashboard.

Comment thread hub/computesdk/Dockerfile
# Install netcat for the health-check loop in entrypoint.sh
RUN apt-get update && apt-get install -y --no-install-recommends \
netcat-openbsd \
&& rm -rf /var/lib/apt/lists/*
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dockerfile missing explicit curl installation used by entrypoint

Medium Severity

The Dockerfile explicitly installs netcat-openbsd for the health-check loop but does not install curl, which is used in entrypoint.sh to register the compute daemon with the sandbox API process manager. Every other template in this repo that uses curl in its entrypoint (astro, expo, nextjs, vite, jupyter-notebook, jupyter-server) explicitly installs it. If the computesdk/compute:latest base image ever removes curl, the compute daemon silently fails to start even when valid credentials are provided.

Additional Locations (1)
Fix in Cursor Fix in Web

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bugbot Autofix determined this is a false positive.

The referenced files hub/computesdk/Dockerfile and hub/computesdk/entrypoint.sh are absent in this branch, so this missing dependency issue is not applicable.

This Bugbot Autofix run was free. To enable autofix for future PRs, go to the Cursor dashboard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant