Cloudflare Dash: A Tour of the Dashboard and What to Set First

The Cloudflare dash is the control panel for the DNS, proxy, security and performance layer that sits in front of your site, and the handful of settings that matter most are DNS records, the SSL mode, caching rules and security basics.

It is a dense interface because it covers many products at once. This is a map of the parts a website owner actually touches, and the order to set them in.

Table of contents

• What the dashboard is and what it is not
• The sections worth knowing
• DNS records and the orange cloud
• SSL/TLS: the setting that breaks sites
• Caching and security: first-day settings
• When to leave the dashboard alone
• Account safety and the changes you cannot easily undo
• How this fits the rest of the stack
• FAQ

What the dashboard is and what it is not

The dashboard at dash.cloudflare.com is the management console for a third-party network that sits between your visitors and your origin server. Once you point a domain’s nameservers at it, requests for your site resolve to Cloudflare first. It can answer from cache, filter bad traffic, apply rules and forward the rest to wherever your site is hosted.

That second sentence is the important one. It is a layer in front of hosting, not hosting itself, for the typical website setup. Your files, application and database still live on a server somewhere, and the dash configures how traffic reaches them. The company also operates a developer platform for running code at the edge, but that is a separate set of products inside the same login, and the dashboard for an ordinary website mostly concerns the proxy layer.

When you first sign in you land on an account home listing your domains, which Cloudflare calls zones, plus the account-level products. Click a domain and the left sidebar changes to settings specific to that site. Almost everything below lives inside a zone.

The official documentation on logging in covers email, single sign-on and social login options. If you manage more than one site, set up two-factor authentication on the account before anything else. This panel controls where your traffic goes, so an account takeover is a site takeover.

The sections worth knowing

The sidebar looks overwhelming, but a site owner uses a small portion of it.

• Overview. Status of the zone, the nameservers it expects, and quick analytics.
• DNS. The records for the domain. This is where an A record, CNAME or MX record is added.
• SSL/TLS. The encryption mode between visitors, the proxy and your origin, plus certificates.
• Security. Firewall rules, rate limiting and bot protections.
• Caching. What gets stored at the edge and for how long.
• Rules. Redirects, header changes and page rules.
• Analytics and logs. Traffic and, on some plans, log delivery.

Treat the rest as optional until you need it. Products for workers, storage, databases and zero trust all appear in the same console and they are easy to wander into. If you only want a faster, safer website, you can ignore most of them.

A habit that saves trouble: before you change a setting, note its current value. The dashboard applies changes quickly and globally, and there is no staging environment for a zone. If something breaks, you want to know what to put back.

DNS records and the orange cloud

The DNS tab lists every record for the domain, and next to each address record sits a cloud icon. Orange means the record is proxied, so traffic flows through Cloudflare. Grey means DNS only, so the name resolves directly to your server and Cloudflare is just a nameserver.

Proxying is what gives you caching, protection and a hidden origin address. It also has a catch. Only HTTP and HTTPS traffic can be proxied on standard plans. A record for mail, SSH or a database port must be grey, or the connection fails. A common mistake is proxying the record that mail points to, which breaks email delivery.

Type   Name    Content          Proxy
A      @       203.0.113.10     Proxied
CNAME  www     example.com      Proxied
A      mail    203.0.113.20     DNS only
MX     @       mail.example.com DNS only

When you add a site, the dashboard scans existing records and imports them. Verify the import. A missing record means an email or subdomain that quietly stops working the moment nameservers switch. Compare the import against your old DNS provider’s zone file before you change anything.

If you need background on how nameserver changes propagate, the post on Cloudflare DNS servers, primary and secondary is a useful companion.

SSL/TLS: the setting that breaks sites

The encryption mode is the single most common source of the dashboard-induced outage. There are several modes, and the differences are about how far the encryption extends.

• Off serves everything over plain HTTP. Avoid.
• Flexible encrypts between the visitor and Cloudflare but not between Cloudflare and your origin. It looks secure and is not.
• Full encrypts the whole path but accepts a self-signed certificate on the origin.
• Full (strict) encrypts the whole path and requires a valid certificate on the origin.

Choose Full (strict) whenever your origin can present a valid certificate. Flexible has a particularly nasty failure mode: if your origin also forces HTTPS, you get an infinite redirect loop, because Cloudflare talks to the origin over HTTP and the origin keeps redirecting it to HTTPS. That is the too many redirects error that sends people searching.

If your host cannot provide a certificate, Cloudflare can issue an origin certificate that is trusted only by its own proxy. That works, but it ties your site to staying proxied. Check whether your hosting already issues certificates before you add one. The related posts on Cloudflare TLS termination and SSL origin go deeper on the options.

Caching and security: first-day settings

Two groups of settings are worth a look on day one.

For caching, the defaults are conservative: static assets such as images, CSS and JavaScript are cached and HTML is not. That is safe. Aggressive caching of HTML is where the large speedups live, and also where logged-in users start seeing other people’s pages if you get the rules wrong. Add cache rules deliberately and bypass the cache for any path that depends on a cookie, such as account or checkout pages. If you purge, purge by URL rather than everything, unless you must.

For security, start with the basics. Turn on the managed protections for common attack patterns, enable bot protections at a level that does not block legitimate crawlers, and add a rate limit on login and API endpoints. A rate limit on the login path blocks credential-stuffing attempts cheaply. The Cloudflare rate limiting post covers the thresholds.

Do not tighten everything at once. Make one security change, watch the analytics for blocked legitimate traffic for a day, then make the next. A challenge that blocks your own payment provider’s webhook will not announce itself loudly.

When to leave the dashboard alone

The dashboard is genuinely useful, but a proxy layer is also another thing to debug. When a page fails, you now have three suspects: your origin, the proxy and DNS. A site that is fast and low-traffic may not need the layer at all.

Reasons to add it: you want free or inexpensive DDoS absorption, you serve a global audience with mostly static assets, or you want rules and redirects managed outside your app. Reasons to skip it: your host already provides TLS, caching and a CDN, and you would be duplicating work.

If your site runs on a managed platform, check what is already included. A RunxBuild static site comes with build from the repository, custom domains with certificates handled, plus headers, redirects, rewrites and SPA fallback, with 120GB of bandwidth included before $0.10 per GB. Whether to also place a proxy in front is then a choice, not a necessity. The static sites introduction lists what is included.

Account safety and the changes you cannot easily undo

Because the dashboard sits in front of production traffic, treat account hygiene as part of the setup rather than an afterthought. Use a hardware key or an authenticator app for two-factor, store recovery codes somewhere other than the same password manager entry, and give teammates their own logins with the narrowest role that lets them do their job. Shared logins make it impossible to tell who changed a rule when something breaks.

If you automate changes, prefer scoped API tokens over the global key. A token limited to editing DNS records for one zone cannot accidentally disable the firewall on another. Rotate tokens when people leave.

A few changes deserve a pause before you click. Switching nameservers moves your entire DNS to a new provider. Changing the SSL mode can take a working site offline in seconds. Purging the whole cache sends every request back to your origin at once, which can topple a small server. None of these is dangerous when planned, and all of them are unpleasant at five on a Friday.

How this fits the rest of the stack

A proxy in front of your site is a monthly line item and an operational dependency, so cost it alongside everything else. The RunxBuild hosting calculator shows the hosting side as separate numbers so you can see what each layer adds. When you want a site and its domain running first, the RunxBuild dashboard is where to create it.

Useful related references:

• Cloudflare Postgres: Why Hyperdrive, Not a Managed Database
• Cloudflare Logpush: What It Ships, What It Costs, and What It Misses
• Cloudflare Analytics: Web Analytics vs Zone Analytics, Explained
• Services on RunxBuild

FAQ

How do I log in to the Cloudflare dashboard?

Go to dash.cloudflare.com and sign in with email and password, single sign-on or a supported social login. Enable two-factor authentication immediately, because this account controls where your domain’s traffic goes.

What do the orange and grey clouds in DNS mean?

Orange means the record is proxied through Cloudflare, so you get caching and protection. Grey means DNS only, which resolves straight to your server. Records for mail, SSH and database ports must be grey.

Which SSL/TLS mode should I choose?

Full (strict) when your origin has a valid certificate. Avoid Flexible, which leaves the origin leg unencrypted and can create redirect loops if the origin forces HTTPS.

Can I use the dashboard without moving my hosting?

Yes. For a typical website it sits in front of your existing host. You change your domain’s nameservers and keep your origin where it is.

Do I need it if my host already has a CDN?

Not necessarily. If your host already provides TLS, caching and DDoS protection, an extra proxy mostly adds another layer to debug. Add it for a specific need, not by default.