The FE deployment process is divided into four main steps:

1. S3 Bucket Setup
   Set up an Amazon S3 bucket to store the frontend application's static files, such as HTML, CSS, JavaScript, and images.
2. AWS Certificate Manager (ACM) Setup
   Request and validate an SSL/TLS certificate for the domain we intend to use. This step also requires configuring the domain's DNS records through the Domain Provider to validate the certificate and enable secure HTTPS access.
3. CloudFront Setup
   Configure Amazon CloudFront as the Content Delivery Network (CDN) to distribute the frontend files stored in S3. CloudFront also handles HTTPS connections using the SSL/TLS certificate configured in ACM and connects the custom domain to the frontend application.
4. CI/CD Setup Using GitHub Actions
   Configure GitHub Actions to automate the deployment process. When changes are pushed or merged into the designated branch, the workflow builds the frontend application and uploads the generated files to S3. CloudFront's cache can then be invalidated to ensure users receive the latest version.

S3 Setup

1. Create bucket

2. Add bucket name e.g. growsocials-l-a-f
3. If possible, we can copy settings from an existing bucket

4. Object ownership: choose ACLs disabled
5. Turn off all public access and check the “I acknowledge that the current settings might result in this bucket and the objects within becoming public.”

6. Disable the Bucket Versioning
7. Leave the tags empty

8. Encryption type choose: Server-side encryption with Amazon S3 managed keys (SSE-S3)
9. Enable the Bucket Key
10. Disable the Object Lock
11. Settings done; now create the bucket. Once we create the bucket, the screen will navigate to the bucket details, as shown in the image below.

12. Once it’s done, we need to change the Bucket Policy inside the Permissions tab

13. Use this template for the bucket policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "........................."
    }
  ]
}

14. Change the “Resource” value with the “Bucket ARN”  `Bucket ARN value /*` and Save
15. Edit the Static website hosting inside the Properties tab.
16. Enable static hosting, index document, and error document; both add index.html

Certificate Manager Setup

1. Request certificate

2. Add domain name for the certificate

3. Allow Export

4. Validation method: choose DNS validations

5. Key Algorithm: choose RSA 2048

6. Leave the Tags empty and click on the Request button

7. Open the certificate details and check the Domains section
8. Copy the CNAME name and CNAME value

9. Register the CNAME name and **CNAME value **to the domain DNS settings. In example bellow was DNS settings from **Cloudflare Pages. **Disable the proxy because we will use it from Cloudfront.

10. Wait for the certificate to be propagated and verify it on the certificate details page
11. If successful, the status will be updated like image below.

CloudFront Setup

1. Create Distribution

2. Choose the free plan for Stage; Pay as you go for Prod

3. Add the **Distribution name **and the **Description **as the same

4. Distribution type: choose Single Website

5. Leave the Domain and Tags empty

6. Origin Type: choose Amazon S3

7. S3 Origin: browse the S3 bucket that we already created, then click on the “Use website endpoint”

8. Use default security option

9. Create distribution

10. Open the distribution that we have create and add the domain

11. Add the domain; make sure the domain is the same as the domain that we already registered in Certificate Manager

12. Choose the certificate that we created in Certificate Manager; if the name is correct, it will be automatically chosen

13. Add domain

14. Copy the distribution domain name in CloudFront

15. Use the CloudFront distribution domain name as a CNAME value/target in Cloudflare Pages. And put the domain name as the name that we want to use for our app domain.

Frontend CI/CD Deployment

1. Deployment Flow Diagram

[ GitHub Actions Runner ]
        │
        ├─ 1. Checkout repository (ref)
        ├─ 2. Setup Node.js 20 & Yarn cache
        ├─ 3. Install dependencies (frozen-lockfile)
        ├─ 4. Vite build (injects VITE_API_BASE_URL)
        ├─ 5. Pre-compress assets (.js, .css with gzip -9)
        │
        ├────────────────────── AWS Credentials ──────────────────────┐
        │                                                             │
        ▼                                                             ▼
[ Amazon S3 Bucket ]                                        [ Amazon CloudFront ]
   ├── /assets/*.js  (gzip, max-age=1yr, immutable)                   │
   ├── /assets/*.css (gzip, max-age=1yr, immutable)                   │
   ├── /static/*     (images/fonts, max-age=1yr, immutable)           │
   ├── /.well-known/ (no-cache)                                       │
   └── index.html    (no-cache, entrypoint)                           │
                                                                      ▼
                                                            Invalidate Cache (/*)
                                                                      │
                                                                      ▼
                                                          [ End Users / Browsers ]

2. GitHub Configuration (Secrets & Variables)

Secrets and variables are scoped to GitHub Environments (**Settings → Environments → **staging) or repository-level (Settings → Secrets and variables → Actions).

3. How to Trigger a Deployment

Deployments are manual to ensure team control over releases.

Step-by-Step Instructions:

1. Navigate to the GitHub repository: Actions tab.
2. In the left sidebar, click on Deploy Frontend (S3 + CloudFront).
3. Click the Run workflow dropdown on the right side.
4. Fill in the parameters:
   • Branch / Tag / Ref: Enter the branch (e.g. main, develop, or a feature branch).
   • Deployment environment: Select or enter staging (default).
5. Click Run workflow.

4. Deployment Lifecycle & Workflow Stages

The entire pipeline executes in a single self-contained file (.github/workflows/deploy-frontend.yml):

5. Caching Strategy & Rules

To provide instant load times while eliminating stale asset caching bugs:

1. Fingerprinted JS/CSS (/assets/*.js, /assets/*.css):
   • Cache-Control: public, max-age=31536000, immutable (1 year).
   • Bundles have unique content hashes in filenames (e.g. index-B2d9x1.js). When code changes, a new filename is generated.
2. HTML Entrypoint (index.html):
   • Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0 (Expires: 0).
   • Browsers never cache HTML, meaning users always request the newest bundle references immediately.
3. CloudFront Invalidation:
   • On every deploy, /* is invalidated so edge locations immediately discard cached HTML and point to the newly uploaded build.