VUE HOSTING
Vue hosting for a project you have already built
Vue hosting without a pipeline: build the project, upload the folder your tooling produced, and it is live on its own HTTPS address in seconds. Vue, Nuxt and VitePress each write somewhere different, and this page is mostly about getting that part right.
Free plan, free SSL, no credit card.
- 4
- Vue toolchains with their own build guide here
- 25 MB
- storage on the free plan, no card
- 5,000
- visits a month before you pay anything
- 25
- publishes a day while you iterate
How it works
Three steps, start to live link
-
Build the project
Run the build you already run. Nothing about the project changes and nothing new has to be installed for it to be publishable.
-
Upload the output folder
Drag the folder the build wrote, or a ZIP of it. Two of the four Vue toolchains hide it inside a dot-directory, which is the part worth checking.
-
Republish to the same address
A new build replaces the old one at the same URL. Documentation links and review links you have already sent stay valid.
The plain answer
What is Vue hosting?
Vue hosting means serving the static files your Vue build produced. Vue runs in the browser, so once Vite has compiled your single-file components into HTML, JavaScript and CSS, the result is an ordinary folder that needs nothing more than a web server pointed at it.
Where it gets confusing is that "a Vue project" covers four quite different builds. A plain Vue app scaffolded with create-vue is a Vite project and writes to dist. Nuxt renders on a server by default and only produces a publishable folder when you ask it to generate one. VitePress and VuePress both write into a folder nested inside a dot-directory, which is why people upload their Markdown source by mistake.
None of that is a Vue problem, and none of it needs a special host. It just means the folder you upload is the one decision that matters, and it is different for each tool. The framework deploy guides name the exact command and folder for all four, and the Nuxt guide covers the generate step in particular.
Who it is for
The people who reach for this
-
Developers
A place to put a built Vue app or a documentation site without configuring a deployment target for it.
-
Teams shipping docs
A VitePress or VuePress site is a folder of finished HTML, which makes publishing it a drag rather than a project.
-
Designers
A built prototype opens as a real page on a real device, which is a different conversation from a screen recording.
-
Agencies and freelancers
Hand a client a working link instead of a build folder and a paragraph about how to open it.
In detail
What you actually get
Four toolchains, four folders, named
Uploading the wrong directory is the failure that costs a Vue developer an afternoon, and the Vue ecosystem makes it easy: two of the four write into a hidden folder. Each has its own guide rather than one page of averages.
- Vue with Vite: the build writes to dist. See the Vite deploy guide.
- Nuxt: npx nuxi generate rather than the usual build, and the site lands in .output/public. See the Nuxt guide.
- VitePress: the output is nested at docs/.vitepress/dist, not the docs folder holding your Markdown. See the VitePress guide.
- VuePress: same shape, at docs/.vuepress/dist. See the VuePress guide.
Vue Router paths that resolve
Vue Router in history mode produces clean paths that exist only once the app has loaded. Asked for one directly, a static host looks for a file, finds nothing and answers 404. Every static host has this problem and it has a one-switch fix here.
- Turn on the Single-page app switch in the site settings and unknown paths are served the root index.html, so the router resolves them.
- Free on every plan, applied without a redeploy.
- Leave it off for a VitePress or VuePress site: those generate a real file per page and should return a real 404.
A check on what the bundle is carrying
Vite compiles anything prefixed for the client straight into the bundle, where it is readable by anyone who opens the page. Every publish is read and anything sensitive is named in plain language.
- A committed .env file, a .git directory, a private key, or an API key left in a JavaScript chunk.
- It runs after the site is live and never blocks a publish.
- Included on the free plan. See how the security check works.
A domain, and a URL that survives the next release
Documentation earns its links slowly, so the address has to outlive the build that created it. Publishing a new version keeps the address, and from Pro the address can be one you own.
- The URL does not change when you republish, so external links and search results keep resolving.
- Certificates are issued and renewed automatically on both the Droply address and yours.
- Free sites are served noindex. Search visibility starts on Starter, which matters more for docs than for a prototype.
No card required
What the free plan includes
Everything below is on the free plan, with no card and no trial to run out, which is enough to put a built Vue app or documentation site at a real address today.
- 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.
Droply vs Static.app
How this compares with Static.app
Static.app publishes the same kind of per-framework page, and neither product builds your project for you. These are the rows that differ for somebody holding a Vue or Nuxt build folder.
| Droply | Static.app | |
|---|---|---|
| Free plan | 1 site, 25 MB storage, 5,000 visits a month, no card, and a plan rather than a trial. | A 7-day trial with no credit card, then paid. 1 site and 50 MB during it. |
| Entry paid price | $5 a month for Starter, or $60 a year. | $5 a month or $60 a year for Starter: 2 sites, 500 MB, custom domain included. |
| Loose .html file accepted | Yes, dropped on its own with nothing around it. | No. Its own documentation states a loose .html file must be zipped first. |
| Single .jsx or .tsx without a build | Yes. It is transformed in the visitor browser at the published address. | Not offered. |
| Single-page app fallback | A switch in the site settings, free on every plan, applied with no redeploy. | Not documented as a per-site setting. |
| Security check on every publish | Every plan, free included: leaked keys, a stray .env, a committed .git folder. | Not offered. |
Static.app figures checked 8 September 2026 on its own pricing page (free tier: 1 site, 50 MB, a 7-day trial with no credit card; Starter $5 a month or $60 a year for 2 sites and 500 MB with a custom domain; Medium $10; Large $15) and on its Claude hosting page, which states that a loose .html file is not accepted for upload and must be zipped first. Both products publish finished output rather than running your build, so the rows below compare what each one accepts and what it costs, not build speed. Product plans can change.
When Droply is the wrong choice
Nuxt is the reason this section matters more on a Vue page than on most. It is a server framework that can also generate a static site, and the two modes are genuinely different products. If your project depends on the server half, publishing the generated half will look like it worked and then behave incorrectly.
- Your Nuxt app uses server routes, anything under server/, or server middleware. Those do not come across when you generate.
- You need data fetched per request rather than at build time. Generated pages carry the data as it was when you built them.
- You want incremental or on-demand regeneration. That is a server feature, so it needs a host that runs Node.
- 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.