Netlify Drop: The Fastest Way to Put a Folder on the Internet

Netlify Drop takes a folder containing an index.html, uploads it, and hands back a live HTTPS URL on a random subdomain. No account, no git repository, no build configuration, no command line. It takes about ten seconds.

The feature has been around in one form or another since 2013, which by web-platform standards makes it ancient. It survives because it answers a question nothing else answers as directly: I have a folder, I want a link, right now.

It is also the origin story for a lot of production sites, which is where the interesting part is — knowing when the drag-and-drop deploy has stopped being the right tool.

Table of contents

• What it does, exactly
• What it is genuinely good for
• Where it stops, and the signals to watch for
• The upgrade path is short
• The distinction that actually matters
• How this fits the rest of the stack
• FAQ

What it does, exactly

You visit the drop page and drag a folder onto it. The folder needs an index.html at its root. Within seconds you get a URL on a randomly generated subdomain, served over HTTPS from a global CDN.

Two things are less obvious:

• It can build, not just serve. Drop a project folder for a framework like Astro, Vite or Next.js and the build runs server-side rather than requiring you to produce dist/ first. That widens the useful range considerably.
• The deploy is anonymous but claimable. A site deployed without an account exists in a temporary state. Signing in afterwards claims it into your account, at which point it gains a custom domain, deploy history, and everything else. If you never claim it, it eventually goes away.

That claim step matters more than it sounds. An unclaimed URL is not a place to put anything you would be annoyed to lose.

The same endpoint is available to automated clients, which is how a lot of AI coding tools publish their output — the model generates a site and pushes the folder through the same path a person would drag it onto.

What it is genuinely good for

The honest use cases, where nothing else is faster:

• Showing a client a static mockup without explaining git, or waiting for a build pipeline.
• Sharing a one-off HTML report — a coverage report, a generated dashboard, a Lighthouse output — with someone who will not run a local server.
• Testing whether something works on a real HTTPS origin. Service workers, the clipboard API, camera access and crypto.subtle all require a secure context, and file:// is not one.
• Teaching. A first-time HTML learner gets a real URL for their work without an account, a terminal, or a lecture about version control.
• Checking a build output you suspect is subtly broken. Serving dist/ from a CDN reveals path assumptions that a local dev server papers over.

That last one is underrated. A remarkable number of build outputs work perfectly on localhost and break on a real origin, because something references an absolute path that only exists on your machine or assumes a base URL of /.

Where it stops, and the signals to watch for

The limits are not arbitrary — they follow from what the tool is. It uploads a folder of files and serves them. Everything a folder of files cannot do, it cannot do.

• No deploy history worth the name. You dragged a folder. There is no commit, no diff, no answer to what changed and who changed it. Rolling back means finding the old folder on somebody’s laptop.
• No repeatability. The next deploy is another manual drag, by whoever happens to be around. This is the failure mode that arrives quietly: the person who deploys goes on holiday.
• No environment variables. Anything secret in that folder is public. An API key in a JavaScript bundle is readable by anyone who opens devtools, and no amount of minification changes that.
• No server-side anything. A contact form has nowhere to submit to. Authentication has nothing to authenticate against. A database has nothing to connect from.
• No preview per change. No branch URLs, because there are no branches.

The signal that you have outgrown it is usually one of three sentences: can you redeploy this, I fixed a typo; where do the form submissions go; or which version is live right now. Each one is the tool telling you it has finished its job.

The upgrade path is short

Moving from a dragged folder to a repository-driven deploy is a smaller step than it looks, and it is worth taking at the first sign of the sentences above.

1. Put the folder in a git repository. Even a local one, even with a single commit — you now have a record of what changed.
2. Push it somewhere. GitHub is the usual answer.
3. Connect the repository to a host, specify the build command and the output directory, and deploy on push.
4. Move anything secret out of the bundle and into environment variables that are read at build time or on the server.

The whole thing is fifteen minutes and you get back deploy history, rollback, per-branch previews, and a deploy that anyone on the team can trigger by merging. The manual drag becomes something you do deliberately for one-offs rather than as your release process.

The step people skip is the fourth. Dragging a folder trains a habit of putting configuration in the files, because there is nowhere else to put it. That habit outlives the tool, and it is how keys end up in bundles.

The distinction that actually matters

Static hosting serves files. That covers a genuinely large share of the web — documentation, marketing sites, blogs, portfolios, generated reports, client-rendered applications that talk to an API somewhere else.

What it does not cover is anything with state. The moment your site needs to remember something between visits, accept a submission, check a password, or run code that you would rather users could not read, you need a process running somewhere with a database behind it.

There is a familiar sequence here. A landing page goes up as a folder. Then it needs a signup form. Then the signups need to go somewhere. Then somebody needs to log in and read them. Each step is small, and by the end you are running an application with a static site’s deploy process bolted on the side.

None of that is an argument against dragging a folder. It is an argument for noticing which of the two things you are building, ideally before the form appears.

How this fits the rest of the stack

The drag-and-drop deploy is the right answer to a narrow question and the wrong answer to the one that follows it. Once a project needs a form endpoint, a login, or anything it must remember, the folder is no longer the unit of deployment — the application is.

RunxBuild covers both halves on one platform. Static sites build from a GitHub repository with custom domains, headers, redirects, SPA fallback and 120GB of bandwidth included, then $0.10/GB. When the site grows a backend, a web service in Node, Python, Go, Ruby, Java, .NET or Docker deploys the same way, with environment variables kept out of the bundle, a managed MySQL or Postgres beside it, build and runtime logs in one place, and rollback to the previous deploy. To see what the site plus its API and database actually come to, the RunxBuild hosting calculator puts each piece on the page as its own line item.

Useful related references:

• MySQL Delete Database: DROP DATABASE and Recovery Considerations
• psql Drop Database: DROP DATABASE, FORCE, and the Active-Session Trap
• Postgres Drop Index: Doing It Without Locking the Table
• Services on RunxBuild

FAQ

Do I need an account to use Netlify Drop?

No. You can deploy anonymously and get a working HTTPS URL immediately. That deploy is temporary, though — signing in afterwards claims the site into your account, which is what gives it a custom domain, deploy history and permanence. An unclaimed site eventually disappears, so do not put anything there you would mind losing.

Can Netlify Drop build my project, or do I have to upload dist?

It can build. Dropping a project folder for a framework like Astro, Vite or Next.js triggers a server-side build rather than requiring you to produce the output directory yourself. Uploading a pre-built folder also works and is faster, since there is nothing to compile.

Can I add a custom domain to a dropped site?

Only after claiming it into an account. An anonymous deploy lives on a randomly generated subdomain with no domain settings attached. Once claimed, it becomes an ordinary site with the usual domain and certificate configuration.

Can a drag-and-drop site handle a contact form?

Not on its own. Static hosting serves files; a form needs something server-side to receive the submission. Netlify offers a forms feature for sites configured to use it, but that is a platform feature rather than something a dropped folder gets automatically. Anything that must remember state needs a backend.

Is it safe to put API keys in a dropped site?

No. Everything in that folder is public, including anything inside a JavaScript bundle — minification is not concealment, and devtools shows the whole thing. Secrets belong in environment variables read at build time or on a server, which means moving to a repository-driven deploy.