A Netlify alternative for pages, not platforms

BetaDrop vs Netlify

Netlify figures reflect the credit-based free plan for accounts created on or after 4 September 2025, as published August 2026; accounts created before that date keep the legacy 100 GB / 300-build-minute plan. Pricing models shift. Check Netlify's own pricing page before deciding on numbers alone.

What Netlify's free tier actually costs you

Start with the arithmetic, because the marketing word is "free" and the operative word is "300". A credit-based free account gets 300 credits a month, and everything metered draws from that one pool: a production deploy is 15 credits, bandwidth is 20 credits per GB, web requests are 2 credits per 10,000, and compute is 10 credits per GB-hour (netlify.com/pricing, checked August 2026). Divide it out and the month has a shape: about 20 production deploys if you spend nothing else, or roughly 15 GB of traffic if you deploy nothing else. A mixed month gets there faster than it sounds: ten production deploys is 150 credits, five GB of traffic is another 100, a quarter of a million requests is 50, and that is the allowance, exactly.

Netlify's billing documentation is admirably direct about what happens next, and it is the fact worth carrying away from this page: when the balance is used up, your web projects are paused, and visitors get a "Site not available" page at each project URL. On the free plan that is a hard limit rather than an overage: auto recharge and add-on credit packs start on the Personal plan at $9 a month, and unused monthly credits do not roll over below the larger Pro tiers. Nothing degrades gracefully; the page is up, and then it is a placeholder.

For an application that is a reasonable design: usage is the cost, and a busy app is a real bill. For a page it has one specific consequence worth thinking about: credits are pooled per account, not per project. A privacy policy that gets nine visits a month is not going to exhaust anything on its own, but it shares a balance with whatever else is on that account, so the marketing site that lands on Hacker News can take the store-submission URLs down with it. And a paused privacy-policy or support URL is not an inconvenience. It is the link an App Store reviewer clicks while your build sits in review.

Two honest qualifiers. First, if your Netlify account was created before 4 September 2025 you are on a legacy plan (100 GB of bandwidth and 300 build minutes a month), and none of the credit story applies to you unless you switch. Second, deploy previews and branch deploys cost nothing at all, unmetered even on free, which is a genuinely generous carve-out and the reason the credit model is not the squeeze it first reads as for teams doing pull-request review.

BetaDrop's free tier costs you something too, just not in the same currency: a deploy is capped at 100 MB, total storage at 1 GB, and a free site stays live for 30 days with one free renewal before it parks (files and URL held for a while, restored the moment you renew or upgrade; a site left parked is eventually deleted and its name released, with an email first). That is a window you can see on a calendar rather than a credit balance. Traffic is the one thing with a monthly allowance, 100 GB. Because there is no build step, no functions and no compute, it is the only figure that could ever accumulate; a busy week of deploys cannot spend it down, only visitors can.

When a Netlify alternative is the wrong call

• Your site has a build. React, Vite, Hugo, Astro, built on every push: Netlify runs it and BetaDrop deliberately runs none. Note the detail that makes this a good deal on credit pricing: build minutes are not metered separately, so a production deploy costs the same 15 credits whether the build takes twenty seconds or twenty minutes. A heavy framework build is cheap there.
• Deploy previews per pull request. Unlimited, and unmetered even on the free plan. A URL for every branch, reviewers leaving comments against it, the whole review loop. This is Netlify at its best, and BetaDrop has nothing resembling it.
• Anything server-side. Functions, form submissions, a Postgres database, blob storage, edge redirects. A static-only host rules all of that out by definition, and no amount of positioning changes it.
• A custom domain on the free tier, today. Netlify includes custom domains with SSL on the free plan. BetaDrop free sites live on a betadrop.site subdomain with HTTPS configured, and custom domains are still planned rather than shipped. If that is the deciding row, it is theirs.
• You want the URL private until you say so. On Netlify teams created since late July 2026, new projects start private and become publicly accessible only when you choose to publish. Useful for a client demo you are not ready to hand over.

The short version: if the thing you are hosting is part of an application, host it on a platform. This page is for the case where it isn't.

Dropping the pipeline for the pages that aren't your app

The realistic move is not leaving Netlify. You have a repository wired to it, a build command that works, and previews your team relies on; there is nothing here worth unpicking. The move is narrower: take the handful of pages that are not the application off the account, so they stop drawing from the same credit pool and stop sharing a fate with it.

The clearest set is the trio every app-store submission needs, all of them live URLs a reviewer will open: a privacy policy, a support page, and an account-deletion page. Three HTML files, no build, no functions, traffic measured in reviewer visits. What each of them has to contain is a separate question; where they live does not need to be an infrastructure decision at all.

If the page does have a build (an Astro or Vite one-pager, a documentation export), you already own the pipeline that produces it. Run it once locally and upload the output rather than wiring a hosted build to rerun it on every push:

npm run build                 # vite build / astro build / next build …
cd dist && zip -r ../site.zip .   # dist, build or out — whichever your framework emits

Drag that zip onto static hosting and the URL exists. Be clear about what you have given up on that page: no deploy previews for it, no functions, no redirect rules, no rebuild when the repository changes. You upload again, which for a page that changes twice a year is the right trade and for your application is obviously the wrong one. What you get back is a URL on a flat, published allowance (100 GB of traffic a month) instead of a credit pool shared with your app.

Frequently Asked Questions