From the team behind aidrop.it — one workspace to build, host, and keep changing your code.
A host can look for abuse in three places: at signup, when an address opens to the internet, and after somebody reports it. Signup checks measure the person and see no application, because nothing has been published yet. The moment worth checking is the one where harm becomes possible: when the lock comes off an address. Judge there, automatically when the result is clean, and reserve a person for disputes.
The response side has a shape too. Stop the address first, keep the code and the data, and treat deletion as the last step rather than the first, because on a host that keeps no backups it is the one step nobody can undo.
Signup checks measure the person, not the application
A card on a free plan, a phone number, an identity document, a review queue before the first deploy: each answers "who are you", and none answers "what will this address show". They cost every honest user a step and cost a determined abuser a prepaid card. The application they are supposed to judge does not exist yet.
That is why signup friction tends to grow without catching more. Each incident adds a check for the next person, and the check is placed where the evidence is thinnest. A host that wants to be judged on what it hosts should look at what it hosts.
Publication is where harm becomes possible
An application behind a password harms nobody, whatever it contains. The moment worth a check is when that lock comes off, because a check run then sees exactly what a visitor would see. It can run automatically, pass a clean application without a person in the loop, and hand only the disputed cases to a human.
Two properties keep such a check honest. It must fail closed: a check that could not run is not a check that passed, so an outage of the checker refuses to publish rather than waving everything through. And closing must never depend on it: after a close, the internet sees a password form, and no check should be able to hold an address open.
This is making publication a deliberate act, seen from the host's side. If opening an address is a decision somebody takes, it is also the one moment a host can judge what is being opened.
Stop first, delete last
A takedown should run as a ladder, and the rungs should be far apart. Stop the application, so the address stops answering while the code and the data remain. Remove the deployment. Suspend the account or the team. Delete. Each step should be reversible except the last, and the last should be reserved for abuse that is severe, deliberate or unlawful.
The gap between "stopped" and "deleted" is where your options live. While the application is only stopped, an export still works and a reply to the notice can still restore it. A host that keeps no backups makes deletion final by definition, which is exactly why it should not be the first response. The clocks differ from the non-payment ones, and an abuse suspension usually runs shorter.
Two more things to expect. Reports should be read by a person, not a filter, and you should be able to reply to a notice and have the measure lifted when the cause is gone. A custom domain pointed at a removed deployment stops resolving to the host; the name itself stays yours.
The ladder, to fill in once per host
Answer this from the abuse policy and the terms, link the source, and keep it with the project. A blank line means the host has not said, and "has not said" is the answer to plan around, the same way it is for the questions about leaving.
# Takedown ladder — <host>, checked <date> by <name>
## Where it judges
- [ ] At signup: card / phone / identity / review queue / nothing
- [ ] At publication: automated check / human review / none
- [ ] After a report: read by a person? yes / no
## What it does first
- [ ] First response: request to fix / stop / remove / suspend / delete
- [ ] A stop keeps: code / data / address / custom domain
- [ ] Days from suspension to deletion: ____ warning before? yes / no
- [ ] Export works while stopped? yes / no / needs a ticket
- [ ] Backups exist after deletion? yes / no → my export is the only copy
## How I get it back
- [ ] Where to dispute: reply to the notice / email / form / nowhere stated
- [ ] Lifted when the cause is removed? yes / no
- [ ] Does paying lift an abuse suspension? yes / no
Source: <link to the abuse policy and the terms>
FAQ
Why does a free hosting plan ask for a credit card? Mostly to raise the cost of repeated trials and throwaway accounts. It measures the person at signup, not the application, and it does nothing about an application that turns abusive after it is published. Treat it as a friction decision, not a safety one.
What happens when a host suspends my app for abuse? It depends on the host, which is why the ladder above exists. The good pattern is a request to fix, then a stop that keeps code and data, then a longer clock before anything is deleted, with a person reading the report and a way to reply. The bad pattern is deletion on the day of the report.
Does aidrop.it review my app before I can deploy? No. An address is public from its first deploy, and nothing reviews the application before it runs. Abuse is handled when it is reported: a person reads the report, the address is closed first if it has to be, and deletion is the last measure because aidrop.it keeps no backups.
Can I dispute a takedown? You should be able to reply to the notice you received, explain what happened and what was corrected, and have the measure lifted when the cause is gone. If a policy names no way to dispute, that is a finding about the host.
One workspace to build, host, and keep changing your code
The repository, what the project knows, the rules a change has to follow, and the path to an address — kept together, and reachable by the coding agent your team already uses.