STATIC HOSTING FOR DEVELOPERS
Static hosting for developers with a finished build
Put a prototype, docs build, demo or generated report online without adding a repository integration to a project that may only need one review round. Build locally, upload the output, share the URL.
Free plan, free SSL, no credit card.
- 23
- framework guides with the build command and output folder
- 96
- accepted file types across sites and documents
- 25
- publishes a day on the free plan
- 0
- server-side runtimes in the visitor path
How it works
Three steps, start to live link
-
Build on your machine
Run the framework build you already trust and find its output folder. The deploy guides name the command and folder for common static frameworks.
-
Upload only the output
Drop the dist, build, out or public folder, not node_modules and not a source tree that still needs a bundler. A single self-contained JSX or TSX file is the narrow no-build exception.
-
Put the URL in the work
Share the live browser result in a pull request, ticket, demo note or review call. Re-publish the next build behind the same address.
What developers actually send
What developers actually send
Static hosting for developers serves files that are already ready for a browser: HTML, CSS, JavaScript, images, fonts and media. It is the last mile for a built demo or document, not a build service and not an application server.
The artifact is often smaller than the infrastructure normally used to publish it. A proof of concept may need a URL for an afternoon. A docs build may need to survive a release review. A generated coverage report may need to be opened by somebody outside the local network. In those cases a browser preview link answers the requirement without teaching the project a new CI provider.
The boundary is the build output. Vite usually produces dist; Create React App usually produces build; a static Next.js export produces out. The framework guides keep those commands and folders together. If an AI tool gave you one self-contained React component, single-file React hosting can run .jsx or .tsx in the browser, but a component importing third-party packages still needs its project build.
- Prototype A working interaction for a product conversation, with enough fidelity to click rather than explain.
- Built application demo The static output of Vite, React, Vue, Astro or another framework after the local build succeeds.
- Documentation A generated docs site, reference or release guide that should be readable without cloning the repository.
- Test or coverage report An HTML report produced by a tool, preserved as its own reviewable artifact.
- Code experiment A single HTML, JSX or TSX file that has no server dependency and needs a public browser.
- Static export The browser-ready version of a project whose source repository is not itself deployable as static files.
Who it is for
Small deployment jobs that do not need a platform
The common thread is not the framework. It is that the output is complete and the next person needs a URL.
-
Prototype builders
Share a working browser preview in a ticket or call instead of recording a video of localhost.
-
Frontend developers
Publish the built ZIP or folder after the framework has produced static output.
-
AI-assisted builders
Put a generated page online through AI output hosting, with the no-build path only when the file is actually self-contained.
-
Docs maintainers
Use the framework guide hub to find the output folder, then publish the generated site as one immutable deployment.
In detail
What you actually get
A strict static boundary
The server sends the files you built and never executes user code. That boundary keeps the visitor path small and makes a failed upload explainable: either the output is present or the project still needs a runtime.
- HTML, CSS, browser JavaScript, images, fonts and media are served as files.
- PHP, Node servers, API routes and server actions do not run.
- A client-side app can call an existing API when that API allows browser requests.
Immutable deploys, stable site address
Each publish creates a separate deployment and then points the site at it. A broken update does not overwrite the previous files, and the public address stays attached to the site rather than to one upload.
- The same URL opens the newest deployment after each publish.
- Rollback begins on Pro for a one-click return to an earlier deployment.
- The free plan includes up to 25 publishes a day.
A security check at the handoff
Static does not mean harmless. A copied project can still contain credentials, repository metadata or private files, so every deploy is inspected after it goes live and warnings stay attached to that deployment.
- The check looks for a published .env file, .git directory and private-key material.
- It also flags API-key patterns left in browser JavaScript.
- A warning is visible on every plan and should trigger secret rotation, not reassurance.
A route from local output to a public browser
The project can stay local or live in any source-control system. Publishing does not require a webhook, deploy key or build configuration because those are not part of this workflow.
- Use deploy guides for the exact build command and output directory.
- Use HTML hosting when the artifact is one page and its assets.
- Use the HTML tester before publishing pasted or generated markup.
A real example
Ship a prototype your team can click.
Developers
Drop a build, a demo, or your docs and hand over a working link, straight from your machine.
- Prototype
- Demo
- Docs
- Report
No card required
What the free plan includes
The free plan covers one demo, docs site or report and enough daily publishes for an active review loop.
- 1 live site on a real free plan, not a trial of a paid one, and no card to start.
- Up to 25 MB per upload and 25 MB of storage across the account.
- 5,000 visits and 5 GB of traffic a month.
- HTTPS with a real certificate, issued and renewed for you.
- Up to 25 publishes a day, so you can iterate without asking permission.
- The deploy-time security check, which reads what you published and warns about a stray .env file, a .git folder, a private key or an API key left in your JavaScript.
- A small Droply badge in the corner of the page. Removing it starts on Starter.
- Free sites are served noindex, so search engines do not list them. Search visibility starts on Starter.
- A public API and editor integrations are available when the browser upload is not the right entry point.
A live build or a screenshot
A screenshot answers a different question
A screenshot is faster when the reviewer only needs to see one state, and it belongs in the ticket beside the explanation. A hosted build earns its extra step when the reviewer needs to click, resize, inspect browser behavior or verify the current revision.
| Droply | Screenshot or local preview | |
|---|---|---|
| Interaction | Links, controls, routes and browser JavaScript run in the published build. | A screenshot records pixels and a local preview only opens on a machine that can reach it. |
| Responsive review | The same URL opens on the reviewer's phone, tablet or desktop. | A screenshot records one viewport; a localhost URL is not normally public. |
| Revision path | Publish the next build behind the same site address. | Send another image, recording or temporary tunnel address. |
| Browser debugging | The reviewer can reproduce real network, console and layout behavior. | A still image has no runtime to inspect. |
| Context in the ticket | The ticket holds a link to the current external artifact. | A screenshot is visible inline and may be better for one exact state. |
| Setup | Build, upload and name the site. | A screenshot takes one capture; a local preview needs no publish at all. |
Workflow rows checked 8 September 2026 against MDN's file URL reference. This compares observable browser behavior, not a vendor plan. A screenshot remains the better artifact when one fixed state is the whole subject.
When Droply is the wrong choice
Use a developer deployment platform when the project needs the platform to build, run or coordinate the application. This route is intentionally narrower: finished static output goes in, files come back out.
- You want a preview for every pull request, a build on every commit or branch-aware environments. Use a Git-connected platform.
- You need server rendering, API routes, middleware, queues, databases or long-running processes. Those need an application host.
- You are sharing one visual state and the reviewer should see it inline in a ticket. A screenshot is quicker and clearer.
- You need a database, a login system, or code that runs on the server. Droply serves files; it does not execute your application.
- You want a build to run on every push to a repository. Droply has no Git integration and no CI: you build locally and upload the result.
- You are running WordPress or another PHP application. A static export of it can be hosted here, but the application itself cannot.
Frequently asked questions
What should a developer upload to static hosting?
Can I upload a React, Vue or Astro project?
Does Droply run npm install or npm run build?
Can I host a Next.js app?
Can a static site call my API?
Will the preview URL change after a new build?
Can I keep a prototype out of search results?
Is there an API for publishing a build?
What does the deploy security check find?
When should I use GitHub Pages, Netlify or Vercel instead?
Related pages
Keep exploring
- All use cases Choose by audience or by the thing you have to publish.
- Framework guides Build commands, output folders and static-export gotchas.
- Host a static site from ZIP The folder structure and index.html rule in detail.
- Host AI-generated output The direct-file path and the cases that still need a build.