Stopped Is Not Deleted

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

"I removed the service" can mean three different things, and the difference is what is still there afterwards. A stopped application keeps its address, its image and its data. A deleted service loses the running application and the address but keeps the code. A destroyed database loses the data, and nothing brings it back.

Ask what each verb leaves behind, not what it removes. The removal is the part everybody agrees on. The leftovers — an address that still resolves, a reservation still counted against the plan, a database another service is still reading — are what turn "I deleted it" into a bill, a 503 a customer finds, or a dashboard that says Running over something that is not.

Stop keeps everything except the process

A stop scales the application to zero and removes nothing. The image that was running is kept, so a start resumes it without a build. The data in the backing services is untouched. The address is kept too, and that is the surprise: it still resolves, but the edge has nothing to send the request to, so a visitor gets an error page rather than nothing.

Keeping the address is deliberate. Removing it would take the network and the name with it, and a start would then be a redeploy rather than a resume. The cost is that "the address exists" stops being evidence of anything. A status that infers Running from a live address will say Running over a stopped application; the deployment's own state is the only honest source.

Delete removes the application and keeps the code

Deleting a service removes the running application from the cluster and withdraws the address, in that order, and stops if the cluster cannot confirm the application is gone — a service archived while still serving is the failure worth refusing over. Then the record is archived. The repository is not touched, and neither is the image registry.

What it also does is unlink, not destroy. A database the service was attached to may be serving another service mid-transaction, so the delete removes the link and leaves the instance. That is why the two verbs are separate: a delete can be undone by a new build of the same code, and a build is not a pure function of a commit, but the data is still where it was.

Destroy is the one with no undo

Destroying a backing service deletes the data in it, and if the host keeps no backups that is the end of it. It is the only one of the three that should ask for explicit confirmation every time, and the only one where "are you sure" is not ceremony. Before it, the sequence is always the same: take a copy, restore the copy somewhere, then destroy.

The same asymmetry decides what non-payment should do. A host that stops paying customers' applications and deletes nothing has turned a billing error into a pause; one that destroys on the day of the bounce has turned it into a loss.

What to tell the agent to report

An agent that ran one of these verbs should say which one, and what is still there. "Done" hides the difference this whole article is about. Put the report format into the instructions it reads, beside the stop rules for its deploy loop, so the person reading the conversation learns the state without asking.

WHAT EACH VERB LEAVES            address   image   data   code   billed
stop     (undo: start)           kept*     kept    kept   kept   yes**
delete   (undo: build again)     gone      kept    kept   kept   no
destroy  (undo: none)            —         —       gone   kept   no
 * resolves, answers an error until started
 ** a stopped app keeps its reservation until the service is deleted

AFTER stop / delete / destroy, REPORT:
  verb:            stop | delete | destroy
  target:          <service or backing service>, <id>
  still there:     address? image? data? code?
  still billed:    yes / no
  undo:            start | build again | none — copy taken at <time>? y/n
  who else used it: <services still attached>, or none

FAQ

What is the difference between stopping and deleting a service? A stop scales the application to zero and keeps its address, image and data, so a start resumes it. A delete removes the application and the address and archives the record; the code and the data stay where they were.

Does a stopped app still cost money? Usually, in reservation if not in usage. A stopped application keeps its share of the plan's capacity until it is deleted, and its address is still claimed. If the goal is to stop paying, delete; if the goal is to pause, stop.

Why does a stopped app's address still resolve? Because the name and the network are kept so that a start is a resume rather than a redeploy. The edge answers an error page until the application is back. A tool that reads "address exists" as "running" is wrong about every stopped app.

Which of these needs confirmation on aidrop.it? service_stop takes an explicit confirmed, as do shared_resource_delete and shared_resource_purge, because each one takes something away from a live address or a live dataset. service_delete does not: it removes the application and the address, but the repository stays and the databases are unlinked rather than destroyed, so a new service_build brings it back.