Guide · Cloudflare for South African SMEs
What a responsible Cloudflare setup includes.
Cloudflare can be a useful layer between customers and your website. A responsible setup is less about switching on every feature and more about knowing what changes, who owns it, how you test it and how you recover when a change is wrong.
Updated · Technical references link to Cloudflare’s official documentation.
First, understand the traffic path
Cloudflare DNS stores the records that tell the internet where a hostname belongs. For an A, AAAA or CNAME record, proxy status determines whether web traffic passes through Cloudflare or goes directly to the origin. A proxied record can use Cloudflare’s caching and security controls; a DNS-only record resolves to the origin and does not receive those HTTP/HTTPS controls.
That distinction is why a setup starts with an inventory. Website traffic may be proxied, while MX and TXT records for email and domain verification remain DNS-only. Cloudflare’s proxy status documentation explains the difference and its limitations.
South African practical note: your registrar, DNS provider, hosting company and email provider may be different companies. Write down each login and owner before changing nameservers. A Cloudflare account should not become the only place where the business knows how its domain works.
The five parts of a responsible setup
01 · Inventory and ownership
List domains, subdomains, DNS records, registrar, origin, email, integrations and account owners. Confirm which records are web traffic and which must stay DNS-only.
02 · A deliberate traffic policy
Choose proxy status, cache behaviour, origin exposure and TLS settings per hostname. Cloudflare’s DNS record guidance explains the fields and decisions.
03 · Rules that match a risk
Use WAF and rate limiting for a named concern—such as a vulnerable path, login abuse or API exhaustion—with an action and threshold that leave normal customers able to use the site.
04 · A testable change plan
Back up the current state, stage changes, define pass/fail checks and identify who can approve a rollback. Nameserver changes deserve extra care because they affect the whole zone.
05 · Handover and review
Document what changed, who owns it, what is excluded and what to watch. Review rules and cache behaviour after real traffic, especially after a launch or application change.
Ownership is part of the technical design
The business should know who owns the Cloudflare account, registrar, hosting account and email system. Use individual user accounts where possible, least-privilege access and MFA; do not leave a consultant’s personal email as the only recovery route. The person who approves a DNS or security change should be identifiable, even if Arlow performs the implementation.
Your handover should include the zone name, account owner, registrar nameservers, origin host, DNS export or record list, proxy decisions, TLS mode, rule intent, exclusions, test evidence, monitoring destination and an agreed emergency contact. Store it somewhere the business can reach without the implementer.
Cloudflare’s account and domain best practices cover MFA and account-protection practices. The exact controls available may depend on the account and plan.
Plan the rollback before the change
A rollback is not simply “turn Cloudflare off.” It may mean restoring a DNS record, disabling a specific rule, changing proxy status, returning a TLS mode to the last known working setting, purging an incorrect cache object or moving nameservers back at the registrar. The safe option depends on what changed.
A small rollback checklist
- Export or record the current DNS and relevant settings before editing.
- Capture the current origin address, certificate state and application test results.
- Make one related group of changes at a time, with an owner and timestamp.
- Define a stop condition: for example, failed checkout, broken email, invalid certificate or repeated false positives.
- Keep the previous values and the registrar access available until post-change checks pass.
Testing should resemble a customer’s day
A green dashboard does not prove that a South African customer can use the site. Test from more than one network and device where possible, and include the business journeys that matter—not just the homepage.
DNS and email
Resolve apex and www records; confirm MX, SPF, DKIM, DMARC and verification records remain correct; send and receive a test message.
HTTPS and origin
Check certificate validity, redirects, mixed content, the selected encryption mode and a healthy connection to the origin.
Customer journeys
Exercise contact forms, logins, checkout, bookings, uploads, webhooks and any API calls that should not be cached or challenged.
Cache and content
Publish a harmless content change, inspect headers, confirm private or dynamic responses are not served incorrectly, and purge only when needed.
Security rules
Use safe test requests and review events to confirm the intended rule matches while legitimate traffic remains unblocked.
Failure path
Record what an operator sees, who is contacted, and which setting or record can be reverted if a check fails.
For CDN behaviour, inspect response headers and application behaviour rather than assuming every page is cached. Cloudflare says static assets are cacheable by default while HTML and JSON are not cached by default; its default cache behaviour documentation describes the exceptions and controls.
Free and paid features can differ
Do not promise a feature from a tutorial without checking the current plan matrix for the customer’s zone. Cloudflare documents availability by plan for WAF capabilities, rate limiting, analytics, cache limits and other controls. A feature can also have different limits, actions, retention or support depending on plan.
For example, Cloudflare’s WAF overview shows a Free/Pro/Business/Enterprise availability table, and the rate-limiting documentation notes plan-dependent parameters and behaviour. The cache documentation also lists plan-specific upload and cacheable-size limits.
The written scope should name the plan assumed, features included, third-party charges excluded and what happens if a paid feature is needed. A safe alternative may be a narrower rule, application-side control or a later upgrade—chosen after testing, not implied as an automatic fix.
What Cloudflare does not solve by itself
Cloudflare does not replace secure code, dependency updates, strong admin authentication, backup and restore testing, email security, access reviews, fraud controls or a business continuity plan. WAF rules can reduce some unwanted requests but cannot know every business-specific vulnerability. Rate limiting can reduce abuse of a path, but Cloudflare notes that enforcement is not designed to deliver a perfectly precise number of requests to your origin.
TLS also has two connections to consider: visitor-to-Cloudflare and Cloudflare-to-origin. Cloudflare’s encryption mode guidance recommends Full or Full (strict) where possible; Full (strict) requires a valid origin certificate. That is a configuration decision to verify, not a promise that every origin is immediately ready.
A setup is not a POPIA opinion, certification or guarantee of compliance. Personal-information governance, retention, contracts, breach response and decisions about suppliers remain the organisation’s responsibility and should be addressed with appropriately qualified advisers.
Need help with the next safe step?
Arlow can review the current state, write a bounded scope and help your team retain ownership of the result.
Explore Cloudflare setup services