Put a Lightsail WordPress Site Behind Cloudflare

2026-02-15

The Bitnami image makes a WordPress site quick to start on AWS Lightsail. Once the site has been running for a while, you may still notice intermittent slowdowns or repeated login probes even when ordinary readership is steady. The access log can show whether automated traffic is part of the problem.

WordPress serves public endpoints for login, comments, XML-RPC and its REST API. Many requests need to reach PHP and the database. Enough concurrent work can slow a small instance or leave the proxy waiting for a response.

Cloudflare can sit in front of the Lightsail instance. Its proxy can serve cacheable content from the edge and filter some traffic there, while sending requests that need WordPress to the original server.

The setup has three moving parts: DNS, a certificate on the Lightsail instance, and Cloudflare’s encryption mode. Set them up in the right order so that you can test the origin before putting the proxy in front of it.

Trace the connection

This is how the request path changes.

  • Before: Visitor → Lightsail server
  • After: Visitor → Cloudflare edge → Lightsail server

A proxied HTTPS request can involve two separate TLS connections.

  1. Visitor ↔ Cloudflare
  2. Cloudflare ↔ Lightsail origin

Cloudflare presents one certificate to visitors. In Full (strict) mode, the Lightsail origin presents another certificate that Cloudflare validates.

1. Add the domain and review DNS

Add the domain to Cloudflare and review the DNS records it imports. Check email records and any other services before changing the nameservers, along with the records for the website.

The apex A record points to the Lightsail instance. Attach a static IP in Lightsail so this record still points to the right place after an instance stop and start.

The following example shows the final proxy setting. During initial certificate issuance with bncert, leave the relevant records DNS only so they resolve directly to Lightsail.

Type: A
Name: @
IPv4 address: Lightsail static public IP
Proxy status: Proxied

If you serve the site at www as well, add a CNAME pointing to the apex.

Type: CNAME
Name: www
Target: @
Proxy status: Proxied

Once you have verified HTTPS at the origin, turn on the proxy for the web records you want Cloudflare to handle. Records left DNS only do not use Cloudflare’s HTTP cache or firewall.

2. Update the domain’s nameservers

At the domain registrar, enter the nameservers assigned to this zone by Cloudflare. Cloudflare will then become the authoritative DNS provider for the domain once the change takes effect.

Check that the Cloudflare dashboard marks the zone Active. DNS caching can leave some visitors on older answers for a while. Only records set to Proxied will route web requests through Cloudflare.

3. Install a certificate on Lightsail

On the Bitnami image, bncert can set up a Let’s Encrypt certificate. Make sure every hostname you include resolves directly to the Lightsail instance as required by AWS’s instructions. Then connect over SSH and run the following command.

sudo /opt/bitnami/bncert-tool

Follow the prompts for domain names and redirects. The tool updates the web server configuration and sets up renewal. Before enabling the proxy, open the site over HTTPS and verify the certificate and redirects for the hostnames you will use.

4. Set Cloudflare’s encryption mode

In the dashboard, open SSL/TLS → Overview.

Choose Full (strict) for this configuration.

The three modes differ on the origin side.

  • Flexible sends requests from Cloudflare to the origin over HTTP. An origin that redirects HTTP to HTTPS can send the browser into a loop.
  • Full uses HTTPS for HTTPS requests to the origin, but Cloudflare does not validate the origin certificate.
  • Full (strict) also validates the origin certificate, including its expiry, issuer and hostname.

A valid Let’s Encrypt certificate for the hostname satisfies the certificate requirements for Full (strict).

5. Check WordPress redirects

With Full (strict), the HTTPS request reaches the Lightsail web server over HTTPS. If WordPress is caught in a redirect loop, first check the site and home URLs, the Cloudflare encryption mode, and redirects on the origin.

A separate reverse proxy between Apache and PHP can change how WordPress sees the request scheme. Use the configuration for that specific proxy chain.

A forwarded protocol header is trustworthy only when a trusted proxy sets it and direct requests cannot spoof it. Avoid adding a generic header-based override to wp-config.php on a publicly reachable origin.

If you change the web server configuration, use the restart procedure for your Bitnami image and test the public site and the login afterward.

sudo /opt/bitnami/ctlscript.sh restart

Keep a record of which layer handles redirects. It makes a loop much easier to trace.

6. Review caching and security options

Once the site works over HTTPS, decide which Cloudflare settings are useful for it.

Here are the options considered in this setup.

  • Always Use HTTPS redirects visitor HTTP requests at the edge.
  • Automatic HTTPS Rewrites can help with eligible mixed-content URLs. Correct hardcoded HTTP URLs in the site where possible.
  • Bot Fight Mode can challenge some automated traffic. Test integrations and legitimate clients before leaving it enabled.
  • Keep the Standard caching level as a starting point. Avoid caching private pages or authentication responses.

A cache hit can spare the origin a request for a static asset. A security rule acts on the requests it matches. Check those two effects independently.

Check what changed

Once the proxy is on, confirm the public URL stays on HTTPS and compare the logs and timing against the earlier setup.

  • Check whether fewer automated login requests reach the origin.
  • Compare CPU usage during similar traffic periods.
  • Check response times from regions where readers are located.
  • Watch the volume of comment spam if you changed bot or firewall settings.
  • Track whether intermittent timeouts fall in the origin logs.

A smaller instance can benefit when the edge handles work it previously had to do. An origin that remains reachable directly can still receive traffic that bypasses Cloudflare.

The order to remember

This setup gives the site an edge proxy and a validated HTTPS connection to the server it sits in front of. The sequence matters.

  1. Install and verify the origin certificate.
  2. Confirm DNS delegation and enable proxying on the intended web records.
  3. Use Full (strict) to validate the origin certificate.

Then check a public page, an administrative login and any redirects from the other hostnames you configured.

Search stories