Modern Cloud-Native Development for AWS Deployments (Part 1)

A few years ago, “setting up your dev environment” often meant losing half a day to installing Node versions, fixing PATH issues, fighting dependency conflicts, and hoping the project would run the same way on everyone’s machine. Today, cloud-native development is changing that workflow. Instead of treating your laptop as the only place you can build software, you can develop inside consistent, containerized environments that live in the cloud—accessible from any browser, anywhere.

This is Part 1 of a 3-part series on Modern Cloud-Native Development for AWS Deployments, where we’ll build and ship a production-ready portfolio website using modern frontend tooling and AWS services:

• Part 1 (this article): Build the full portfolio site using GitHub Codespaces as your cloud development environment
  
• Part 2: Host your static assets (images, resume PDF, gallery) using Amazon S3
• Part 3: Deploy to production with CI/CD using AWS Amplify, and monitor with Amazon CloudWatch

By the end of this series, you’ll have a polished portfolio website inspired by modern developer portfolios, and you’ll gain hands-on experience that maps directly to real-world cloud workflows: containerized development environments, asset hosting, and production deployment on AWS.

Let’s start where cloud-native work begins: a consistent dev environment you can spin up in minutes.

Why Developers Need a Portfolio Website

A developer portfolio website isn’t just “a nicer resume.” It’s a high-signal artifact that shows how you think, how you present work, and what you can build end-to-end. In a competitive industry, your portfolio becomes a shortcut for recruiters and hiring managers: instead of guessing your skills from a list of keywords, they can see your output.

Professional visibility

Your portfolio is your digital business card, the one link you can put everywhere: LinkedIn, GitHub bio, email signature, and applications. When someone looks you up, your portfolio is the page that should answer: Who are you? What do you build? What value do you bring?

Personal branding and online presence also matter more than ever. Stack Overflow’s blog references Northeastern University’s point that building your presence “boosts your career,” and notes that hiring managers often consider personal brand as part of hiring decisions.

Showcase your work (beyond GitHub)

GitHub repositories show your code. A portfolio shows the complete picture:

• A clear project story (problem → approach → results)
  
• Usability and design decisions
  
• Live demos and links
  
• Screenshots, metrics, and outcomes

A portfolio also helps non-technical stakeholders evaluate you. Not every decision-maker will dig through a repo, but almost anyone can scan a well-structured portfolio and understand impact.

Personal branding (control the narrative)

A resume is constrained. A portfolio lets you highlight what matters:

• The types of problems you like solving
  
• The technologies you’re confident with
  
• Your learning trajectory and growth
  
• Your personality and communication style
  

This is especially useful if you’re early-career, shifting roles, or building credibility in a new stack.

A learning opportunity with real deployment value

Building your own portfolio is one of the best “real projects” you can do because it forces you to practice production-oriented skills:

• A modern framework (Next.js + React)
  
• Component structure and maintainable code organization
  
• Accessibility and responsive design
  
• Performance considerations
  
• Deployment workflow and hosting (which we’ll do on AWS in Parts 2 and 3)
  

This series is designed so that the output isn’t “just a tutorial app.” It’s something you can actually ship, iterate on, and use in your career.

Now that we’re aligned on why portfolios matter, let’s look at the design reference we’ll use so we can build with a clear target in mind.

Design Reference: Inspiration from bryllim.com

To keep our portfolio professional and recruiter-friendly, we’ll take design inspiration from bryllim.com, a modern developer portfolio with a clean layout and strong readability. The site works well because it prioritizes clarity over clutter: the spacing feels intentional, typography is easy to scan, and the content is organized in a way that quickly communicates credibility.

The layout also reflects what hiring managers typically expect to see in a portfolio: a clear introduction, proof of work through projects, credibility through experience and certifications, and a straightforward way to contact you. We’ll follow these same design principles while keeping our implementation fully original and customizable.

bryllim.com – Light Mode

Light mode view showing clean typography and structured layout.

bryllim.com – Dark Mode

Dark mode view highlighting contrast and readability.

bryllim.com – Mobile View

Mobile responsive layout showing stacked sections and spacing.

Why GitHub Codespaces for Cloud Development?

GitHub Codespaces is a cloud-hosted development environment that runs in a container and gives you a full VS Code experience in the browser. Instead of setting up Node, managing versions, and troubleshooting local machine quirks, you can open a project and start building immediately, on any device.

This is especially useful for portfolio projects because the workflow is reproducible: the same repository can spin up the same environment every time. Codespaces also supports configuration-as-code through dev container settings, which mirrors how modern teams standardize development workflows in professional environments.

Finally, Codespaces fits the cloud-native mindset: we develop in a containerized environment, then later deploy with AWS services (S3 and Amplify) without tying the project to a single laptop setup. 

By treating even a simple project like a real cloud deployment, we set ourselves up for a cleaner, more professional AWS architecture.

Creating the GitHub Repository

1. Go to github.com/new
   
2. Configure your repository:
   
   • Repository name: cloud-native-portfolio
     
   • Description: A modern cloud-native portfolio website built with Next.js, Tailwind CSS, and deployed on AWS Amplify. Part of the Tutorials Dojo article series.
     
   • Visibility: Public
     
   • Initialize with README: Toggled on
     
   • Add .gitignore: Node
3. Click Create repository

Why these choices matter:

• Public repos are easier to share as portfolio proof.
  
• README helps explain your project quickly.
  
• Node .gitignore avoids committing build artifacts.
  
• MIT license is common for open learning projects.
  

📁 GitHub Repository for Code Reference: https://github.com/pabilandokarenpv/cloud-native-portfolio

Setting Up GitHub Codespaces

Launch Codespaces

Step 1. Open your repository on GitHub

Step 2. Click the green Code button

Step 3. Go to the Codespaces tab

Step 4. Click Create codespace on main

Wait for initialization (usually 1–2 minutes)

What’s happening behind the scenes?

When you launch Codespaces:

• GitHub provisions a Linux container
  
• Your repo is cloned into the container
  
• VS Code connects to it via browser
  
• You get an isolated dev machine with terminal access
  

What you’ll see

A VS Code-like interface in your browser:

• File explorer (left)
  
• Editor (center)
  
• Terminal (bottom)
  

💡 Tip: Stop your Codespace when you’re not using it to conserve your free quota. GitHub also documents how Codespaces usage is measured and billed.

Creating the Devcontainer Configuration

To make our development environment reproducible and consistent, we configure GitHub Codespaces using a dev container setup. Instead of manually installing tools or configuring extensions per machine, we define everything once and version-control it with the project.

This approach reflects real-world cloud development practices: infrastructure and environment configuration should be treated as code.

In this project, the dev container:

• Uses a Node.js 18 base image
  
• Installs the AWS CLI for later parts
  
• Automatically installs recommended VS Code extensions
  
• Forwards port 3000 for local development preview
  
• Runs dependency installation on container creation

You can find the complete configuration in the Gist below:

📁 Dev Environment Configuration Gist: 

After adding the configuration file, simply rebuild the Codespace so the environment provisions correctly

This gives you a clean, repeatable development setup , exactly how modern teams standardize workflows.

Initializing the Next.js Project

With the environment ready, we initialize the portfolio using Next.js with the App Router, TypeScript, Tailwind CSS, and ESLint enabled.

Instead of pasting long terminal commands here, refer to:

📁 Project Initialization Steps Gist: 

This gist includes:

• The exact initialization command
• Required flags and what they enable
• Additional packages installed (Framer Motion, Lucide, next-themes)

Once initialized, running the development server will allow you to preview the default Next.js starter page inside Codespaces.

At this stage, we have:

• A modern React framework
  
• Type safety via TypeScript
  
• Utility-first styling via Tailwind
  
• A cloud-based dev workflow
  

Everything is production-ready from a structural standpoint.

Setting Up the Project Structure

Clean structure matters more than most developers realize. A portfolio is small, but we design it like a scalable application.

Instead of mixing everything into one folder, we separate responsibilities:

• layout/ for page structure components
  
• sections/ for major content blocks
  
• ui/ for reusable components
  
• data/ for editable portfolio content
  
• types/ for TypeScript definitions
  
• lib/ for helpers and utilities
  

You can find the complete folder map here:

📁 Project Structure Reference Gist:

This structure keeps the project readable, maintainable, and professional. If someone else opens your repository, they immediately understand how it’s organized.

Configuring the Design System

Instead of hardcoding random colors and styles across components, we define a simple design system using Tailwind configuration. This includes:

• Background and surface colors
  
• Text hierarchy (primary, secondary, muted)
  
• Accent color for links and buttons
  

• Dark mode configuration using class-based switching
  

The goal is consistency. Every section should feel part of the same system.

For the complete configuration and explanation of tokens, refer to:

📁 Tailwind Design System Gist:

By centralizing design tokens, we ensure:

• Easier theme adjustments
  
• Cleaner code
  
• A professional visual identity
  

This mirrors how real production apps handle design systems.

Building the Portfolio Components

Now the portfolio starts to take shape.

Instead of dumping hundreds of lines of component code into this article, the full implementation is available in the repository and organized Gists.

📁 Component Architecture Overview Gist:

The architecture includes:

• Layout components (Header, Sidebar, MainContent, Footer)
  
• Section components (Hero, About, Tech Stack, Projects, Certifications, Experience, Gallery, Contact, etc.)
  
• Reusable UI components (Button, Card, Badge, ThemeToggle)
  

We also separate content into data files. That way, updating your projects or experience does not require editing layout logic.

The two-column desktop layout collapses cleanly on mobile using responsive utilities. Dark mode is handled through next-themes, and interactive elements like carousels or galleries are isolated as client components.

The focus here is structure, not complexity. The result is a clean, recruiter-ready portfolio built like a real application.

Testing Your Portfolio

Before committing anything, verify that everything behaves as expected.

Open the development server and confirm:

• Light and dark mode toggle works
  
• Layout adapts properly on mobile
  
• Sections render in correct order
  
• No console errors appear
  
• Interactive components function smoothly
  

Cloud-Native Portfolio – Light Mode

Light mode view result showing clean typography and structured layout inspired by bryllim.com portfolio website.

Cloud-Native Portfolio – Dark Mode

Dark mode view result highlighting contrast and readability inspired by bryllim.com portfolio website.

Cloud-Native Portfolio – Blog Page

Cloud-Native Portfolio – Mobile View

Mobile responsive layout result showing stacked sections and spacing inspired by bryllim.com portfolio website.

Testing in browser DevTools (responsive mode) ensures the layout collapses correctly below tablet breakpoints. 

Even though this is “just a portfolio,” treating testing seriously reinforces good cloud development discipline.

Committing Your Progress

With everything working, commit your changes to GitHub. This locks in your environment configuration, project structure, and initial implementation.

Pushing your code at this stage ensures:

• The repository reflects a complete, working foundation
  
• Codespaces can recreate the environment anytime
  
• You’re ready to connect AWS services in the next part
  

From here onward, your portfolio is no longer just local code, it’s a versioned, cloud-ready workload.

What This Teaches About AWS — Even Without Using It Yet

Even though Part 1 doesn’t create any AWS resources, it already builds the habits behind good AWS architecture. We designed the portfolio as a portable, cloud-ready workload that can move cleanly into S3 and Amplify later.

• Stateless by design: the app isn’t tied to one machine, which matches cloud-friendly workload patterns.
• Reproducible environments: defining setup through configuration (Codespaces/dev container) reflects the same mindset as infrastructure-as-code on AWS.
• Separation of app and deployment: we built the application foundation first so hosting and delivery can be attached later without rewriting core code.
• Cost-aware decisions early: free-tier tooling and minimal always-on resources align with AWS cost optimization thinking.
• Static hosting readiness: the structure fits naturally into S3-based asset hosting and CDN-style delivery in the next parts.

What’s Next: Part 2 – Hosting Portfolio Static Assets with Amazon S3

Now that the portfolio application is built and structured correctly, the next step is moving into AWS infrastructure.

In Part 2, we will:

• Create and configure an Amazon S3 bucket
  
• Understand how object storage works in AWS
  
• Upload portfolio assets (profile photo, gallery images, resume PDF)
  
• Configure proper public access settings and bucket policies
  
• Apply CORS configuration for frontend access
  
• Connect our Next.js application to S3-hosted assets
  
• Review S3 best practices for cost control and organization
  

This is where application design transitions into infrastructure design.

Helpful Resources

• GitHub Codespaces Documentation
  https://docs.github.com/en/codespaces
• Mr. Bryl Lim’s Portfolio Website
  https://docs.github.com/en/codespaces
• MDN Web Docs – Structuring Web Projects
  https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/Files
• Amazon S3 – Product Overview
  https://aws.amazon.com/s3/
• AWS – What Is Cloud Computing
  https://aws.amazon.com/what-is/cloud-computing/ 
• AWS Well-Architected Framework (Overview)
  https://aws.amazon.com/architecture/well-architected/