Apple and Google both hold your submission until you hand them a working privacy policy URL, plus a support URL for App Store Connect, and an account-deletion link if your app has accounts. Write the page, drag the index.html into BetaDrop, and paste the live HTTPS URL into the console. No server, no FTP, no domain to buy, no credit card.
Anywhere it is a public HTTPS page a stranger can open without signing in. BetaDrop hosts it free: write the policy as a single index.html, drag it into the dashboard, and paste the https://yourapp.betadrop.site/ URL you get back straight into App Store Connect or Play Console. No domain to buy, no server to rent, no DNS to point, no credit card. It is live within seconds of the file landing.
The consoles want slightly different things, and it helps to know which of them is blocking you. Apple requires a privacy policy URL and a support URL for every app. Google requires a privacy policy URL for every app on Play — including apps that collect no user data at all — and, if your app lets people create an account, a web link where they can request deletion, entered in the Data safety form. The requirements differ; the files do not. One small site holding privacy.html, support.html and delete-account.html fills every one of those fields, and the same privacy policy URL works in both consoles.
What actually gets people rejected is not the absence of a page but a link that behaves differently for a reviewer than it does for you. The console field accepts any string; review opens it. A Google Doc or Notion page whose sharing looks fine from your logged-in browser can still show a sign-in wall to someone at Apple, and a login wall reads as a broken URL. So does a PDF in Drive, a link to your homepage instead of the policy itself, and a template with another company's name still in it. A plain HTML page on your own subdomain has no sharing settings to get wrong: it is either up or it is not, and you can check it in a private window in five seconds.
One caveat to read before you rely on it, because finding it later is worse. A store listing points at these URLs for as long as the app is listed, and a free site here is a trial window: 30 days, renewable once for free, after which it parks until you upgrade. The subdomain and files are kept either way, and we warn you first. That is fine for getting a submission through, and it is the wrong shape for a URL a live listing depends on. Move those to a paid plan, or to any host you will still be paying attention to in two years.
Which points at the case where you should not use this at all: if you already have a marketing site, put the policy on it. One more path under a domain you control beats a second host to remember, and nothing about these pages needs to be anywhere in particular. This exists for the developer who has an app and no website, which, on a first submission, is most of them.
Apple asks for a privacy policy URL and a support URL; Google asks for a privacy policy URL plus, for apps with accounts, an account-deletion link. Hosting the page takes one drag. Knowing what has to be on it is the part that holds up submissions, so each of these goes into the rules and the rejections in full.
For the whole list in one table — including the two fields nobody requires, the marketing URL and a custom EULA — see every URL the App Store and Play Store require.
Three steps, and the only one that takes any thought is writing the page.
A privacy policy or support page is one index.html: a heading, honest paragraphs about what you collect, and an email address. No framework, no build step.
Drag in the index.html, or a .zip holding privacy.html, support.html and delete-account.html together. It deploys in seconds: no server, no FTP, no Git remote.
You get yourapp.betadrop.site over HTTPS. Privacy policy and support URL go into App Store Connect; privacy policy and the deletion link go into Play Console's App content section.
Built for the page a reviewer is about to open, with no repository behind it.
Served over public HTTPS with no login wall and no sharing settings to get wrong — which is the exact way a Google Doc or Notion privacy policy fails once a reviewer, not you, clicks it.
Deploy without a credit card. A free account includes 1 GB of storage shared with your builds.
Drag and drop. No pipeline to configure, no build minutes to burn, no queue to wait on. A redeploy keeps the same URL, so the console never needs editing twice.
A clean yourapp.betadrop.site address you choose, on a domain kept separate from the app so hosted pages can never touch an account session.
A free site stays live for 30 days and renews once free. When it parks, the subdomain and files are kept — a free renewal brings it back without a redeploy.
Built by a beta-distribution tool, so the store paperwork lives next to where you already ship the .ipa and .apk it belongs to.
How do I host a website for free? Upload the finished files to a static host and it gives you a URL. BetaDrop is free web hosting for static websites: drag a .zip of your built site or a single index.html into the dashboard, and it is live at your own yourapp.betadrop.site address over HTTPS within seconds. No server to rent, no FTP client, no cPanel, no DNS to configure, no credit card. A free account includes 1 GB of storage and up to 100 MB per deploy. A landing page, a changelog, product docs, a coming-soon page or a conference demo are all the same one drag as a privacy policy.
“Static” is the one constraint worth understanding, and it is what makes the hosting free. Your files are served exactly as you uploaded them, so anything a browser can run on its own works: HTML, CSS, JavaScript, images, fonts, and single-page apps built with React, Vue or Svelte. What will not run is code that needs a server: PHP, Node, Python, WordPress and databases all need somewhere to execute, and there is no runtime behind your files here. If your site needs a backend, host the backend elsewhere and call it over HTTPS from the page.
The free window described above applies to any site, not only policy pages, and the second limit worth knowing is domains: custom domains are not supported yet, so every free site is served on a betadrop.site subdomain. If you need a custom domain today, GitHub Pages, Netlify and Vercel all offer one for free and are the better answer.
The store paperwork is rarely the only page you end up needing in launch week. The same drag handles a release-notes or changelog page, a simple app landing page to point the optional marketing URL at, API or product docs, a coming-soon page, or any hand-written HTML you want reachable from a link. They can all live on the same site, at their own paths, in one upload.
And if you are here because you are shipping an app rather than a website, the rest of BetaDrop is the other half of that job: upload a signed iOS .ipa or an Android .apk and share an over-the-air install link with your testers. If you are weighing that against Apple's own tooling, the TestFlight alternatives comparison covers where each one wins.
Static hosting means exactly what it says, and knowing the edge of it up front saves you an upload that cannot work.
.zip of your build folder up to 100 MB per deploy, or a single index.html. Single-page apps work, and so does anything that calls an API from the browser.dist, build or out. Every static framework works on those terms: Vite, Next.js with output: export, Create React App, Astro, Hugo, Jekyll, SvelteKit with the static adapter, or plain HTML..ipa and .apk builds have a home already; that is what the build distribution side is for.All three are good products, and for a site you maintain from a repository they are the better answer, including for these pages, if you already have a site to put them on. BetaDrop is aimed at the case they serve worst: one policy page needed online tonight, with no repository behind it.
| Feature | BetaDrop (Free) | GitHub Pages | Netlify (Free) | Vercel (Hobby) |
|---|---|---|---|---|
| Built for store privacy-policy pages | Yes | Generic | Generic | Generic |
| Deploy method | Drag-drop .zip or index.html | Git push or Actions | Git, CLI or drag-drop | Git or CLI |
| Git repo required | No | Yes | No, with drag-drop | Effectively yes |
| Free subdomain | yourapp.betadrop.site | username.github.io | name.netlify.app | name.vercel.app |
| Custom domain on free | Not yet | Yes | Yes | Yes |
| Site stays live free | 30 days, renewable once | Indefinitely | Indefinitely | Indefinitely |
Free tiers change often; these were checked against each provider's public documentation when this page was written. Storage on a free BetaDrop account is 1 GB shared across builds and hosted files, and traffic is capped at 100 GB a month.
Two of those columns have a page of their own: a GitHub Pages alternative for pages that are not git projects and a Netlify alternative with no build step.
Everything worth knowing before you upload.
Anywhere it is a public HTTPS page that opens without a login, which is what BetaDrop's free hosting is for. Write the policy as a single index.html, drag it into the dashboard, and paste the yourapp.betadrop.site URL you get back into App Store Connect or Play Console. There is no domain to buy, no server to rent and no DNS to configure. Because a store listing points at that URL for as long as the app is listed, use a paid plan for a page a live listing depends on: a free site is a trial window, not a permanent address.
Yes. Put all three in one .zip and upload it once: privacy.html, support.html and delete-account.html, each served at its own path on your subdomain. That covers the support URL App Store Connect requires and the deletion link Google Play's Data safety form requires. One thing a hosted page does not cover: Apple's guideline 5.1.1(v) asks for account deletion that can be started inside the app, so the web page is the Play requirement and a courtesy for Apple, not a substitute for the in-app flow.
You can paste one in, and that is exactly why it goes wrong. The console field accepts any string, but review opens the link, and a document that loads fine in your logged-in browser can still show a sign-in wall to a reviewer, which reads as a broken URL and gets the submission rejected. The same goes for a PDF in Drive and for a link to your homepage rather than the policy itself. A static HTML page on your own subdomain has no sharing settings to get wrong; open it in a private window and what you see is what review sees.
Yes, and it is published rather than discovered: 100 GB of traffic a month on free, 500 GB on Pro and 2000 GB on Studio. The allowance resets when the calendar month rolls over. For the pages this hosting is built for, a privacy policy or a support page, 100 GB is roughly fifty thousand visits a month, so it is not a number most sites go looking for. Worth knowing rather than worth worrying about. Note it only counts traffic to the hosted site: build downloads and install pages are on a different domain and are never metered against it.
Yes. Free web hosting with no credit card: one website with its own subdomain, unlimited redeploys, and 1 GB of storage shared across your builds and hosted files. The limit is duration rather than money: a free site runs on a renewable window, and keeping it online permanently needs a paid plan. The next answer has the exact numbers.
A free site stays live for 30 days and can be renewed once, free, from the dashboard. When the window runs out the site parks; the subdomain stays yours and the files are kept, so upgrading brings it straight back rather than making you redeploy. Paid plans have no window at all: the site stays live for as long as the subscription does. We send a reminder before a site parks. For a URL that sits on a public store listing, that reminder is the difference between a policy page and a 404 in front of your next reviewer.
Upload it. Sign in, open the static hosting page, and drag your index.html file into the dashboard. That is the whole process. Within a few seconds the file is served at your own subdomain over HTTPS, and you get a URL you can share, bookmark or paste into a form. There is no FTP client to configure, no cPanel, no DNS records to add, and no server to rent. If you have a whole folder of HTML, CSS and images rather than a single file, zip it and upload the zip instead: we unpack it and serve index.html as the front page.
No to both. Every site gets a free yourapp.betadrop.site subdomain with HTTPS already set up, so there is nothing to buy and no certificate to install or renew. You are not renting a server either: this is static file hosting, so there is no VPS, no cPanel, no FTP and nothing to keep patched. Bringing your own custom domain is not supported yet; if you need one today, a host that offers custom domains on its free tier is the better choice, and we would rather say so than waste your time.
A .zip of your built site — the contents of your dist, build or out folder — or a single index.html or .htm file. Up to 100 MB per deploy. Static files only: HTML, CSS, JavaScript, images and fonts. There is no server-side runtime, so PHP, Node, Python and databases will not run; anything dynamic has to come from an API you host elsewhere and call from the browser.
Any framework that produces static output: Vite, Next.js with output: export, Create React App, Astro, Hugo, Jekyll, SvelteKit with the static adapter, or hand-written HTML. Upload the built folder, not the source: we do not run a build step, so a .zip of your repository will not work. If your build assumes it is served from the root of a domain, that is fine here because each site gets its own subdomain; we show a heads-up if the files we find look like they expect a different base path.
Drop a new .zip or index.html on the same site and it replaces what is there; the URL does not change, so anything already pointing at it keeps working. You can delete the site whenever you like, and it stops resolving immediately. Renaming your subdomain is possible but rate-limited, because a subdomain someone else has already linked to should not change casually.
It depends on whether you have a Git repository, and being honest about that is more useful than a sales pitch. If your site lives in a repo and you want it to rebuild on every push, GitHub Pages, Netlify and Vercel are all excellent and all free: use one of them. BetaDrop is aimed at the case they serve worst: you have finished files and no repository, and you need a URL in the next two minutes. There is no Git remote to connect, no build to configure and no account verification to sit through; you drag a .zip or an index.html in and get a link. The trade is that a free site here runs on a renewable window rather than staying up indefinitely, and custom domains are not available yet.
Not yet. Every site today gets a free yourapp.betadrop.site subdomain, and custom domains are on the roadmap rather than in the product. We would rather say that than list a feature you cannot switch on. A betadrop.site subdomain is a perfectly acceptable privacy policy or support URL for both stores — neither Apple nor Google requires the page to sit on your own domain.
3 to 63 characters, using lowercase letters, numbers and hyphens. It cannot start or end with a hyphen or contain two hyphens in a row — the same rules DNS itself imposes. Names are first come, first served, and a handful are reserved.
Privacy policy, support page, account deletion — up to 100 MB per deploy, live on your own subdomain in seconds. Start on the 30-day free window and upgrade when the listing depends on it.
