Cloudflare and Deploynix are a natural pairing. Cloudflare handles the edge — caching, DDoS protection, and global content delivery — while Deploynix handles the origin — server provisioning, application deployment, and infrastructure management. Together, they give your Laravel application both performance and operational simplicity.
But getting the two working correctly requires attention to a few critical configuration details. Misconfigured SSL settings, incorrect proxy behavior, or overly aggressive caching can cause subtle issues that are difficult to debug. This guide walks through the setup step by step, covering the configurations that matter and the pitfalls to avoid.
Why Cloudflare with Deploynix
Before diving into configuration, let us be clear about what Cloudflare adds to a Deploynix-managed server:
CDN and caching. Cloudflare has data centers in over 300 cities worldwide. Static assets — CSS, JavaScript, images, fonts — are cached at the edge and served from the location closest to your users. This reduces latency for static content from hundreds of milliseconds to single digits.
DDoS protection. Cloudflare absorbs distributed denial-of-service attacks at the network edge before malicious traffic reaches your server. Even on Cloudflare's free tier, you get unmetered DDoS mitigation.
Web Application Firewall (WAF). Cloudflare's WAF filters malicious requests — SQL injection attempts, XSS payloads, and other common attacks — before they reach your Laravel application.
Performance optimizations. Cloudflare offers Brotli compression, HTTP/2 and HTTP/3 support, image optimization, and minification, all applied at the edge without changes to your application code.
DNS management. Cloudflare provides fast, reliable DNS with built-in DNSSEC support.
Step 1: Add Your Domain to Cloudflare
If you have not already, add your domain to Cloudflare:
- Sign up or log in at dash.cloudflare.com.
- Click "Add a Site" and enter your domain.
- Choose a plan (the free tier is sufficient for most Laravel applications).
- Cloudflare scans your existing DNS records and imports them.
- Update your domain's nameservers at your registrar to the Cloudflare nameservers provided.
Nameserver propagation typically takes a few hours but can take up to 48 hours. During this period, your site continues to work through your old DNS — there is no downtime.
Step 2: Configure DNS Records
Once your domain is on Cloudflare, you need DNS records pointing to your Deploynix-managed server.
Create an A record for your root domain:
- Type: A
- Name: @ (or your domain)
- Content: Your server's IP address (found in the Deploynix dashboard)
- Proxy status: Proxied (orange cloud)
Create a CNAME record for the www subdomain (if applicable):
- Type: CNAME
- Name: www
- Content: yourdomain.com
- Proxy status: Proxied (orange cloud)
The orange cloud icon means traffic flows through Cloudflare's network. If the cloud is grey (DNS only), traffic goes directly to your server and you get none of Cloudflare's benefits.
Important: When the proxy is enabled, Cloudflare hides your server's real IP address. This is a security benefit — attackers cannot target your origin server directly if they do not know its IP. However, it means your server will see Cloudflare's IP addresses in request logs instead of your visitors' real IPs. We will address this in the trusted proxies section below.
Step 3: SSL Configuration — Getting This Right Is Critical
This is the most important section of this guide. Incorrect SSL configuration between Cloudflare and Deploynix causes redirect loops, mixed content warnings, or insecure connections. Here is how to get it right.
Understanding the SSL Chain
With Cloudflare proxying your traffic, there are two SSL connections:
- Visitor to Cloudflare: Your user's browser connects to Cloudflare's edge server over HTTPS.
- Cloudflare to Deploynix: Cloudflare connects to your origin server (managed by Deploynix) over HTTPS.
Cloudflare offers four SSL modes:
- Off: No encryption. Never use this.
- Flexible: Encrypts visitor-to-Cloudflare but connects to your server over plain HTTP. Avoid this — it gives users a false sense of security.
- Full: Encrypts both connections but does not validate your origin server's SSL certificate. Accepts self-signed certificates.
- Full (Strict): Encrypts both connections and validates your origin server's SSL certificate. Requires a valid certificate on your server.
The Correct Setting: Full (Strict)
Set your Cloudflare SSL mode to Full (Strict). Here is why:
Deploynix automatically provisions valid Let's Encrypt SSL certificates for your sites. These are trusted certificates that Cloudflare can validate. Using Full (Strict) ensures end-to-end encryption with certificate validation — the most secure option.
To configure this:
- In the Cloudflare dashboard, go to SSL/TLS > Overview.
- Select Full (Strict).
That is it. Because Deploynix handles Let's Encrypt certificate provisioning and automatic renewal, your origin always has a valid certificate for Cloudflare to validate.
Avoiding Let's Encrypt Conflicts
Deploynix uses HTTP-01 challenges to issue Let's Encrypt certificates. This requires that Let's Encrypt can reach your server on port 80 at a specific URL path (/.well-known/acme-challenge/).
When Cloudflare is proxying your domain, Let's Encrypt's validation requests go through Cloudflare first. This usually works fine, but there are two scenarios that can cause issues:
Page rules or redirects that force HTTPS on all paths. If you have a Cloudflare page rule that redirects all HTTP traffic to HTTPS, the ACME challenge request (which comes over HTTP) gets redirected and fails. Solution: Do not create page rules that redirect /.well-known/acme-challenge/* paths. Cloudflare's "Always Use HTTPS" setting in SSL/TLS > Edge Certificates handles HTTPS redirection without interfering with ACME challenges.
Cloudflare's "Always Use HTTPS" setting. This setting redirects HTTP to HTTPS for all visitor requests but does not affect server-to-server validation requests. It is safe to enable and does not interfere with Let's Encrypt certificate issuance through Deploynix.
Alternative: Cloudflare Origin Certificates. If you want to avoid Let's Encrypt entirely for the origin connection, you can generate a Cloudflare Origin Certificate. This is a certificate signed by Cloudflare that is trusted by Cloudflare's proxies but not by browsers. It is free, lasts up to 15 years, and eliminates the need for Let's Encrypt renewal on the origin. However, if you ever need to bypass Cloudflare (for debugging or during a Cloudflare outage), your site will show a certificate error in browsers. For most setups, Let's Encrypt through Deploynix is the better choice.
Step 4: Configure Trusted Proxies in Laravel
When Cloudflare proxies your traffic, your Laravel application sees Cloudflare's IP addresses instead of your visitors' real IP addresses. This affects:
-
request()->ip()returns Cloudflare's IP, not the visitor's. - Rate limiting based on IP address limits Cloudflare, not individual users.
- Logging and analytics show Cloudflare IPs.
Laravel's TrustProxies middleware solves this. In your bootstrap/app.php, configure trusted proxies:
->withMiddleware(function (Middleware $middleware) {
$middleware->trustProxies(at: '*');
})
Setting at: '*' trusts all proxies, which is appropriate when Cloudflare is your only proxy layer. If you want to be more specific, you can set Cloudflare's IP ranges, but these change periodically and managing them adds maintenance burden.
With trusted proxies configured, Laravel reads the X-Forwarded-For header that Cloudflare sets, correctly identifying your visitors' real IP addresses.
Step 5: Caching Configuration
Cloudflare's caching is powerful but needs to be configured carefully for Laravel applications to avoid serving stale or incorrect content.
What Cloudflare Caches by Default
By default, Cloudflare caches static files based on file extension: CSS, JavaScript, images, fonts, and other static assets. It does not cache HTML responses or API responses.
This default behavior is generally correct for Laravel applications. Your Blade views, API responses, and dynamic pages are not cached by Cloudflare, while your Vite-compiled assets are cached at the edge.
Cache-Control Headers
Your Laravel application should send appropriate Cache-Control headers. For most dynamic pages:
return response()->view('dashboard')
->header('Cache-Control', 'no-store, no-cache, must-revalidate');
For API responses that can be cached briefly:
return response()->json($data)
->header('Cache-Control', 'public, max-age=60');
Cloudflare respects your origin's Cache-Control headers. If you do not set them, Cloudflare applies its own defaults, which might cache content you do not want cached.
Vite Asset Caching
Laravel Vite generates hashed filenames for compiled assets (e.g., app-DfG8h2k.js). Because the filename changes whenever the content changes, these assets can be cached aggressively. Cloudflare handles this automatically — hashed assets are cached until they expire or are purged, and new deployments generate new filenames that bypass the cache.
Purging the Cache After Deployment
If you deploy a change that affects cached content (for example, updating a publicly cached API response), you may need to purge Cloudflare's cache. You can do this through the Cloudflare dashboard under Caching > Configuration > Purge Everything, or through the Cloudflare API.
For automated cache purging after deployment, you can add a step to your Deploynix deploy script that calls the Cloudflare API:
curl -X POST "https://api.cloudflare.com/client/v4/zones/YOUR_ZONE_ID/purge_cache" \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-H "Content-Type: application/json" \
--data '{"purge_everything":true}'
Replace YOUR_ZONE_ID and YOUR_API_TOKEN with your actual values. Store the API token in your environment variables, not hardcoded in the hook.
Step 6: Security Settings
Bot Protection
Cloudflare's Bot Management (available on paid plans) and Bot Fight Mode (available on free plans) help filter out malicious automated traffic. Enable Bot Fight Mode under Security > Bots.
Be aware that overly aggressive bot protection can block legitimate traffic, including:
- Webhook deliveries from services like Stripe, Paddle, or GitHub.
- API clients that integrate with your Laravel application.
- Monitoring services that check your site's availability.
If you use webhook endpoints, consider creating a Cloudflare WAF rule that bypasses bot protection for those specific paths.
Firewall Rules
Cloudflare's WAF rules (free tier includes 5 custom rules) can block traffic before it reaches your server. Useful rules for Laravel applications:
- Block requests to sensitive paths: Block direct access to
.env,.git,storage/, and other paths that should never be publicly accessible. - Country blocking: If your application only serves specific regions, block traffic from countries where you have no users.
- Rate limiting: Cloudflare's rate limiting rules complement Laravel's built-in rate limiting by stopping abusive traffic before it consumes server resources.
Security Headers
Cloudflare can add security headers to responses at the edge. Under SSL/TLS > Edge Certificates, enable:
- HTTP Strict Transport Security (HSTS): Forces browsers to use HTTPS for all future requests. Enable with a max-age of at least 6 months.
- Minimum TLS Version: Set to TLS 1.2 to block connections using outdated, insecure protocols.
Step 7: Performance Optimizations
Brotli Compression
Enable Brotli compression under Speed > Optimization > Content Optimization. Brotli provides better compression ratios than gzip for text content, reducing the size of HTML, CSS, and JavaScript responses.
Early Hints
Cloudflare supports HTTP 103 Early Hints, which tells browsers to preload critical resources before the HTML response is fully generated. Enable this under Speed > Optimization to shave milliseconds off your page load times.
HTTP/3 (QUIC)
Enable HTTP/3 under Network. HTTP/3 uses QUIC, which provides faster connection establishment and better performance on unreliable networks (mobile, WiFi). Modern browsers support HTTP/3 and will use it automatically when available.
Argo Smart Routing (Paid)
Argo Smart Routing optimizes the network path between Cloudflare and your origin server, reducing latency by routing around congested internet paths. It costs $5/month plus $0.10 per GB, but for latency-sensitive applications, the improvement can be significant.
Common Issues and Solutions
Redirect loops. Almost always caused by incorrect SSL mode. Set SSL to Full (Strict) and ensure Deploynix has a valid SSL certificate for your domain.
Mixed content warnings. Your HTML references HTTP resources. Cloudflare's "Automatic HTTPS Rewrites" (under SSL/TLS > Edge Certificates) can fix this automatically by rewriting HTTP URLs to HTTPS in your responses.
WebSocket connection failures. Cloudflare supports WebSocket connections on all plans, but you must ensure the proxy status is enabled for the subdomain your WebSocket server uses. Laravel Reverb works through Cloudflare's proxy without additional configuration.
Large file upload failures. Cloudflare's free plan has a 100MB upload limit per request. If your application accepts large file uploads, you may need to upgrade to a paid plan (200MB on Pro, 500MB on Business) or implement direct-to-S3 uploads that bypass Cloudflare entirely.
Final Configuration Checklist
Before considering your Cloudflare + Deploynix setup complete, verify:
- DNS records point to your Deploynix server with the orange proxy cloud enabled.
- SSL mode is set to Full (Strict).
- Let's Encrypt certificates are issuing and renewing successfully on Deploynix.
- Trusted proxies are configured in your Laravel application.
-
Cache-Controlheaders are set appropriately for your dynamic routes. - Bot Fight Mode is enabled without blocking legitimate webhooks.
- HSTS is enabled with an appropriate max-age.
- Brotli compression is enabled.
- HTTP/3 is enabled.
With these settings in place, your Laravel application benefits from Cloudflare's global network and Deploynix's operational management. Traffic is filtered, cached, and optimized at the edge, and your origin server handles only the requests that actually need dynamic processing.
This is the configuration that scales from a personal project to a high-traffic production application, and it starts with getting the fundamentals right.
