﻿# Vast.ai Stop and Destroy: instance and data lifecycles

Understand Vast.ai Stop, Restart and Destroy, including retained files, storage billing, GPU availability and a verified export before deletion.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/vast-ai-instance-lifecycle-stop-destroy/
Language: en

Vast.ai Stop pauses an instance and preserves its data while storage charges continue. Destroy permanently deletes the instance and its data. Restart attempts to obtain compute again, so preserved storage and immediate GPU availability are separate properties.

## Read the state literally

The management guide distinguishes Inactive, Scheduling, Offline and other states. Inactive describes stopped compute with retained data. Scheduling indicates an attempt to obtain GPU resources. Offline describes a machine disconnected from the platform, rather than a deliberate user pause.

Keep instance ID, machine ID and rental end date outside the instance. A saved SSH command cannot explain the current contract or availability. Those details can change independently of the profile stored on a laptop.

## Account for the paused disk

Stopped instances continue occupying billable storage. Pricing separates compute, storage and bandwidth, so Stop should not be treated as a promise that all expense ends.

Give each paused resource an owner and a review date. Compare the cost of retention with the work of rebuilding a reproducible environment. Irreplaceable results still need a verified copy; reducing the bill is not a reason to remove unidentified data.

## Plan for a waiting restart

An instance attempting to restart may need to wait for available GPU capacity. For a deadline-sensitive task, prepare a separate restoration route instead of relying solely on the original instance's play button.

For example, an image-processing team stops overnight and finds compute unavailable the next morning. Saved configuration and exported progress make another resource a practical option. If the only useful state lives in the old process, a retained disk alone may not solve the problem.

## Verify data before Destroy

Stop writers, identify required data and configuration, copy them through a supported path and test reading the result. Check the instance ID before deleting. Do not use the only project copy to experiment with deletion behaviour.

Rental expiration is not an indefinite archive arrangement. Allow time for transfer before the contract ends. Your final record should state current status, saved-copy location, recovery instructions and any intentionally retained resources. A new environment should read a control result and find its inputs without depending on the old container for undocumented setup details.

For a pause of unknown duration, keep a dated decision rather than leaving the instance indefinitely without a responsible project owner.

## Turn the check into a practical next step

Stop preserves instance data and storage charges; Destroy removes the instance. Retained files do not guarantee that compute can restart immediately.

For the documented details, consult the [primary documentation](https://docs.vast.ai/guides/instances/manage-instances); [configuration reference](https://docs.vast.ai/guides/instances/pricing). Continue with [vast ai copy data between instances](/journal/vast-ai-copy-data-between-instances/) and [vast ai storage network charges](/journal/vast-ai-storage-network-charges/).
