Cloudflare Free vs Web Hosting: What Does Each Service Do?

Two different services in one request path

A web hosting provider stores the site's files or runs the application that generates responses. Cloudflare's standard DNS and reverse-proxy service can sit between visitors and that origin server, resolving names, handling eligible web requests, and applying selected caching and security controls. These are different roles. Turning on Cloudflare's Free plan does not transfer a WordPress database, upload website files to a new host, or take responsibility for server maintenance. A customer may use both services together, or choose a different delivery architecture. The first question is where the actual website runs, followed by which network layer receives the visitor's request.

Understand the origin before changing anything

The origin is the system that supplies the website's content when Cloudflare cannot answer from its cache or other configured service. It might be a shared hosting account, a VPS, a managed platform, or an application endpoint. Record the origin hostname, IP address where relevant, hosting supplier, application type, and administrator before editing DNS. A proxied record can make visitors see Cloudflare addresses rather than the origin address, but that does not mean the origin has vanished. If the application server fails, uncached dynamic pages may still fail. Protecting the route to a server is not equivalent to operating a redundant server.

DNS hosting is not web hosting

Authoritative DNS answers questions about which hostnames point to which destinations. Web hosting answers HTTP requests by serving pages or running code. Cloudflare can act as authoritative DNS without proxying a particular hostname; in that case a DNS-only record exposes the destination and visitors connect to it directly. A DNS record also cannot repair missing website files, a failed database, or an expired hosting subscription. Keep a service inventory identifying the domain registrar, DNS provider, web host, and email provider separately. This avoids the common mistake of assuming that moving nameservers also moves all services associated with the domain.

What the orange and grey clouds mean

Cloudflare documents that eligible A, AAAA, and CNAME records can be proxied. The orange-cloud status routes supported HTTP or HTTPS traffic through Cloudflare, while grey-cloud DNS-only status returns the actual target without that proxy path. MX and TXT records are not proxied. These controls apply per relevant hostname, so a website record and a mail record should not be treated identically. The orange cloud does not guarantee a particular security outcome, cache hit, or page speed. Check which records are web-facing, whether the application supports proxying, and what the destination must resolve to before changing a switch.

Why email needs its own DNS review

Business email commonly uses MX records to direct incoming messages and hostnames for SMTP, IMAP, or POP3 connections. Cloudflare's standard HTTP proxy does not carry those ordinary mail protocols. Its official troubleshooting guidance warns that a mail hostname resolving to Cloudflare proxy addresses can prevent mail clients from connecting. Keep dedicated mail hostnames DNS-only and verify the exact MX destinations against the mail provider's instructions. Preserve SPF, DKIM, and DMARC records where used; changing authoritative DNS without copying these records can disrupt authentication or delivery. Cloudflare Email Routing is a distinct feature and must not be enabled accidentally over an existing mailbox arrangement.

Free caching has specific boundaries

A content delivery network can reduce repeat requests to the origin by serving eligible files from nearby edge locations. Cloudflare's current cache documentation lists common static assets such as images, CSS, and JavaScript as cacheable by default, subject to response headers and other rules. HTML and JSON are not cached by default under its standard behaviour. A visitor requesting an uncached page may still wait for the original application and database. Treat caching as a measured optimisation, not a replacement for adequate hosting capacity. Record which paths should be public and cacheable, and which contain personalised or changing information.

Avoid caching private customer pages

An online store, booking system, or membership website may generate different content for each logged-in user. Applying a broad cache-everything rule without understanding cookies, authentication, and cache keys can cause stale content or inappropriate sharing. A safe review distinguishes public product information from carts, account dashboards, checkout responses, and administration pages. Examine the origin's Cache-Control and Set-Cookie behaviour before adding cache rules, and test logged-in and anonymous sessions separately. A static brochure page and a personalised account page should not inherit the same policy merely because both use HTTPS. Keep a documented way to purge outdated public content after publishing changes.

HTTPS has two separate connections

When a hostname is proxied, the browser connects to Cloudflare and Cloudflare connects onward to the origin. These are two separate transport connections. Cloudflare's SSL/TLS documentation describes encryption modes and recommends Full or Full (strict) where possible. Full (strict) validates the origin certificate, while ordinary Full does not perform that same validation. The origin still needs suitable HTTPS configuration and a certificate that meets the selected mode. A browser padlock alone does not prove that the origin connection is correctly authenticated. Plan certificate renewal, hostname coverage, and redirect behaviour with the hosting administrator before changing encryption settings.

A CDN cannot repair an unhealthy application

Cloudflare may cache eligible assets and provide network-level controls, but it cannot automatically fix a broken plugin, exhausted database connection pool, invalid application code, or deleted files at the origin. Error messages can also originate at different layers. A DNS failure, a TLS handshake problem, an origin timeout, and a website application exception require different investigations. When the site fails, capture the URL, time, response status, whether the request was proxied, and any origin log evidence. Avoid changing several DNS and security settings simultaneously, because that obscures the cause. A reliable incident plan names who can investigate each layer.

Proxy limits and unsupported services

The ordinary Cloudflare reverse proxy is designed around supported web traffic and ports, not every internet protocol. Official network-port documentation lists the HTTP and HTTPS ports handled by default, with separate conditions for caching on some ports. Services such as remote administration, database connections, and mail should not be assumed to work through the orange-cloud proxy. Proxied requests also have size and timeout limits that depend on product and plan. A large file upload or slow application response may therefore need design changes or a different route. Confirm current published limits for the actual service rather than relying on an old tutorial.

Security controls are not a security guarantee

Cloudflare offers selected protective controls at the network edge, but the availability and depth of features depend on the current plan and configuration. A firewall rule can reduce certain unwanted requests yet cannot guarantee that a vulnerable plugin, weak administrator password, or exposed origin is safe. Keep the website application and server patched, require appropriate authentication, restrict administrative access, and test backups. Review security events for false positives that block legitimate customers. The provider's dashboard is one evidence source, not proof that the business has completed an independent security assessment. Never describe a Free plan as making a website invulnerable.

Cloudflare Pages is a different product

There is an important exception to the statement that Cloudflare never hosts websites. Cloudflare Pages can deploy static site assets, and Pages Functions can provide selected server-side functionality; Cloudflare also directs new application projects toward Workers. Those products are not the same thing as merely putting an existing cPanel website behind Cloudflare DNS and the Free proxy. A PHP application that depends on a traditional database and filesystem does not automatically become a Pages project when nameservers change. Evaluate application compatibility, deployment workflow, storage needs, and provider terms separately before considering an actual platform migration. Do not confuse a product capability with an enabled service.

Prepare a nameserver change carefully

For a common Cloudflare Free full DNS setup, the domain's authoritative nameservers are changed at the registrar after the zone records have been reviewed. Cloudflare's official setup guidance warns that existing DNSSEC delegation must be handled correctly; stale DS records can make the domain unreachable. Before changing nameservers, export or record the existing A, AAAA, CNAME, MX, TXT, and relevant service records. Identify third-party verification entries and delegated subdomains. Plan a reversible change window, confirm who controls the registrar, and know how to verify delegation afterward. A DNS migration is a business continuity task, not a cosmetic dashboard preference.

SaaS websites require provider-specific checks

Some website builders already operate their own delivery and certificate systems. Cloudflare's DNS proxy use-case guidance warns that proxying a hostname pointed at certain SaaS platforms can cause certificate conflicts, redirect loops, or rejected requests unless the platform explicitly supports the arrangement. If a business uses a hosted website builder, follow that provider's required DNS configuration rather than applying a generic orange-cloud instruction. Keep verification CNAME records DNS-only where the service requires direct target resolution. A successful DNS lookup does not by itself prove that the website builder has accepted the custom domain or issued the correct certificate.

Measure speed rather than assuming it

A cached image may arrive faster from an edge location, but the total experience also depends on the origin response, page size, JavaScript execution, third-party scripts, and the visitor's device. Compare page-load and server-response measurements before and after an approved configuration change under similar conditions. Inspect whether static assets are cache hits, whether HTML still reaches the origin, and whether authenticated paths behave correctly. If performance is poor, image compression, fewer blocking resources, and application optimisation may help more than changing a DNS proxy setting. Do not promise a ranking improvement or a particular loading-time reduction merely because Cloudflare is enabled.

A hypothetical shop with existing email

Imagine a Malaysian shop whose website and email use the same domain but different suppliers. Its website runs on shared hosting, and staff read mail through a separate business email service. The owner wants Cloudflare for eligible web caching and security controls. The safe planning sequence is to identify the web origin, map every current DNS record, preserve MX and mail authentication records, and check certificate compatibility. Proxy only the supported website hostnames; leave mail hostnames DNS-only. Test web pages and mail after any authorised nameserver change. This example illustrates separation of responsibilities, not a claim that OnHypp has changed any customer's configuration.

What to ask before choosing Free

Ask which Cloudflare features are actually included in the current Free plan, what the proxy and cache limits are, and whether the application requires unsupported protocols or ports. Confirm the origin's certificate, website backup process, and administrator access. Find out who will manage DNS changes, investigate false-positive security blocks, clear stale cache, and renew the hosting subscription. Keep separate renewal and billing records for the domain, web host, and any optional services. Free entry-level functionality may be useful, but it does not remove the cost of application maintenance or create a support agreement that has not been purchased.

Troubleshoot by layer and keep rollback notes

If a website stops working after a DNS or proxy change, do not immediately assume that the hosting server is down. First determine whether authoritative nameservers resolve correctly, whether the affected hostname is proxied, and whether the origin responds directly through an authorised diagnostic route. Next inspect TLS errors, redirects, application logs, and cache behaviour. If mail fails, inspect MX records and DNS-only mail hostnames separately. Record every changed setting and its previous value so a responsible administrator can reverse a bad configuration. Avoid exposing credentials or confidential customer data in screenshots and support tickets. Production changes require a separately approved plan.

Make a service-map decision

For an existing small-business website, draw four boxes: registrar, authoritative DNS, web origin, and email service. Add Cloudflare's proxy between visitors and the origin only for hostnames and features that fit the design. Note which party owns each account, which settings require approval, and which tests establish success. If the requirement is merely to keep a PHP website online, continue paying for compatible hosting even if the domain uses Cloudflare DNS. If the requirement is to host a new static site on Pages or Workers, evaluate that as a separate platform project. A clear service map prevents both duplicate spending and dangerous assumptions.

A managed cloud website and a CDN solve different problems

A CDN can cache suitable public assets closer to visitors and apply edge rules, but it cannot fix an exhausted origin database or guarantee the completion of an authenticated checkout. Compare the hosting account's PHP workers, CPU, RAM and database policy with the application's actual bottleneck; then evaluate caching as a complementary measure. Sensitive school reports, private HR records and payment responses should never be assumed safe to cache publicly.

The extra plans include one eligible domain allowance within their annual price, but they remain managed web hosting rather than a VPS or an automatic email-storage upgrade. If the business already operates mailboxes elsewhere, preserve mail-related DNS records during any CDN or hosting changes. Plan application maintenance and permissions separately from the provider's network and infrastructure responsibilities.

Sources & further reading

Put this into practice

Email & hosting Domains Website design