Leave GoDaddy and Go Completely Serverless Using Just Cloudflare and S3 Buckets: Part Two

This is the continuation of Part One. The goal again is:

Results

Here is my serverless WordPress website now:

Table of Contents

Part Two

• Serverless: Serve a WordPress Website without a Server
• The Plan for Apache’s Htaccess
• Step 15. Set up a Cloudflare Worker Dev Environment
• Step 16. Serve Dynamic Content, Formerly PHP Scripts
• Step 17. Publish a Cloudflare Worker
• Step 18. Prevent Bots from Hammering your Workers
• Step 19. Cron Jobs without a Server
• Step 20. Move Comments and Schedules to a Third-Party
• Advanced Serverless Options
• Advanced Concepts and Gotchas
• Checklist: Move Sites from GoDaddy
• The GoDaddy Experience Simulator
• Results and Summary

Part One

• More Reasons to Leave GoDaddy
• GoDaddy is Indirectly Vulnerable to Hacks
• Many Domains Point to the GoDaddy Shared Server
• Motivation to Leave
• Let’s Get Organized
• High-Level Plan of Action
• Step 1. Calculate the Monthly Cost with AWS S3
• Step 2. Back Up Everything
• Step 3. Test the Cloudflare Email Routing Service
• Step 4. (Optional) Test a Third-Party Email Forwarder
• Step 5. Create a Virtual Machine Running Docker
• Step 6. Install Docker with Cloud-Init
• Step 7. Replicate GoDaddy’s WordPress Environment
• Step 8. Generate Static HTML Offline
• Step 9. Sync Static Production Files to S3
• Step 10. Verify the 404 Page Works
• Step 11. Allow Cross-Origin Resource Sharing (CORS)
• Step 12. Allow Subdomain Virtual Hosts with S3
• Step 13. Query Strings and S3 Bucket Keys
• Step 14. Enable HTTPS Websites with HTTP-Only S3
• Summary of AWS S3 Bucket CLI commands

Serverless: Serve a WordPress Website without a Server

Congratulations. At this point we have a working website, and do not even need Workers or Lambdas: HTML and images load fast, virtual subdomains work, the 404-page functions, and the whole site responds via HTTPS.

Some people throw a lot of services at serverless, overcomplicating serverless. But, why? Before you read an article that talks you into using Route53, API Gateway, Lambdas, CloudFront, CloudWatch, RDS, and Terraform to hold it all together, stop and ask yourself what you need, not what is en vogue on a résumé.

My vision of serverless looks closer to this:

Where to start? Notice in the production/ folder there is a remnant .htaccess file with such contents as:

There are more directives, like different cache timings for different assets, a rewrite rule to redirect www to the root domain, rules to block bad bots, and so forth. These neat rules are Apache rules, but do we even need all of them any longer?

My Identified Serverless Needs

Before following anyone’s “Set up Serverless in 10 Minutes” article, I need to brainstorm what I need in Serverless to get away from GoDaddy without becoming a full-time SRE¹.

Do I need a Gateway? Am I just trying to be cool by throwing every service at the problem? Am I fooling myself into thinking that if I have every AWS service touching my Serverless site that it will make me marketable?

The best solution is one that works and keeps working.

Here is what I’ve identified as my needs:

• Serve a custom 404 page.
• Honour the accept-encoding: gzip, deflate, br request.²
• Have great SEO performance.
• Redirect moved pages over time.
• Serve vanity affiliate links.
• Serve tracking links in emails.
• Run cron jobs with custom PHP.
• Collect information with a 1×1 pixel in PHP.
• Mitigate bot scraping.
• Publish and forget the site.
• Keep backups.

Some Htaccess Thought Experiments:

Now that I have my Serverless needs written down, we can brainstorm what to do with the .htaccess directives:

• If we merely delete the .htaccess directives file, then:
  • No rewrites at all.
  • No 401, 403, 301, 302, 500, … etc. response codes, ever.
  • Only 200 and 404 response codes are supported directly with S3.
  • Deleted pages in the future are 404, not 410 (Gone).
  • It is impossible to 301-redirect pages, only duplicate content.
  • Cloudflare only allows three page rules, but one is already HTTP –> HTTPS.
  • We will have big SEO problems in the future.

• If we run a thin Apache server, then:
  • We will need a host or an EC2 in AWS.
  • It will be slower than simply loading an index.html from S3.
  • It will make me sad because if I have to use a server, it should be Nginx.

• If we run an AWS Gateway with an incoming Lambda, then:
  • Problem solved, but…
  • We have the overhead of a cold-start Lambda on each GET request (poor SEO).
  • Every image and asset is either piped through the Lambda or gets a 302-redirect (poor SEO).
  • I’d be deeply tied to AWS and the fragility of glue between its services.
  • I'd have to write a mini server in Python or Node and hardcode and maintain rules, then…
    • I'll cry myself into a coma.

• If we serve static files from S3 and use the 50 redirection rules allowed, then:
  • 404 errors are trivial.
  • It's easier to maintain a JSON file of URL redirects.
  • There are still no status code headers (just 302).
  • S3 only accepts HTTP requests and drops HTTPS requests.
  • S3 does not use gzip to return objects.
  • Metadata (Last-Modified, ETag) can be set, but with standalone PUT requests.
  • Easy redirects can be configured in JSON, and 410-gone rules can be in a Lambda, but…
    • I'd have to maintain JSON rules in S3, and a coded Lambda: two places, deeper coma.

• If we use Cloudflare Pages, then:
  • We're tied into another vendor's configuration.
  • You'd notice right away that we're not a Vue, Angular, React, Jekyll, Hugo, etc. app.
  • Those gigabytes of images and assets still need to go somewhere: not GitHub!

• If we use Cloudflare Workers, then:
  • We're still vendor-locked.
  • The coding languages are only: vanilla JavaScript, TypeScript, and Rust.
  • It's still coding a thin server, just in a simpler lambda-like Worker.
  • We get WAF, caching, redirects, TLS (HTTPS), logging, and much more for free.

Top ↩

The Plan for Apache’s Htaccess

So, what am I going to do with that core Apache file?

• Turn off any Hide My WordPress obfuscation plugins. With static HTML, who cares if anyone sees /wp-uploads/ anymore? A bot can hammer the non-existent /wp-admin/ all day long. Then, most of the rewrite rules elegantly vanish. These can all be removed:

• Turn off local compression. Yes, you read that right. I have an abandoned plugin called BWP Minify that caches content in gzip-compressed files. There are too many places compression can bite us in the rear, plus we won’t have a compression header in S3 assets. By turning off compression for offline assets, we are sure HTML, CSS, and JS are stored and scraped correctly for offline static storage.

• Remove all the wonderful attack mitigation directives. For a static presentation website hosted in S3, I say go for automated XSS injection, Bot Farmers. These can all be removed:

• Set edge cache expiration and web visitor cache expiration details in Cloudflare under caching instead of .htaccess. These can all be removed:

• Remove all the WordPress rules in .htaccess.

• Remove security rules in .htaccess. These can all be removed:

• Remove all the 410-gone redirects because “currently Google treats 410s (Gone) the same as 404s (Not found), so it’s immaterial to [Google] whether you return one or the other. (ref)”

• What is left is dynamic redirects and important headers concerning affiliate links. Plus, I will sometimes give a custom URL in an email link (e.g. ericdraken.com/linkedin4/ –> ericdraken.com/) and can detect if the recipient has clicked on it. For this, there has to be some dynamic processing. The remainder of the .htaccess essentially looks like this:

• For dynamic URL redirects, I will use S3 redirects and explore vanilla JS with Cloudflare Workers. See the next section.

• For static redirects, S3 redirects work, as well as using regular HTML redirects like so:

Summary

For most static WordPress sites, you can just delete the .htaccess file. For typical URL redirecting needs, there are easy solutions like those above. We no longer need security rules, so those can go. If you have a lot of dynamic affiliate links or cloaked URLs, that is when you need S3 redirect rules, Worker JavaScript redirects, or paid Cloudflare redirects. For static redirects, you can effectively use HTML redirects.

Top ↩

Step 15. Set up a Cloudflare Worker Dev Environment

Say I need something dynamic triggered by a web page. Cloudflare has a Lambda alternative called Workers that runs JavaScript or Rust and has no cold start (there are severe limitations, however).

This is a simpler solution than breaking out IAMS, Roles, Route53, cold-start Lambdas, monitoring, metrics, maybe Terraform, yadda-yadda because Cloudflare takes care of all of that in your account.

FYI, the Worker needs to be uploaded from the console, but the good news is that it can be kept under version control offline. An example of a vanilla JS worker is this:

Install the Workers CLI

Cloudflare suggests I install Node.

Let’s use a Node Docker container with Wrangler (Cloudflare’s CLI tool) instead. I’ve made a Dockerfile and updated the docker-compose.yaml and .env (I’ll evolve these later on):

Why is this so cool? Now I can run docker-compose run --rm wrangler2 and communicate with Cloudflare Workers from the VM. Also, I can test my Workers offline in dev mode. Awesome. First, I’ll need to create a Workers token in the Cloudflare dashboard.

I’ve created a sample Worker and am running it locally:

Now we can have fun exploring Workers.

With rich request information and a map function, we can recreate those .htaccess rules.

Top ↩

Step 16. Serve Dynamic Content, Formerly PHP Scripts

I have a tracking URL that looks like this:

https://innisfailapartments.com/pixel/
  ?loc=/contact/form
  &ua=Mozilla/4.0 (MSIE 6.0; Windows NT 5.1)
  &rnd=6242006519216

I made a tracking pixel many years ago and I’m not sure it even does anything, anymore. But, it is supposed to execute a PHP script:

Ok, so it sends visitor logs to Twitter (for some reason). Ah, Slack wasn’t mainstream back then, plus I was overseas at the time and I casually wanted to gauge visitor interest in that site.

Additionally, the active WordPress theme renders HTML based on the user-agent header (e.g. iPhone, Edge, Chrome, etc.). For instance:

How would I run PHP in a serverless setup?

Some ideas:

• Rewrite the PHP into TypeScript to run in a Worker.
  • Easiest to implement and test locally. Cloudflare has a transpiler.
• Host a baby PHP-FastCGI server on Vultr, DigitalOcean, Linode, etc. just to execute PHP.
  • Too much overhead, but maybe needed in rare cases.
• Run the PHP in AWS Lambda, which runs PHP.
  • A PHP code rewrite will still be needed, and maybe more.
  • We'll then have both a Lambda and a Worker.
• Use AWS or Cloudflare metrics and decommission such a script.⁴
  • Easiest to implement: just use Cloudflare metrics and/or GTM metrics.
• Drop theme elements that inspect headers and switch to Responsive CSS.
  • Wise to implement, anyway.

Fortunately, I can drop the tracking pixel and scrape detection for this simple website. I found it easy to rewrite some PHP scripts into JavaScript.

Top ↩

Step 17. Publish a Cloudflare Worker

When the 100,000 invocation limit is exhausted, an error will be returned to the web browser. The good news is that you can make multiple routes for a Worker. For example,

https://innisfailapartments.com/pixel/*

can be a route. Let’s let S3 serve 404s and real pages, and the Worker be invoked deliberately. Here is a production Worker that doesn’t do much except to exist:

Given the following wrangler.toml:

Publishing is as simple as:

Additional Workers Topics

Please explore these concepts if you are excited to use Workers for your dynamic needs.

• Durable Objects (paid feature)
• Key-Value Storage (free, 25MB limit, eventual consistency)
• HTMLRewriter (because DOMParser is unavailable)

Top ↩

Step 18. Prevent Bots from Hammering your Workers

Someone with an ax to grind may come along, write a multi-threaded URL blaster, and hammer your Worker until you reach your limit for the day (in under 2 minutes⁵). Say they really don’t like you, so they set a cron job to run every day at 12:01. You’re hooped. Why do I even come up with these scenarios? I have experience with AdWords click fraud.

Mitigation: WAF

You could enable WAF Rate Limiting, but there is a cost of about a nickel for every 10,000 rolling good requests – this can add up quickly.

Mitigation: Short Cache

You could add a Page Rule to cache responses from Workers for 30s and ignore query strings for caching. Combine that with a Transform Rule to strip off any no-cache headers from the client – this works, but is advanced and has drawbacks. It works because a bad actor can spin up 16 threads to perform IO requests to your Worker, but only one will do anything. Its drawback is the Worker may cache, say, GeoIP info if you are not careful.

Mitigation: Polymorphic Worker Endpoints

If you are a Champion of Cheap, or just like the mental exercise, you can do something wicked for free: Make a Worker create a (cache) item in S3 (not Cloudflare), and make an S3 Policy to redirect to the Worker if said cache object does not exist. After a few or several seconds, a subsequent Worker request can delete that object and replace it with a fresh version for caching again. S3 does all the heavy lifting, and you can cache for as little as 5 seconds. Feel like being cheeky? Make a Worker polymorphically change its endpoint via the Cloudflare API (also update S3) to keep the b@stards from hitting the Worker endpoint directly.

Or do nothing and be kind to everyone. Or just pay Cloudflare. Whichever.

Top ↩

Step 19. Cron Jobs without a Server

How to schedule cron jobs within this simple serverless design? Cloudflare is awesome and it comes to the rescue again:

It is straightforward to create a cron job that periodically calls a Worker. That Worker can do anything from rotating logs in S3 to fetching the latest Cloudflare CIDR blocks to running a batch job on visitor IPs to perform GeoIP lookups to then make neat graphs. The sky is the limit. To leave GoDaddy, I’m not in need of a cron job here.

Top ↩

Step 20. Move Comments and Schedules to a Third-Party

If you allow comments in your WordPress site: Stop.

There are too many prevalent XSS vulnerabilities whereby a bad actor leaves a malicious message like:

I love your site! This is so helpful. A+ <img src=”data-uri:base64 1×1-pixel” onload=”alert(‘Add backdoor user.’)”></a>

As an admin, you check the comments which are “held for moderation”, but as soon as you do, it’s too late. While logged in as an admin, you’ve just triggered some JavaScript:

You’d never know. The hacker or bot can modify your WordPress site with the same rights as an admin. Trust me.

When you move to S3, you will no longer have comments and interactive WordPress schedules. I suggest you use something like Disqus and JaneApp to keep that interactivity. For my needs, I prefer no comments at all.

Top ↩

Advanced Serverless Options

Really, I just need to get away from GoDaddy. Here are some impressive features that Cloudflare offers… for free. Feel free to let your mind go wild with the possibilities.

• Serve compressed HTML and assets.
• Enable HTTP/3 with QUIC for speed.
• Use TLS Stapling for a speed-up.
• Early Hints of more URLs for a given HTML page.
• Add GTM and scripts via Cloudflare.
• Create firewall rules.
• Set up a scrape shield.
• Reject bots from visiting.
• Set up DDoS mitigation (save money on S3 and Workers).
• Rewrite some HTML sections with Workers on the fly.

S3 Compression: Did you know that the objects stored in S3 are served uncompressed? If a 100 kB file of spaces is uploaded to S3, that 100 kB is served to the visitor. Some people suggest compressing objects offline and uploading them to S3. Clever, but, hey, wait, Cloudflare caches responses from S3. Let’s see how Cloudflare helps us with compression:

Cloudflare rocks. Brotli compression rocks too.

Top ↩

Advanced Concepts and Gotchas

SEO Juice

Do you want Google to give SEO juice to example.com.s3-...-amazonaws.com or example.com? Add this to your website on each page:

Protect S3

Want to prevent users from visiting example.com.s3-...-amazonaws.com?

Try a combination of these handy header scripts on every page (in a header.php). Combine them or mix and match. I use them all.

Rewrite HTML

Want to edit server-side HTML on the fly with Cloudflare’s HTMLRewriter? You can do some pretty cool server-side rewrites and the client would never know.

However, there is a super gotcha: you get 10ms and scant memory to run a Worker. So, forget using DOMParser or regex if you effectively want to modify HTML in a template. You need to be creative if you want to serve a populated HTML template on the fly without using client-side JavaScript (SEO prefers server-side-rendered content).

Serve Third-Party Fonts ‘Locally’

Let’s serve a cached copy of Google Fonts instead of going to their CDN. Why? Each domain that has assets needs to perform a DNS lookup as well as a TLS handshake which slows down the loading of those assets, potentially blocking the site from painting. From DevTools, it’s straightforward to find the CSS and the WOFF files and “host” them locally.

Top ↩

Checklist: Move Sites from GoDaddy

I operate dozens of sites doing all kinds of things, but I really want to get this site off GoDaddy. Let’s review and automate the steps to break up with GoDaddy.

1. Create or reuse the ByeDaddy VM.
2. Convenience symlink: ln -s ~/godaddy/homedir/public_html/example_com ~/example.
3. Confirm a ‘staging’ folder of the site exists.
4. Create a docker/ folder; copy the docker-compose.yaml, .env, Dockerfile, and php.ini.
5. Update the .env file with the wp-config.php values.
6. Create the logs/ folder; add debug.log and apache_errors.log.
7. Copy the aws/ folder with the policy and cors JSON files.
8. Update the JSON files with the new site domain name.
9. Run aws configure if this is the first time.
10. Create the two S3 buckets: example.com and static.example.com.
    aws s3 mb s3://example.com --region us-west-2 aws s3 mb s3://static.example.com --region us-west-2

    1 2	aws s3 mb s3://example.com --region us-west-2 aws s3 mb s3://static.example.com --region us-west-2

11. Change the buckets to static websites.
    aws s3 website s3://example.com/ --index-document index.html --error-document not-found/index.html aws s3 website s3://static.example.com/ --index-document index.html --error-document not-found/index.html

    1 2	aws s3 website s3://example.com/ --index-document index.html --error-document not-found/index.html aws s3 website s3://static.example.com/ --index-document index.html --error-document not-found/index.html

12. Set the public policy of the buckets.
    aws s3api put-bucket-policy --bucket example.com --policy file://policy.json aws s3api put-bucket-policy --bucket static.example.com --policy file://static.policy.json

    1 2	aws s3api put-bucket-policy --bucket example.com --policy file://policy.json aws s3api put-bucket-policy --bucket static.example.com --policy file://static.policy.json

13. Allow CORS for the buckets.
    aws s3api put-bucket-cors --bucket example.com --cors-configuration file://cors.json aws s3api put-bucket-cors --bucket static.example.com --cors-configuration file://cors.json

    1 2	aws s3api put-bucket-cors --bucket example.com --cors-configuration file://cors.json aws s3api put-bucket-cors --bucket static.example.com --cors-configuration file://cors.json

14. Stop any other local sites: docker-compose down or ctrl+c.
15. Block commercial plugins from phoning home:
    # wp-config.php define('WP_HTTP_BLOCK_EXTERNAL', true); define('WP_ACCESSIBLE_HOSTS', implode(',', [ '*.wordpress.org' ]));

    1 2 3 4 5 6

    # wp-config.php define('WP_HTTP_BLOCK_EXTERNAL', true); define('WP_ACCESSIBLE_HOSTS', implode(',', [   '*.wordpress.org'     ]));

16. Start the WordPress staging site: docker-compose up; confirm SQL import succeeded.
17. Edit /etc/hosts; add 127.0.0.1 example.com and 127.0.0.1 static.example.com.
18. Visit https://example.com/wp-admin/; verify site looks great.
19. (Optional) Keep yourself logged in longer for local WordPress dev work.
    # Add this to the theme functions.php add_filter( 'auth_cookie_expiration', 'keep_me_logged_in_for_1_year' ); function keep_me_logged_in_for_1_year( $expirein ) { return 365 * 86400; // 1 year in seconds }

    1 2 3 4 5

    # Add this to the theme functions.php add_filter( 'auth_cookie_expiration', 'keep_me_logged_in_for_1_year' ); function keep_me_logged_in_for_1_year( $expirein ) {   return 365 * 86400; // 1 year in seconds }

20. Edit .htaccess; remove any .htpasswd references.
21. Disable any Hide My WP plugins or similar.
22. Remove any production/* contents (not the folder itself!).
23. Generate static HTML and assets to a newly-created production/ folder (confirm /var/www/production/).
24. Repair any static HTML generation problems.

    

25. Address any 404 or 30X issues, and especially any 50X errors.

    

26. Generate static HTML and assets, again.
27. View static production site offline with a custom vhosts.conf.
    Tip: To view the static HTML files, you will still need a vhosts. I recommend modifying the WordPress Docker container to serve the production/ folder. Don’t forget about CORS, even offline. Hint:

    <IfModule mod_headers.c> Header add Access-Control-Allow-Origin "*" </IfModule>

    1 2 3

    <IfModule mod_headers.c>     Header add Access-Control-Allow-Origin "*" </IfModule>

28. Spot check for broken images or broken pages.
29. (Optional) Replace strings or URLs throughout the site:
    docker-compose run --rm wpcli search-replace '/old-files/' '/files/' --dry-run

    1	docker-compose run --rm wpcli search-replace '/old-files/' '/files/' --dry-run

30. (Optional) Create a Worker; test offline; deploy; set the DNS entry if needed.
31. (Optional) Create a redirect.json for S3 for URL redirects and/or Workers. Include again the index and error docs:
    { "IndexDocument": { "Suffix": "index.html" }, "ErrorDocument": { "Key": "not-found/index.html" }, "RoutingRules": [ { "Condition": { "KeyPrefixEquals": "out/affiliate" }, "Redirect": { "HostName": "affiliatesite.com", "HttpRedirectCode": "302", "Protocol": "https", "ReplaceKeyPrefixWith": "?params=..." } }, { "Condition": { "KeyPrefixEquals": "out/affiliate/" }, "Redirect": { "HostName": "affiliatesite.com", "HttpRedirectCode": "302", "Protocol": "https", "ReplaceKeyPrefixWith": "?params=..." } } ] }

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

    {   "IndexDocument": {     "Suffix": "index.html"   },   "ErrorDocument": {     "Key": "not-found/index.html"   },   "RoutingRules": [     {       "Condition": {         "KeyPrefixEquals": "out/affiliate"       },       "Redirect": {         "HostName": "affiliatesite.com",         "HttpRedirectCode": "302",         "Protocol": "https",         "ReplaceKeyPrefixWith": "?params=..."       }     },     {       "Condition": {         "KeyPrefixEquals": "out/affiliate/"       },       "Redirect": {         "HostName": "affiliatesite.com",         "HttpRedirectCode": "302",         "Protocol": "https",         "ReplaceKeyPrefixWith": "?params=..."       }     }   ] }

32. (Optional) Push the bucket policy file to all site buckets:
    aws s3api put-bucket-website --bucket example.com --website-configuration file://redirect.json aws s3api put-bucket-website --bucket static.example.com --website-configuration file://redirect.json

    1 2	aws s3api put-bucket-website --bucket example.com --website-configuration file://redirect.json aws s3api put-bucket-website --bucket static.example.com --website-configuration file://redirect.json

33. Sync the production folder to (both of) the S3 buckets:
    cd production/ aws s3 sync . s3://example.com --delete aws s3 sync . s3://static.example.com --delete

    1 2 3

    cd production/ aws s3 sync . s3://example.com --delete aws s3 sync . s3://static.example.com --delete

34. Enroll in the Cloudflare Email Routing service; enable catch-all.
35. Add or replace MX and TXT records in DNS settings.
36. Send a test email to catchme@example.com to verify email forwarding works.
37. Update Cloudflare DNS CNAME records to point to corresponding S3 buckets:
    • CNAME: example.com –> example.com.s3-website-us-west-2.amazonaws.com
    • CNAME: static –> static.example.com.s3-website-us-west-2.amazonaws.com
38. Clear Cloudflare cache: Purge Everything. Here is a shell script:
    #!/bin/bash set -o allexport source .env set +o allexport curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache" \ -H "X-Auth-Email: $EMAIL" \ -H "Authorization: Bearer $API_KEY" \ -H "Content-Type: application/json" \ --data '{"purge_everything":true}'

    1 2 3 4 5 6 7 8 9 10

    #!/bin/bash set -o allexport source .env set +o allexport   curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache" \      -H "X-Auth-Email: $EMAIL" \      -H "Authorization: Bearer $API_KEY" \      -H "Content-Type: application/json" \      --data '{"purge_everything":true}'

39. Test URL redirection; test affiliate links, etc.
40. Check for broken outbound links and fix or remove:

    

41. Backup the running SQL database. Please see my Stackoverflow post for a detailed explanation.
    docker-compose exec db sh -c '\ mysqldump -uroot -p$MYSQL_ROOT_PASSWORD --all-databases --routines --triggers \ ' | gzip -c > ../sql/backup-`date '+%Y-%m-%d'`.sql.gz

    1 2 3

    docker-compose exec db sh -c '\   mysqldump -uroot -p$MYSQL_ROOT_PASSWORD --all-databases --routines --triggers \ ' | gzip -c > ../sql/backup-`date '+%Y-%m-%d'`.sql.gz

42. Cancel your GoDaddy hosting account.
43. Set Cloudflare Edge Cache rules.

    

Top ↩

The GoDaddy Experience Simulator

Friends, GoDaddy’s cachet from the dot-com boom has long waned since the founder sold his majority of shares in 2011 and it transformed into a profit grinder using old hardware, cobbled-together third-party portals, and a mess of upselling. GoDaddy is a remnant of a by-gone era in a landscape where AWS, Linode, and Vultr (to name a few) do hosting as their bread and butter.

Here is a video of me trying to cancel my hosting account. This is me in real-time struggling to cancel my account. You can see that GoDaddy’s pages are broken, so I had to investigate and reverse the JavaScript in the console to skip the “chat with an agent first” blocker and jump to the satisfying denouement. GoDaddy, just… ByeDaddy.

Did you experience how broken and painful the GoDaddy backend is?

Top ↩

Results and Summary

Hello from S3. I moved ericdraken.com to S3+Cloudflare and you are reading this from Cloudflare cache with S3 as the origin. I expect to pay about 12 cents a month for this site's hosting. Let's see how fast the site loads:

The waterfall and timings look beautiful, too.

Success

When you realize that a WordPress site with a heavy theme and dozens of plugins takes 5~8s for a page to actually load under Apache and PHP, having under one second load time is nearly miraculous.