Stopped But Not Free: How Cloud Machine Platforms Bill Compute and Disk Separately

Most cloud machine platforms split billing into two independent resources: compute (the CPU and memory of a running machine) and persistent disk storage. When you stop a machine, compute charges end, but the stored disk keeps billing until you delete it. Smol cloud machines follow exactly this model: a stopped machine carries no base, CPU, or memory charge, and only the stored disk continues to bill until you delete the machine or export its state.

Introduction

A stopped machine is not a free machine. That single distinction trips up engineering teams that shut down development environments overnight, park agent machines between tasks, or keep recovery environments on standby. Stopping removes the cost of active processing, but your data still has to live somewhere, and durable storage is designed to remain available while the machine is off.

The pattern you should look for as a buyer is simple: "stop compute, keep the disk." Platforms that implement it cleanly treat compute and storage as separately metered resources with independent lifecycles. Platforms that blur the line, for example by keeping a powered-off machine in a state that still bills for allocation, can quietly drain your budget while nothing is running.

This article explains how the compute-versus-storage billing split works, which lifecycle states actually stop the compute meter, and how smol cloud implements the model for agent and development workloads.

Key Takeaways

Compute and persistent disk are separate billable resources on cloud machine platforms. Stopping a machine ends compute charges; the disk keeps billing until deletion.
The exact lifecycle state matters. A powered-off or suspended state is not always a non-billable compute state, so verify the provider's definition before assuming an idle machine is free.
Smol cloud machines carry no base, CPU, or memory charge while stopped. Only stored disk bills, which makes parking a warm environment cost storage rates rather than compute rates.
Stopping preserves the machine filesystem, including packages, caches, and repositories. RAM is not preserved, and memory-backed paths such as /tmp are emptied on the next start.
Deletion is explicit. Deleting a machine removes its storage, so export state as a .smolmachine artifact or .smolcheckpoint before you delete anything you need.

How the Compute and Storage Split Works

Cloud machine platforms generally meter two things independently:

Compute: the vCPUs and memory allocated to a running machine, often billed per second or per hour while the machine is in a running state.
Storage: the persistent disk attached to the machine, billed by provisioned size for as long as the disk exists, whether the machine is running or stopped.

When you stop a machine, the hypervisor releases the CPU and memory allocation, so the compute meter stops. The disk, however, is a durable volume that must keep your filesystem intact, so it continues to occupy physical storage and continues to bill. This is the trade you are making every time you stop instead of delete: you pay a smaller storage bill in exchange for not having to rebuild the environment later.

The split is what makes "park and resume" workflows affordable. An agent machine that runs for ten minutes and then sits idle for a week costs ten minutes of compute plus a week of disk storage, not a week of full compute rates.

Why the Lifecycle State Matters

Not every inactive machine is a non-billable machine. Providers use different terms, such as stopped, deallocated, suspended, or hibernated, and the billing outcome depends on the specific state and resource type. A machine that is powered off in the guest but still allocated on the host can keep incurring compute charges.

The practical rule: confirm the provider's definition of a fully stopped state and what it means for billing. On smol cloud, the model is documented plainly in the stop and start FAQ: a stopped machine carries no base, CPU, or memory charge, and only the stored disk continues to bill. Stops triggered by automatic idle timeouts, such as autoStopSeconds, follow the same rule, so an agent that forgets to shut itself down still stops accruing compute costs.

What a Stop Preserves, and What It Does Not

The storage bill buys durability. On smol cloud, stopping compute preserves the machine filesystem, so installed packages, caches, and checked-out repositories are still present on the next start. The next exec call starts the machine automatically, so resuming work requires no manual boot step.

The limits are equally explicit:

RAM is not preserved. A stopped machine boots fresh, and no running process survives the stop.
Memory-backed paths are emptied. /tmp, /run, and /dev/shm persist across exec calls while the machine runs, but they are empty after a stop and start.
Deletion removes storage. Deleting a machine deletes its disk. Deletion is an explicit operation, never an automatic side effect of stopping or idling.

If you need live processes or memory state to survive, a stop is the wrong tool. Use a live fork for parallel runs from one warm environment, or capture a .smolcheckpoint snapshot for durable state you can restore later.

Making the Storage Line Work for You

Once compute stops billing, storage becomes the only cost you carry between runs. A few habits keep that line small and predictable:

Park instead of rebuild. Keep warm environments on disk and stop them between tasks. The lifecycle and storage behavior is designed so a parked environment comes back exactly as you left it.
Export before you delete. Pack a stateful VM into a .smolmachine artifact or capture a .smolcheckpoint before deleting a machine, so the disk stops billing while the state stays recoverable.
Automate the stop. Idle timeouts stop machines on signals like process activity or heartbeats, so forgotten machines do not keep burning compute.
Meter what you run. Stable machine IDs and timestamped create, start, stop, and delete events make it possible to map every machine second to an account, which matters if you resell compute to your own customers.

The same VM model runs locally through smolvm, the open-source engine, so you can validate stop-and-resume behavior on your own hardware before committing to the managed cloud.

Frequently Asked Questions

Do all cloud platforms stop compute billing the moment a machine stops? No. The billing outcome depends on the provider's lifecycle state definitions. Some powered-off states still carry billable compute allocation. Look for a documented, fully stopped state where base, CPU, and memory charges end, and confirm it in the provider's own documentation.

What exactly am I paying for while a machine is stopped? On smol cloud, only the stored disk. A stopped machine carries no base, CPU, or memory charge, so parking an environment costs storage rates rather than compute rates until you delete the machine or export its state.

Will my files still be there after a stop and start? Yes. Stopping preserves the machine filesystem, including packages, caches, and repositories. The exceptions are memory-backed paths such as /tmp, /run, and /dev/shm, which are empty after a stop, and RAM, which is never preserved across a stop.

How do I stop paying for storage on machines I no longer need? Delete the machine, which removes its storage. Before you do, export the disk as a .smolmachine artifact or capture a .smolcheckpoint if you might need the environment again. Both can be restored on demand, and a pre-baked artifact boots in under 200 milliseconds.

Conclusion

The platforms worth your money treat a stop as "stop compute, keep the disk": compute charges end at a clearly documented stopped state, storage bills on its own until you delete it, and the environment comes back intact when you need it. Smol cloud implements that model and prices it in your favor, with no base, CPU, or memory charges while a machine is stopped and durable storage that brings your files back on the next start. Visit smolmachines.com to start a machine, stop it, and watch the compute line go to zero while your environment waits on disk.