Category: Web Development

My original deploy flow was the classic “freelancer special”:

Make changes locally, open FileZilla, SFTP into the server, drag files over, hope I didn’t miss anything, refresh the site, repeat.

It worked, but it was slow and it always felt a little fragile. So we switched to auto-deploys with GitHub Actions. Now whenever I push to main, GitHub connects to the server and runs a deploy script automatically.

Push code → live site updates. No more FileZilla sessions.

And here’s a bonus I didn’t fully appreciate until I started using it: it also makes it ridiculously easy to make small static page edits from my phone using the GitHub.com editor. Change a line of HTML, fix a typo, update a link, commit to main, and it deploys the same way as if I did it from my laptop.

What We Set Up

• Trigger: A push to main runs the workflow.
• Action: The workflow SSHs into the server (in our case, an AWS Lightsail instance), goes to the site’s document root, and runs a small deploy script.
• Result: Every push to main updates the live site without manual SFTP, SSH, or FTP.

1. The GitHub Workflow

Create .github/workflows/deploy.yml in your repo:

name: Deploy to Lightsail

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: SSH deploy
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USERNAME }}
          key: ${{ secrets.SSH_KEY }}
          port: ${{ secrets.PORT || 22 }}
          script: |
            cd /opt/bitnami/apache/htdocs
            ./scripts/deploy.sh

What’s happening here:

• appleboy/ssh-action runs the given script on your server over SSH.
• host, username, key, and optionally port come from GitHub Secrets so you never put credentials in the repo.
• Adjust the cd path to your actual document root.

2. The Deploy Script on the Server

On the server, we keep the deploy logic in a script (e.g. scripts/deploy.sh) that the workflow runs:

#!/bin/bash
set -euo pipefail
git pull origin main

• set -euo pipefail makes the script exit on errors and on use of unset variables.
• The only “deploy” step is pulling the latest main. You can expand this later (build steps, dependency installs, cache clears, service restarts, etc.).

Make sure:

• The script is executable: chmod +x scripts/deploy.sh
• The directory you’re deploying from is a git clone of your repo, with origin pointing to the same GitHub repo you push to.

3. GitHub Secrets

In your repo: Settings → Secrets and variables → Actions. Add:

• HOST – Your server’s hostname or IP (example: origin.antpace.com)
• USERNAME – SSH user (Bitnami stacks often use bitnami)
• SSH_KEY – Private key content that can log in as that user (paste the whole key including the BEGIN/END lines)
• PORT (optional) – SSH port if not 22

Now the runner can SSH in and deploy without you storing credentials in the repo.

4. The Underrated Win: Editing From Your Phone

This is the part that feels almost unfair once you have it.

Because deploys are tied to main, you can make simple static changes directly in the GitHub.com editor on mobile:

• Fix a typo
• Update a phone number
• Swap a link
• Change a headline
• Add a quick announcement banner

Commit to main, and the same workflow runs. No laptop required. No FileZilla. No “I’ll do it later when I’m home.”

5. One More Thing: Cache Invalidation

If you sit behind a CDN (like CloudFront), you may need to invalidate cache after deploy so you actually see your changes immediately.

You can:

• Add a workflow step that uses the AWS CLI to create a CloudFront invalidation, or
• Run it inside the same SSH script (if the AWS CLI is installed on the server)

---

That’s it.

The whole goal here is to stop “deploying” and start “pushing.” Once this is in place, you’re not moving files around anymore. You’re making changes in one place (your repo), and production stays in sync automatically.

I wanted an easy win on this exam, without turning it into a long project.

Cloud Practitioner is not a deep technical test. It is mostly about understanding AWS at a high level, knowing what the core services do, and being comfortable with billing, support plans, and the shared responsibility model.

Here is how I prepared.

Step 1: I used the exam guide as my checklist

Before I watched anything, I pulled up the official exam guide and treated it like a scope document.

If something was on the guide, I studied it. If it was not on the guide, I did not go down the rabbit hole.

That one decision saved me a lot of time.

Step 2: I learned AWS in “service groups”

Trying to memorize individual services is painful. It clicked for me when I grouped things by category and learned the role each category plays.

My main buckets were:

• Compute: EC2, Lambda
• Storage: S3, EBS, EFS
• Databases: RDS, DynamoDB
• Networking: VPC, Route 53, CloudFront
• Security: IAM, KMS, shared responsibility model
• Monitoring: CloudWatch
• Billing: pricing models, free tier, Cost Explorer, support plans

Once you can explain these things, most questions stop feeling tricky.

Step 3: Practice questions became the real study plan

After I had the basics, I moved to practice exams earlier than I expected.

I did not use them to “see my score.” I used them to find my weak spots.

Every wrong answer turned into a quick note:

• What was the correct answer?
• Why was my answer wrong?
• What is the simple rule that would help me next time?

That loop is where most of my improvement came from.

I used ChatGPT to generate practice exams, one question at a time. I could answer by typing in a letter choice. I would then ask it to explain each answer options, whether I got it wrong or correct.

Step 4: I focused hard on billing and security

If you ignore billing and security, you can feel confident and still miss a lot of easy points.

I made sure I was solid on:

• Shared responsibility model
• IAM basics (users, groups, roles, policies, least privilege, MFA)
• Pricing basics (On Demand vs Reserved Instances vs Savings Plans)
• What is included in the free tier
• Support plan differences

Step 5: I made exam day simple

I did some boring preparation the day of the exam. Clean desk, quiet room, testing software working, ID ready, no weird tech surprises. A few days before, I had to borrow a laptop because my ten-year-old MacBook was too old to run the testing software. The goal was to spend my energy on the questions, not on setup problems. I was worried about losing internet (that happened once before, years ago), but it turned out fine.

The digital proctor had me spin my laptop camera around to check the room. He had me move a few things from my mostly empty desk, like a pack of tissues

If you are studying now

Do not overcomplicate it. Learn the high level purpose of the services, drill practice questions, and tighten up billing and security.

That is the path that worked for me.

I put CloudFront in front of my Lightsail site for a few reasons: faster load times globally, less load on my instance, and better options for defending against bot traffic at the edge. I also wanted a setup where Lightsail is just the origin and CloudFront is the public front door, which makes future changes easier.

This is what I did, what broke, and what fixed it.

What I started with

• A Lightsail Linux instance running Apache
• The main site is mostly PHP pages plus CSS/JS/images
• The blog lives at antpace.com/blog (WordPress)
• DNS already in Route 53
• HTTPS already working on the instance using Certbot

The mental model

CloudFront is the front door. Lightsail becomes the origin behind it.

That means two separate HTTPS concerns:

• Visitors hitting antpace.com need a certificate attached to CloudFront (ACM)
• CloudFront talking to the origin also needs HTTPS on an origin hostname

Setting up the origin hostname

CloudFront won’t accept an IP address as an origin. It needs a domain name. So the first move was creating:

• backdoor.antpace.com → Lightsail static IP (Route 53 A record)

Then I made sure the origin worked over HTTPS using the same mechanism I already had on the instance.

To confirm what I was actually using:

sudo certbot certificates
sudo sed -n '1,200p' /etc/letsencrypt/renewal/antpace.com.conf

That confirmed Certbot and showed the exact webroot path being used for renewals.

• Route 53 record for backdoor.antpace.com
• certbot certificates output

Getting the CloudFront certificate (ACM)

CloudFront requires an ACM certificate in us-east-1, even if your origin is in a different region.

So I requested a cert in ACM for:

• antpace.com
• www.antpace.com

Then validated it through Route 53.

• ACM certificate request page showing the domains and DNS validation records

Creating the distribution and choosing policies

This is where the setup becomes worth it, but it’s also where you need to treat the main site and WordPress differently.

My main site is basically “static-ish” content, but /blog is WordPress. So I split behaviors and used different policies.

Default behavior (*) for the main site

• Viewer protocol policy: Redirect HTTP to HTTPS
• Allowed methods: GET, HEAD
• Cache policy: CachingOptimized (managed)

I verified caching was working with:

curl -I https://antpace.com | egrep -i 'x-cache|age|via'
curl -I https://antpace.com | egrep -i 'x-cache|age|via'

First request was a Miss, second request was a Hit with an age header.

• CloudFront distribution details page
• Behaviors tab showing Default (*)

Blog behaviors for WordPress (/blog/*)

I kept WordPress safe by disabling caching on the blog paths and forwarding what WordPress needs.

Behaviors I added:

• /blog/wp-admin/*
• /blog/wp-login.php
• /blog/*

I know the above is redundant, but in the future I may allow some cacheing on the blog post pages, but always keep the other two routes disabled.

For all three:

• Viewer protocol policy: Redirect HTTP to HTTPS
• Allowed methods: All
• Cache policy: CachingDisabled
• Origin request policy: AllViewer

This is the “don’t get fancy yet” setup. It keeps logins/admin sane and avoids CloudFront caching anything dynamic.

Behaviors list showing the /blog/* paths and policies

Bot defense at the edge

One of the underrated reasons to do this is that CloudFront gives you an edge layer for basic bot defense. Even on the free plan, you can enable rate limiting/monitoring so random traffic is handled earlier, instead of everything slamming your Apache box directly.

I turned on the recommended rate limiting settings (it starts in monitor mode), then I can tighten it later if I need to.

• Security / rate limiting settings screen

The redirect loop issue (and why it happened)

After switching DNS, browsers started throwing “too many redirects.”

The fastest way to see what was happening:

curl -IL https://www.antpace.com | head -n 40

It was an endless chain of 301s. The cause was not CloudFront. It was my origin.

I had unconditional Apache redirects living in two configs:

• /opt/bitnami/apache/conf/bitnami/bitnami.conf
• /opt/bitnami/apache/conf/bitnami/bitnami-ssl.conf

And the line was:

Redirect permanent / https://www.antpace.com/

That redirect is too blunt once CloudFront is in front. CloudFront can cache the redirect and then you’ve got a fast global redirect loop.

This command found it immediately:

sudo grep -R --line-number -E "RewriteEngine|RewriteCond|RewriteRule|Redirect" \
/opt/bitnami/apache/conf/bitnami /opt/bitnami/apache/conf/vhosts 2>/dev/null

Fix was removing those redirects from both files.

• grep output showing the redirect line in both files
• browser redirect error page

Canonical redirect at the edge (CloudFront Function)

I still wanted apex → www, but I didn’t want Apache doing it anymore.

So I created a CloudFront Function and attached it to the Default behavior on Viewer request:

function handler(event) {
  var request = event.request;
  var host = request.headers.host.value;

  if (host === 'antpace.com') {
    var qs = request.querystring;
    var loc = 'https://www.antpace.com' + request.uri + (qs && qs.length ? ('?' + qs) : '');
    return {
      statusCode: 301,
      statusDescription: 'Moved Permanently',
      headers: {
        location: { value: loc }
      }
    };
  }

  return request;
}

This makes the redirect logic obvious and centralized, and it keeps the origin hostname out of the equation.

• CloudFront Function code + association on the behavior

Invalidate CloudFront cache on deploy (GitHub Actions)

My deploy process is GitHub Actions. It SSHes into Lightsail and runs my deploy script. With caching enabled, I wanted updates to show up immediately after a push.

So I added a CloudFront invalidation step after deploy:

- name: Configure AWS credentials (OIDC)
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
    aws-region: us-east-1

- name: Invalidate CloudFront
  run: |
    aws cloudfront create-invalidation \
      --distribution-id "${{ secrets.CLOUDFRONT_DISTRIBUTION_ID }}" \
      --paths "/*"

That’s the simple version. I can narrow it later, but /* makes “deploy means live” true.

• GitHub Actions run showing the invalidation step
• CloudFront invalidations tab

What I got out of this

• Faster global delivery of the main site via edge caching
• Less load on Lightsail
• WordPress stays safe because /blog/* is not cached and forwards the right stuff
• Better options for bot defense at the edge
• Canonical redirects handled at CloudFront instead of server config files
• Automated deploy invalidation so changes show up right away

If you’re doing this on a mixed site (static-ish pages plus WordPress), the split behaviors are the whole thing. Treating everything the same is how you end up caching logins or debugging redirects at 2am.

When I went to save this post in WordPress, it kept failing with the classic editor error: “Updating failed. The response is not a valid JSON response.” At first it looked like a WordPress problem, but the actual response coming back was a CloudFront-generated 403 “Request blocked” HTML page, which meant the request never made it to WordPress at all. The weird part was it only happened with certain content. Normal edits saved fine, but as soon as I pasted in code-heavy sections (Apache config blocks, rewrite rules, YAML, JS), CloudFront’s built-in WAF protections flagged the request body as suspicious and blocked it. The fix was simple once we knew what was happening: I enabled WAF “monitor mode” on the CloudFront distribution so it would log potential blocks instead of enforcing them, and after the change finished deploying across CloudFront, saves started working again. I kept rate limiting on for bot defense, but left the common-threat protection in monitor mode until I eventually switch to a full WAF Web ACL where I can add exceptions for WordPress editor endpoints.

One extra thing I did on the WordPress side was add a tiny mu-plugin as a guardrail. I like mu-plugins for infrastructure-style fixes because they always load and they cannot be accidentally disabled in the admin UI. I did not put anything “in wp-admin” because the block editor issue is really about REST requests and editor endpoints, and WordPress updates can overwrite admin code anyway. Also, I don’t track that file in version control.The mu-plugin lives in wp-content/mu-plugins/ and keeps the behavior consistent no matter what theme or normal plugins are doing.