Docs / Stop and start

Stop and start a deployment

A deployment does not have to run all month. Stop it and the GPU instance is gone and its hourly billing ends; the configuration, the API key and any staged weights stay. Resume it and the instance comes back under the same endpoint. This page describes the states, what staging changes, what the wake estimate means, and the API.

States

State	Compute billing	What it means
`ready`	yes	Serving. The endpoint answers.
`stopping`	until confirmed off	In-flight requests get up to the drain timeout to finish, new ones are refused, then the compute is turned off. Billing ends when the provider confirms the instance is gone.
`stopped`	no	Parked. Configuration, key and staged weights retained. Only a stage bills, at your provider's storage rate.
`resuming`	yes, from the create call	The instance is being created. Billing starts before the first provider call, so a lost response is still counted.
`stop_failed`	possibly	The provider could not confirm the compute is off. Treated as live for billing until you retry the stop or destroy.
`recovering`	yes	Spot only: the provider reclaimed the instance and a fresh one is booting from the stage. See Spot instances.

A manual stop places a hold: the schedule will not wake a deployment you stopped by hand until you resume it. A manual resume clears that hold and the schedule owns the deployment again from its next boundary. Budget holds are different: a deployment stopped by its budget cap or its monthly budget only starts again after the cap is raised, never by a schedule or a wake.

Staging is chosen at deploy time

A stage is a copy of the model weights in your own account, next to where the instance runs: an S3 prefix on AWS, a network volume on RunPod, a shared filesystem on Nebius, a block volume on Verda. With a stage, a resume is a warm boot: the instance reads the weights from the stage instead of downloading them again. Without one, every resume is a cold boot, the same as the first deploy.

The choice is made when you deploy, not when you stop, because the stage has to be populated by a running instance. It costs storage whether the deployment is running or stopped, and the deployment page shows that monthly line before you confirm. Several deployments of the same model and revision in the same location share one stage; the storage line appears once, on the stage, not once per deployment.

Wake estimate

The deployment page shows how long a resume is expected to take. Until three resumes have been measured it is the readiness allowance you consented to, labeled as an estimate. After that it is the median of your own resumes, labeled as measured. It is never a guarantee: the provider has to have a GPU of the consented shape free, and a resume that finds none walks the fallback shapes you confirmed, then waits and retries. If it cannot start inside its allowance the deployment stays stopped and shows the reason it could not resume.

The stopped endpoint

What a client sees while the deployment is stopped depends on the gateway placement chosen at deploy.

Node-local (default). The gateway runs on the instance, so while the instance is gone the hostname has nothing to answer. Clients see a connection error until the resume completes.
Hosted or private edge. A small always-on gateway answers the hostname. A stopped deployment returns HTTP 503 with a stable JSON body and a Retry-After header; with wake-on-request enabled, the first authenticated request starts the deployment and the body says so.

HTTP/1.1 503 Service Unavailable
Retry-After: 120
Content-Type: application/json

{
  "status": "sleeping",
  "deployment": "9c1e0b0e-...",
  "message": "the deployment is stopped. It starts on its schedule, on request from its owner, or on the next authenticated request when wake-on-request is on",
  "next_start": "2026-09-03T06:00:00Z",
  "wake": { "waking": false }
}

status is one of sleeping, waking (a start is in flight; wake.estimate_seconds sizes the retry), gated (the deployment is warmed up ahead of its window and opens at next_start) and draining (a stop is in progress). Unauthenticated requests never wake anything: the key is verified before any side effect, and a key over its limit gets 429.

API

# Stop (in-flight requests get the drain timeout to finish)
curl -X POST https://app.llmhangar.com/v1/deployments/$ID/stop \
  -H "Authorization: Bearer $TOKEN"

# Resume
curl -X POST https://app.llmhangar.com/v1/deployments/$ID/resume \
  -H "Authorization: Bearer $TOKEN"

# Wake (the same wake an authenticated request triggers; 202 when it fires)
curl -X POST https://app.llmhangar.com/v1/deployments/$ID/wake \
  -H "Authorization: Bearer $TOKEN"

# Drain timeout, idle autostop, minimum runtime, soft monthly budget
curl -X PATCH https://app.llmhangar.com/v1/deployments/$ID/lifecycle \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"drain_timeout_seconds": 120, "idle_stop_minutes": 30, "min_runtime_seconds": 600, "monthly_budget_usd": 400}'

Every stop and resume is an audited event on the deployment and a webhook delivery when you have endpoints configured (see Schedules for signature verification). The deployment's current_attempt names the shape it is provisioned as right now, so a resume that fell back to a consented fallback shape is visible, not silent.

Quotas and fees

Your provider bills the GPU hours and the storage at its own rates; LLM Hangar never resells compute. The LLM Hangar plan fee is a flat monthly amount that does not change with how many hours the deployment runs. A stopped deployment counts against the deployments included in your plan the same as a running one.