A GitHub Pages alternative for pages that aren't git projects

BetaDrop vs GitHub Pages

GitHub Pages figures from GitHub's published limits (1 GB published site size, 100 GB/month soft bandwidth), checked August 2026. Both products change; check their pricing page before deciding on numbers alone.

What GitHub Pages' free tier actually costs you

Not money. GitHub Pages is free in the way very few things still are, and the rest of this page assumes that. What it costs is stated plainly in GitHub's own documentation, and the first line is the one people meet last: Pages is available in public repositories on GitHub Free, and in public and private repositories on Pro, Team, Enterprise Cloud and Enterprise Server (checked August 2026). So the free path publishes your source alongside your site. For an open-source project that is a feature. For a client's landing page, a pre-announcement demo, or anything with a half-finished copy deck in the commit history, it is a decision you have to make rather than a default you can ignore.

Then the quotas, all published: a site of no more than a gigabyte, a source repository with the same recommended ceiling, a deployment that fails if it takes longer than ten minutes, a soft bandwidth limit of 100 GB a month, and a soft limit of ten builds an hour; that last one is lifted if you publish through your own GitHub Actions workflow. Requests that trip rate limiting get an HTTP 429. Go past the quotas and GitHub's wording is honest about the outcome: it may not be able to serve your site, or Support may email you suggesting a CDN or a different host. These limits are generous, and they are also the reason "soft" is doing work in that sentence.

The clause most people have never read is the usage one. GitHub states that Pages is not intended for, or allowed to be used as, a free web-hosting service to run an online business, an e-commerce site, or anything primarily directed at facilitating commercial transactions or providing commercial SaaS. GitHub also states that Pages sites should not be used for sensitive transactions such as passwords or card numbers. Plenty of indie apps host their marketing page, their pricing page and their support page on Pages without incident. It is still worth knowing that the platform's own terms draw a line somewhere near where your product sits, and that you did not agree to it on purpose.

And one structural limit that catches people out: you get a single user or organization site per account. Everything else is a project site, served under <owner>.github.io/<repository>/. That is fine until an absolute path in your HTML sends the browser to /style.css at the domain root and the page renders unstyled. That is not a bug in Pages; it is the cost of a URL shape you did not choose.

BetaDrop's free tier has its own price, and it is a time window rather than a policy: a deploy up to 100 MB, 1 GB of storage in total, and a site that stays live for 30 days with one free renewal before it parks (files and URL held for a while, restored on renewal or upgrade; a site left parked is eventually deleted and its name released, with an email first). Nothing about your source is published, nothing needs a repository, and the acceptable-use policy has no equivalent clause about commerce. It is about what you may host, not what your business model may be.

When a GitHub Pages alternative is the wrong call

• A documentation site that lives with its repo. Docs that version alongside code belong in the same repository, and Pages republishes them on merge. The git dependency this page treats as friction is, in that case, the entire point: the site's history is the project's history, and a bad paragraph is reverted with the commit that introduced it.
• Set-and-forget-forever hosting. Pages sites do not expire. BetaDrop's free tier parks a site after 30 days (one free renewal; files held for a while, restored on renewal or upgrade, then deleted if the site stays parked). Permanence is what the paid tier sells, and if a free URL that still resolves in three years is the requirement, GitHub wins that row outright.
• A custom domain on a free tier, today. Pages does custom domains with HTTPS at no cost. BetaDrop free sites live on a betadrop.site subdomain and custom domains are planned rather than shipped.
• A Jekyll blog, or any build you want re-run for you. Pages builds Jekyll natively and will run an Actions workflow for anything else. Building through your own workflow also lifts the ten-builds-an-hour soft limit. BetaDrop runs no build step at all, by design.
• Real traffic. A soft 100 GB a month is a lot of static bandwidth to be given for nothing, and for a popular project site it is a better deal than anything on this page.

None of this is faint praise. If your page is a git project, put it in git. The only thing being argued here is that plenty of pages are not.

The git route, step by step (and what you skip)

Publishing one HTML file on GitHub Pages is not hard. It is just longer than it looks written down, and every step is a place to stop:

1. Create a repository, public unless you are on a plan that publishes Pages from private repos.
2. Get the files into it: clone and commit, drag them into the web editor, or push from wherever they currently are.
3. Open Settings, find Pages, and choose a source: a branch and a folder, or an Actions workflow.
4. Wait for the deployment. It has ten minutes before it times out; it will not need them.
5. Open the URL and notice it is /your-repository/, not the domain root, because a project site is served from a subpath. Every absolute /style.css in your HTML now points at nothing, so you go back and make the paths relative.
6. If you want a real domain, add a CNAME file and the DNS records to match.

The BetaDrop version of that list is: drag a .zip or an index.html onto static hosting, and the HTTPS URL exists. Your files are served from the root of their own subdomain, so the paths you wrote locally are the paths that work. No repository, no commit, no source made public, no build to configure, and no git knowledge required from whoever is editing the page next.

The clearest case for that is the store-submission trio: Apple and Google both require live URLs a reviewer will open: a privacy policy, a support page, and for apps with accounts an account-deletion page. None of them is a git project, none of them will ever have a second contributor, and two of them exist entirely so a reviewer can click them once. What each page has to contain is the part worth your attention; where it is hosted should take a minute.

Frequently Asked Questions