GitHub Actions dropped Node 20: calling Sume needs no Node

Calling Sume from a workflow does not depend on a Node version. The Sume CLI is a native binary installed with one curl line, and the API is HTTPS, so a run: step with curl works on a runner that only has Node 24. Only JavaScript actions you use are affected by the Node 20 removal, and you update those to their latest releases.

GitHub's side is from its 2026-09-23 changelog (read 2026-09-30). Sume's side is from the CLI install and Jobs and results docs.

What did GitHub change?

The changelog says Node 20 is no longer available on Actions runners, runners now use Node 24 for JavaScript actions, and the temporary ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION opt-out is gone. Maintainers should set runs.using to node24; users should move to the latest versions of actions that support Node 24.

Which Sume paths touch Node at all?

What does a step look like?

Store the API key as a repository secret and expose it as SUME_API_KEY in the step's environment. Derive the Idempotency-Key from something stable such as the commit, so a re-run of the job returns the original job instead of billing a second one. The submit is async, which returns a job id at once.

set -euo pipefail
curl -fsS -X POST https://api.sume.com/v1/image-1.0/generate \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: release-image-$GITHUB_SHA" \
  -d '{"prompt":"Product hero shot of a matte black bottle on marble","mode":"async"}'

What about the CLI in CI?

The docs say manual API-key setup and environment variables are still supported for CI and server automation, so after the installer runs, set SUME_API_KEY and call sume. The installer verifies the download against checksums.txt. For a pinned install, the docs say to replace latest in the release URL with a tag.

What if the step is cancelled or times out?

Do not resubmit the paid request because a local process timed out. Reuse the same Idempotency-Key for a retry, and read the job with GET /v1/jobs/{id}/status. Re-running a workflow with the same key covers the details.