“Per-second billing” sounds simple: run something for 10 seconds, pay for 10 seconds.

For disposable infrastructure, that detail matters a lot.

RackMint is designed around short-lived Kubernetes environments. A cluster might exist for an hour, 20 minutes, or sometimes just a few minutes. If billing worked in large time increments, disposable environments would quickly become less disposable.

So we built billing around actual runtime.

The clock starts when the environment starts

When you create a RackMint cluster, the environment goes through its normal provisioning lifecycle.

Once the cluster is running, usage begins accumulating based on how long the underlying compute is allocated to that environment.

If your cluster runs for:

• 47 seconds → you pay for 47 seconds
• 8 minutes 32 seconds → you pay for 8 minutes 32 seconds
• 51 minutes → you pay for 51 minutes

There isn’t a requirement to keep the environment around for a minimum hour just because you needed it for a few minutes.

That makes a difference when environments are created automatically.

Why per-second billing matters for branches

Consider a team with 20 pull requests.

Instead of deploying all of them into one staging cluster, you can give each branch its own Kubernetes environment.

A typical lifecycle looks like this:

Create cluster
     ↓
Deploy application
     ↓
Run tests / review
     ↓
Branch merged
     ↓
Cluster deleted

If a preview environment only exists for 12 minutes, the infrastructure shouldn’t economically behave as if it existed for an entire day.

Per-second billing makes the lifecycle match the cost model.

Billing and TTL work together

RackMint environments can have a TTL.

That means you can create an environment with a defined lifetime and let the platform clean it up automatically when you’re done.

This is important because disposable infrastructure isn’t particularly useful if someone has to remember to manually delete every environment.

The combination is what makes the model practical:

TTL controls how long the environment lives. Per-second billing controls how much that runtime costs.

You can create environments aggressively without creating a collection of forgotten infrastructure that runs overnight.

What about the compute underneath?

RackMint can manage Kubernetes on customer-owned compute, including VPS, EC2, or bare-metal infrastructure.

That means the billing model isn’t based on pretending that every Kubernetes resource is independently consuming a tiny cloud instance.

The environment has a real lifecycle on real compute.

This is particularly useful for teams that want the isolation of a separate Kubernetes cluster without having to provision an entirely new long-lived cloud infrastructure stack for every branch or test run.

The point isn’t cheaper Kubernetes

Per-second billing isn’t interesting because “seconds” are a nicer billing unit.

It’s interesting because it changes what is economically reasonable to automate.

When infrastructure is expensive to leave running, teams naturally create fewer environments, share more infrastructure, and tolerate more staging drift.

When environments can be created, used, and destroyed quickly, you can make a different tradeoff:

Create the environment when you need it. Use it for as long as you need it. Delete it when you’re done. Pay for the time it actually existed.

That’s the billing model we wanted for disposable Kubernetes. """