Project 1 - Part 2 - Custom Domain, HTTPS, and Cloudflare Integration

Overview

After the site structure and Azure Functions endpoint were working, the next step was to improve the project from a deployment perspective.

In this part, I connected the website to a real custom domain, enabled HTTPS, and used Cloudflare as the DNS and edge layer. This made the project feel much closer to a production-style website instead of only a default cloud-hosted demo.

The goal was not to build a complicated networking setup. The goal was to apply practical cloud operations thinking to a small portfolio site:

• use a real domain
• validate HTTPS properly
• route traffic cleanly
• keep the site structure simple
• add a basic security and edge layer through Cloudflare

Why I Added a Custom Domain

A default Azure Static Web Apps domain is useful for deployment, but it does not present the project as strongly as a real domain.

Adding a custom domain improved the project in several ways:

• it made the site look more professional
• it created a more realistic production-style setup
• it added practical DNS work to the project
• it created a better foundation for Cloudflare integration
• it improved the overall portfolio value of the website

For this project, the domain became part of the technical work, not just a cosmetic change.

Step 1 - Buy the Domain and Prepare DNS

I purchased the domain and managed DNS through Cloudflare.

This gave me a central place to handle:

• DNS records
• domain routing
• HTTPS-related edge settings
• redirect behavior
• basic traffic and security controls

At this stage, the website was already working on the Azure Static Web Apps default hostname. The custom domain work was about replacing that default entry point with a cleaner public address.

Step 2 - Start with the www Subdomain

Instead of starting with the root domain immediately, I began with:

www.lwcsecinfra.com

This was the simpler path because Azure Static Web Apps supports custom subdomain validation cleanly through DNS.

I treated www as the primary website hostname and planned to handle the root domain separately through redirect logic.

This made the setup easier to reason about:

• www would be the real site
• the root domain would forward to www

Step 3 - Add the Custom Domain in Azure Static Web Apps

Inside Azure Static Web Apps, I added a custom domain for:

www.lwcsecinfra.com

Azure then provided the required DNS validation information for domain ownership.

For this subdomain flow, the important DNS record was a CNAME that pointed www to the Azure Static Web Apps hostname.

This was the stage where Azure verified that the domain was correctly connected to the site.

Step 4 - Create the CNAME Record in Cloudflare

In Cloudflare DNS, I added a CNAME record for the www subdomain.

The structure was conceptually:

Type: CNAME
Name: www
Target: <azure-static-web-app-hostname>
Proxy status: DNS only

I intentionally used DNS only during the initial validation step so that Azure could verify the custom domain relationship cleanly.

This was an important detail. Cloudflare proxying is useful later, but for first-time validation it is often cleaner to keep the record as DNS only until Azure finishes the ownership and certificate process.

Step 5 - Wait for Validation and HTTPS Provisioning

After the DNS record was in place, Azure Static Web Apps completed the custom domain configuration.

Once the validation succeeded, HTTPS became available for the custom domain.

This was the key result:

https://www.lwcsecinfra.com

The site was no longer using only the Azure-generated hostname. It was now reachable on the custom domain with HTTPS working properly.

Step 6 - Test the Live Domain and API

After the custom domain setup completed, I tested both the website and the API endpoint through the live domain.

This included checking:

• the homepage
• the Projects / Lab section
• the first project page
• the live API endpoint

The API health endpoint also worked through the custom domain path:

https://www.lwcsecinfra.com/api/health

That confirmed the site and the serverless endpoint were both reachable under the production-style hostname.

Step 7 - Configure Cloudflare Proxying

After the custom domain validation was complete, I moved the www record from DNS only to Proxied.

This allowed traffic to flow through Cloudflare instead of only using Cloudflare for raw DNS resolution.

That change made Cloudflare part of the live traffic path and enabled:

• edge proxying
• Cloudflare analytics
• security features
• HTTPS-related controls at the edge

This was the point where the project gained a more realistic CDN and edge-security layer.

Step 8 - Set SSL/TLS Mode to Full (strict)

Once the custom domain and HTTPS were working, I configured Cloudflare SSL/TLS mode to:

Full (strict)

This was the correct fit for the project because Azure Static Web Apps already provided a valid HTTPS setup for the custom domain.

Using Full (strict) means Cloudflare does not just talk to the origin over HTTPS. It also expects the origin certificate to be valid.

This made the HTTPS path stronger and more production-minded.

Step 9 - Enable Always Use HTTPS

Since the site already supported HTTPS correctly, I enabled Always Use HTTPS in Cloudflare.

This forced HTTP requests to redirect to HTTPS automatically.

That meant:

• visitors would always land on the secure version of the site
• accidental HTTP access would be corrected automatically
• the public entry point became cleaner and safer

For a production-style site, this is a small but important detail.

Step 10 - Redirect the Root Domain to www

After www was working correctly, I handled the root domain separately.

The final routing approach was:

• www.lwcsecinfra.com = real website hostname
• lwcsecinfra.com = redirect to https://www.lwcsecinfra.com

To support this in Cloudflare, I used:

• a proxied root record
• a redirect rule from the apex domain to the www hostname

This kept the site architecture simple:

• one primary hostname serves the actual site
• the root domain acts as a clean redirect layer

This avoided unnecessary complexity while still giving the site a professional public entry point.

Step 11 - Add Basic Edge Security Settings

With the site fully live behind Cloudflare, I applied a small set of practical edge settings.

These included:

• proxied traffic for the main website hostname
• Full (strict) SSL/TLS mode
• Always Use HTTPS
• root-to-www redirect

I also reviewed additional Cloudflare options such as:

• Bot Fight Mode
• DNSSEC
• Under Attack Mode

For this stage, the important lesson was that not every security toggle needs to be enabled immediately. The project benefited most from getting the core routing, TLS, and edge path correct first.

Result

At the end of this stage, the project had moved from a default Azure hostname to a production-style public setup with:

• a real custom domain
• working HTTPS
• Cloudflare-managed DNS
• Cloudflare edge proxying
• enforced HTTPS
• root domain redirect to www
• a cleaner public-facing architecture

This made the project significantly stronger as a cloud portfolio example because it now demonstrated not only deployment, but also practical domain and edge integration.

What This Part Demonstrates

This part demonstrates:

• custom domain setup for Azure Static Web Apps
• domain ownership validation through DNS
• practical Cloudflare DNS configuration
• production-style HTTPS handling
• Cloudflare proxy integration
• root-to-www redirect design
• a more realistic public deployment architecture

What I Learned

A few practical lessons stood out from this stage:

1. It is easier to start with www than with the root domain
2. DNS validation and certificate provisioning require patience
3. Cloudflare proxying should be introduced at the right stage, not too early
4. Full (strict) is a better long-term HTTPS setting when the origin is already configured correctly
5. Clean public routing is part of production thinking, even for a small website

Final Reflection

By this point, the project was no longer just a static site hosted in Azure.

It had become a more complete cloud-based portfolio project with:

• static hosting
• serverless integration
• branch-based deployment workflow
• custom domain setup
• HTTPS
• Cloudflare DNS and edge handling

That combination made the site much more valuable as a practical demonstration of cloud, Azure, and deployment skills.