Your build environment is already running
One long-lived warm pod per pipeline, every step image resident, the workspace on a persistent volume. No pod per step. No image pull. No cache to restore.
Which you can spend on a smaller bill, or on a faster team. Most people want some of both.
Same architecture. Two very different reasons to want it.
Warm pods remove work from every run. Whether that shows up as a smaller invoice or a shorter feedback loop is a decision you get to make, not one we make for you.
If you’re counting every dollar
The cheapest compute is the compute you never provisioned
Every ephemeral job pays for scheduling, image pull, and cache restore before it runs your first command. Multiply that by a few hundred builds a day and you are renting a great deal of compute to do setup.
- No per-step pod scheduling or image pull
- No cache upload and download per job
- Dependencies pulled once cluster-wide, not once per build
- Idle pipelines scale to zero and release their volume
- Runs on spot nodes, handled gracefully
If your constraint is engineering time
An inner loop measured in seconds, not deploys
The expensive part of a change is rarely the compute. It is the engineer waiting on it, losing the thread, and going to do something else while a test environment rebuilds.
- Runs start executing immediately, not after setup
- Sync a change into a running pod and auto-reload
- No image rebuild or registry push to try a change
- Live build output streamed as it happens
- Failures surface in seconds, while context is fresh
The second column is the one people underestimate, and it is also the one that quietly saves the most money — because a test environment that updates in place isn’t building images, pushing them to a registry, storing them, or pulling them back down.
Most CI time isn’t spent building
The ephemeral-runner model pays for a cold environment on every single job. Sampleless CI pays for it once.
Ephemeral runner
- Schedule pod
- Pull step image
- Attach volume
- Restore cache from remote
- Run your command
Every job. Every time.
Sampleless CI
- Schedule pod
- Pull step image
- Attach volume
- Restore cache from remote
- Run your command
The pod is already up, with the images and the caches on it.
The saved time is the setup, not the build. Which means the more your pipeline depends on, the more you get back.
The same pipeline, measured
An 11-phase Rust and container build, run on the same cluster and the same node class. This is the workload that made us stop using Tekton.
Measured on our own build fleet, 11 phases, single node, identical step images. Your numbers will differ — the gap scales with how much of your build time is dependency resolution and image pull, so dependency-heavy builds gain the most. We’ll run your pipeline during an evaluation and show you the real delta.
Built for repositories that build all day
Every design choice trades a little cluster residency for a lot of wall-clock time.
Warm pods
One long-lived pod per pipeline, holding every step image as a running container on a persistent workspace. Steps are dispatched into containers that are already up.
- No per-step pod scheduling
- No per-step image pull
- Phases can run concurrently in one container
- Node selection scored on free capacity
Caches that persist by default
The workspace is a real volume that survives runs. Git sync cleans tracked files but leaves ignored build state alone, so dependency and compiler caches are simply still there.
- node_modules, .venv, Cargo target/ stay hot
- BuildKit local cache persists
- No cache keys to declare
- No upload or download per job
Pipelines as custom resources
Pipelines, runtime config, runs, reusable steps, image builds, and build history are typed Kubernetes objects. Query them with kubectl, select by label, scope with RBAC.
- SciPipeline, SciPipelineConfig, SciPipelineRun
- SciStep for reusable steps
- SciImage for standalone image builds
- SciBuild for per-branch build history
Reusable steps with patches
Reference a shared step by name and namespace, then apply overlay patches to it. Override an image, env, or resources without forking the step.
- Cross-namespace step references
- JSON Patch and strategic-merge patches
- Library steps for git, cargo, BuildKit, npm, deploy
- Preview the resolved result before you push
Kafka-backed run queue
Each pipeline has a topic that acts as the job queue. Strict ordering and crash recovery come from consumer offsets rather than an external lock service.
- FIFO with single-in-flight when configured
- Runs resume after eviction or restart
- Orphaned phases force-finalized on recovery
- No Redis lock to acquire and release
Live build streaming
The runner serves the in-flight run status and log deltas over server-sent events straight from the pod, with a database fallback for historical runs.
- Per-phase log capture
- No database round trip for live runs
- Head-and-tail truncation for huge logs
- Per-step exit codes on the run resource
Every dependency, fetched once
Turn on dependency proxying per pipeline and Sampleless CI writes the package manager config for you, pointing each ecosystem at an in-cluster pull-through cache.
A given version is pulled from the public internet at most once for the whole cluster. Upstream rate limits and upstream outages stop being your problem, and the second build of the day doesn’t re-download the internet.
Supported ecosystems
Also cached cluster-wide
- Container base images
- Rust and C/C++ compiler objects via sccache
- BuildKit layer cache in the registry
Edit against the real cluster, without rebuilding it
Run your app in the cluster in dev mode, with changes synced from Git into the running pod and a file watcher triggering auto-reload. Building a container image to see one edit is a lot of machinery for a question you want answered in ten seconds.
The usual loop
- Commit a change
- Build an image
- Push it to a registry
- Store a tag nobody will ever use again
- Pull it back down onto a node
- Restart the pod, losing its state and connections
- Wait, then find out you needed one more line
Every step costs compute, storage, or bandwidth. Most cost all three, and all of them cost attention.
Dev mode in-cluster
- Commit a change
- It syncs into the running pod
- The file watcher fires and the app reloads
- Look at it
The pod keeps running. Its caches, its connections, and its in-memory state survive the edit.
You are testing against the real thing
Real service discovery, real network policy, real sidecars, real data shapes. The category of bug that only appears in the cluster appears while you are still looking at the code that caused it, rather than three environments later.
What you stop paying for
Image build compute on every iteration. Registry storage for hundreds of throwaway tags. Pull bandwidth onto every node. Cold starts on every restart. None of that was buying you anything — it was the cost of asking a question.
For already-deployed services, Packageless can push a newly published package version into running pods without a rebuild. That’s a different mechanism for a different moment.
Warm when it matters, zero when it doesn’t
A warm pod that nobody uses is just a bill. Idle pipelines scale to zero and release their workspace volume automatically.
Hot
Reclaims after 24h idle
For pipelines that run most days and should stay instant.
Warm
Reclaims after 1h idle
For pipelines that run in bursts and can afford a cold start.
Explicit
Your own window
Set the idle duration directly, or never reclaim at all.
The next run after a reclaim re-provisions the pod and workspace, paying a one-time cold start.
Image builds without a repository
Some images are just a Dockerfile. Put it inline in a resource, apply it, and the build runs when the content changes.
Content-hash rebuilds
The Dockerfile, inline context files, and build args are hashed. Identical content is a no-op; changed content supersedes any in-flight build.
Unprivileged build pods
Builds run as a client against a shared build engine, so the build pod itself needs no elevated privileges.
Git history is the audit trail
The Dockerfile lives in the resource, so what built an image and when is answerable from the resource history.
Registry layer cache
Layer cache is exported to and imported from the registry, so unchanged layers are not rebuilt across runs or machines.
More in Sampleless CI
The pieces that make a build platform something a team actually lives in.
GitHub and Bitbucket triggers
The trigger match type is already structured per forge. GitLab push webhooks ship today; GitHub is the next forge in.
Operator-side commit status streaming
Phase transitions reported back to your forge by the operator itself, rather than by a step in your pipeline.
Blame and attribution in run history
Author attribution and per-phase duration histograms on every run, so you can see which change made the pipeline slower and who to ask about it.
Ephemeral per-run workspaces
An opt-in isolated workspace per run for pipelines that handle untrusted input, alongside the persistent warm workspace.
Portable automation actions
A typed action that runs identically as a pipeline step, a scheduled job, or an admission-webhook reaction — where the action itself declares which contexts may invoke it, rather than the caller claiming the right.
If one of these is the thing standing between you and a decision, tell us — we’ve pulled dates forward for customers before.
Frequently asked questions
- Why not just run self-hosted GitHub Actions runners?
- Because a self-hosted runner is still ephemeral. Every job schedules a container, pulls images, and restores caches before your first command runs, and you pay for that setup on every job forever. A warm pod pays it once. If your builds are short and infrequent, runners are fine and cheaper to adopt.
- How much faster, actually?
- On our own 11-phase build, 90 to 250 seconds became roughly 60. The gap is entirely setup, not compilation, so dependency-heavy builds gain most and a build with no dependencies gains almost nothing. We will run your pipeline during an evaluation and show you your number rather than ours.
- What happens if a warm pod dies mid-run?
- The run resumes. Queue position and completed phases survive the pod, so a node eviction or a crash picks up where it stopped instead of restarting from the top. Warm pods run on spot in our own fleet for exactly this reason.
- What is dev mode?
- Your app runs in the cluster in development mode. Changes sync from Git into the running pod, a file watcher fires, and the app reloads itself. No image is built, nothing is pushed, the pod never restarts. You iterate against real service discovery and real sidecars instead of a local approximation.
- Does an idle pipeline keep costing money?
- No. Pipelines reclaim to zero on a window you set, releasing their storage with them, so a pipeline nobody has run this month costs nothing. The next run re-provisions and pays a single cold start.
- How disruptive is migrating?
- Pipelines are Kubernetes resources rather than YAML in your repo, so migration is a translation of your existing stages, not a rewrite of your build. Most teams move one pipeline first, run it alongside the incumbent, and compare wall-clock before moving the rest.
See a warm run
The fastest way to understand the difference is to watch the same pipeline run twice.