Introduction

Running Kubernetes on bare-metal or self-managed servers can be both exciting and painful. Recently, I ran into an issue that completely broke my control plane — all because my Linux server’s IP address changed. Kubernetes taught me a lesson: never underestimate an IP change, and I learned this the hard way after reassigning my server’s IP address.

The symptoms were confusing at first: kubectl refused to connect, control plane pods were crash-looping, and even etcd couldn’t bind to its endpoint. It looked like my cluster was dead. What seemed like a small network reconfiguration turned into an API server certificate mismatch problem that prevented my cluster from working.

It turned out the issue came from stale IPs hardcoded into Kubernetes configuration files and API server certificates.

In this article, I’ll walk you through:

• What caused the issue
• How I discovered the root cause
• The detailed troubleshooting steps I took
• The fix I applied to bring my cluster back to life
• Lessons learned to prevent this in the future

If you ever have to change the IP address or hostname of your control-plane node, this guide should save you hours of frustration.

What led to the Issue

I had a single-node Kubernetes cluster running on my Ubuntu server. Initially, the control-plane node was assigned the IP address:

• My server’s old IP address: 192.168.166.33

Later, I reconfigured my network and changed the IP to:

• My server’s new IP address: 192.168.0.8

Kubernetes doesn’t automatically reconfigure itself when a host IP changes. Instead, it stores the control plane’s IP address in multiple places:

• etcd manifest (/etc/kubernetes/manifests/etcd.yaml)
• kubeconfig files (/etc/kubernetes/admin.conf, kubelet.conf, etc.)
• API server certificates, which include the old IP in their SANs

Once the IP changed, the cluster couldn’t start because all references still pointed to the old address.

Why does changing node IPs break Kubernetes (on bare metal)?

On Cloud-managed K8s:

• Kubernetes clusters are usually provisioned through managed services like EKS, GKE, and AKS.
• These services abstract away the underlying IPs — they use load balancers, DNS names, and service endpoints instead of binding critical cluster components directly to a machine’s raw IP address.
• So if a node IP changes, the control plane or kubelet can usually still find each other via DNS or cloud networking.

On Bare Metal or VM K8s:

• The API server, etcd, kubelet configs, and certs are often tied to the node’s static IP.
• If that IP changes, Kubernetes components will still try to talk to the old IP, causing failures. Also, Certificates (like the API server cert) include specific IPs in their SANs.
• If the IP changes and isn’t in the SAN, TLS verification fails.

That’s why it’s mostly a problem on bare metal / self-hosted clusters — because you are the cloud provider, and Kubernetes isn’t abstracting IP changes for you.

First Signs Something Was Wrong

After the change, I noticed that etcd was failing to start and kubectl could no longer connect to the API server. Checking the kube-system pods revealed that etcd and kube-apiserver were in a CrashLoopBackOff state.

Logs confirmed the issue:

• etcd failed to bind to 192.168.166.33
• kube-apiserver threw certificate validation errors

This was the first clue — etcd was still trying to bind to the old IP (192.168.166.33) even though the host was now using 192.168.0.8.

When I tried to run:

kubectl cluster-info
kubectl get nodes

I also got TLS errors about failing to connect to the API server.

Troubleshooting Process

Step 1: Inspecting my current Kubernetes cluster

I started by inspecting and verifying the API server address of my current Kubernetes cluster, and also listed all the cluster names that I have defined.

kubectl config view --minify | grep server:
kubectl config get-clusters

Step 2: Checking Cluster Component Status

I started by inspecting containers managed by kubelet:

sudo crictl ps -a

I saw that etcd and apiserver containers were constantly restarting.

Looking at their logs (journalctl -xeu kubelet), the recurring issue was that they couldn’t bind to the old IP.

Step 3: Checking etcd and kubeconfigs Files

Etcd runs as a static pod managed by kubelet, so I inspected:

sudo cat /etc/kubernetes/manifests/kube-apiserver.yaml
sudo grep -R --line-number "192.168.166.33" /etc/kubernetes || true

Every major kubeconfig was still pointing to the old IP.

Step 4: Updating Configurations

I updated the kubeconfigs and the etcd manifest to reference my new IP:

sudo sed -i 's/192.168.166.33/192.168.0.8/g' /etc/kubernetes/*.conf
sudo grep -R "192.168" /etc/kubernetes/*.conf

sudo sed -i 's/192.168.166.33/192.168.0.8/g' /etc/kubernetes/manifests/etcd.yaml
sudo grep -E 'listen-|advertise|initial-cluster|initial-advertise' /etc/kubernetes/manifests/etcd.yaml

Step 4: Restart kubelet

I reloaded systemd and restarted kubelet:

sudo systemctl daemon-reexec
sudo systemctl restart kubelet

After restartingkubelet, etcd began starting properly and was able to bind successfully, but kubectl still failed due to TLS certificate mismatch.

The API server still wouldn’t come up because its TLS certificates were signed with the old IP as a Subject Alternative Name (SAN).

Step 5: Regenerating Certificates

To fix the certificate issue:

1. Backed up existing API server certificates using

sudo cp -r /etc/kubernetes/pki /etc/kubernetes/pki.bak

2. Remove old API server certs/keys

sudo rm /etc/kubernetes/pki/apiserver.*

3. Regenerate the apiserver certificates with kubeadm

sudo kubeadm init phase certs apiserver \
  --apiserver-advertise-address=192.168.0.8 \
  --apiserver-cert-extra-sans=192.168.0.8,pedroops,PedroOps \
  --control-plane-endpoint=192.168.0.8

This generated a new certificate that included both my IP and hostname (PedroOps) in the SAN list. This way, the cert will be valid whether you connect via: “192.168.0.8, pedroops, or PedroOps"

4. Restart control-plane pods

They are static pods, so kubelet will restart them automatically when the cert changes. To speed it up:

sudo systemctl restart kubelet

Step 6: Test

After regenerating the certs, the kube-apiserver finally started successfully. I verified the cluster status:

sudo kubectl cluster-info
sudo kubectl get nodes

The node was back in the Ready state, which shows that the control plane is healthy again.

Key Takeaways

1. Plan for IP stability: Kubernetes is very sensitive to IP changes. Changing node IPs in Kubernetes is not straightforward. The IPs are baked into etcd, kubeconfigs, and API server certificates. Always set a static IP or use DNS names.
2. Know your critical files:

/etc/kubernetes/manifests/*.yaml
/etc/kubernetes/*.conf
Certificates under /etc/kubernetes/pki/

3. Use kubeadm tooling: Instead of manually hacking certs, kubeadm init phase is your friend.

4. Always check etcd manifests and kubeconfigs when troubleshooting control-plane startup failures.

5. Certificates must be regenerated if the advertised IP or hostname changes.

Conclusion

This issue served as a timely reminder that Kubernetes is highly sensitive to control-plane IP/hostname changes. If you ever reconfigure your network or migrate a master node to a new IP, don’t forget to:

• Update manifests and kubeconfigs
• Regenerate the API server certificate with the correct SANs

Doing so will save you from frustrating TLS errors and etcd crashes.

A minor IP change brought down my entire control plane — but through systematic troubleshooting, I gained valuable insights into Kubernetes internals and learned how to recover.

If you’re running your own cluster, I strongly recommend practicing disaster recovery scenarios like this. It’ll save you when the unexpected happens.

How I Migrated My Cloud Engineer Portfolio to AWS with S3, CloudFront, Route 53 & GitHub Actions CI/CD.

A practical cloud engineering project showcasing AWS migrations, automation, and DevOps best practices.

🔗My Cloud Portfolio

OVERVIEW

In cloud engineering, even something as simple as a personal portfolio can become a real-world project. Instead of keeping mine on Netlify, I treated it like a production-grade migration: hosting on AWS S3 + CloudFront, securing it with ACM, moving DNS to Route 53, and setting up GitHub Actions CI/CD with OIDC for automated deployments. The site is served over HTTPS, supports SPA deep routes, has www → apex redirect at the edge, and is deployed using CI/CD automation.

This wasn’t just about a website—it was about applying the same principles I’d use for enterprise cloud infrastructure. In this article, I’ll walk you through the full migration process—step by step—so you can learn how to host static sites on AWS the right way.

Pascal Attama | Cloud Engineer

The migration leverages:

• Amazon S3 → Static website hosting for the frontend.
• Amazon CloudFront → Global CDN distribution with HTTPS.
• AWS Certificate Manager (ACM) → Free SSL/TLS certificates.
• Amazon Route 53 → Domain and DNS management (migrated from Namecheap).
• GitHub Actions with OIDC → Automated deployments without storing AWS credentials.

The project was executed in two phases:

1. Phase 1: The Migration + Manual Deployment with AWS CLI
2. Phase 2: Automated CI/CD using GitHub Actions + OIDC (no long-lived keys)

WHAT I GAINED:

• Speed: Global CDN edge caching via CloudFront.
• Security: (S3 bucket stays private; only CloudFront’s OAC can read it and there are no IAM keys in GitHub.)
• Cheap: Mostly within the free tier for low traffic.
• Reliability: (AWS infra).
• Automation: One-push deploys (build → sync → invalidate → done).
• Cohesion: a single provider (AWS) will provide tighter integration and lower vendor coupling.

PREREQUISITES

• An AWS account (free tier).
• AWS CLI configured locally.
• A local Linux server running with Node.js, npm/yarn, and git.
• A React app locally built in the frontend/ directory with npm run build output in frontend/build/.
• A custom domain (pedroops.com) registered at Namecheap (or any registrar) and currently pointing to Netlify (or any other DNS hosting provider).
• A GitHub account containing the Git repo of the source code for the portfolio website.

HIGH-LEVEL PLAN

• Build the React app on your local Linux server.
• Set up AWS CLI on the local server.
• Create an S3 bucket and upload build/content (use aws s3 sync).
• Configure S3 for private origin and allow CloudFront to read (OAC).
• Create an ACM cert in us-east-1 and validate with DNS.
• Create a CloudFront distribution (S3 REST origin + OAC; default root object index.html; custom error responses for SPA).
• Create a Route 53 hosted zone, reproduce all DNS records (MX, SPF, DKIM split, verification TXT), and create an A (Alias) for apex and a CNAME/Alias for www pointing to CloudFront.
• Create a CloudFront function to redirect www → pedroops.com (viewer request).
• Add the GitHub OIDC provider in IAM.
• Add the GitHub Actions workflow.
• Verify the pipeline with dig and curl.

FULL STEP-BY-STEP PROCESS:

(A). Phase 1 (Migration):

1. DNS Query

Query the DNS server to verify where ‘pedroops.com’ is currently being hosted and its associated IP address using the dig and curl commands:

dig pedroops.com
dig www.pedroops.com
dig pedroops.com +short
dig www.pedroops.com CNAME +short
curl -I https://pedroops.com
curl -I http://www.pedroops.com
curl -I pedroops.com
curl -I https://pedroops.com/some/deep/route

It indicates that the server is pointing at Netlify.

2. Create the S3 bucket (private, origin for CloudFront)

Why private? Best practice. CloudFront will read from S3 using Origin Access Control (OAC), not public S3 URLs.

Console path

• S3 → Create bucket →
• Name: pedroops or yourdomain.com(should be globally unique).
• AWS Region: any (CloudFront is global).
• Block Public Access: Keep ON (all four checks).
• Bucket Versioning: Enable (easy rollback).
• Default encryption: Enable (SSE-S3).
• Click Create bucket.

3. Deploying the S3

• Navigate to the directory where your source code is located on your local machine, or you can clone my GitHub repo and build the React app on your local Linux server.

git clone https://github.com/Pascalpedro/my-portfolio-website.git
cd ~/my-portfolio-website/frontend

npm ci             # or npm install
npm run build      # creates ./build/
# confirm:
ls -la build/

• Install Dependencies & Build

# Make sure Node.js and npm/yarn are installed. Then:
npm ci             # or npm install
npm run build      # creates ./build/
# confirm:
ls -la build/

• Install & Configure AWS CLI on the Linux Server

# if not already installed:
sudo apt update && sudo apt install awscli -y

# Then configure it:
aws configure

Provide your:

AWS Access Key ID

AWS Secret Access Key

Default region (e.g., us-east-1)

Output format → json

(Use an IAM user with S3 permissions, not root.)

• Sync Your Build Folder to the S3 Bucket

aws s3 sync build/ s3://your-s3-bucket-name/ --delete

4. Request an SSL Certificate in AWS ACM

CloudFront requires HTTPS certificates in the us-east-1 region, even if your S3 bucket is elsewhere. So, the region must be in us-east-1 (N. Virginia) for CloudFront.

• Go to AWS Certificate Manager (ACM) → Request a certificate.
• Choose Request a public certificate → Next.
• Enter your domain:

pedroops.com
www.pedroops.com

• Choose DNS validation → Next.
• Click Create.

ACM will provide CNAME records that you need to add to Namecheap DNS. Copy the four NS servers Route53 gives you.

In Namecheap, add and update your domain’s nameservers to use these four Route 53 NS. Log in to Namecheap → Domain List → Manage → Advanced DNS.

Wait a few minutes; ACM will validate automatically. Status will become "Issued." When issued, go back to CloudFront and attach this certificate to your distribution (Settings → Edit → Custom SSL certificate).

5. Create a CloudFront distribution with OAC (secure S3 origin)

Goal: Serve your site via HTTPS at a fast global edge.

Console path

• CloudFront → Create distribution.
• Origin Settings:
• Origin domain: choose your S3 bucket (the bucket endpoint, not the “website” endpoint).
• Origin access: Origin access control (OAC) → Create new OAC → Save.
• CloudFront prompts to update the S3 bucket policy. Choose “Yes, update bucket policy” so that CloudFront will update the S3 bucket policy automatically.
• Default root object: index.html
• Viewer protocol policy: Redirect HTTP to HTTPS
• Allowed HTTP methods: GET, HEAD
• Cache policy: CachingOptimized (default)
• Alternate domain names (CNAMEs): add pedroops.com and www.pedroops.com (N/B: use your own custom domain)
• Custom SSL certificate: choose the ACM certificate you just validated.
• Create distribution. Wait until the status becomes Enabled and note the Distribution domain and Distribution ID.

6. Create a Route53 hosted zone.

Important: re-create all required DNS records inside Route 53 before changing Namecheap nameservers—this avoids downtime for email and verification records.

• Route 53 → Hosted zones → Create a hosted zone called ‘pedroops.com.’
• Type: choose Public hosted zone
• Re-create every record you need (copy from Namecheap).

7. SPA routing and add a CloudFront function.

Set CloudFront custom error responses for SPA deep routes. React SPAs need index fallbacks to avoid 404 on refresh:

• Add custom error response rule:CloudFront → Distribution → Error pages → Create custom response

403 → Response page /index.html, HTTP response code 200
404 → Response page /index.html, HTTP response code 200
(this ensures SPA deep routes don’t 404)

This ensures React Router handles deep links.

• Create a tiny CloudFront function to redirect www → apex:

CloudFront → Function → Create function

• Function name: redirect-www-to-apex
• Function code (Viewer request):

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

  // Only redirect the www host (leave apex and everything else untouched)
  if (host === 'www.pedroops.com') {
    // Rebuild query string (supports single and multivalue)
    var qsObj = request.querystring || {};
    var q = '';
    for (var k in qsObj) {
      if (qsObj.hasOwnProperty(k)) {
        var item = qsObj[k];
        if (item && item.value) {
          q += (q ? '&' : '') + k + '=' + item.value;
        } else if (item && item.multiValue && item.multiValue.length > 0) {
          for (var i = 0; i < item.multiValue.length; i++) {
            q += (q ? '&' : '') + k + '=' + item.multiValue[i].value;
          }
        }
      }
    }

    var location = 'https://pedroops.com' + request.uri + (q ? '?' + q : '');

    return {
      statusCode: 301,
      statusDescription: 'Moved Permanently',
      headers: {
        location: { value: location },
        // (Optional) HSTS if you want strict HTTPS:
        // 'strict-transport-security': { value: 'max-age=31536000; includeSubDomains; preload' }
      }
    };
  }

  // Otherwise, continue to origin
  return request;
}

Publish and associate with Viewer request for the default cache behavior.

8. Verification checklists

To verify if the DNS has been rerouted, let’s use the dig and curl commands that we ran at the beginning of the project.

• Using the terminal, run the below commands:

# Check DNS resolution
dig pedroops.com
dig www.pedroops.com
dig pedroops.com +short
dig www.pedroops.com CNAME +short

# Check certificate & headers
curl -I https://pedroops.com
curl -I http://www.pedroops.com
curl -I pedroops.com

# Check deep route (SPA)
curl -I https://pedroops.com/some/deep/route

You should see server: AmazonS3 (origin) + via: … cloudfront.net and x-cache: Hit/Miss from cloudfront.

Alternatively, you can use the browser.

(B). Phase 2: (CI/CD with GitHub Actions + OIDC)

By using GitHub Actions + OIDC in this project:

• CI/CD pipeline—Every time you push to main, your site rebuilds and deploys automatically.
• No long-lived keys—secure authentication (temporary credentials only).
• Automatic CloudFront cache invalidation—Ensures new changes appear instantly.
• Scalability—Can add test steps, linting, or deployment to staging.

1. Add the GitHub OIDC Provider in IAM (GitHub OIDC → AWS IAM Role)

• IAM → Identity providers → Add provider
• Provider type: OpenID Connect
• Provider URL: https://token.actions.githubusercontent.com
• Audience: sts.amazonaws.com
• Click Save.

2. Create an IAM Role the workflow can assume

• IAM → Roles → Create role
• Trusted entity type: Web identity
• Identity provider: select token.actions.githubusercontent.com (the one you just added).
• Audience: sts.amazonaws.com
• Click Next to attach a custom policy

3. Trust policy (restrict to your repo + branch)

• Open the new role → Trust relationships → Edit trust policy and paste the trust JSON below:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GitHubOIDCTrust",
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:Pascalpedro/my-portfolio-website:ref:refs/heads/main"
        }
      }
    }
  ]
}

This means only the main branch of Pascalpedro/my-portfolio-website can assume this role.

4. Permissions policy (least-privilege)

Create a customer-managed policy (IAM → Policies → Create policy → JSON) and attach it to the role. This grants:

• Upload/delete/list in your bucket; pedroops
• Create invalidations on your distribution; E4K*******UIL

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "S3ListBucket",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::your-s3-bucket-name"
    },
    {
      "Sid": "S3ObjectRW",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::your-s3-bucket-name/*"
    },
    {
      "Sid": "CloudFrontInvalidate",
      "Effect": "Allow",
      "Action": "cloudfront:CreateInvalidation",
      "Resource": "arn:aws:cloudfront::123456789012:distribution/YOUR_CLOUDFRONT_DIST_ID"
    }
  ]
}

Attach this policy to the role.

• Role name: GitHubActionsOIDC-PedroOps
• Create the role.

5. Add GitHub Actions Workflow

In your repo, create .github/workflows/deploy.ymlat the root project directory.

name: Deploy React App to S3 + CloudFront

on:
  push:
    branches:
      - main

permissions:
  id-token: write    # Required for OIDC
  contents: read

env:
  AWS_REGION: us-east-1
  S3_BUCKET: your-s3-bucket-name
  CF_DISTRIBUTION_ID: YOUR_CLOUDFRONT_DIST_ID

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      # 1. Checkout code
      - name: Checkout code
        uses: actions/checkout@v4

      # 2. Setup Node.js
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
          cache-dependency-path: 'frontend/package-lock.json'

      # 3. Install dependencies & build React
      - name: Install dependencies & build
        working-directory: frontend
        run: |
          npm ci
          npm run build

      # 4. Configure AWS credentials (OIDC)
      - name: Configure AWS credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsOIDC-PedroOps
          aws-region: ${{ env.AWS_REGION }}

      # 5. Sync build folder to S3
      - name: Sync to S3
        run: |
          aws s3 sync ./frontend/build s3://${{ env.S3_BUCKET }} --delete --exact-timestamps

       # 6. Optional: make index.html less cachey (recommended for SPAs)
      - name: Set Cache-Control for index.html
        run: |
          aws s3 cp s3://${{ env.S3_BUCKET }}/index.html /tmp/index.html
          aws s3 cp /tmp/index.html s3://${{ env.S3_BUCKET }}/index.html \
            --cache-control "no-cache, no-store, must-revalidate" \
            --content-type "text/html" \
            --metadata-directive REPLACE

      # 7. Invalidate CloudFront cache
      - name: Invalidate CloudFront cache
        run: |
         aws cloudfront create-invalidation \
          --distribution-id ${{ env.CF_DISTRIBUTION_ID }} \
          --paths "/*"

      # 8. Notify
      - name: Deployment complete
        run: echo "🚀 Deployed pedroops.com from frontend/ via OIDC!"

6. Verify the pipeline

On GitHub:

• GitHub → Actions: confirm the Deploy React workflow ran and succeeded.

On AWS CLI:

# S3
aws s3 ls s3://pedroops/ - recursive | tail   #shows fresh timestamps

# CloudFront
aws cloudfront list-invalidations - distribution-id YOUR_CLOUDFRONT_DIST_ID     # shows your invalidation

CONCLUSION

This migration project showcases the full lifecycle of deploying and managing a cloud-native portfolio site:

• From manual S3 sync + CloudFront invalidation →
• To secure automated CI/CD with GitHub Actions OIDC.

The final setup is scalable, secure, and automated, reflecting modern AWS Cloud + DevOps practices.

Practical cloud engineering project for showcasing full-stack skills!!!

INTRODUCTION

In today’s cloud-native world, showcasing your professional skills requires more than just a static web page. This project is a dynamic, full-stack portfolio web application built to help engineers, developers, and tech professionals present their work, certifications, and credentials with real-time interactivity, analytics, and cloud-native deployment.

🔗 GitHub Repo | 🌐 Live Demo

As a cloud engineer, this project not only helps you demonstrate your DevOps and full-stack abilities but also serves as a template for deploying modern web applications using scalable, cloud-based services.

In this article, I walk you through how I built my full-stack developer portfolio, hosted on the cloud with React, FastAPI, MongoDB, Netlify, and Railway.

TECH STACK OVERVIEW

This project uses a modern full-stack architecture:

| Layer     | Stack                                       |
| - - - - - | - - - - - - - - - - - - - - - - - - - - - - |
| Frontend  | React, TailwindCSS, Framer Motion           |
| Backend   | FastAPI (Python), Motor (MongoDB async)     |
| Database  | MongoDB Atlas                               |
| Hosting   | Netlify (frontend), Railway (backend)       |
| Analytics | Google Analytics 4                          |
| DevOps    | Git, Docker + Docker Compose                |

FEATURES & FUNCTIONAL HIGHLIGHTS

🔹 Modern Full-Stack Architecture

• Frontend: Built with React, styled using TailwindCSS, and enhanced with Framer Motion for UI animation and user experience.
• Backend: A scalable FastAPI service written in Python, exposing a REST API to serve portfolio data and handle form submissions.
• Database: MongoDB Atlas, a cloud-native NoSQL database that stores dynamic portfolio content and contact form data.

🔹 Cloud-Ready Deployment & CI/CD

• Frontend Hosting: Deployed to Netlify, utilizing build automation and CDN-powered delivery.
• Backend Hosting: Deployed to Railway, supporting seamless continuous deployment from GitHub.
• Infrastructure-as-Code Ready: The stack can be containerized using Docker and deployed via Docker-Compose, aligning with IaC and Kubernetes adoption patterns.
• Environment Management: Uses .env files to securely manage configuration across environments — ideal for multi-stage cloud deployments.

🔹 DevOps & Monitoring Integration

• Cloud Integration Patterns:
  - Simulates real-world separation of frontend/backend concerns.
  - Can be deployed on AWS using S3 + CloudFront (frontend) and EC2/Fargate/Lambda (backend)
• Analytics & Monitoring:
  - Integrated with Google Analytics 4 (GA4) to track user interactions like CV views and downloads, reflecting cloud observability best practices.
• Secure Data Handling:
  - MongoDB hosted on Atlas with secure connection strings.
  - Supports future integrations like AWS Secrets Manager, CloudWatch, or SES for alerting and mailing.

🔹 Dynamic & Maintainable

• Projects, certifications, and CVs are served dynamically from the backend.
• Google Drive is used for CV hosting to reduce static asset load
• Adminless and scalable — ideal for solo deployment or resume infrastructure.

Why This Portfolio Matters for a Cloud Engineer

This isn’t just a personal website — it’s a miniature cloud-native application, built from the ground up to highlight:

• ✅ Proficiency in multi-tier architecture.
• ✅ Skill in deploying full-stack applications to the cloud.
• ✅ Demonstrates containerization potential using Dockerfile and docker-compose.yml.
• ✅ Separates concerns across services, mirroring microservice architecture best practices.
• ✅ The ability to build developer-facing tools and user interfaces.
• ✅ Real-world implementation of API integration, async database handling, and CI/CD-ready architecture.
• ✅ Illustrates how to securely handle environment variables and backend secrets.

This application is designed to be migratable to AWS infrastructure, enabling:

• S3 + CloudFront for static frontend hosting
• API Gateway + Lambda or ECS for backend logic
• DynamoDB or DocumentDB for backend persistence
• CloudWatch for event monitoring
• SES or SNS for contact form alerting

In essence, it helps you showcase your DevOps maturity while hosting your credentials in a live, interactive, and cloud-native environment.

🗂️ Project Structure

bash

my-portfolio-website
├── frontend/ # React App
│ ├── src/
│ ├── public/
│ ├── netlify.toml
│ ├── Dockerfile #Frontend Dockerfile
│ └── .env
├── backend/ # FastAPI App
│ ├── server.py
│ ├── email_utils.py
│ ├── venv/ #Virtual Env
│ ├── Dockerfile # Backend Dockerfile
│ └── requirements.txt # Python dependencies
│ └── .env
│── nginx.conf
├── .gitignore
├── render.yaml
├── docker-compose.yml
└── README.md

Getting Started

1. Clone the Project Repo

bash

git clone https://github.com/Pascalpedro/my-portfolio-website.git
cd my-portfolio-website

2. Backend Setup (FastAPI)

bash

cd backend
python -m venv venv
source venv/bin/activate # On Windows: venv\Scripts\activate
pip install -r requirements.txt

• create .env in backend/:

env

MONGO_URL=mongodb+srv://<username>:<password>@cluster.mongodb.net/
DB_NAME=portfolio_db

• Run the backend:

bash

uvicorn server:app - reload - port 8000

3. Frontend Setup (React)

bash

cd frontend
npm install

• Create .env in frontend/:

env

REACT_APP_API_URL=http://localhost:8000/api
REACT_APP_GA_MEASUREMENT_ID=G-XXXXXXX

• Start the frontend server:

bash

npm start

⚙️ Step-by-Step Setup

🔗 Kindly find the complete, well-detailed step-by-step setup instructions on my GitHub Project Repo

📷 Screenshots

🎯 Conclusion

This project goes beyond a typical portfolio—it’s a cloud-engineered personal showcase platform. Built with production-ready practices, it provides cloud engineers with a valuable asset to:

• Exhibit their projects and certifications
• Practice full-stack cloud deployment workflows
• Demonstrate real-world skills across frontend, backend, database, and DevOps tooling

Whether you’re aiming to impress recruiters or clients or looking to build out your cloud development portfolio, this project equips you with everything you need to stand out in today’s competitive tech landscape.

INTRODUCTION

Have you ever felt curious about Ubuntu Linux and wanted to try it out? Perhaps you’re a developer wishing to test software or a student yearning to explore its vast capabilities but, at the same time, worried about tampering with your main system. VirtualBox offers a fantastic solution!

Whatever your reason, VirtualBox offers a fantastic platform to experience Ubuntu in a safe and isolated environment.

This guide will walk you through the installation process, transforming your computer into a virtual playground for exploring the wonders of Ubuntu.

Are you ready to embark on this adventure? Alright, follow the steps below; let’s rock& roll...🤝

(1). PREPARATION:

However, some prerequisites must be completed before we can begin the installation procedures on the Ubuntu Linux machine running in VirtualBox. These consist of:

• First, we must find the VirtualBox software, ensure its compatibility with your system, and download it from its website: https://www.virtualbox.org/wiki/Downloads, and then install it with the right settings. This is a straightforward process.
• Also, we need to obtain and download the desired Ubuntu ISO file from the official website: https://ubuntu.com/download/desktop and choose a 64-bit version for optimal performance.

Have you finished downloading the two essential pieces of software mentioned above? Then stay tuned for the next level. 😉

Below is a well-detailed explanation with pictorial illustrations and a step-by-step guide on the Ubuntu Linux installation and setup.

(2). CREATING THE VIRTUAL MACHINE:

Now, to begin your setup, these are the steps to follow:

(2.1). Launch the newly installed VirtualBox application on your computer and click the “New” button on the homepage to create a new machine.

(2.2). Provide a name for your virtual machine. A best practice is using the OS name and version for uniqueness and simplicity. (e.g., “Ubuntu-22.04”)

(2.3). Select “Linux” as the type and choose “Ubuntu (64-bit)” or the appropriate version you downloaded as the version.

(2.4). Assign a memory size of 2048MB (2 GB) for your RAM to allocate a memory size.

By default, it will assign you a memory size of 1024MB (1 GB), but a good starting point for RAM allocation is 2048MB (2 GB), which can also be adjusted based on your system's available memory and the desired performance of the virtual machine. The memory can be allocated using the slider or by entering a value in the memory field.

(2.5). Select “Create a virtual hard disk now” and click the ‘create’ button to create a Virtual Hard Disk.

(2.6). Keep the default option “VDI (VirtualBox Disk Image)” selected and click the ‘next’ button.

(2.7). Choose “dynamically allocated” for disk storage type. This will allow the virtual disk to grow as needed, and click the ‘next’ button.

(2.8). Set the desired location and size for the virtual disk, and click the ‘create’ button. A minimum of 20 GB is recommended, but you can allocate more depending on your needs.

The above steps will add a brand new Ubuntu machine to your VirtualBox machine.

(3). INSTALLING UBUNTU

After creating the virtual hard disk, we will have to install and set up Ubuntu ISO files on the newly created machine.

To attach the Ubuntu ISO:

(3.1). On the virtual machine homepage, navigate to the storage section and click the empty (optical drive) controller icon under “IDE secondary device.”.

(3.2). Select “Choose virtual disk file...” from the drop-down menu and locate and select the Ubuntu ISO file downloaded earlier, and load it into the IDE device.

To start and install the virtual machine:

(3.3). Select your newly created virtual machine on the VirtualBox homepage and click the “Start” button.

(3.4). Click on the first option, “Try or install Ubuntu,” and wait for a while for the booting process to activate.

(3.5). Select your language.

(3.6). Choose “Try Ubuntu” or “Install Ubuntu,” depending on your preference, and select your keyboard language and layout.

(3.7). Choose the installation type (normal installation is recommended) tick ‘Download updates while installing Ubuntu’ and click continue.

(3.8). Choose “Erase disk and install Ubuntu.” and click the “Install Now” button.

N/B: The message on this page appears because you’re setting up a new virtual machine with Ubuntu, and VirtualBox hasn’t detected an existing operating system on the virtual disk you created. This is perfectly normal for a fresh installation. This option is exactly what you want since you’re creating a new Ubuntu system on the virtual machine. Don’t worry, it won’t erase anything on your physical computer. It will erase the virtual disk (which is currently empty anyway) and prepare it for the Ubuntu installation. It refers to formatting the virtual disk you allocated for the Ubuntu installation within VirtualBox.

(3.9). Select your location and click continue.

(3.10). Set up your user account credentials and authentication details, where:

• “Your name”: Your real name, which is optional and used for display purposes.
• “Your computer’s name”: hostname, used for network identification, sharing, and remote access.
• “Username”: Username, used for login credentials for user authentication.
• “Password”: choose a strong password that comprises “capital, small, digits, and symbols.”

The installation process might take some time.

(3.11). Once complete, you’ll be prompted to restart the virtual machine to use the new installation. Remove the virtual media (ISO file) from the settings before restarting.

(4). BOOTING INTO UBUNTU

(4.1). Select your virtual machine and click “Start.”

(4.2). You’ll be presented with the Ubuntu login screen. Enter your username and password created during installation.

The virtual machine will boot into the newly installed Ubuntu system.

CONGRATULATIONS!!! You’ve successfully installed Ubuntu on your VirtualBox virtual machine. Now you can explore the Ubuntu desktop and start using it. CHEERS!!!😁😁😁