Skip to content
AppFoyer
Start free

Guides

Where to host a privacy policy when you have no domain

Six places developers actually put the URL, what each one costs you at review time and two years later, and the one requirement that rules half of them out.

You do not need a domain — you need a public URL that loads without a login and still works in two years. Static hosts, document links, platform hosting and paid services all qualify on that test alone. What separates them is whether they can also receive an account-deletion request.

Checked 19 September 2026. Store policies change, sometimes without notice. Everything below links to the official documentation, and that page — not this one — is the authority. If the two disagree, the store is right.

You do not need a domain to publish a privacy policy — you need a public URL that loads without a login and will still load in two years. Both stores check the link, and Apple’s App Privacy documentation lists “the URL to your publicly accessible privacy policy” as a required field. The question is only where to put it.

Six places developers actually use, with what each one really costs. None of them is wrong for everyone; they fail in different places.

1. A static host on a subdomain they give you

GitHub Pages, Cloudflare Pages, Netlify, Vercel. Free, fast, and the URL is stable as long as the account is.

Where it breaks: the account-deletion page. Static hosting serves files; it cannot receive a request. If your app has accounts, Google Play wants a web route where a user can ask for deletion — so you end up printing an email address on a static page for scrapers to harvest, or bolting on a third-party form service that now sees your users’ email addresses. It also breaks if you ever rename the repo or the project, because the URL changes and the store listing does not.

2. A document link — Google Docs, Notion, a PDF

The fastest thing in the world and the one reviewers are most sceptical about.

Where it breaks: sharing settings. A document that is “anyone with the link” today becomes “people in your organisation” after a workspace policy change, and nobody tells you. Notion pages get un-published. A PDF is a download, not a page, on some devices. Beyond the mechanics it reads as improvised, which is exactly the impression you do not want attached to a submission that is already being checked for something else.

3. Firebase Hosting

Free tier, a real domain you are given, text/plain served correctly — and specifically named by AdMob as an acceptable place for app-ads.txt, which is convenient if you also show ads.

Where it breaks: same as any static host for account deletion, plus you now maintain a deploy step for five pages of text. Workable if Firebase is already in your stack, overhead if it is not.

4. A page on a site you do not control

A social profile, a page on a publisher’s site, a friend’s blog.

Where it breaks: everything, eventually. You cannot fix a broken link on someone else’s site at the moment a review is blocked on it, and a store reviewer treating a social profile as a privacy policy is not something to plan around.

5. Buying a domain and hosting it yourself

Around $12 a year plus an afternoon. The right answer if you were going to want a marketing site anyway.

Where it breaks: renewals and the receiving problem. A lapsed domain takes down the privacy URL, the support URL and the deletion URL in a live store listing at the same moment, and the first you hear of it is from the store. If you go this way, put the renewal on a card that does not expire and set a calendar reminder a month out.

6. A hosted compliance page

A service that gives you the five pages on a URL of their own.

Where it breaks: what happens when you stop paying. This is the question to ask before you paste the URL anywhere, and it is a fair one to ask us too — see below.

The requirement that rules half of these out

If your app has accounts, you are not publishing one page, you are publishing a set: the privacy policy, and a web route where a user can request account deletion. Google Play asks for both an in-app path and a public web link. A page that only displays text cannot answer the second one, which is why options 1 to 3 quietly turn into “and a form service” the moment you get to it.

Decide it once, for all five URLs, rather than solving the privacy policy this evening and rediscovering the problem at the next rejection.

Whatever you pick, check it the way a reviewer will

Signed out, in a private window, on mobile data rather than your own network:

curl -i https://your-url.example/privacy

200 OK and readable content. The common findings are a 404, a redirect to a login, or a page that is fine on your laptop only because you are signed in to the service hosting it.

What AppFoyer does here

All five pages go live on your app’s own subdomain, without a domain or a server of your own, and the account-deletion page can actually receive a request — it stores it and notifies you. Email notification is on every plan including the free one; Telegram and Slack are on the paid plans. You perform the deletion in your own systems; we have no access to them and never claim otherwise.

The fair question, answered: if you stop paying, the account-deletion page stays online, indefinitely. Your users never chose us and know nothing about your billing, so losing their route to you over an unpaid invoice would be our mistake rather than yours. One app is free, with no card.

The authoritative sources

Do this in a few minutes instead

AppFoyer hosts the pages this guide is about — privacy policy, terms, support, account deletion and app-ads.txt — on their own subdomain, with no domain or server of your own. One app is free, and nothing a store requires is ever behind a paywall.

Start free See a live example