If you’ve used cloud VMs before, you probably expect a simple answer: “I stopped it, so my stuff is still there.” On Hivenet’s Compute, that’s mostly true, with one rule that matters more than anything else.
Technically, VM persistence refers to a virtual machine or virtual desktop configuration where the user's data, installed applications, and personal settings are saved and retained across reboots, logoffs, and sessions. A persistent virtual machine (or persistent VM) is designed to keep all changes, files, and configurations between sessions, making it suitable for long-term, reliable operations where data retention is critical.
What is true for Compute? Stopping keeps your environment. Terminating deletes it. Stopped instances also don’t live forever.
If you want the quick “VM or container?” decision first, read: [[Interlink: VM or container: how to choose in 60 seconds]]. If you want the product update that introduced VMs on Compute, start here: Compute now supports virtual machines (VMs).
Note: Persistence means your data and settings are retained, but always check backup and restore options to avoid accidental loss.
The short version
Stop = pause the instance and pause compute billing. Your files, packages, and configuration stay intact. You can start it again later, but only within a limited window.
Terminate = delete the instance permanently. The instance disk is erased. There’s no recovery.
The rule that catches people: if an instance stays stopped for more than 5 days, it is automatically terminated.
What persists when you stop and start
When you stop an instance on Compute and start it again later, your environment is preserved. That includes your files on the instance disk, the packages you installed, and your configuration changes.
One important detail: stop/start preserves the environment, but it does not reserve the underlying hardware. When you start again, availability depends on demand, and you may be placed on different hardware in the same region. You should not assume you’ll get the exact same GPU back, even if the instance size matches.
What gets deleted (and when)
Termination wipes the instance and its local storage. That includes anything you left on the system disk, like datasets you downloaded, checkpoints you forgot to copy out, and “I’ll move it later” files. When a virtual machine using ephemeral storage is terminated, all data stored on the local hard drive is permanently lost.
Termination can happen in a few ways:
- You make a termination request manually from the console to delete the instance.
- It auto-terminates after 5 days in the stopped state.
- It may be terminated if your credit balance gets too low while it’s running (Compute uses a short pre-emptive window to avoid negative charges).
A termination request can fail if, for example, the instance is protected from deletion or if the request includes an incorrect instance ID. In such cases, the termination process does not succeed and the instance remains active.
If you want the exact wording and current behavior, the docs are the source of truth.
Storage options: ephemeral vs persistent disks
You'll find two main storage types when you launch a virtual machine on any cloud platform: ephemeral disks and persistent disks. You need to understand these differences to protect your data and make your instance work as expected.
Ephemeral disks attach directly to your VM and live only as long as that instance runs. People also call them local or instance store volumes. When you delete or stop the VM, you lose any data on these disks. They work well for temporary files, caches, or data you can recreate easily. A web server might use an ephemeral disk for session data or cache files that don't need to stick around if you restart or replace the server.
Persistent storage works differently. These include attached EBS volumes on AWS or persistent disks on Google Cloud and Microsoft Azure. They stay available after you stop or delete your VM. You can design persistent virtual disks to survive instance shutdowns, reboots, or moves to different servers. Most people use persistent storage for important files, user data, app settings, and anything they can't afford to lose. You can detach the disk from one instance and attach it to another, which makes data migration and recovery simple.
The key differences come down to how long your data lasts and how much control you have. Ephemeral disks run faster and cost less for short-term use, but they won't keep your data past the current session. Persistent disks focus on reliability and backup. They let you protect important files and make sure you don't lose them if something happens to your VM.
Most companies and users mix both types. They use ephemeral disks for fast, temporary storage and persistent volumes for anything they need to save or share between instances. You might set up your app to write logs or cache data to an ephemeral disk while storing user uploads, databases, or backups on a persistent virtual disk.
Pick your storage based on your workload and what data you need to protect. If losing the data would break your app or hurt your users, go with persistent storage. If you just need fast, local space for files you can recreate, ephemeral disks will save you money and speed things up.
You need to understand how your data gets stored, what happens when your VM shuts down, and how to set up your system for the best mix of cost, speed, and reliability. Plan your storage strategy early to avoid surprises and keep your files, databases, and user data where you need them, no matter what happens to your VM.
The safest way to think about it
Treat an instance disk as a working desk, not a vault.
That doesn’t mean “don’t keep anything on it.” It means “don’t keep the only copy of anything important on it.”
A simple habit that prevents the worst outcomes:
- Keep code in Git (or whatever your team uses).
- Copy trained weights, checkpoints, and results somewhere designed for storage before you stop for the day.
- Write down setup steps you’d hate to redo, even if it’s just a short README in your repo.
For the most part, following these practices will keep your data safe and make recovery straightforward. If you lose access to important data or encounter issues, contact support for assistance.
If you’re using containers, custom templates can also help you recreate an environment quickly.
Stop vs terminate: when to use which
Use Stop when you’re taking a short break and you know you’ll return soon. It’s a “pause button,” not a parking garage. In documentation, these states are often referred to as "stopped" (for paused but restorable VMs) and "terminated" (for deleted VMs), so understanding how each state is referred to can help avoid confusion when managing your resources.
Use Terminate when you’re done, or when you’re keeping important outputs elsewhere and you want to stop thinking about the instance. It’s also the cleanest way to control costs, because nothing can accidentally keep running. Persistent VMs are suitable for applications that require administrative access and a reliable level of performance, making them a good choice for workloads where you need to maintain state or configuration between sessions.
If cost control is the reason you’re stopping, this article complements the lifecycle story: Cloud GPU VM pricing: what you’re really paying for. Developers who want to go deeper into how Hivenet positions Compute for real workloads can also read about why developers should Compute with Hivenet.
A few common questions people ask
Does stopping delete my files?
No. Stop/start preserves your environment. The risk comes from the 5-day auto-termination window and from assuming the instance disk is permanent storage.
Will I keep the same GPU after I start again?
Not necessarily. Compute doesn’t reserve the underlying GPU while stopped. When you start again, it allocates matching capacity based on what’s available.
What if my instance is in an error state?
Try restarting it from the console first. If it stays in an error state and you cannot resolve it, contact support for assistance. If the instance remains in an error state, it can be automatically deleted after a period of time. Don’t leave important data stranded there.
How do I avoid losing access to a web UI after restart?
Connectivity is a separate issue from persistence. If you’re exposing a service, make sure you understand SSH vs HTTPS vs TCP/UDP. Persistent VMs are often used to host a website or site that needs to be accessible globally, ensuring your site remains available to users. When a website is properly configured with hosting and domain registration, it can be accessed from anywhere in the world. Persistent VMs are also essential for applications needing to store data locally within the VM, such as databases or development environments requiring long-term storage.
Try Compute
If you want to learn this behavior with low risk, launch a small instance, create a file, install a package, stop it, and start it again. Once you’ve seen what persists, you’ll make better calls about what to keep on the instance and what to store elsewhere.
Tomorrow, you can try more advanced tasks, such as setting up a web server or creating a WordPress site, to further explore persistent VM capabilities.
Persistent VMs offer superior customization and a familiar user experience, making them ideal for power users rather than general task workers.
