Cloudflare Free Plan for Small AI Sites: What It Gives (and Doesn't)

You put a small AI tool online, point the domain at a server, and within a day you're wondering whether to put Cloudflare in front of it. The free plan gives you DNS, a CDN, TLS certificates, DDoS protection, five firewall rules and a single rate limit. It does not cache your HTML, does not stop a user from running up your LLM bill, and it will time out a slow model call at 125 seconds.

I read the Cloudflare documentation pages cited below on 2026-10-09. Several came back through a summarising fetch, not as raw pages, so treat my wording as a paraphrase and check the exact text before you rely on a limit. Cloudflare changes plans often. The pricing page I tried (cloudflare.com/plans) only showed developer-platform limits, so I did not verify the plan comparison table itself, and I did not set up a zone in this session. Everything here is a reading of the docs, not a test.

This post is part of a launch series. For the full order of operations see the launch checklist for an AI side project.

What does the Cloudflare free plan include for a small site?

Here is what I could confirm, with the doc it came from.

Two things that are easy to miss. First, "free" here is the plan for your domain's traffic. Cloudflare's developer products have their own free tiers (Workers at 100k requests a day, D1, R2 and so on, per the plans page), and those are a separate decision. I did not check support or uptime terms for the free plan, so read those before you rely on it for anything a customer pays for.

Should you put your AI app behind the proxy at all?

Maybe not for everything. Cloudflare's "orange cloud" proxy sits between visitors and your server. That helps with TLS, caching static files and absorbing junk traffic. It also adds one more thing that can break.

Use the proxy when:

• You run a public site or landing page and want free TLS and a CDN for images and scripts.
• Your origin IP is exposed and you'd rather it wasn't.
• You see scanner noise or scraping you want challenged before it reaches your server.

Think twice when:

• Your app returns slow, long-running responses (next section).
• You depend on non-web services such as SSH or a database port on the same hostname. I did not check which ports the free proxy supports, so keep those on a DNS-only record.
• You haven't decided who your users are. A challenge page on an API endpoint can break mobile apps and scripts. The Bot Fight Mode page warns that it "may challenge API or mobile app traffic".

You can mix both. Proxy www.example.com, and give your API or admin tool its own DNS-only subdomain protected by a login and your own firewall.

What happens to slow LLM responses behind Cloudflare?

This is the AI-specific catch. The error 524 page says the default proxy read timeout is 125 seconds, and that only Enterprise customers can raise it (up to 6,000 seconds). If your origin doesn't answer in time, the visitor sees a 524 even though your server may still be working.

A long agent run or a slow reasoning model can cross that line. Options, in the order I'd try them:

1. Stream the response. Send tokens as they arrive so the connection shows activity. I have not tested how your particular stack streams through the proxy, so test it with a real long request after you switch it on.
2. Make it a job. Return a job ID at once and let the browser poll a status endpoint. This is the pattern the 524 page itself suggests ("polling the status of long-running processes").
3. Go DNS-only for that hostname. The same page suggests a grey-cloud subdomain for long requests. You lose the proxy's protection there, so put your own rate limits and auth in front.

To measure rather than guess, time one real request from your own machine:

curl -s -o /dev/null -w "total: %{time_total}s status: %{http_code}\n" https://your-domain.example/api/slow-endpoint

(Unrun template: replace the URL with your own endpoint.) If time_total approaches 125 and you see a 524, you've found the limit.

What does Cloudflare cache by default, and why does that matter for AI apps?

Cloudflare caches by file extension, not by content type. Per the cache docs, images, CSS, JavaScript, fonts, PDFs and archives are cached by default, and "HTML or JSON" is not (robots.txt is the noted exception). For a dynamic AI app that is the safe default. You don't want one user's generated answer served to another user because a rule cached an API route.

Practical rules:

• Let static assets cache by default.
• If your marketing pages are static HTML, add a Cache Rule for those paths only, and test by viewing the cf-cache-status response header.
• Never write a cache rule that matches /api/*, /chat or anything that reads cookies or an Authorization header.

How far do the five custom rules and one rate limit go?

Not far, so spend them on the cheapest wins. These are untested templates; check the field names in the rule builder, which I did not open.

1. Protect your admin path. Block or challenge /admin and /wp-login.php style paths for anyone outside your own IP. A challenge is kinder if your IP changes.
2. Challenge countries you never serve, only if you're sure. If you sell in India only, that's a decision, but remember VPN users and travellers.
3. Block known-bad request shapes you actually see in logs, such as probes for .env or .git.
4. Challenge the expensive endpoint. Put your single rate limit on the endpoint that calls the model. With one rule, a counting period of 10 seconds and IP as the only counting characteristic, it will catch one machine hammering the endpoint. It will not catch a botnet, a shared office NAT misread as one user, or a logged-in user who is allowed to be slow but wasteful.
5. Keep one rule free for the day you need an emergency block.

The part that surprises people: none of this protects your wallet. If each request costs you LLM tokens, the real control is per-user limits, daily caps and provider-side spend limits inside your app. See rate limiting a free-tier AI app and how to estimate the cost per 1,000 requests.

Which SSL mode should you pick?

The SSL/TLS modes page describes four: Off, Flexible, Full and Full (strict). In Flexible, visitors reach Cloudflare over HTTPS but Cloudflare talks to your origin over plain HTTP. Cloudflare "strongly recommends" Full or Full (strict). Use Full (strict) once your origin has a valid certificate (a public CA, or a Cloudflare Origin CA certificate). If you leave Flexible on, an attacker on the path between Cloudflare and your server can read traffic, including login tokens and prompts.

A failure I'd expect when switching modes (reasoned from how Flexible works, not tested here) is a redirect loop: your server redirects HTTP to HTTPS while Cloudflare, in Flexible mode, keeps connecting over HTTP. The fix is to move to Full (strict) after installing a certificate on the origin.

What about Cloudflare's own analytics and email?

Cloudflare Web Analytics is described as "privacy-first analytics" that works without changing DNS or using the proxy, and "available on all plans". The page I read did not say whether it sets cookies or how it collects data, so I'm not making a claim. If you want to pick an analytics tool deliberately, see cookie-free analytics with Plausible or Umami.

Email Routing forwards mail sent to hello@yourdomain to a real inbox. It's inbound only. For sending password resets or receipts you need a separate sending service.

A setup order that avoids downtime

Do this when traffic is low, and keep notes of the old nameservers.

1. Add the site in the dashboard and let Cloudflare import DNS records. Compare them line by line with your current DNS. Missing MX or TXT records break email.
2. Set every record to DNS-only (grey) at first, then change nameservers at your registrar.
3. When Cloudflare says the zone is active, turn on the proxy for web hostnames only (not mail records).
4. Set SSL mode to Full (strict) after your origin has a certificate.
5. Add your custom rules and rate limit. Watch the Security Events log for a day before tightening anything.
6. Test a long request, a login, and a form post through the proxy.

For hardening the server behind Cloudflare, use the VPS hardening checklist for AI agent servers. A proxy is not a firewall for your origin: lock the origin's own ports down too.

Is the free plan enough?

For a launch, yes. You get TLS, a CDN, unmetered DDoS mitigation and a few rules at no cost. Upgrade only when a specific limit blocks you, such as needing more than five custom rules or the fuller managed rulesets. Never treat it as your only defence. Your app still owns authentication, per-user limits and key hygiene.