Stop GPU Instance Without Losing Data: Spheron's Park Feature

Spheron shipped a feature on 5 September 2026 to let you stop a GPU instance without losing data. Before v1.27.0, hitting Stop on a Spheron instance meant destroying it, disk included. Now Stop parks the machine instead: the GPU stops billing, the disk stays exactly where it was, and Start brings it back when you want it.

TL;DR: Stop, Park, and Terminate on Spheron, in One Table

Spheron's Stop control now parks a GPU instance instead of destroying it: the GPU-hour billing stops, and the disk and IP stay put, as of the 5 Sep 2026 release.

Stop is self-serve on Spheron AI and Spheron ES. See Spheron's H100 pricing for a live rate to run the savings math against.

What Changed: Now You Can Stop GPU Instance Without Losing Data

The mechanics are in the changelog entry itself: "Stopping an instance used to mean destroying it. Now it parks: the GPU stops billing, the disk and everything on it stays exactly where it was, and you start it again when you want it." That's a real behavior change, not a UI relabel. Before v1.27.0, hitting Stop on a Spheron instance meant the same thing as Terminate does today: the disk went with it.

The practical effect is that a GPU instance now has a genuine middle state between running and gone. If you've been terminating dev and test instances every evening and redeploying from a fresh image every morning to avoid paying for idle GPU time, that's the exact workflow this closes. Spheron's overview docs describe it the same way from the feature side: "Stop instead of destroy: Park an instance you will come back to. Stopping releases the GPU and drops billing to the disk rate while the disk and everything on it stays in place," and starting it again "returns the same environment on the same public IP."

That last detail matters more than it sounds like it should. A restart that hands you a new IP address means updating DNS, SSH config, and anything else pointed at the old address. Park doesn't do that. Whatever pointed at the instance before Stop still points at it correctly after Start.

GPU Cloud Instance Lifecycle Management: Where Park Fits

A GPU instance moves through a small number of states, and each one means something different for your bill. Here's the full lifecycle as Spheron implements it:

Restart is a different operation from Stop, worth separating out because the two get confused. Per the changelog: "A restart reboots in place. Your billing does not change and the instance keeps its status." Stop changes your instance's billing state; Restart doesn't change anything except that the machine rebooted.

Detached persistent storage sits outside this lifecycle entirely. Spheron's overview docs note you can "create persistent storage volumes that exist independently from your instances," and "attach a volume to a running instance, detach it without losing data, and reattach it to a different instance later." That's a second way to keep data alive across instance changes, useful when you want to move a dataset to a different GPU type rather than pause the same instance.

The Billing Math: What You Pay Stopped vs Running

A parked instance is cheaper than a running one, but it isn't free, and Spheron shows you the exact trade before you confirm. The stop dialog, per the changelog, "quotes both rates before you commit. It shows what the instance costs running, what it will cost stopped, the saving as a percentage, a monthly figure for leaving it that way, and an itemised list of what is still being charged."

Worked example: Spheron's on-demand H100 runs $2.64/hr as of 05 Oct 2026. Parking that instance drops the GPU-hour charge to zero and leaves you paying only for the retained disk and, where the provider charges for it, the dedicated public IP. Spheron's own persistent-volume storage rate was roughly $0.00016/GB/hr as of 12 May 2026, which is a separate storage product from the disk bundled into an instance's hourly rate rather than a direct stand-in for it, but it gives you the right order of magnitude: storage for a 2TB disk at that rate works out to well under a dollar an hour even before any volume discount applies. The GPU, not the disk, is almost always the expensive part of the bill, which is exactly why parking instead of terminating saves real money on a workload you're coming back to.

The one caveat that actually bites people: a stopped instance still costs something, and it still needs a funded account behind it. Parking an instance protects it from an accidental Terminate click. It does not protect it from an empty balance.

Pricing fluctuates based on GPU availability. Spheron rates above are live as of 05 Oct 2026; other providers reflect their most recent published rates and may have changed. Check current GPU pricing → for live rates.

Step-by-Step: Parking and Restarting an Instance on Spheron

1. Open the instance card or its details panel. Stop and Start are self-serve controls in both places, no ticket needed.
2. Select Stop. The confirmation dialog shows the running rate, the stopped rate, the percentage saved, a monthly projection for leaving it parked, and an itemized list of what's still charged (disk, plus a public IP where the provider bills for one).
3. Confirm. The GPU releases immediately and billing drops to the stopped rate. The disk and its contents don't move.
4. Start it again whenever you need it. The instance comes back with the same disk, the same contents, and the same public IP, so any saved SSH config or connection string still resolves correctly.

That's the whole flow for an instance type that supports it. Not every instance type does, which is the part worth checking before you build a workflow around it.

Which Providers Support It and Which Don't

Spheron aggregates 5+ providers on its backend, and Stop/Park isn't uniform across all of them.

On Spheron AI specifically, the limiting factor isn't a blanket rule, it's inventory: "On Spheron AI it also depends on the machine type and the region: roughly half of one upstream's catalog cannot hibernate, and one region refuses to shut instances down at all." When a machine type or region can't support it, the deploy summary and instance panel say which of the three reasons applies, since the fix differs depending on whether it's the machine type, the region, or the provider itself.

Outside Spheron's own aggregated set, Hyperstack offers a comparable control called VM hibernation, which saves VM state and pauses billing without a full cold start. It's a genuine advantage for session-based workflows, with the caveat that GPU VRAM contents (loaded model weights) aren't guaranteed to persist across a hibernation cycle on a standard cloud VM the way disk state is. Spheron's Park keeps the disk; it isn't a VRAM snapshot either, since the GPU itself is released on Stop.

When to Park vs When to Terminate for Good

Park when you're coming back to the exact same environment: a dev box you use during business hours, a fine-tuning setup you're iterating on across a few days, or any instance where re-provisioning and reinstalling dependencies costs you more time than the stopped-rate disk charge does. Startups running intermittent dev and test GPU workloads are the clearest case: paying the running rate 24/7 for a GPU that's only in active use during working hours is the kind of idle-GPU cost that adds up fast, the same mistake one team traced back to a starved dataloader rather than a genuine compute shortage once they actually measured utilization instead of assuming it.

Terminate when the workload is actually done, or when the instance type doesn't support Park at all, like Spheron MS bare metal. There's also a middle case Park doesn't solve: moving a workload to a different provider or a different GPU entirely, as opposed to pausing it on the same one. That's a migration, not a pause, and it needs portable checkpoints and a cutover plan rather than a Stop button.

And if you're running training on a provider or instance type where Park isn't available, or on spot capacity that can be reclaimed without notice regardless of Park support, checkpointing discipline is still doing the job Park does for a stoppable instance. Spot GPU training resilience covers the checkpoint intervals and preemption-recovery pattern that keeps a run safe when there's no parking option to fall back on.

Picking up a paused project shouldn't mean rebuilding the environment from scratch. Spheron's Stop control parks the GPU instance, keeps the disk exactly as you left it, and brings it back on the same public IP when you're ready.

Get started on Spheron →