How it works
A handful of ideas explain every surface. Learn them once and the CLI, the MCP tools and the API all read the same way.
Static files, and nothing else
Every publish is files served from the edge over HTTPS. There is no server running your code: no request handlers, no environment variables read at request time, no database. A single-page app, a static-site generator's output, a folder of documents — all fine. Anything that needs to execute on request needs a different host.
This is the first thing to check against, because nothing downstream reports it as an error: a folder with server code in it publishes successfully, and the code is then served as text.
A site is a name; a deploy is a version
A site owns a subdomain and nothing else. A deploy is one immutable set of files.
Publishing never overwrites. Each deploy is stored under its own key, and going live is a single switch that points the subdomain at the new one. So:
- A site is never half-published and never blank mid-publish
- The previous version is still there afterwards, which is what makes rollback possible. How many earlier
versions keep their files depends on the plan (the pricing page lists it as "Versions kept"). Counting
goes by versions that were live, the current one included, not by age: publish six times in an hour on
a plan that keeps five, and the first can no longer be rolled back to.
get_siteand the dashboard's version list say which ones still can - Publishing the identical folder creates no deploy at all — you get "already up to date"
That last one is not a shortcut. The server compares the manifest of hashes it was sent against what the site already serves, and if every file matches there is nothing to publish. A redeploy that changed three files out of five hundred uploads three.
Two domains, and why they are different
dropto.run | The dashboard and the API. Your session lives here. |
dropto.live | Published sites. <subdomain>.dropto.live |
They are separate apexes, not separate subdomains, and that is a security boundary rather than
tidiness: if published sites shared an apex with the dashboard, JavaScript in a site somebody published
could set a cookie on the parent domain and take a dashboard session with it. Same reason netlify.app
is not netlify.com.
Nothing you publish is ever served on dropto.run. This documentation is the exception that proves the
rule — it is ours, and it is served by the front-end proxy rather than by the edge that serves sites.
Subdomains are not indexed; custom domains are
Anything served on a dropto.live hostname — the default subdomain and per-deploy preview URLs alike —
is sent with X-Robots-Tag: noindex. That is deliberate and not configurable: a page published on a whim,
by a person or by an agent, should not turn up in search results afterwards.
A custom domain does not carry the header. Attaching one is how a site becomes indexable, and it is the paid tier's job.
Reaching every edge takes about a minute
Going live writes one mapping, and that mapping propagates to edges around the world in up to roughly 60 seconds. From where you published, it is immediate: that is already your nearest edge.
So a URL that works for you and 404s for a colleague across an ocean is normal for the first minute, and not a sign anything failed.
Folders of documents
A folder with an index.html is served as-is. A folder of .md or .pdf files, with no index.html, is
served through a reader instead: sidebar of the folder tree, syntax highlighting, maths, mermaid
diagrams, PDF rendering.
Both are the same publish. What decides is what is in the folder.
Limits come from your plan
Everything countable — sites, files per deploy, bytes per file, deploys per day — is read from the plan
on the account, not hardcoded. GET /api/plans returns the table the pricing page and the pre-flight
check both read, so what a client refuses and what the server refuses cannot drift.
Publishing without an account works, on a tier of its own: those sites expire after a few days unless you sign in and claim them, and creation is counted per network address to keep bots out. A signed-in account is never limited by address.
On the free plan and on sites published without an account, every page carries a small "Hosted on dropto.run" link in a corner. It is added as the page is served, so it is not in your files. Paid plans serve the pages as you published them.
Files that are never published
A few names are dropped before anything is uploaded, from every surface — browser, CLI and chat alike:
.DS_Store · Thumbs.db · desktop.ini · .gitignore · .gitkeep · ._* sidecars · and the whole
subtree of __MACOSX · .git · node_modules · .svn · .hg · .idea · .vscode
The filtering is why: a .git directory published and then served is a repository handed to anybody who
asks.