PulseGrid
A lightweight distributed CI platform, like GitHub Actions or Buildkite, where I built the infrastructure myself: webhooks, a DAG workflow engine, a resource-aware scheduler, pull-based Docker workers, and leases that survive crashes.
The infrastructure behind CI, not the UI around it.
Everyone uses CI. Few people know what happens between git push and a green check. I wanted to build that part myself, end to end, so every step below is real code in PulseGrid.
A developer pushes code
Signature verified, retries de-duplicated
Finds the repo and exact commit
Jobs with real dependencies
Matches jobs to CPU, memory, GPU
Checks out the exact SHA
Isolated run, logs back
Back to the developer
Simple on top. Serious underneath.
Connect a repo, add a small workflow file, push. From there it's a live view of every job, the machines running them and the result back on GitHub.
Watch every job live
Each run shows the exact commit, every job's state and timing, and real-time logs for any job you open.
See the machines
Workers advertise CPU, memory, GPU and health. The scheduler only hands a job to a worker that can actually fit it.
Results where you work
Status goes back to the commit on GitHub, with durable delivery: if GitHub is down, the update retries, and an old result can never overwrite a newer one.
Go ahead. Crash a worker.
I didn't want a system that only works when everything behaves. Every job runs on a lease. Workers must keep renewing it with heartbeats, or PulseGrid takes the job back and gives it to someone else.
The tricky part isn't retrying. It's making sure the old worker can't come back and overwrite the new result. Every heartbeat, log and completion call carries its lease ID, so a stale attempt is rejected. A chaos demo in the repo reassigns a job with a new lease after a worker expires.
It understands which job waits for which.
A small YAML file becomes a directed acyclic graph. Lint and tests run in parallel, build waits for both, deploy waits for build. The engine decides what's ready, the scheduler decides where it fits.
# .pulsegrid/workflow.yml name: ci jobs: lint: image: python:3.12-slim command: ruff check . tests: image: python:3.12-slim command: pytest build: image: python:3.12-slim command: python -m build needs: [lint, tests] deploy: image: alpine:3.20 command: ./deploy.sh needs: [build]
The hard infrastructure already runs.
The execution core and the GitHub runtime are working today. The product layer that teams would pay for comes next.
Built 08
Next 06
The brain coordinates. Workers just run.
The control plane owns workflow state, scheduling, leases, retries and GitHub. Workers only provide compute and run jobs safely. That split is what lets it grow from three workers to hundreds without changing anything for the developer.
Everything developers expect, on the same core.
The production version adds the features teams rely on, plus observability, so when a pipeline suddenly takes ten minutes you can see why.
Secrets & private repos
Encrypted secrets, private checkout, scoped GitHub App access
Caching & artifacts
Dependency and Docker-layer caches, build artifacts
Limits & rules
Cancellation, timeouts, concurrency limits, branch rules
Autoscaling
Add compute when the queue is busy, shut it down when quiet
Reusable workflows
Shared pipelines across repositories
Orgs & sign-in
Organizations, roles, repository permissions
Observability
Queue depth, worker health, utilization, failure and retry rates
Analytics
Workflow duration and performance over time
Not just a script that runs Docker. A small, real distributed execution platform.
ForgeDB
A database written from the disk page up.