A deploy that sits in staging for a week, then asks before production. A nightly sync that retries the one record that failed instead of the whole batch. An order flow that waits days for a payment webhook. Hyperspool runs all of them the same way: every step's result is saved, so a failure picks up at that step, and a run that's waiting holds no machine.
Draw it on the canvas, keep it as a pipeline in your repo, or script it in whatever language you already use. The copilot can draft one from a sentence too (early access, so expect rough edges).
Your pipeline, plus everything after green: deploys, soaks, approvals and rollbacks in the same run, on machines you don't have to look after.
Durable runs without a worker fleet to host. Write YAML, draw it, or script it in any language, and approvals, schedules and a console are already there.
Build it visually like you're used to, then get pinned versions, dry runs, reruns from the failed step and your own code steps on top.
Anything that waits on people, time or other tools. It runs start to finish and you can see where each one is.
A build can start a business workflow, a cron job can wait for an approval, and a webhook can wake a run that's been waiting for days. Same runs, same history, same console.
Because CI and automation tools end up running everything. Builds, sure, but also cron jobs, syncs and the business automation nobody had anywhere else to put - it's the system you have. And they're rigid about it. Fail halfway and you start over from scratch. Anything that needs to wait turns into a sleep loop or a second job someone has to remember.
We wanted one system built for all of it, where a build and a business workflow are the same kind of thing and can start each other. That's Hyperspool.
Each finished step saves its result. When the process stops, the run replays from those results and carries on from the step it was on. A waiting run holds no agent and no machine, and it finishes on the definition it started with, so publishing a change leaves runs in flight alone.
durable.sh picks a random number in a saved step, sleeps, then adds one.
The process exits at the sleep and starts again from the top, and you get the same
number back because the step replayed from its record. Like so:
spool run ./durable.sh
picked 21
- replaying from checkpoint (completed steps are cached, not re-run)
picked 21
21 + 1 = 22
You can try this one without an account. Install the CLI, spool init
writes a few starters, and spool run runs one on your machine:
curl -fsSL https://hyperspool.com/install.sh | shAll three are the same workflow underneath, with the same checkpoints and history, so pick whatever suits the person who'll maintain it.
Wire steps together and fill each one in. Expressions complete against what earlier steps produced. Start from a template, or describe what you want and let the copilot draft the graph (early access).
Try it runs your unsaved draft as a dry run. Branches and transforms run for real, while shell, HTTP and connector steps get the last run's output, so nothing outside gets touched. Publish when it looks right.
YAML for build, test and deploy, with the waiting bits as job kinds: wait for an event, an approval, a timer, a child workflow. This one deploys to staging, waits up to two weeks for an alert, rolls back if one fires, and otherwise asks before production:
jobs:
build:
requires: [build]
steps:
- { name: compile, run: make release }
deploy:
depends_on: [build]
steps:
- { name: ship, run: ./deploy.sh staging }
soak:
depends_on: [deploy]
wait_for_event: { event: alerts.fired, timeout: 14d }
rollback:
depends_on: [soak]
if: ${{ !steps.soak.output.timed_out }}
steps:
- { name: undo, run: ./deploy.sh staging --rollback }
promote:
depends_on: [soak]
if: ${{ steps.soak.output.timed_out }}
approval:
prompt: "Promote to production?"
A preview environment that deploys, stays up for a week, then tears down. A week
later the teardown gets the same environment back from the saved step. Python has an
SDK. Bash, and basically anything else that can run a command, uses
spool step.
from datetime import timedelta
from hyperspool import script
env = script.step_fn("deploy", lambda: deploy(host))
script.sleep(timedelta(days=7))
script.step_fn("teardown", lambda: teardown(env))env="$(spool step deploy -- ./deploy.sh "$host")"
spool sleep 7d
spool step teardown -- ./teardown.sh "$env"A push, a schedule or a webhook. Connect a GitHub, Gitea or Forgejo repo with one command, paste the webhook URL and secret it prints into the forge, and every push runs the pipeline checked into the repo. The commit gets its status back.
spool repo connect https://github.com/acme/web \
--repo-credential gh-read \
--status-credential gh-statusOn environments Hyperspool starts for each step. If a step needs something those don't have, run an agent of your own and the step goes there instead.
Started on demand.
build get amd64 VMs with 16 cores,
32 GiB of memory, Nix and KVM.
spool agent run on a machine of yours.
Every run in one place. Anything it shows, the CLI can reach too.
Approvals waiting on you and things only you can fix come first. Then what's running, what's waiting and what broke.
Every run on one lane per workflow, with a line for now and what's scheduled next.
Each workflow gets its canvas, a plain-language Words view, its runs with step timings, its code and its settings.
Early access. Drafts or changes a workflow from a description and answers questions from the docs. It only proposes - you save and publish.
It's an invited preview and still early days, so expect some rough edges. It already runs production work though, its own CI included. Sign in, create an organization on the Free plan, and you'll have a project ready for a first run.
Tell us who you are and what you'd like to automate. A person reads every request and answers by email.
Rather write? Mail support@hyperspool.com.