ASTRO HOSTING
Astro hosting for a site that is already static
Astro hosting with nothing to configure: Astro builds to plain HTML by default, so you run the build, upload dist, and the site is live on its own HTTPS address in seconds. The only thing that changes that is an adapter you added on purpose.
Free plan, free SSL, no credit card.
- 0
- adapters needed for a default Astro build
- dist
- is the folder to upload
- 25 MB
- storage on the free plan, no card
- 5,000
- visits a month before you pay anything
How it works
Three steps, start to live link
-
Build the site
Run the build you already run. A default Astro project needs no adapter and no extra configuration to produce publishable output.
-
Upload dist
Drag the dist folder or a ZIP of it in. Your pages, assets and any island scripts keep the paths the build gave them.
-
Share the address
The site is live on HTTPS in seconds, and republishing a new build keeps the same address.
The plain answer
What is Astro hosting?
Astro hosting means serving the output of an Astro build, which by default is a folder of finished HTML pages with almost no JavaScript attached. Astro renders components at build time and ships interactive islands only where you asked for them, so what you upload is a site rather than an application.
That makes Astro the easiest case in this cluster. There is no export switch to remember and no adapter to install: the default output mode already produces exactly what a static host serves, and the folder is dist.
The one way it stops being true is an adapter. Adding an SSR adapter, for node or for a specific platform, changes the build so that it emits a server instead of finished pages, and at that point there is nothing static to upload. That is a deliberate choice somebody made in astro.config, so the fix is knowing whether it was made. The Astro deploy guide covers both cases.
Who it is for
The people who reach for this
-
Writers and content sites
A blog or documentation site built from Markdown, published as the finished pages it already is.
-
Designers
A portfolio or case-study site that has to load fast on a phone and be a link you can put in a bio.
-
Marketing teams
A landing page that is measured on load time, published on its own address without a release process.
-
Agencies and freelancers
A client site delivered as a URL, with the same address surviving every round of revisions.
In detail
What you actually get
Nothing to configure, which is the feature
Most framework hosting pages exist because the framework needs coaxing into producing static output. Astro does not, so this page is mostly about the two ways a project stops being static.
- A default Astro build writes finished pages to dist and needs no adapter.
- An SSR adapter in astro.config changes that: the build emits a server, and there is nothing to upload.
- Hybrid rendering has the same effect for the routes marked server-rendered.
- The Astro deploy guide carries the command and the folder, and stays in step with the message a failed upload shows.
Real pages, so real 404s
Astro generates a file per route, which means the host can answer for each path properly instead of guessing. That is a genuine difference from a single-page app and it is worth not undoing.
- Leave the Single-page app switch OFF. Astro sites have real files, and a fallback would serve the home page in place of a missing one.
- A custom 404 page in your build is served as the 404, so a wrong link looks like your site rather than like a host.
- Every page is separately cacheable, which is most of why an Astro site feels fast.
The check that reads what you published
Content sites get built from repositories, and repositories carry things that should not be public. 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 client-side script.
- It runs after the site is live, never blocks a publish, and reports in sentences rather than as a score.
- Included on the free plan. See how the security check works.
A domain and an address that outlives the rebuild
A content site accumulates inbound links, so the address has to be stable across every republish. It is, and from Pro it can be your own.
- Republishing keeps the URL, so external links and search results keep resolving.
- Certificates issued and renewed automatically on both the Droply address and yours.
- Free sites are served noindex. Search visibility starts on Starter, which a content site will want from the beginning.
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 Astro 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. These are the rows that differ for somebody holding an Astro dist 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. |
| Custom 404 page from your build | Served as the 404, because the site keeps its real file structure. | Not documented as a per-site setting. |
| Rollback to a previous build | One click from Pro, with every version kept. | Backups are offered as a separate feature rather than a per-publish version history. |
| 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
Astro is unusually honest about what it is doing, so the wrong-choice list here is short and specific. It is almost always about an adapter that somebody added, sometimes without noticing what it changed.
- Your astro.config has an SSR adapter. The build then produces a server bundle, and there is nothing static in it to upload.
- You use hybrid rendering with routes marked server-rendered. Those routes have no file behind them after the build.
- You are using Astro Actions or server endpoints for form handling. Those need a runtime that this host does not provide.
- 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.