DEV Community: Goodnews Azonubi

How I Built and Deployed a Production ready MERN Application on AWS using Modular Terraform and Keyless GitHub Actions OIDC 🚀

Goodnews Azonubi — Fri, 11 Sep 2026 17:15:54 +0000

Deploying a full-stack web application into production is often one of the most daunting steps for modern developers. You build a complete application locally, but when it comes to hosting it securely on cloud infrastructure with HTTPS, custom domains, and automated deployment pipelines, things can quickly get overwhelming.

In this post, I will walk you through how I built and deployed an end-to-end full-stack MERN application ("Little List")—from the frontend user interface and Express REST API to provisioning production AWS cloud infrastructure with Terraform and automating deployments with Keyless GitHub Actions OIDC.

Whether you are a beginner looking to understand full-stack architecture & cloud deployment or an experienced engineer reviewing multi-environment Terraform design, this guide covers the entire end-to-end workflow!

📱 What is "Little List"? (Application Overview)

"Little List" is a full-stack personal productivity and management application built from scratch:

React SPA Frontend (Vite): Modern, responsive UI with state management, JWT auth flows, interactive diary logging, and custom URL shortener interfaces.
Node.js & Express API Backend: Modular REST API with secure authentication, refresh tokens, MongoDB integration, and route validation.
MongoDB Database: Persistent storage for users, diary entries, and shortened link analytics.

📋 Prerequisites

Before diving in, here is what you will need if you want to replicate this deployment architecture:

AWS Account: An active AWS account with permissions to manage EC2, S3, CloudFront, ECR, IAM, and Route 53.
Terraform CLI: Installed on your machine (>= 1.16.2).
AWS CLI: Installed and configured with your credentials (aws configure).
Docker: Installed locally for testing container builds.
Node.js & npm: Installed locally for building the frontend.
GitHub Account: A repository containing your MERN codebase.
Custom Domain (Optional): A domain registered on Namecheap, GoDaddy, or Route 53 if you want custom SSL support (e.g., ideategudy.tech).

🏗️ The Cloud Architecture Overview

Before writing code, let us look at the high-level architecture diagram of what we are provisioning on AWS:

                               ┌──────────────────────┐
                               │    GitHub Actions    │
                               └──────────┬───────────┘
                                          │
                        ┌─────────────────┴─────────────────┐
                        │                                   │
                  Frontend deploy                      Backend deploy
                        │                                   │
                        ▼                                   ▼
                ┌───────────────┐                    ┌───────────────┐
                │      S3       │                    │      ECR      │
                │ React build   │                    │ Docker image  │
                └───────┬───────┘                    └───────┬───────┘
                        │                                    │
                        │                                    │ docker pull
                        │                                    ▼
                        │                            ┌───────────────┐
                        │                            │      EC2      │
                        │                            │ Express/Docker│
                        │                            └───────┬───────┘
                        │                                    │
                        │                            ┌───────┴───────┐
                        │                            │      ASG      │
                        │                            │  EC2 fleet    │
                        │                            └───────┬───────┘
                        │                                    │
                        ▼                            ┌───────▼───────┐
                ┌───────────────┐                    │      ALB      │
                │  Route 53 DNS │                    │ Load Balancer │
                └───────┬───────┘                    └───────▲───────┘
                        │                                    │
                        ▼                                    │
                ┌───────────────┐                            │
                │  CloudFront   │────────────────────────────┘
                │  CDN (HTTPS)  │ Path-based routing (/api/*)
                └───────────────┘

Core Components Explained for Beginners:

AWS Route 53: Highly available DNS service that manages custom domain records (dev.ideategudy.tech) and routes client requests directly to CloudFront via A-record Aliases.
Amazon S3: Hosts the static, compiled single-page React frontend (dist/ build files) privately.
Amazon CloudFront: A global Content Delivery Network (CDN) that serves the React app over HTTPS and acts as a single reverse proxy for both client and backend requests.
Amazon ECR (Elastic Container Registry): Private Docker image registry to store backend container builds.
AWS ALB (Application Load Balancer): Receives API traffic from CloudFront and balances requests across EC2 instances.
AWS Auto Scaling Group (ASG): Manages an auto-healing fleet of EC2 instances running Canonical Ubuntu 24.04 LTS and Docker.
GitHub OIDC (OpenID Connect): Allows GitHub Actions to obtain short-lived security tokens to deploy to AWS without storing permanent AWS Secret Access Keys in GitHub.

📂 Repository & Project Structure

Here is how the project files are structured:

.
├── client/                     # Vite + React SPA Frontend
├── server/                     # Node.js + Express API Backend (Dockerized)
├── infra/                      # Modular Terraform Infrastructure
│   ├── main.tf                 # Root Terraform Module
│   ├── variables.tf            # Root Variables & Configuration Defaults
│   ├── outputs.tf              # Root Terraform Outputs
│   ├── versions.tf             # AWS & Provider Requirements
│   ├── dev.tfvars.example      # Development Environment Settings
│   ├── prod.tfvars.example     # Production Environment Settings
│   └── modules/
│       ├── vpc/                # VPC, Public Subnets (2 AZs), IGW, Route Tables
│       ├── backend/            # ECR, ALB, ASG, Launch Template, EC2 IAM Role
│       ├── frontend/           # S3 Bucket, CloudFront OAC, CDN Distribution, Route53/ACM
│       └── github_oidc/        # GitHub OIDC Identity Provider & IAM Role
└── .github/
    └── workflows/
        └── deploy.yml          # Parallel CI/CD Workflow (Frontend & Backend)

🧱 Key Technical Deep Dives

1. Unified Single-Domain Routing with CloudFront

One common challenge with SPA + API setups is CORS and handling multiple URLs (api.domain.com vs domain.com). We solved this by serving both frontend and backend under the exact same domain (https://dev.ideategudy.tech) via CloudFront Path-Based Routing:

Request Path Pattern	Origin Target	Description
`/` or `/assets/*`	`s3-frontend`	Serves static React SPA files
`/api/`, `/s/`, `/healthz`	`alb-api`	Forwards API requests directly to the EC2/Express backend

💡 Pro-Tip: When forwarding requests through CloudFront to an ALB, ensure your CloudFront cache behavior explicitly forwards the Authorization, Accept, Content-Type, Origin, and Referer headers! Otherwise, CloudFront strips the Authorization: Bearer <jwt> header by default, leading to 401 Unauthorized errors on authenticated routes.

2. Zero Secrets in GitHub via AWS OIDC

Instead of creating long-lived IAM user keys (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) and pasting them into GitHub Secrets, we configured an AWS IAM OIDC Identity Provider.

GitHub Actions assumes a temporal AWS IAM Role dynamically per pipeline run using OpenID Connect authentication. If your pipeline is compromised, there are no static credentials to leak!

🌐 Custom Domain, Subdomain Setup (`dev.ideategudy.tech`) & SSL Configuration

Primary infrastructure resources (VPC, EC2, ASG, ALB, ECR, S3) are deployed in eu-north-1 (Stockholm). HTTPS is terminated at the CloudFront CDN level using AWS Certificate Manager (ACM) in us-east-1 (required by CloudFront for global edge distributions).

Why Use a Subdomain (`dev.ideategudy.tech`)?

Instead of pointing the root/apex domain (ideategudy.tech) directly to this environment, we configured a dedicated subdomain (dev.ideategudy.tech) for several key reasons:

Environment Isolation (dev vs prod): Using subdomains allows us to run isolated development (dev.ideategudy.tech) and production (ideategudy.tech or app.ideategudy.tech) infrastructure in separate Terraform workspaces without DNS conflicts.
Subdomain NS Delegation in Namecheap: By adding custom NS records for dev.ideategudy.tech in Namecheap, we delegate only the dev subdomain DNS resolution to AWS Route 53 while keeping the parent apex domain (ideategudy.tech) managed at Namecheap.
Multi-Environment Testing: It enables continuous testing of AWS infrastructure changes (CloudFront, ALB, ASG) on a real HTTPS domain without risking downtime for main production domain traffic.

Connecting Namecheap Subdomain (`dev.ideategudy.tech`) to AWS:

In infra/dev.tfvars:

   domain_name         = "dev.ideategudy.tech"
   create_route53_zone = true

Run terraform apply --var-file="dev.tfvars".
Copy the 4 output nameservers from Terraform:

   route53_nameservers = [
     "ns-1143.awsdns-14.org",
     "ns-1698.awsdns-20.co.uk",
     "ns-263.awsdns-32.com",
     "ns-847.awsdns-41.net"
   ]

Log into Namecheap -> Domain List -> Manage ideategudy.tech -> Advanced DNS -> Add 4 NS Records for Host dev pointing to the Route 53 Nameservers.

Figure: Configured NS records in Namecheap delegating dev.ideategudy.tech to AWS Route 53.

In minutes, free auto-renewing SSL is active across https://dev.ideategudy.tech!

⚡ Automated CI/CD Pipeline (`deploy.yml`)

When code is pushed to main, GitHub Actions triggers .github/workflows/deploy.yml which executes two parallel jobs:

💡 Note for Beginners: You do not need to manually build the React frontend or Docker container on your local computer before pushing. GitHub Actions automatically compiles the React production bundle and builds/pushes the Docker image in the cloud during the pipeline run!

deploy-frontend:
- Builds Vite/React bundle.
- Authenticates keylessly to AWS via OIDC.
- Syncs static assets to the private S3 bucket (aws s3 sync).
- Invalidates CloudFront edge cache (aws cloudfront create-invalidation).
deploy-backend:
- Builds Docker image for Express API.
- Authenticates to Amazon ECR via OIDC.
- Pushes new Docker tag to ECR.
- Syncs runtime application secrets into AWS SSM Parameter Store (/mern-deploy/dev/...).
- Executes zero-downtime container updates across EC2 ASG instances via AWS SSM RunShellScript.

🚀 Step-by-Step Deployment Instructions

Step 1: Provision AWS Infrastructure with Terraform

cd infra

# Copy example variables
cp dev.tfvars.example dev.tfvars

# Edit values in dev.tfvars (domain_name, github_org, github_repo)
terraform init
terraform plan --var-file="dev.tfvars"
terraform apply --var-file="dev.tfvars" --auto-approve

Figure 1: Successful terraform apply showing outputs for S3, CloudFront, ECR, and ALB.

Step 2: Configure GitHub Repository Secrets & Variables

In your GitHub repo under Settings -> Secrets and variables -> Actions:

💡 Tip: You can retrieve all your Terraform output values anytime by running terraform output inside the infra/ folder.

Figure 2: GitHub Actions repository variables and secrets configured for OIDC deployment.

Secrets:
- MONGODB_URI: MongoDB connection string
- ACCESS_TOKEN_SECRET: JWT access secret
- REFRESH_TOKEN_SECRET: JWT refresh secret
Variables:
- AWS_ROLE_ARN: Output github_actions_role_arn
- AWS_REGION: eu-north-1
- ECR_REPOSITORY: Output ecr_repository_name
- FRONTEND_BUCKET: Output frontend_bucket
- CLOUDFRONT_DISTRIBUTION_ID: Output cloudfront_distribution_id
- API_ASG_NAME: Output api_asg_name
- SSM_PREFIX: Output ssm_prefix
- CLIENT_URL: https://dev.ideategudy.tech
- SERVER_URL: https://dev.ideategudy.tech

Step 3: Trigger Automated Build & Deployment

Push your updates to the repository:

git add .
git commit -m "Deploy production architecture to AWS"
git push origin main

Figure 3: Parallel CI/CD execution for deploy-frontend and deploy-backend jobs.

🎉 Live Application Demo

Figure 4: The live full-stack application running on https://dev.ideategudy.tech served securely over CloudFront HTTPS.

⚡ Key Benefits & Architectural Trade-Offs

🟢 Key Benefits

Choosing this cloud setup over monolithic single-server hosting provides several high-value production advantages:

🚀 Zero-Downtime & Ultra-Fast Global Delivery:
By hosting the React SPA on Amazon S3 + CloudFront, static assets are cached globally at edge locations close to users. CloudFront delivers lightning-fast page loads while shielding your backend EC2 instances from static file requests.
💰 Extreme Cost Optimization (Free Tier Friendly):
- S3 & CloudFront: Nearly zero cost for static SPA bandwidth.
- EC2 Auto Scaling: Scales t3.micro instances based on CPU utilization and traffic demands without paying for oversized idle instances.
- Amazon ECR Lifecycle Policies: Configured to auto-expire old image tags, keeping container storage well under free-tier limits.
🔒 Enterprise-Grade Keyless Security (OIDC):
By avoiding permanent AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY credentials in GitHub Secrets, your deployment security posture is greatly hardened. GitHub Actions requests temporary, short-lived IAM credentials via OIDC scoped strictly to the resources it needs.
🛡️ High Availability & Auto-Healing:
The Application Load Balancer (ALB) and Auto Scaling Group (ASG) automatically monitor EC2 instance health. If an instance crashes or fails health checks, ASG automatically terminates it and launches a fresh, containerized replacement instance seamlessly.
📦 Modular & Multi-Environment Ready:
The modular Terraform layout (vpc, backend, frontend, github_oidc) makes it effortless to spin up separate dev, staging, and production environments in minutes with zero manual AWS Console clicking.

⚠️ Architectural Trade-Offs & Considerations

No cloud architecture is silver bullet. Understanding the trade-offs helps you decide when to choose this pattern over alternatives:

Initial Setup Complexity vs. Single-Server EC2:
- Trade-off: Setting up S3, CloudFront OAC, ALB, Target Groups, ACM SSL, and OIDC requires more initial Terraform code than launching a single EC2 instance running Docker Compose + Nginx.
- Mitigation: The modular Terraform structure (modules/) abstracts away this complexity so it only needs to be written once.
Cold Start / Provisioning Time for New EC2 Instances:
- Trade-off: When ASG scales up a new instance, the user-data script installs Docker, pulls the image from ECR, and fetches SSM parameters before serving traffic (~2–3 minutes).
- Mitigation: Setting api_min_size = 1 ensures at least one instance is always warm and ready. For even faster scaling, custom pre-built AMIs (via Packer) can be used.
CloudFront Cache Invalidation Lag:
- Trade-off: Updating the React SPA requires invalidating CloudFront caches (/*), which takes ~30–60 seconds to propagate across all edge locations worldwide.
- Mitigation: Automated in the CI/CD pipeline (aws cloudfront create-invalidation) so developers don't have to trigger it manually.
Stateful Session Management (Sticky Sessions):
- Trade-off: Because requests are load-balanced across multiple EC2 instances by the ALB, the backend API must remain stateless.
- Mitigation: Authentication is handled using stateless JWT tokens and external MongoDB storage rather than in-memory server sessions.

🎯 Conclusion

Building cloud infrastructure using modular Terraform modules and automated keyless CI/CD pipelines transforms complex AWS operations into predictable, repeatable, and maintainable software engineering workflows.

By decoupling the architecture into public VPC subnets, S3/CloudFront SPA hosting, and auto-scaling EC2 container fleets, the application stays fast, cost-optimized, and resilient.

🔗 Related Documentation & Alternative Architecture

Looking for a simpler, single-server EC2 deployment pattern? Check out the companion article:

👉 How I Built and Deployed a Full-Stack MERN App on AWS EC2 using Docker Compose, Terraform, and GitHub Actions

This guide covers deploying the full-stack MERN application on a single AWS EC2 instance using Docker Compose, Nginx reverse proxy, Certbot (Let's Encrypt SSL), and SSH-based GitHub Actions CI/CD.

🤝 Connect & Follow Me

If you found this guide helpful or have any questions about AWS, Terraform, Docker, or MERN stack architecture, let us connect!

🐙 GitHub: github.com/ideateGudy
💼 LinkedIn: linkedin.com/in/ideategudy
🗃️ Source Code: github.com/ideateGudy/terraform-docker-compose-ci-cd-mern-aws-deploy

Drop a reaction on Dev.to and feel free to star the GitHub repository! Happy coding! 🚀

How I Built and Deployed a Full-Stack MERN App on AWS EC2 using Docker Compose, Terraform, and GitHub Actions 🚀

Goodnews Azonubi — Fri, 11 Sep 2026 12:53:53 +0000

Building a full-stack web application from scratch is an exciting journey—from writing clean React components and Express REST APIs to persisting data in MongoDB. However, taking that application from your local machine and deploying it securely to production with HTTPS, custom domains, and automated CI/CD can often feel daunting.

In this tutorial, I will walk you through how I built an end-to-end full-stack MERN application and deployed it to AWS EC2 using Terraform (Infrastructure as Code), Docker Compose, Nginx Reverse Proxy, Let's Encrypt (Certbot) for free HTTPS, and GitHub Actions for push-to-deploy CI/CD.

Whether you're a beginner learning full-stack development and DevOps or a developer looking for a reproducible cloud deployment pattern, this guide covers the entire end-to-end workflow! 🛠️

📱 What is This Project? (Application Overview)

This is a complete full-stack personal diary & management application built from scratch using the MERN stack:

React SPA Frontend (client): Built with React & Vite. Features interactive diary entry logging, authentication state management, responsive UI, and custom URL shortener views. It is packaged with an optimized Nginx multi-stage Docker build.
Node.js & Express API Backend (server): Lightweight RESTful API supporting JWT user authentication (Access & Refresh tokens), diary management endpoints, and URL redirection logic.
MongoDB Database (mongo): Containerized MongoDB instance for persistent storage of users, diary logs, and link analytics.

📋 Prerequisites & Tools Required

Before we begin, ensure you have the following installed and set up on your machine:

Git: Version control system to manage project code.
Docker & Docker Desktop: To build and test containerized services locally.
AWS CLI: Configured with IAM credentials (aws configure).
Terraform CLI (v1.16.2 or higher): To provision AWS infrastructure declaratively.
AWS Account: An active AWS account with permissions to launch EC2, VPC, Security Groups, and Elastic IPs.
Custom Domain Name: (Optional but recommended) A domain name pointing to AWS (e.g. from Namecheap, Cloudflare, GoDaddy).

🏛️ High-Level System Architecture

Here is how all the moving parts work together once deployed on AWS:

                       ┌────────────────────────────────────────────────────────┐
                       │                   AWS EC2 Instance                     │
                       │                                                        │
                       │    ┌──────────────────────────────────────────────┐    │
                       │    │             Nginx Container (client)         │    │
  User Browser         │    │           Exposes Ports 80 / 443             │    │
┌─────────────┐        │    │                                              │    │
│  HTTP /     ├───────►│    │ - Serves built React SPA frontend            │    │
│  HTTPS      │        │    │ - Reverse proxies /api and /s/ to backend    │    │
└─────────────┘        │    └──────────────────────┬───────────────────────┘    │
                       │                           │                            │
                       │                           ▼                            │
                       │    ┌──────────────────────────────────────────────┐    │
                       │    │         Node.js Express Server (server)      │    │
                       │    │              Internal Port 3000              │    │
                       │    └──────────────────────┬───────────────────────┘    │
                       │                           │                            │
                       │                           ▼                            │
                       │    ┌──────────────────────────────────────────────┐    │
                       │    │               MongoDB (mongo)                │    │
                       │    │            Internal Port 27017               │    │
                       │    └──────────────────────────────────────────────┘    │
                       └────────────────────────────────────────────────────────┘

Key Architectural Highlights:

Nginx (Frontend Container): Listens on standard public ports 80 (HTTP) and 443 (HTTPS). It serves the production React build and acts as a reverse proxy, forwarding /api/ traffic to the backend server.
Node.js Express (Backend Container): Communicates internally over Docker's bridge network (port 3000). It is not directly exposed to the public internet, adding a layer of security.
MongoDB (Database Container): Persists application state internally (port 27017) using Docker named volumes.

📁 Repository Structure Overview

Here is the clean layout of our project repository:

.
├── client/                     # React Frontend Application (Vite + Nginx Dockerfile)
│   ├── Dockerfile              # Multi-stage build (Node build -> Nginx runtime)
│   ├── nginx.conf              # Production Nginx reverse proxy configuration (SSL HTTPS)
│   └── nginx.local.conf        # Local development Nginx configuration (HTTP localhost)
├── server/                     # Node.js Express Backend API
│   └── Dockerfile              # Lightweight Node 22 Alpine container build
├── terraform/                  # Terraform IaC Infrastructure Code
│   ├── main.tf                 # Root Terraform entry point
│   ├── variables.tf            # Variable definitions
│   ├── outputs.tf              # Server Public IP, Domain & SSH output definitions
│   └── modules/ec2/            # EC2 module (Instance, Security Group, EIP, UserData)
├── .github/workflows/
│   └── deploy.yml              # GitHub Actions automated SSH deployment pipeline
├── docker-compose.yml          # Multi-container production orchestration config
├── docker-compose.override.yml.example # Local HTTP development override template
└── .env.example                # Sample environment variables reference

🚀 Step-by-Step Deployment Walkthrough

Step 1: Local Development & Container Verification

First, verify that your multi-container application runs smoothly on your local machine using Docker Compose:

# 1. Clone the repository
git clone https://github.com/ideateGudy/deploy-list.git
cd deploy-list

# 2. Copy sample environment file
cp .env.example .env

# 3. Enable local HTTP development config (bypasses SSL cert check on localhost)
cp docker-compose.override.yml.example docker-compose.override.yml

# 4. Build and launch containers locally
docker compose up -d --build

💡 How Local vs Production Works: Creating docker-compose.override.yml tells Docker to use nginx.local.conf so your app runs on http://localhost without expecting SSL certificates. Since docker-compose.override.yml is in .gitignore, it will not be pushed to EC2. On EC2, Docker Compose automatically falls back to nginx.conf with full Let's Encrypt HTTPS support!

You can test your application locally at:

Frontend SPA: http://localhost
Backend API: http://localhost/api/auth/
Health Check: http://localhost/healthz

Figure 1: Docker Desktop showing all three containers (diary-mongo, diary-server, and diary-client) running green and healthy.

Figure 2: The full-stack application running live in browser on http://localhost.

Step 2: Provision Infrastructure using Terraform (IaC)

Instead of manually clicking through the AWS Console, we use Terraform to provision an EC2 instance, an Elastic IP (static IP), Security Groups (firewall rules), and install Docker via automated user_data scripts.

1. Configure AWS CLI & Security Key Pair

Make sure your AWS CLI is authenticated and generate an AWS EC2 Key Pair (e.g. ann_notch or diary-app-key).

2. Provision with Terraform

# Navigate to terraform directory
cd terraform

# Create your tfvars configuration file
cp terraform.tfvars.example terraform.tfvars

Edit your terraform.tfvars:

aws_region       = "eu-north-1"
environment      = "prod"
instance_type    = "t3.micro"
key_name         = "ann_notch"            # Your AWS SSH Key Pair name
allowed_ssh_cidr = "0.0.0.0/0"
ami_id           = "ami-0aba19e56f3eaec05" # Ubuntu 26.04 LTS (amd64)
domain_name      = "ideategudy.tech"

Initialize and apply the Terraform configuration:

terraform init
terraform apply -auto-approve

Once complete, Terraform will output your server_public_ip (Elastic IP) and domain_name. Keep these outputs handy!

Step 3: Configure Custom Domain & DNS Records (Optional but Recommended)

To make your application accessible at a real domain (e.g., ideategudy.tech) and issue SSL certificates:

Go to your Domain Registrar DNS settings.
Create an A Record: Name @ $\rightarrow$ Value <YOUR_SERVER_PUBLIC_IP>.
Create a CNAME Record: Name www $\rightarrow$ Value ideategudy.tech.
Verify DNS propagation:

   nslookup ideategudy.tech 8.8.8.8

Step 4: Configure GitHub Repository Secrets & Variables

To enable seamless, zero-downtime CI/CD deployment on every code push, navigate to your GitHub Repository:
Settings > Secrets and variables > Actions

💡 Tip for Beginners: You can retrieve all your Terraform output values (like your EC2 Public IP) anytime by running terraform output inside the terraform/ folder!

Add the following Repository Secrets:

Secret Name	Value / Description
`EC2_HOST`	Public Elastic IP address from Terraform output
`EC2_USERNAME`	`ubuntu`
`EC2_SSH_KEY`	Entire private SSH key contents (`.pem` file)
`MONGODB_URI`	`mongodb://mongo:27017/diarydb`
`ACCESS_TOKEN_SECRET`	Secure random secret string for JWT access
`REFRESH_TOKEN_SECRET`	Secure random secret string for JWT refresh

Add the following Repository Variable:

Variable Name	Value / Description
`DOMAIN_NAME`	`ideategudy.tech` (or your domain name)

Step 5: Automated Deployment via GitHub Actions CI/CD

Our repository includes .github/workflows/deploy.yml.

💡 Note for Beginners: You do not need to manually SSH into your server or build Docker containers on your local computer before pushing! When you push code to GitHub, GitHub Actions automatically connects to your EC2 server, pulls the latest code, issues SSL certificates, and restarts your application containers in the cloud.

When you push changes to the main branch:

GitHub Actions connects securely to your EC2 server via SSH.
It pulls the latest code.
It updates environment variables (.env).
It executes Certbot to issue/renew free Let's Encrypt SSL certificates automatically.
It runs docker compose up -d --build to re-deploy updated containers with zero downtime.

To trigger your deployment:

git add .
git commit -m "Deploy fullstack application to production"
git push origin main

Head over to the Actions tab in GitHub to watch your deployment complete in real-time! ⚡

Step 6: Live Production Verification & Secure HTTPS

Once the GitHub Actions workflow completes successfully, open your browser and navigate to your production domain:

Deployed App (HTTPS): https://ideategudy.tech

❓ Troubleshooting & Common Gotchas

If something doesn't work on your first try, don't worry! Here are the most common hiccups beginners face and how to fix them:

SSH Connection Timeout in GitHub Actions:
- Cause: Security Group blocking SSH or wrong IP.
- Fix: Ensure allowed_ssh_cidr = "0.0.0.0/0" in terraform.tfvars and check that EC2_HOST secret matches your Terraform output IP.
Certbot / SSL Failure:
- Cause: DNS record has not fully propagated before pushing to GitHub Actions.
- Fix: Run nslookup yourdomain.com first to confirm your domain resolves to your EC2 IP before triggering the workflow.
MongoDB Connection Failed:
- Cause: Containers starting out of order or invalid URI.
- Fix: Make sure MONGODB_URI in GitHub Secrets is set to mongodb://mongo:27017/diarydb (using the container service name mongo).

🛡️ Production Best Practices Implemented

IMDSv2 Enforced: AWS Instance Metadata Service v2 required for enhanced EC2 protection (http_tokens = "required").
EBS Volume Encryption: Server storage volume (gp3) encrypted by default.
Log Management: Docker container logging capped at 10MB per file to prevent disk exhaustion.
Enhanced Security Headers: Nginx configured with X-Frame-Options, X-Content-Type-Options, and server_tokens off.

⚡ Key Benefits of This Architecture

Choosing this containerized single-server deployment architecture provides several high-value advantages for developers and small-to-medium applications:

💰 Cost Efficiency (AWS Free Tier Friendly):
By running Nginx, Node.js Express, and MongoDB inside a single containerized t3.micro EC2 instance with an Elastic IP, you eliminate the overhead of paying for managed load balancers (ALBs) or separate database instances (RDS) during initial rollout or MVP stages.
🔒 Enhanced Security & Internal Networking:
- Internal Docker Bridge: Backend API (port 3000) and MongoDB (port 27017) are isolated on internal Docker networks and not exposed directly to the internet.
- Nginx Reverse Proxy: Shields application servers by acting as the sole entry point, handling request routing, rate limiting, and SSL termination.
🔁 Clean Dev-to-Prod Parity with Docker Compose:
The exact same docker-compose.yml file used for local development runs in production. This eliminates the classic "it works on my machine" bugs by ensuring identical runtimes across development and cloud environments.
🚀 Automated Reproducibility (Infrastructure as Code):
With Terraform, your entire cloud infrastructure (EC2, VPC, Security Groups, Elastic IP) is defined declaratively as code. Re-creating or destroying your environment requires just a single command (terraform apply or terraform destroy).
⚡ Frictionless Push-to-Deploy CI/CD:
The GitHub Actions SSH workflow completely automates the release cycle. Every code push automatically updates code, manages SSL certificates via Certbot, and builds updated containers with zero manual server maintenance required.

🎯 Conclusion

Congratulations! 🥳 You've built and deployed a production-ready, containerized full-stack application on AWS!

Here is a quick recap of what we accomplished:

Orchestrated local multi-container environments using Docker Compose.
Automated cloud infrastructure provisioning using Terraform.
Established secure reverse-proxying and routing with Nginx.
Automated SSL HTTPS certificate generation via Let's Encrypt & Certbot.
Built a push-to-deploy CI/CD pipeline using GitHub Actions.

Infrastructure-as-Code and containerization give you complete confidence that your deployment is reproducible, maintainable, and scalable.

🔗 Related Documentation & Alternative Architecture

Looking for an enterprise-grade, multi-environment AWS deployment pattern? Check out the companion article:

👉 How I Built and Deployed a Full-Stack MERN Application on AWS using Modular Terraform and Keyless GitHub Actions OIDC

This guide covers an advanced deployment architecture featuring S3 static site hosting, CloudFront CDN, Application Load Balancers (ALB), EC2 Auto Scaling Groups (ASG), Amazon ECR, and keyless deployments with GitHub Actions OIDC.

🤝 Connect & Follow Me

If you found this guide helpful, hit the ❤️ button, bookmark it for later, and feel free to connect with me!

🐙 GitHub: github.com/ideateGudy
💼 LinkedIn: linkedin.com/in/ideategudy

Got questions or run into issues? Drop a comment below—I'd love to help out! Happy coding! 🚀

Build Smart AI Agents with Mastra and TypeScript (Integrating with Telex.im)

Goodnews Azonubi — Sat, 01 Nov 2025 22:15:28 +0000

Introduction

Ever wish there was a smarter way to search for tech jobs? I built an AI agent that understands natural language queries like "Find me 5 latest Flutter jobs" and returns relevant postings from public job feeds.

This isn't a tutorial on how to build agents from scratch. Instead, I'm walking you through how this specific project works, the Mastra features I used, and how I integrated it with Telex.im — an AI agent platform like Make (you can also think of it as a Slack alternative for education, communities, or bootcamps).

Telex:

Live agent on Telex: Tech Jobs Agent

The agent workflow is simple but practical:

User asks: "Show me remote backend roles"
Agent extracts keywords: ['backend', 'remote']
Agent calls a tool that searches cached RSS feeds
Tool returns ranked, deduplicated jobs
Agent formats results for the user

You'll need Node.js 18+, an OpenAI API key, and comfort reading TypeScript. We're not reinventing the wheel here—just building on top of some solid libraries.

What You'll Need

Before diving in, have these ready:

Node.js 18+ and npm
An OpenAI API key (get one at https://platform.openai.com/)
Basic TypeScript (don't need to be expert—just comfortable with types)

If you've never used Mastra before, that's fine. I'll explain the key pieces as we go.

The Big Picture: How It All Fits Together

Imagine you're building a small app with AI. You don't just ask the AI a question and hope for the best. You:

Give it a tool it can use (in our case: "search these job feeds")
Give it strict instructions (in our case: "always use the tool, don't make stuff up")
Cache external data so you're not hammering RSS feeds every second
Validate everything with schemas so the code doesn't break

Here's the folder structure I'm working with:

src/mastra/
├── agents/
│   └── jobs-agent.ts       ← The agent + its instructions
├── tools/
│   └── rss-tool.ts         ← The "search jobs" tool
├── workflows/
│   └── jobs-workflow.ts    ← Compose steps that use the agent
├── utils/
│   ├── keyword-extractor.ts   ← Parse "Find 5 Flutter jobs"
│   ├── feed-cache.ts          ← Cache RSS data locally
│   └── feed-scheduler.ts      ← Auto-refresh feeds every 30 min
├── scorers/
│   └── jobs-scorer.ts      ← Grade agent responses
└── index.ts                ← Wire it all together

Don't worry about memorizing this. You'll see it in action.

Walking Through the Code: Step by Step

Step 1: The Agent Asks a Question

When a user types a query, it goes to the jobsAgent. Here's what that agent looks like:

export const jobsAgent = new Agent({
  name: 'Jobs Agent',
  description: "Fetches recent remote and tech-related job listings from public RSS feeds",
  instructions: `
You are a jobs search assistant. ALWAYS use the fetch-jobs tool to search for jobs.
Never make up job listings. If the tool returns 0 jobs, clearly state that no matches were found.
Format results with: Title, Company, Location, Description, Posted Date.
  `,
  model: 'openai/gpt-4o-mini',
  tools: { rssTool },
  memory: new Memory({
    storage: new LibSQLStore({
      url: 'file:../mastra.db',
    }),
  }),
});

Mastra Features Used

Agent: Defines the AI’s role, behavior, and model.
Tool: Lets the agent call external logic (RSS fetcher).
Memory: Persistent storage using LibSQLStore.
Scorers: Evaluate the agent’s performance after each response.
Workflows: Combine multiple steps (keyword extraction → tool call → response).

What's happening here:

We're creating an agent that uses GPT-4o-mini (a fast, cheap OpenAI model)
We give it strict instructions to always use the fetch-jobs tool (this prevents hallucination)
It can access a memory store to remember past conversations

The key insight: the instructions are very explicit. We don't say "maybe search for jobs." We say "ALWAYS use the fetch-jobs tool." This keeps the agent honest.

Step 2: Extracting Keywords

Before calling the tool, we need to extract what the user wants. If someone says "Find me 5 latest Flutter jobs," we extract:

Keywords: ['flutter']
Limit: 5
Location: maybe 'remote'

This happens in keyword-extractor.ts:

export function extractKeywords(input: string): string[] {
  const stopwords = new Set([
    "find","show","latest","remote","job","jobs","for","me","the",
    // ... 40+ more common words
  ]);

  const stemmer = natural.PorterStemmer;

  const words = input
    .toLowerCase()
    .replace(/[^\w\s+.#]/g, "")  // keep tech symbols like + and #
    .split(/\s+/)
    .filter(word => word.length > 2 && !stopwords.has(word))
    .map(word => stemmer.stem(word));  // "jobs" → "job", "running" → "run"

  return [...new Set(words)];  // remove duplicates
}

Breaking this down:

We remove "noise words" like "find", "show", "the" (these don't help find jobs)
We use a stemmer to reduce words to their root (so "Flutter", "flutter", "FLUTTER" all become "flutter")
We return only the meaningful keywords

Example:

Input: "Find 5 latest Flutter jobs"
Output: ['flutter']   // (removed: find, latest, jobs)

This is effective because job titles usually contain the tech you're searching for.

Step 3: The RSS Tool Tool Does the Heavy Lifting

The rssTool is where the magic happens. It's a Mastra tool, which means it has:

An input schema (what data it accepts)
An output schema (what it returns)
An execute function (what it actually does)

This Mastra tool performs the actual job search from cached RSS feeds.

export const rssTool = createTool({
  id: 'fetch-jobs',
  inputSchema: z.object({
    query: z.string().describe('e.g., "Flutter developer"'),
    limit: z.number().default(10),
  }),
  outputSchema: z.object({
    jobs: z.array(jobListingSchema),
    total: z.number(),
    query: z.string(),
  }),
  execute: async ({ context }) => {
    const { query, limit } = context;
    const keywords = extractKeywords(query);

    // Load all cached jobs from RSS feeds
    let allJobs = [];
    for (const feedUrl of rssFeeds) {
      const feedJobs = await fetchFeedWithCache(feedUrl);
      allJobs = allJobs.concat(feedJobs);
    }

    // Remove duplicates (same job posted to multiple feeds)
    const uniqueJobs = deduplicateJobs(allJobs);

    // Filter: only keep jobs that match keywords
    const matchedJobs = uniqueJobs.filter(job => {
      const title = job.title.toLowerCase();
      const desc = job.description.toLowerCase();
      return keywords.some(kw => title.includes(kw) || desc.includes(kw));
    });

    // Sort by relevance (title matches > description matches), then by date
    const sorted = matchedJobs
      .sort((a, b) => {
        const aScore = (a.title.toLowerCase().match(keywords[0]) ? 2 : 0);
        const bScore = (b.title.toLowerCase().match(keywords[0]) ? 2 : 0);
        return bScore - aScore;
      })
      .slice(0, limit);

    return {
      jobs: sorted,
      total: sorted.length,
      query,
    };
  },
});

What this does:

Takes your keywords and limit
Loads all cached job listings (from .cache/jobs, refreshed every 30 minutes)
Removes duplicates (a job might be posted to multiple feeds)
Filters to only jobs matching your keywords
Ranks by relevance (title matches are more important than description matches)
Returns the top N results

Notice: we don't fetch live RSS here. We use a cache. This is important because:

RSS feeds can be slow (5-10 second timeouts)
We'd hit rate limits if we fetched on every query
Users expect fast responses

Scorers in Mastra

Scorers are automated tests that evaluate Agents outputs using model-graded, rule-based, and statistical methods. It analyzes what the agent has produced and determines how relevant, accurate, or useful those outputs are to the agent’s goal or the user’s query. I have created 2 scorers for this project:

Keyword Relevance & Tool Selection:

Evaluates if the agent extracted relevant keywords from user input and selected the correct tool (rssTool) with appropriate parameters (query + limit). Returns 0-1 score.

Jobs Response Quality:

Evaluates how relevant, correct, and professionally toned a job-search assistant's response is. Returns a 0-1 score (higher is better).

Step 4: Feed Caching and Scheduling

The cache lives in .cache/jobs and stores raw job listings for ~4 hours. Here's how it works:

export async function fetchFeedWithCache(feedUrl: string): Promise<CachedJob[]> {
  // Try cache first
  const cached = await loadFromCache(feedUrl);
  if (cached !== null) {
    return cached;  // Cache hit! Return instantly
  }

  // Cache miss: fetch live, then save
  try {
    const response = await axios.get(feedUrl, { timeout: 8000 });
    const feed = await parseFeed(response.data);

    const jobs = feed.items.map(item => ({
      title: item.title || 'No title',
      link: item.url || '',
      description: item.description?.substring(0, 500) || 'No description',
      pubDate: item.published?.toISOString(),
      source: feedUrl,
    }));

    // Save to cache for next time
    await saveToCache(feedUrl, jobs);
    return jobs;
  } catch (error) {
    console.error(`Failed to fetch ${feedUrl}:`, error.message);
    return [];  // Return empty list, don't crash
  }
}

Why this matters:

First request for a feed? We fetch and parse the RSS (takes 2-3 seconds)
Follow-up requests within 4 hours? We serve from cache (instant)
After 4 hours? We refresh from live feeds again

Step 5: Auto-Refresh with a Scheduler

We don't want stale data. So every 30 minutes, we automatically refresh all feeds:

export function startFeedScheduler(intervalMinutes: number = 30): void {
  if (isSchedulerActive) return;

  const cronExpression = `*/${intervalMinutes} * * * *`;  // */30 = every 30 min

  cron.schedule(cronExpression, async () => {
    const result = await refreshAllFeeds();
    console.log(`Refreshed: ${result.refreshed} feeds, Failed: ${result.failed}`);
  });

  isSchedulerActive = true;
}

How it works:

Uses node-cron to schedule a background job
Every 30 minutes, it refreshes to see if the 4 hours interval has elapsed so it can fetch new feeds and updates the cache
If a feed fails, we catch the error and continue (don't crash the app)
This happens in the background—users don't wait for it

Step 6: Validation with Zod

Every tool and workflow uses Zod schemas. This is important because TypeScript types disappear at runtime, but Zod validates at runtime:

const jobSchema = z.object({
  title: z.string(),
  link: z.string(),
  description: z.string(),
  pubDate: z.string().optional(),
  source: z.string(),
});

const jobSearchResult = z.object({
  jobs: z.array(jobSchema),
  total: z.number(),
  query: z.string(),
});

Why this matters:

If something returns bad data, Zod will catch it
The agent can't accidentally pass malformed data downstream
You get helpful error messages instead of mysterious crashes later

Actually Running This Thing

Let's get it working locally first:

npm install
npm run dev

This starts a dev server on http://localhost:4111/ with a web playground. Go there, select jobsAgent from the dropdown, and try typing:

Find 5 latest Flutter jobs

You'll see the agent:

Extract "flutter" as the keyword
Search the cached jobs
Return formatted results with links

For production, build it:

npm run build

This creates .mastra/output with all the bundled code, and tells you how to start it:

node --import=./.mastra/output/instrumentation.mjs .mastra/output/index.mjs

Environment Setup

Create a .env file in the project root:

OPENAI_API_KEY=sk-your-key-here

That's it. Everything else has sensible defaults.

How to Extend This project

Add a New Tool

Say you want a tool that looks up company data. Here's the pattern:

// src/mastra/tools/company-lookup.ts
import { createTool } from '@mastra/core/tools';
import { z } from 'zod';

export const companyLookupTool = createTool({
  id: 'lookup-company',
  description: 'Get details about a company',
  inputSchema: z.object({
    companyName: z.string(),
  }),
  outputSchema: z.object({
    name: z.string(),
    foundingYear: z.number(),
    description: z.string(),
  }),
  execute: async ({ context }) => {
    const { companyName } = context;
    // Call your API or database
    return {
      name: companyName,
      foundingYear: 2020,
      description: 'A cool company',
    };
  },
});

Then register it in src/mastra/index.ts:

import { companyLookupTool } from './tools/company-lookup.js';

// In the mastra config:
agents: {
  jobsAgent: new Agent({
    // ...
    tools: { rssTool, companyLookupTool },  // ← Add here
  }),
},

Add a New Agent

Same idea—create the agent, give it strict instructions, register it:

// src/mastra/agents/recruiter-agent.ts
export const recruiterAgent = new Agent({
  name: 'Recruiter Agent',
  instructions: `You help recruiters find candidates. Use the lookup-company and fetch-jobs tools.`,
  model: 'openai/gpt-4o-mini',
  tools: { companyLookupTool, rssTool },
  // ... memory, scorers, etc
});

Then in index.ts:

agents: {
  jobsAgent,
  recruiterAgent,  // ← Add here
},

Add Observability

The scorers are already set up to grade agent responses. But you can log what happened:

const response = await jobsAgent.generate("Find Flutter jobs");
console.log(`Agent response:`, response.text);
console.log(`Tool called:`, response.toolResults?.length);
console.log(`Artifacts:`, response.artifacts);

What I Learned

1. Explicit instructions matter more than model size. A cheap model with crystal-clear instructions ("ALWAYS use this tool, NEVER make up jobs") beats a fancy model with vague instructions every time.

2. Cache external data aggressively. RSS feeds are slow and unreliable. Caching with a 4-hour TTL means users get instant responses after the first request.

3. Zod schemas reduce integration bugs. Catching bad data at the tool boundary prevents cascading failures downstream.

4. Schedulers are better than webhooks. Periodic refresh via cron is simpler than trying to monitor feed changes.

Next Steps

Now that you understand how this works, try:

Add more feeds to src/mastra/data/rss-feeds.ts
Improve keyword extraction using embeddings or NER instead of keyword matching
Add company metadata by looking up each job's company in a database
Deploy to production using the build output

Github Repo

References

Mastra docs: https://docs.mastra.ai
@rowanmanning/feed-parser: https://www.npmjs.com/package/@rowanmanning/feed-parser
natural (PorterStemmer): https://www.npmjs.com/package/natural
Zod validation: https://zod.dev
node-cron: https://www.npmjs.com/package/node-cron

Flutter’s UI Architecture Explained for Beginners: Widgets, Elements, and Render Objects

Goodnews Azonubi — Tue, 28 Oct 2025 21:04:23 +0000

Flutter Basics

Flutter Basics Overview
Prerequisites
- What is Flutter?
- Dart
- Declarative UI / Reactive Programming
- Multiplatform Development
- What exactly is State?
The Widget Tree in Flutter
- Key Components of the Widget Tree
  - Main Function
  - Cupertino vs Material Widgets
- Flutter Rendering and UI Architecture
Difference between Stateless & Stateful widgets
Stateful Widget Lifecycle
- How setState() triggers UI rebuilds
Text Changer App Example
Summary

Flutter Basics Overview

Prerequisites:

Basic understanding of dart programming language
Flutter installed on your system
Android studio and Xcode(for Mac)

What is Flutter?

Flutter is a declarative, reactive open-source, multiplatform UI toolkit developed by Google. It allows developers to build natively compiled applications for mobile, web, and desktop from a single codebase. Flutter uses the Dart programming language and provides a rich set of pre-designed widgets to create beautiful and responsive user interfaces.

Flutter developers often hear terms like everything in Flutter is a widget, and this is because Flutter's UI is built using a hierarchy of widgets called the widget tree. Widgets are the building blocks of a Flutter app's user interface, and they can be combined to create complex UIs.

Dart

Dart is an open-source client-optimized programming language developed by Google that compiles to the native machine code of the target platform without runtime overhead leading to fast startup times and predictable performance. It is designed to be easy to learn and use, with a syntax that is similar to other popular programming languages like Java, JavaScript, and C#. Dart is the primary language used for developing Flutter applications.

Declarative UI / Reactive Programming

Flutter uses a declarative approach: you simply describe what the UI should look like for a given state (like color: blue). The framework then uses reactive programming to automatically react to state changes and rebuild the UI efficiently.

Multiplatform Development

Multiplatform development refers to the ability to create applications that can run on multiple platforms using a single codebase. Flutter enables developers to build applications for iOS, Android, web, and desktop platforms using the same codebase, which significantly reduces development time and effort.

What exactly is State?

Now you may wonder what state is. In simple terms, state refers to the data or information that determines the behavior and appearance of a widget at a given time. For example, the state of a button widget may include whether it is enabled or disabled, its color, and its text label.

In Flutter, state can be managed in various ways, including using built-in stateful widgets, provider packages, or other state management solutions. The choice of state management technique depends on the complexity of the application and the specific requirements of the project.

The Widget Tree in Flutter

Now, as the interface of an application is built using widgets, those widgets are combined to create a widget tree. The widget tree is a hierarchical structure that represents the relationship between different widgets in the application. Each widget in the tree can have its own state, which can be updated and managed independently.

When the state of a widget changes, Flutter automatically rebuilds the affected parts of the widget tree to reflect the new state. This is done using a process called rebuilding, which involves creating a new instance of the widget with the updated state and replacing the old instance in the widget tree.

This process is efficient and allows for smooth and responsive user interfaces, as only the affected parts of the widget tree are rebuilt, rather than the entire tree which facilitates the hot reload feature in Flutter.

Key Components of the Widget Tree

The widget tree is structured in a hierarchical manner, with each widget having a parent-child relationship with other widgets. The root of the tree is typically the MaterialApp or CupertinoApp widget, which serves as the entry point for the application. From there, other widgets are added as children of the root widget, forming a tree-like structure.

Main Function

The main function is the entry point of a Flutter application. It is where the execution of the app begins. In the main function, we typically call the runApp function, which takes a widget as an argument and inflates it to fill the screen.

Cupertino vs Material Widgets

Flutter provides two sets of pre-designed widgets: Material widgets and Cupertino widgets. Material widgets are designed to follow the Material Design guidelines developed by Google, while Cupertino widgets are designed to follow the iOS design guidelines developed by Apple. Depending on the target platform, developers can choose to use either set of widgets or a combination of both to create a consistent user experience across different platforms.

Flutter Rendering and UI Architecture

Flutter initially renders the UI using skia, a 2D graphics rendering engine. Skia is responsible for drawing the UI elements on the screen, and it provides a high-performance rendering pipeline that allows for smooth animations and transitions. But with the release of Flutter 3.0, Flutter introduced a new rendering engine called Impeller, which is designed to provide even better performance and visual fidelity. Impeller is a next-generation rendering engine that leverages modern graphics APIs like Metal on iOS and Vulkan on Android to deliver high-quality graphics and smooth animations.

Flutter's rendering and UI architecture is primarily built upon three main trees:

Widget Tree: The widget tree is the hierarchical structure of widgets that make up the user interface of a Flutter application. Each widget in the tree represents a specific UI element, such as a button, text field, or image. The widget tree is responsible for defining the layout and appearance of the UI.
Element Tree: The element tree is a lower-level representation of the widget tree. It consists of Element objects, which are created for each widget in the widget tree (Like a copy of the widget). The element tree is responsible for managing the lifecycle of widgets, including their creation, updating, and destruction. It also handles the communication between widgets and their associated state.
Render Tree (or RenderObject Tree):: The render tree is the final representation of the UI that is used for painting on the screen. It consists of RenderObject instances, which are responsible for the actual layout and painting of the UI elements. The render tree is built from the element tree and is optimized for performance and efficiency during the rendering process.

In summary,

The Widget is the structural description of the UI (Blueprint). it is the immutable description of what the UI should look like and provides configuration and hierarchy.
The Element is the mutable brain that manages the lifecycle of the widget and holds the state. It acts as a bridge between the widget and the render object. Determines what needs to be updated when the widget's state changes.
The Render Object is the Builder/Artist that is responsible for the actual layout and painting(drawing pixels) of the UI on the screen. It takes care of measuring, positioning, and drawing the visual representation of the widget.

The interaction between these three trees is crucial for the efficient rendering of the UI in Flutter. When a widget's state changes, Flutter updates the widget tree, which in turn updates the element tree and the render tree. This process ensures that only the affected parts of the UI are redrawn, leading to smooth and responsive user interfaces.

Difference between Stateless & Stateful widgets

The widget tree can be broadly categorized into two types of widgets based on their ability to manage state:

Stateless Widgets: These are widgets that do not maintain any state. Once built, their appearance and behavior are fixed and cannot change. Stateless widgets are typically used for static content that does not require user interaction or dynamic updates.
Stateful Widgets: These are widgets that can maintain state over time. They can rebuild themselves when their state changes, allowing for dynamic and interactive user interfaces. Stateful widgets are used for content that needs to change in response to user input or other events.

Other kinds of widgets include:

Inherited Widgets: These widgets allow data to be passed down the widget tree efficiently. They are used for sharing data between widgets without the need for explicit passing through constructors. examples include Theme and MediaQuery.

Stateful Widget Lifecycle (initState, dispose)

Stateful widgets have a lifecycle that consists of several stages, each represented by specific methods that can be overridden to perform actions at different points in the widget's life. The key lifecycle methods of a stateful widget are:

createState(): This method is called when the stateful widget is first created. It returns an instance of the associated State class, which holds the mutable state for the widget.
initState(): This method is called after the stateful widget is created and before the widget is built for the first time. It is used to perform any initializations that are required for the state.
didChangeDependencies(): Called immediately after initState(), but before the widget is built for the first time. It's also called when an InheritedWidget that this State depends on changes. It is often a good place to initialize data that depends on the BuildContext (like Theme.of(context)), as initState() may be too early.
build(): This method is called whenever the widget needs to be rebuilt, either due to a change in state or when the parent widget rebuilds. It returns the widget tree that represents the UI of the stateful widget.
setState(): (Triggered by you) This method is used to notify the framework that the state of the widget has changed and that it needs to be rebuilt. The image above illustrates how calling setState() leads to the invocation of the build() method, when the user hits enter after inputing a city name in the TextField. it fetches new weather data and updates the UI accordingly.
didUpdateWidget(): This method is called whenever the parent widget rebuilds and passes new configuration data down to the child stateful widget. It allows the state to respond to changes in the widget's properties by passing the updated stateful widget as a parameter.
deactivate(): This method is called when the State object is removed from the Element tree, but before it is disposed. This might happen temporarily if the widget is moved to a different part of the tree.
dispose(): This is called after deactivate() when the State object is permanently removed from the tree. This is the last method called, and it's essential to use it for cleanup (e.g., canceling timers, unsubscribing from streams, disposing of controllers) to prevent memory leaks. The image above shows the dispose() method being called when the StatefulWidget which is a TextFormField controller is removed from the widget tree after a user submits a form. This ensures that resources are properly released and prevents memory leaks.

How setState() triggers UI rebuilds

The setState() method is a crucial part of the stateful widget lifecycle in Flutter. When you call setState(), you are indicating to the Flutter framework that the internal state of the widget has changed and that the widget needs to be rebuilt to reflect those changes in the UI.
When setState() is called, the following sequence of events occurs:

The callback function passed to setState() is executed, allowing you to update the state variables of the widget.
After the state has been updated, Flutter marks the widget as needing to be rebuilt.
The framework schedules a rebuild of the widget tree, starting from the stateful widget that called setState().
During the rebuild process, the build() method of the stateful widget is called, which constructs a new widget tree based on the updated state.
The framework compares the new widget tree with the previous one and determines which parts of the UI need to be updated.
Finally, the framework updates the UI by redrawing only the affected parts of the widget tree, resulting in a smooth and efficient update to the user interface.

Text Changer App Example

Click Here to view the Text Changer App Explanation.

Summary

In summary, the three trees in Flutter's rendering architecture work together to create a responsive and efficient UI. The widget tree defines the structure and appearance of the UI, the element tree manages the lifecycle and state of the widgets, and the render tree is responsible for the actual painting of the UI on the screen. Understanding these trees and their interactions is key to building performant Flutter applications.

Dynamic Profile Endpoint (Express/Nodejs/Typescript)

Goodnews Azonubi — Sat, 18 Oct 2025 14:20:00 +0000

Here’s a walkthrough of my experience building the “Dynamic Profile Endpoint” (GET /me) for the HNG Internship  Stage 0 task — using TypeScript, Express, and integrating with the Cat Facts API.

The Core Objective: Dynamic Profile Endpoint

The primary goal was to create a single endpoint that returns static profile data combined with real-time, dynamic data fetched from a third-party service.

Key goals:

Use TypeScript to have typed safety and clearer code.
Use Express for the HTTP server.
Add security (helmet), CORS, logging, rate-limiting.
Clean separation: routes, controller, middleware, error handler.

Fetch a live fact (from cat fact api when serving the /me endpoint.

Provide a well‑structured JSON response including status, user info, timestamp, fact.

Endpoint Requirements:

Method: GET
URL: /me
Response: A JSON object containing static user details (name, email, stack), timestamp to show current time the request was made and a dynamic field (fact) fetched from The Cat Facts API.
Success Status: HTTP/1.1 200 OK.

🧠 What I Built

The task required building an HTTP GET /me endpoint that returns:

My profile (name, email, stack)
A dynamic cat fact (from CatFact Ninja)
A timestamp of the request
A consistent JSON response structure

To meet these requirements, I used:

TypeScript: for static typing and better developer experience
Express.js: for building the get /me endpoint
Axios: for HTTP requests to the Cat Facts API
Helmet & CORS: to secure HTTP headers and allow cross-origin requests
Rate limiting middleware: to prevent abuse
Custom error & logging middleware

🗂 Project Structure

├── controllers/
│   └── profile.controller.ts     # Business logic for the /me endpoint
├── middlewares/
│   ├── errorHandler.ts           # Global error handling middleware
│   ├── logging.ts                # Logging middleware
│   └── rate-limiting.ts          # Rate limiting middleware
├── routes/
│   └── profile.routes.ts         # Defines the GET /me endpoint
├── types/
│   └── profile.ts                  # TypeScript interfaces and types
├── utils/
│   └── apiError.ts                # Custom reusable error class
├── .env                          # Environment variables
├── index.ts                      # Main application entry point
├── package.json
└── tsconfig.json

⚙️ Setup & Running Locally

1. Clone the Repository

git clone https://github.com/ideateGudy/Dynamic-Profile-Endpoint.git
cd Dynamic-Profile-Endpoint

2. Install Dependencies

npm install

3. Create .env File

In the root directory, create a .env file and add the following:

PORT=3000
NODE_ENV=development
CATFACT_BASE_URL=https://catfact.ninja

4. Start the Server

Development mode (auto-restart with file changes):

npm run dev

Production build:

npm run build

Run compiled JS:

npm start

Once the server starts, access it via:

http://localhost:3000

🧪 Testing the /me Endpoint

Sample Response

{
  "status": "success",
  "user": {
    "email": "azonubigoodnews@gmail.com",
    "name": "Goodnews Azonubi",
    "stack": "Nodejs/Express/Typescript"
  },
  "timestamp": "2025-10-18T10:43:33.791Z",
  "fact": "A tiger’s stripes are like fingerprints"
}

🔍 Behind the Scenes: How It Works

GET /me Route

Located in: routes/profile.routes.ts

It calls a service function that:

Defines static profile data
Pulls a cat fact via axios
Adds an ISO timestamp
Returns the combined response

Cat Facts API

API used: https://catfact.ninja/fact

Response format:

{
  "fact": "Cats sleep for 70% of their lives.",
  "length": 38
}

Middlewares

helmet: Secures HTTP headers

cors: Enables basic cross-origin requests

rate-limiting: Prevents request abuse

logging: Logs method, path, response time

errorHandler: Catches and handles server errors

📚 What I Learned

Rate Limiting: Added protection against spamming endpoints using express-rate-limit

Middleware Layers: Execution order matters — I learned to carefully apply middlewares in the correct sequence

Structured Error Handling: Centralized error catching and response formatting

Project Structure: Separated routing, controller, and middleware for maintainability

🚀 Github repo

Please refer to the full repository for the complete code
Dynamic-Profile-Endpoint Github Repo

Ansible For Beginners - Part 1

Goodnews Azonubi — Wed, 02 Oct 2024 18:27:50 +0000

Introduction

Ansible is an open-source automation tool used for configuration management, application deployment, and orchestration. It allows system administrators and developers to automate repetitive tasks and also manage infrastructures more efficiently. Whether you're managing a few servers or a vast infrastructure, Ansible simplifies operations using human-readable YAML configuration files, also known as playbooks.

Key Features of Ansible

Agentless: Ansible doesn't require any special software or agents to be installed on the machines you're managing. It uses SSH to connect to and control remote machines or servers.
Idempotent: Ansible ensures that your systems are in a consistent state, applying changes only when necessary.
Simple, Yet Powerful: It uses a simple YAML syntax in the form of playbooks that are easy to read and write.
Extensible: Ansible can be extended through custom modules or plugins, making it highly flexible.

In this guide, we'll explore the basics of Ansible and get you started on your journey toward mastering IT automation.

Prerequisites

Before diving into Ansible, ensure you meet the following prerequisites:

Basic Understanding of Command-Line Usage: Familiarity with using the terminal on Linux OS.
Access to a Control Node (Master node): This is the machine where Ansible will be installed and run (it could be your local machine).
Managed Nodes (Slave Nodes): Remote servers or virtual machines to manage (e.g. AWS, Azure, GCP instances, or virtual machines running locally). You'll need SSH access to these nodes.
Ansible Installed: We will cover the installation, but if you already have Ansible installed, you’re good to go.
Basic Networking Knowledge: Understanding IP addresses, SSH, and network ports is helpful for managing remote systems.

Introduction
- Key Features of Ansible
Prerequisites
Getting Started with Ansible
- Installation on Linux (Ubuntu/Debian)
- Ansible Configuration
- Setting Up SSH for Remote Access
Ansible Inventory File
- Creating a Simple Inventory File
- Inventory Hosts Grouping and Aliases
Running Ansible Ad-Hoc Commands
- What Are Ad-Hoc Commands?
- Example: Ping all servers
- Example: Check disk space
Ansible Modules
- Introduction to Ansible Modules
- Commonly Used Modules: apt service copy
Ansible Playbooks
- What is an Ansible Playbook?
- Structure of a Playbook
- Writing Your First Playbook
- Running a Playbook
Conclusion
- Summary of Key Concepts

Getting Started with Ansible

Before getting started with using Ansible you need to install it and configure the environment. Here's the steps to set it up on your local machine which will act as the control node.

Installation on Linux (Ubuntu/Debian)

1. Update your system

sudo apt update
sudo apt upgrade

2. Install Ansible

sudo apt install ansible

3. Verify installation

ansible --version

Ansible Configuration

Ansible primarily uses SSH to manage remote servers. Therefore, you need remote access to the managed nodes for ansible to work effectively without requiring a password but using SSH key-based authentication.

Setting Up SSH for Remote Access:

1.. Generate SSH key pair

ssh-keygen -t rsa -b 4096 -C "ansible@control-node"

-t rsa: Specifies the type of key to create (RSA in this case).
-b 4096: Specifies the number of bits in the key (4096 is a strong size).
-C "ansible@control-node": Adds a comment to the key for easy identification (you can change this comment to match your setup, e.g., "Ansible control node").

A public and private key is generated (ansible_key and ansible_key.pub) where ansible_key.pub is the public key which will be copied to all the managed nodes. It will be copied to the authorized_keys file of the managed nodes. While the ansible_keyfile contains the private key and should not be exposed publicly.

2.. Copy the public key to the managed nodes

You can either copy the public key manually to the managed nodes

or you can execute this command which will copy it automatically. Since you don't have SSH access you might connect using the password of the managed node to copy your public key.

ssh-copy-id -i ~/.ssh/your_public_key.pub user@managed_node_ip

Once SSH is configured, Ansible can manage the remote node.

Ansible Inventory File

The inventory file contains a list of hosts that Ansible will manage. You can specify hosts or groups of hosts in this file and if you don't create one ansible will use the inventory file default path /etc/ansible/hosts. Creating your own inventory file in Ansible is crucial for several reasons, especially in terms of organization, flexibility, and scalability in managing systems.

Creating a Simple Inventory File

vi inventory

# Group of servers
[webservers]
192.168.1.10
192.168.1.11

# Group of databases
[dbservers]
db1.example.com
db2.example.com

Inventory Hosts Grouping and Aliases

Using the square bracket we can group the target servers into different categories like dbservers, webservers etc. Another way to identify them is using an Alias. We can achieve this by including an alias for each server at the beginning of the line (server1, server2, db1) and assigning the address of the server to the ansible_host parameter.

Ansible_host is an inventory parameter for specifying the dns hostname or ip address of the target server.

[webservers]
server1 ansible_host=192.168.1.101
server2 ansible_host=192.168.1.102

[dbservers]
db1 ansible_host=192.168.1.201

Running Ansible Ad-Hoc Commands

These are one-off tasks that you can execute without creating a playbook. Once Ansible is installed and your inventory file is set up, you can start running ad-hoc commands.

What Are Ad-Hoc Commands?

Ad-hoc commands are quick commands run on the managed nodes. They allow you to perform simple tasks without creating a complete playbook and these commands use the ansible command-line tool.

Example: Ping all servers

You can use the ping module to check connectivity to all hosts in your inventory:

Since we created our own inventory file we need to explicitly define it in our command using the -i flag so ansible doesn't try to use the default file in the /etc/ansible/hosts path.
We can configure Ansible to use the inventory file we created by adding an ansible.cfg file in the current working directory. This does not overwrite the default path but only applies within this directory, as it has higher precedence.

You can look up other parameters like the private_key_file which ansible uses to connect to all your managed nodes. You can view others that can be overridden by viewing the default Ansible configuration file located at: /etc/ansible/ansible.cfg.

ansible all -m ping

Example: Check disk space

To check the disk space on all servers:

ansible all -m command -a "df -h"

Ansible Modules

Introduction to Ansible Modules

Ansible modules are reusable units of code that can be used to perform specific tasks on managed nodes. Modules allow you to automate actions such as installing packages, managing services, copying files, and much more. Ansible modules are categorized into various groups based on their functionality

1. Core Modules: Core modules are the most essential and widely used modules that ship with Ansible. These are stable and maintained as part of the Ansible core.
- File Modules: Manage files and directories. Examples: file, copy, template, fetch, synchronize
- Package Management Modules: Install, update, and remove packages. Examples: apt, yum, dnf, pip
- and more...
2. Cloud Modules: These modules allow you to manage cloud infrastructure resources such as virtual machines, storage, networks, and other services from cloud providers.
- AWS Modules: Manage resources in Amazon Web Services. Examples: ec2, s3, rds, cloudformation
- and more...
3. Utility Modules: Utility modules are for general-purpose tasks such as managing files, running commands, or handling notifications.
- Command and Shell Modules: Run commands or scripts on remote systems. Examples: command, shell, raw
- and more..

We will be using some of these modules in the next section..

Ansible Playbooks

Ansible Playbooks allow you to automate the configuration and deployment of applications on multiple servers in a predictable manner.

What is an Ansible Playbook?

A playbook contains one or more "plays," which map a group of hosts to tasks that should be run on those hosts. It is written in the YAML syntax format.
Playbooks can include variables, conditionals, loops, and more, allowing for complex orchestration.
Play: This define a set of activities to be run on hosts (task). Each play is a list of dictionary ( in YAML term) separated by a dash - which contains properties like name, hosts ans tasks.
- Task: This is a single action to be performed on a host or hosts e.g., install a package

Writing Your First Playbook

1. Create a new YAML file (e.g. install_apache.yml or install_apache.yaml).

nano install_apache.yml

A basic ansible playbook structure looks like this:

---
- name: Install and start Apache Web Server
  hosts: webservers
  become: yes  # This enables privilege escalation (sudo)
  tasks:
    - name: Update Package
      apt:
        update_cache: yes  # Ensures the apt cache is updated before installation

    - name: Install Apache
      apt:
        name: apache2
        state: present

    - name: Start Apache service
      service:
        name: apache2
        state: started

2. Run your playbook:

ansible-playbook install_apache.yml

Play:

Managed Node: apache is installed on the managed node which has an IP address: 192.168.56.10

Default Page: Paste the IP address on your browser to view Apache default page

Conclusion

In this first part of the Ansible for Beginners series, we've covered the following key concepts:

Ansible and its primary functions
Installation and configuration
Setting up SSH for remote access
Understanding the inventory file
Running ad-hoc commands
Ansible modules and their usage
Introduction to Ansible Playbooks

What’s Next in Part 2:

In Part 2, we will delve deeper into more advanced topics, including Ansible variables, conditionals, loops, roles and more..

You can also check out my article on Protecting Sensitive Data using Ansible Vault

Let's connect on LinkedIn here

Docker For Beginners

Goodnews Azonubi — Fri, 27 Sep 2024 17:03:05 +0000

Introduction

Docker is a powerful tool in today’s software world which helps developers/software engineers package their applications and all the things they need to run smoothly into small containers. These containers work the same no matter where they are used whether on a developer’s laptop or in a big server. This guide is for anyone who wants to learn Docker, from people starting in DevOps and software development to students and anyone curious about technology. We’ll cover the basics of Docker, how to set it up, and how to use it in real-life situations. By the end, you’ll have a good grasp of Docker and how it can make your work easier.

Prerequisite

Basic understanding of the command line interface (CLI) or terminal.
Access to a computer with internet connection.

Introduction
Prerequisites
What is Docker?
Benefits of using Docker
Setting Up Docker
Docker Architecture
Creating Your First Docker Image
Basic Docker Networking
Push Your Image To Docker Hub
Docker Compose
Persisting Data with Docker Volumes
Conclusion

What is Docker

Docker is an open-source platform designed to automate the deployment, scaling and management of applications encapsulated into containers. This means that Docker packages the application code along with its dependencies, libraries, configuration files, and other required components into a single, isolated container ensuring that it runs consistently across different computing environments. The underline host where docker is installed is called docker host or docker engine.

Containers vs. Virtual Machines

Unlike virtual machines, which run on hypervisors and require a full operating system to function, containers share the host OS kernel and isolate processes at the application layer, making them more lightweight and efficient. This also means they can be provisioned faster.

Container vs Container Image

A container is a runnable instance of an image which means containers are created from images. When a container is started, docker takes the image and adds a read-write layer on top allowing it to perform certain tasks like save data and interact with the outside world.

A simple command like docker run <image name> can be used to run a container from an image and multiple instances of an image can be run on the same server.

A container image is the template, while a container is an instance of that template in action.

Docker is used for microservices architectures, continuous integration/continuous deployment (CI/CD), simplifying environment setup and scaling applications. It can also be used for Monolithic Architecture where multiple instances of your image are spin up and you can either scale up (adding more instances — vertical scaling) or scale out (provision new server with same image — horizontal scaling) ensuring consistency across servers.

Benefits of using Docker

Efficiency: Containers are lightweight and faster to spin up.
Portability: Containers can run on any system that supports Docker.
Isolation: Containers isolate applications from one another and the host system, improving security.

Setting Up Docker

Docker can be installed on your OS by downloading it from their official website.

Once you’re done installing Docker, you can test your installation by running a simple docker image (hello-world)

docker run hello-world

The docker run command does two things here. If it does not find the image in your local system it goes ahead to first run the docker pull <image-name> which downloads the image from the official dockerhub repository before it executes the docker run <image-name>.

Basic Docker Commands

You might need to add sudo (superuser do) for elevated privileges in a Linux based distribution. sudo docker pull

docker pull: This command is similar to the git pull command, it simply pulls the docker image from the dockerhub registry.

docker run: Run a container from an image.

docker version: Check the installed version of docker.

docker ps: Lists running containers

You can add the - a flag to view stopped containers. docker images: Lists all images (or docker image ls)

docker stop: Stops a running container

docker rm: delete container

docker rmi: delete image

Docker Architecture

Docker uses a client-server architecture where the docker client talks to the docker daemon. The docker daemon does all the heavy lifting of running, building and distributing your docker containers.

Components of Docker

Dockerhub: Docker Hub is a cloud-based registry service provided by Docker that allows you to find, store, and share container images.
Docker Compose: Docker Compose is a tool for defining and running multi-container Docker applications. With Docker Compose, you use a YAML file to configure your application’s services, networks, and volumes. With a simple command you can create and start all the services from your configuration file. We will look more on this later.
Docker Daemon: This is a background process that manages docker images, containers, networks, and storage volumes.
Docker Engine: This is a core component of docker that creates and runs containers.

Docker Objects

Docker Image: A read-only template to create containers which contains all necessary codes and dependencies required to run your application.
Docker Container: A runnable instance of an Image. Containers run the actual application.
Docker Volume: This is a persistent data storage mechanism used to by containers to store data outside the container’s filesystem. More on this later…
Docker Network: This is a networking component that allows docker containers to communicate with each other and non-docker environments.

Creating Your First Docker Image

Docker uses Dockerfile for building docker images. A Dockerfile is a text file that contains instructions on how to build a particular application into a docker image and these instructions are processed by the Docker Engine. A simple Dockerfile will look like this:

FROM ubuntu:20.04
RUN apt-get update && apt-get install -y <dependencies>
COPY . /app
WORKDIR /app
CMD ["./your_app_executable"]

1) FROM ubuntu:20.04

FROM is a Dockerfile instruction that specifies the base image for the Docker container. The base image is the starting point for building your own image.
If the image is not already on your local system docker will pull this image from dockerhub (ubuntu:20.04)
Tags are a way to version and label docker images making it easier to identify and manage different versions of it. You can always find the tag after the colon (:) which is :20.04 or :v1.0, :v2.0

2) RUN apt-get update && apt-get install -y

RUN is a Dockerfile instruction used to execute commands in the container during the build process.
This line runs commands to update the package list and install necessary dependencies.

3) COPY . /app

COPY is a Dockerfile instruction used to copy files and directories from the host filesystem into the container’s filesystem
This line is copying files from the current working directory on the host machine (.) to the (/app) in the container.

4) WORKDIR /app

WORKDIR is a Dockerfile instruction that sets the working directory in the container for any subsequent instructions in the Dockerfile

5) CMD ["./your_app_executable"]

- `CMD` is a Dockerfile instruction used to specify the default command to run when the container starts. These defaults include the executable to run.

To build your image run this:

docker build -t myimage-name .

The -t flag is used to assign a name and an optional tag to the Docker image that is being built from a Dockerfile.

To run a container from that image run this command

docker run -d --name mycontainer myimage-name

I added some extra parameters to this command here

- d: runs the container in detached mode. In simple terms running the container in the background

-- name: the flag is used to assign a unique name to your container for easy identification. You can give it any name depending on it’s function.

Basic Docker Networking

Docker networking allows containers to communicate with each other and with external systems. It is an essential aspect of deploying applications using Docker. To see all the networks on your machine run this command

docker network ls

Network Drivers: Docker provides several network drivers for different use cases:

bridge: The default driver for standalone containers. Containers on the same bridge network can communicate with each other using their IP address. docker run ubuntu
host: Removes network isolation between the container and the docker host, using the host’s networking directly. There’s no need for port mapping as the port created on the container can be accessible directly on the host. docker run ubuntu --network=host
none: Disables all networking. Containers only have a loopback interface. docker run ubuntu --network=none

Creating a Network:

You can create a user-defined bridge network to allow better control over container communication using the create command.

docker network create my_bridge

Connecting Containers to a Network:

When starting a container, you can connect it to a specific network using the --network flag.

docker run -d --name my_container --network my_bridge my_image

Inspecting Networks:

To inspect a network and see the connected containers use the inspect command.

docker network inspect my_bridge

DNS Resolution:

Docker networks have built-in DNS resolution, allowing containers to resolve each other by name.

Push Your Image To Docker Hub

You can push your image to your own docker repository after creating an account on dockerhub. Here is a simple step on how to push your image to your dockerhub repository:

1. Create a Docker Hub Account:

If you don’t have a Docker Hub account, you can create one at dockerhub.

2. Login to dockerhub from the CLI

Open your terminal and log in to dockerhub using the following command:

docker login

You will be prompted to enter your dockerhub username and password.

3. Tagging Your Image

Before pushing your image to dockerhub, you need to tag it with a repository name that includes your dockerhub username. Let’s assume your local image is named my-image.

docker tag my-image:latest yourdockerhubusername/my-image:latest

Replace yourdockerhubusername with your actual dockerhub username.

4. Push the Image to Docker Hub

Use the docker push command to push the tagged image to dockerhub.

docker push yourdockerhubusername/my-image:latest

Docker Compose

Docker Compose allows you to define and run multi-container Docker applications using a YAML file.

Writing a Docker Compose File:

YAML is a human-readable data serialization language that is often used for writing configuration files. Depending on whom you ask, YAML stands for yet another markup language or YAML ain’t markup language (a recursive acronym), which emphasizes that YAML is for data, not documents.

Unlike JSON that uses curly braces YAML uses indentation to define blocks of instructions. A YAML file can either have .yaml or .yml extension.

If you’re unfamiliar with the YAML syntax check out this YouTube video

Example of a docker-compose.yml (this is the standard way of writing a compose file) file for a web application with a database.

version: '3.8'

services:
  web:
    build: ./frontend
    ports:
      - "8080:80"

  api:
    build: ./backend
    ports:
      - "3000:3000"
    environment:
      DB_URL: mongodb://db/db-name


  db:
    image: mongodb:4.0-xenial
    ports:
      - "27017:27017"
    volumes:
      - db_data:/data/db

volumes:
  db_data:

Define docker compose version
Define services: In our case we have frontend(web), backend(api) and database(db).
We need to tell docker how to build an image for each service. We can either use the build property and tell docker where to find our Dockerfile which will be in the root folder of each service or we can pull an image from dockerhub using the image property.
Next we have to define port mapping for each service using the ports property.
Setting up an environment variable for the api service to tell where to find the database. We can use the environment property for this. Since all services are connected using the bridge driver we can access each service directly by calling their name (web,api,db).
The volumes property can be used to store persistent data outside the container’s filesystem.
In the last line we need to define the volumes first before we can use it (db_data).

Running Multi-Container Applications:

To start services run this command

docker-compose up

Once our services are up we can access them using the ports we mapped to each one. Our application has three hosts/containers that communicate with each other using a bridge driver.

You can test to confirm containers can communicate with each other by running a simple ping command.

First let’s enter the terminal shell of our frontend(web) container

docker exec -it -u root web_container_id sh

We have a new command and options here. Let me break it down.

The command docker exec -it -u root web_container_id sh is used to run a shell (sh) inside a running Docker container.

exec: Command to run a command in a running container.
-i: Keeps STDIN open, allowing you to interact with the container. You would be able to provide input to the shell, but the session would not have terminal features, making it less user-friendly.
-t: Allocates a pseudo-TTY (terminal). You would have a terminal interface, but you wouldn’t be able to provide interactive input.
-u root: Specifies the user as root to run the command.
container_id: The ID or name of the running container.
sh: The shell to run inside the container (Bourne shell). Now let’s ping the backend (API) service

ping api

To stop and remove services run this command

docker-compose down

Docker Volumes and Persistent Storage

Docker volumes are used to persist data generated and used by Docker containers. When you stop a docker container by default without explicitly specifying volume mapping, everything generated and stored in it is deleted making it ephemeral, meaning it is tied to the lifecycle of the container

Types of Volumes:

Named Volumes: This is managed by docker and stored in docker’s storage area.
Bind Mounts: This maps a file or directory on the host to a container. This offers more control on the data but less portability.

Creating and Using Volumes:

Create a named volume:

docker volume create my_volume

Use a volume when running a container:

docker run -d --name my_container -v my_volume:/data image-name

Where my_volume is the directory mapped on the host system and /data on the container.

Volume Lifecycle:

Volumes are not automatically deleted when a container is removed, preserving the data.

You can manually remove a volume using this command.

docker volume rm my_volume

Inspecting Volumes:

To inspect a volume and view details about it

docker volume inspect my_volume

Summary

In this article, we covered various fundamental aspects of Docker:

Basic Docker Networking: How containers communicate with each other and external systems, and the different network drivers available.
Docker Volumes and Persistent Storage: Methods to persist data generated by containers and ensure data persists across container restarts.
Docker Compose: Tool for defining and running multi-container applications, simplifying orchestration using a YAML file.
Pushing Docker Images to Docker Hub: Steps to share and manage Docker images on Docker Hub.

By mastering these concepts, you’ll be better equipped to deploy and manage applications using Docker efficiently.

Let’s connect on LinkedIn here

Hosting a Static website on a private Amazon S3 bucket using CloudFront’s OAC

Goodnews Azonubi — Fri, 27 Sep 2024 07:49:26 +0000

Introduction

In this article, we’ll explore how to securely host a static website on a private Amazon S3 bucket using Amazon CloudFront with Origin Access Control (OAC). By following these steps, you can ensure that your website content is accessible only through authorized channels while benefiting from the performance and scalability of CloudFront.

Prerequisites

To follow through with this article you need to meet the following requirements

You should have registered an AWS Account
Static website files to be uploaded (HTML, CSS, JavaScript)

Amazon S3
Amazon CloudFront
Creating an Amazon S3 Bucket
Uploading Static Website Files
Setting Up CloudFront and OAC
Testing Your Setup
Conclusion

Amazon S3

Amazon Simple Storage Service (Amazon S3) is an object storage service used to store and retrieve any type data i.e text files, video files etc.

Amazon CloudFront

Amazon CloudFront is an Amazon web service that speeds up the distribution of your static and dynamic web contents securely using a content delivery network (CDN). CloudFront ensures your web contents are accessible globally by caching them in edge locations.

Creating an Amazon S3 Bucket

Click Create bucket and enter a unique bucket name
Scroll down and click Create bucket

Leave other settings as default. By default your bucket is set to private

Uploading Static Website Files

Upload your static website files to the S3 bucket.

This is all we are doing here for now

Setting Up CloudFront and OAC

Go to the CloudFront service in the AWS Management Console.
Click Create a CloudFront distribution

Choose your s3 bucket name from the origin domain pop up.

Since our bucket is private we need a way to access it privately using CloudFront distribution. To achieve this we need to create an Origin Access Control (OAC) which is a newer way to establish secure connection. Unlike Origin Access Identity (OAI) which is an older way to connect CloudFront distribution to S3, Amazon CloudFront introduces Origin Access Control (OAC) which provides more functionality like signed requests, supports accessing S3 in all AWS regions which includes currently existing and future regions and more features.

You can choose to enable WAF which adds another layer of security to incoming traffic going to your CloudFront distribution

But since this is a temporal deployment you can go with the second option

Now scroll down and click on `Create distribution`

Copy Policy generated by CloudFront OAC

Let’s go back to our S3 bucket permission to paste our generated policy

Paste policy and save changes

Testing your setup
Go back to your CloudFront to copy your Distribution domain name

Paste on your browser

Verify that your content is served securely via CloudFront.

Conclusion

In conclusion, by following the steps outlined in this guide, you’ve successfully set up a secure and efficient hosting environment for your static website using Amazon S3, CloudFront, and Origin Access Control (OAC). Your website content is now accessible only through authorized channels, ensuring both security and scalability.

That’s all for now, I hope you found this helpful 🙂

Let’s connect on LinkedIn

Laravel LAMP Stack Deployment: Automating Setup with Bash Script on an Ubuntu Server

Goodnews Azonubi — Fri, 27 Sep 2024 07:25:16 +0000

Introduction

Automating Deployment of a Laravel LAMP Stack Application using Bash Script introduces an efficient method for deploying web applications built with Laravel, a popular PHP framework known for its elegant syntax and powerful features.

In this article we’ll explore automating the deployment of a Laravel-based web application on a LAMP (Linux, Apache, MySQL, PHP) stack using Bash Scripting. By automating this process, we can ensure consistency, reduce manual errors, and speed up deployment times. Whether you’re a developer aiming to simplify deployment or an operations engineer looking to streamline processes, this guide will walk you through the steps to automate your Laravel LAMP stack deployments effectively.

Prerequisites

Ubuntu Server: Ensure you have an Ubuntu server instance set up and accessible.
SSH Access: Ensure you can SSH into the Ubuntu server.
Basic Linux Commands: Familiarity with basic Linux commands and the terminal.

Introduction
Prerequisites
What is a Bash Script
Automating Laravel LAMP Stack Installation
Deploying Laravel Application
Conclusion

What is a Bash Script

A Bash script is a text file containing a series of commands that are executed by the Bash shell (Bourne Again SHell), which is the default command-line interpreter for Unix-like operating systems, including Linux and macOS. Bash scripts are commonly used for automating repetitive tasks, system administration, and complex command-line operations. They can be executed directly from the command line or scheduled to run at specific times using cron jobs or other scheduling tools.

Automating Laravel LAMP Stack Installation

Step 1: Create a script file laravel.sh and make it an executable.

touch laravel_app.sh && chmod +x laravel_app.sh

We will be using vim as our text editor but you can use nano if that’s what you’re familiar with

Step 2: Open the file in a text editor and press "i" to enter insert mode.

vim laravel_app.sh

Step 3: Let’s start writing our script first by declaring our shebang.

#!/bin/bash

Our script will be divided into functions to handle different tasks. You can declare your function in two ways

function setup() {

}

setup() {

}

and it consists of a

function declaration — “function” (optional)

function name — “setup”

function parameters — “( )” optional

code block — “{ }”

The function parameter can be empty which means the function does not take any arguments

A function will not execute unless it is called. To call a function simply type out the function name (setup)

setup

Step 4: We need a way to keep track of the line our script is currently running so let’s manipulate the echo command output to make it interactive while running the script. Write a function that changes the colour of our echo output.

# Function to display messages in gold
function gold_echo() {

    echo -e "\e[38;5;220m$@\e[0m"
}

Step 5: Write a function that installs the lamp stack (Apache, MySQL and PHP).

function install_lamp() {
# Install PHP
gold_echo "---------------------update php repository-----------------------"

 sudo apt update
 sudo add-apt-repository ppa:ondrej/php -y

gold_echo "-----------------------Installing Php8.2-----------------------------------------"
 sudo apt install php8.2 -y

gold_echo "-------------------------------------Installing php dependencies----------------------------"

 sudo apt install php8.2-curl php8.2-dom php8.2-mbstring php8.2-xml php8.2-mysql zip unzip -y

gold_echo "-------------------------- php done ----------------------------------"

#Install Apache web server

gold_echo "----------------------------Installing Apache--------------------------------------------------"

 sudo apt install apache2 -y
 sudo apt update
 sudo systemctl restart apache2

#Install Mysql-server

gold_echo "------------------------------------Installing mysql-server----------------------------------------------"

 sudo apt install mysql-server -y
}

Check if there are other PHP extensions that are not currently present in your server.

php -m

Laravel PHP extensions requirements:

✅ Ctype PHP Extension
❌ cURL PHP Extension
❌ DOM PHP Extension
✅ Fileinfo PHP Extension
✅ Filter PHP Extension
✅ Hash PHP Extension
❌ Mbstring PHP Extension
✅ OpenSSL PHP Extension
✅ PCRE PHP Extension
✅ PDO PHP Extension
✅ Session PHP Extension
✅ Tokenizer PHP Extension
❌ XML PHP Extension

The items marked in red were not currently present on my server, so I'll be install them.

sudo apt install php8.2-curl php8.2-dom php8.2-mbstring php8.2-xml php8.2-mysql zip unzip -y

We also need to install zip and unzip which will be needed later by composer

Step 6: Write a function to install and setup composer

function composer_setup() {
 cd ~

 if [ -d "$HOME/composer" ]; then

         gold_echo "--------------------------------------Composer Directory Exists--------------------------------------------"
 else
   mkdir composer
   cd composer

   gold_echo "-------------------Directory created successfully--------------------------------"

   curl -sS https://getcomposer.org/installer | php
   sudo mv composer.phar /usr/local/bin/composer

   gold_echo "------------------- Composer Added Successfully-------------------------"
 fi
}

Step 7: Write a function that clones and setup laravel app

function setup_laravel_app() {
 cd /var/www/

 sudo rm -r ./*
 sudo git clone https://github.com/laravel/laravel
 sudo chown -R $USER:$USER laravel
 cd laravel
#Install dependencies using composer
 composer install
 cp .env.example .env
 php artisan key:generate
 sudo chown -R www-data bootstrap/cache
 sudo chown -R www-data storage

}

GitHub repo to laravel app

Step 8: Write a function that configures MySQL Server (create database and user)

function conf_mysql() {
   cd /var/www/laravel

   gold_echo "-------------Setup mysql database and user--------------------------------"

# Configure MySQL database
sudo mysql -uroot -e "CREATE DATABASE laravel_db;"
sudo mysql -uroot -e "CREATE USER 'laravel_user'@'localhost' IDENTIFIED BY '000000';"
sudo mysql -uroot -e "GRANT ALL PRIVILEGES ON laravel_db.* TO 'laravel_user'@'localhost';"
sudo mysql -uroot -e "FLUSH PRIVILEGES;"


gold_echo "-----------------Done with database setup--------------"
gold_echo "------------------Editing .env file--------------------"




   sed -i 's/DB_CONNECTION=sqlite/DB_CONNECTION=mysql/' .env
   sed -i 's/# DB_HOST=127.0.0.1/DB_HOSTS=127.0.0.1/' .env
   sed -i 's/# DB_PORT=3306/DB_PORT=3306/' .env
   sed -i 's/# DB_DATABASE=laravel/DB_DATABASE=laravel_db/' .env
   sed -i 's/# DB_USERNAME=root/DB_USERNAME=laravel_user/' .env
   sed -i 's/# DB_PASSWORD=/DB_PASSWORD=000000/' .env





gold_echo "-------Migrating database--------"

   php artisan migrate

}

Username: laravel_user

Database name: laravel_db

Password: 000000

Step 9: Write a function to create a new Apache virtual host to point our new laravel app.

function apache_conf() {
    #Setup Virtual host for app
    cd ~
    sudo tee /etc/apache2/sites-available/laravel.conf <<EOF
    <VirtualHost *:80 *:3000>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/laravel/public/

    <Directory /var/www/laravel/public/>
            Options Indexes FollowSymLinks
            AllowOverride All
            Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
  </VirtualHost>
EOF


  cd ~
   sudo a2dissite 000-default.conf
   sudo a2enmod rewrite
   sudo a2ensite laravel.conf
   sudo systemctl restart apache2
}

Step 10: Write a function to call our functions

#Functions

function main() {
  install_lamp
  composer_setup
  setup_laravel_app
  conf_mysql
  apache_conf
}

#Execute All Functions
main

Save and exit

Press ESC key
colon wq (:wq)
Enter

Deploying Laravel Application

Execute script

./laravel_app.sh

Output:

Conclusion

This guide has provided a step-by-step approach to automating the deployment of a Laravel LAMP stack application using Bash script on an Ubuntu server. By automating these processes, developers and operations engineers can ensure consistency, reduce errors, and expedite deployment times, leading to a more efficient and streamlined application environment.

Protecting Sensitive Data using Ansible Vault

Goodnews Azonubi — Thu, 04 Jul 2024 13:58:07 +0000

Introduction:

In this tutorial we will explore Ansible Vault which is a feature of ansible that comes pre-installed. We will discuss what Ansible Vault is, and how it can be used for effective management of information such as passwords, API keys, files and other sensitive data.

Prerequisites:

You need to have Ansible installed to be able to follow along with this tutorial. If you don’t have Ansible installed yet follow this tutorial on how to install Ansible on Ubuntu 20.04.

Proceed with this guide once your server has been configured with the above requirements.

What is Ansible
What is Ansible Vault
How to use Ansible Vault
Best Practices for Using Ansible Vault
Conclusion

What is Ansible

Ansible is an open-source automation tool that simplifies IT tasks such as configuration management, application deployment, and orchestration by allowing users to automate repetitive tasks using simple, declarative YAML-based scripts called playbooks.

What is Ansible Vault

Ansible Vault is a feature of ansible which provides a secure way for managing sensitive information such as API keys, password or even private data within your playbook or file. Ansible Vault uses the AES256 algorithm which is a symmetric form of encryption that uses a single key (or password ) for encrypting and decrypting data unlike the asymmetric that uses a private and public key pair.

Ansible Vault has several arguments used to manipulate files such as create, edit, view, encrypt, decrypt, rekey, encrypt_string, decrypt_string

How to use Ansible Vault

The ansible-vault command acts as the primary interface for managing encrypted content within Ansible. It facilitates the encryption of files initially and subsequently enables operations such as viewing, editing or decrypting the encrypted data.

How to create a new encrypted file

Use the ansible-vault create command, followed by the name of the file to create a new encrypted file. This command will prompt you to enter and confirm the password for the newly created file.

ansible-vault create secret.yml

Your new file will open in your default text editor where you can type your secret texts and save.

Note: You can access your decrypted texts by providing the password or pass key you provided during encryption process.

How to encrypt an existing file

Use the ansible-vault encrypt command, followed by the name of the file, to encrypt an already existing file

ansible-vault encrypt file.txt

How to view an encrypted file

Use the ansible-vault viewcommand, followed by the name of the file

ansible-vault view secret.yml

How to edit an encrypted file

Use the ansible-vault edit command, followed by the name of the file

ansible-vault edit secret.yml

How to decrypt an encrypted file

Use the ansible-vault decrypt command, followed by the name of the file

ansible-vault decrypt file.txt

How to change the password of an encrypted file

Use the ansible-vault rekey command, followed by the name of the file

ansible-vault rekey secret.yml

You will be prompted to enter the current password of the file and afterwards you can enter and confirm the new password

Saving your password to a file

Saving your password to a file (make sure the file is not tracking by version control) and specifying the path to the file is also another way of performing different operations without typing the password always on the terminal prompt.

This password should be auto generated by a password generator software and not hard coded to increase security.

Random Password Generator

This key should be kept private and should not be committed to version control

How to decrypt an encrypted file during playbook run-time

Let’s say for instance you encrypt your inventory/hosts file that has the IP address of your slave servers, you can run your playbook without decrypting first. Just specify the path to your password file in your command or input the password before playbook runs

— — ask-vault-pass: This will prompt you to input your password

 ansible-playbook -i ../hosts main.yml --key-file ~/.ssh/ansible --ask-vault-pass

- - vault-password-file: This will use the password file directly without asking for password

 ansible-playbook -i ../hosts main.yml --key-file ~/.ssh/ansible --vault-password-file ~/ansible_vault/vault_pass.txt

Using encrypted variables in playbook

You can access an encrypted variable file using the normal method by including your variable file in your playbook

---
- name: Configure Servers (Ubuntu and CentOS)
  hosts: all
  vars_files:
    - secret_vars.yml

  become: true
  tasks:

    - name: Update Repository Index (Ubuntu and CentOS)
      package:
        update_cache: yes
      changed_when: false

    - name: Clone github repo
      git:
        repo: "{{ github_repo }}"
        dest: "/home/vagrant/test"
        force: yes

Best Practices for Using Ansible Vault

Use Strong Passwords: Ensure passwords are complex and secure.
Version Control: Track encrypted files in version control but never push your password file to it
Backup Encrypted Files: Prevent data loss with regular backups.
Password Access: Regularly audit who has access to view your password file.. you can use the chmod to set permissions

Conclusion

Ansible Vault is a useful tool for managing secret information stored in files by encryption and decryption. To learn more about ansible vault visit the official ansible-vault documentation page.

User Management Automation Using Bash Script

Goodnews Azonubi — Thu, 04 Jul 2024 12:53:00 +0000

INTRODUCTION

As a SysOps (Systems Operations) engineer, managing user accounts and permissions is a critical task. Ensuring that users are properly created, assigned to the correct groups, and have secure passwords is essential for maintaining the security and efficiency of the system. A script file (create_users.sh) will be created to automate the process of user and group creation, making it easier to manage large numbers of users and maintain a secure environment. This is a stage 1 DevOps task given at the HNG 11 INTERNSHIP PROGRAM.

Prerequisites

Basic knowledge of the Linux CLI (command line interface).

Script Code:

#!/bin/bash


# Check if the script is run as root user
if [[ $EUID -ne 0 ]]; then
  echo "This script must be run as root"
  exit 1
fi


# Check if the input file is provided in argument (contains the usernames and groups)
if [ -z "$1" ]; then
  echo "Usage: sudo $0 <filename>"
  exit 1
fi

INPUT_FILE=$1
LOG_FILE="/var/log/user_management.log"

# Create a secure directory to save secret files
mkdir -p /var/secure
chmod 700 /var/secure

# Create secure passwords file
PASSWORD_FILE="/var/secure/user_passwords.txt"
echo "USERNAME  |   PASSWORD" > "$PASSWORD_FILE"
echo "---------------------------------------------" >> "$PASSWORD_FILE"
chmod 600 "$PASSWORD_FILE"



# Read input file line by line
while IFS=';' read -r username groups; do

   # Remove leading/trailing whitespaces
     username=$(echo "$username" | xargs)
     groups=$(echo "$groups" | xargs)

   # Skip empty lines
     if [ -z "$username" ]; then
       continue
     fi


  # Create the user with a personal group
    if id "$username" &>/dev/null; then
      echo "----------------------------------------------------------------" | tee -a "$LOG_FILE"
      echo "User $username already exists" | tee -a "$LOG_FILE"
    else
      useradd -m -U "$username"
      echo "----------------------------------------------------------------" | tee -a "$LOG_FILE"
      echo "User $username created with a personal group" | tee -a "$LOG_FILE"
    fi


  # Create additional groups and assign the user to them
  if [ -n "$groups" ]; then
    IFS=',' read -ra groupName <<< "$groups"
    for group in "${groupName[@]}"; do
      group=$(echo "$group" | xargs)  # Remove leading/trailing whitespaces
      if ! getent group "$group" &>/dev/null; then
        groupadd "$group"
        echo "group: $group created successfully"
      fi
      usermod -aG "$group" "$username"
      echo "user: $username added to group: $group"
    done
  fi


    # Generate, set and store password securely
    password=$(openssl rand -base64 12)
    echo "$username:$password" | chpasswd
    echo "$username |   $password" >> "$PASSWORD_FILE"



    # Set permissions and ownership for the home directory
    chown -R "$username":"$username" "/home/$username"
    chmod 700 "/home/$username"

    echo "-----------------------------------------------------------------------------------"
    echo "  "

    # Log recent actions
    echo "$(date '+%Y-%m-%d %H:%M:%S') - Created user with username: $username and groups: $groups" >> "$LOG_FILE"
    echo "-------------------------------------------------------------------" >> "$LOG_FILE"
done < "$INPUT_FILE"

Key Features

1. Automated User and Group Creation:

The script reads from a file containing user and group information and automates the creation of users and their respective groups.
Personal groups are created for each user, ensuring clear ownership and security. Group Assignment:
Users can be assigned to multiple groups, facilitating organized and efficient permission management.

2. Secure Password Generation:

Random passwords are generated for each user, enhancing security.
Passwords are stored securely in a file with restricted access, ensuring that only authorized personnel can view them.

3. Logging and Documentation:

Actions performed by the script are logged to a file, providing an audit trail for accountability and troubleshooting.

Usage:

1 Input File: The script takes an input file containing the list and users and groups they are to be added. it is formatted as user;groups

light; engineering,marketing,drama
idimma; drama,product
mayowa; hng-premium,design

2. Script file: You need to first make sure your script is executable by using this command chmod +x create_users.sh.

Execute the script with root privileges to ensure it can create users and groups and manage passwords.

sudo bash create_users.sh <filename>

3. Output:

Passwords are securely stored in /var/secure/user_passwords.txt.
All actions are logged to /var/log/user_management.log.

You can checkout for available roles at HNG here and register for the next HNG Internship Cohort

Link to my script and file: https://github.com/ideateGudy/User-Management-Script-Using-Bash

DEV Community: Goodnews Azonubi

How I Built and Deployed a Production ready MERN Application on AWS using Modular Terraform and Keyless GitHub Actions OIDC 🚀

📱 What is "Little List"? (Application Overview)

📋 Prerequisites

🏗️ The Cloud Architecture Overview

Core Components Explained for Beginners:

📂 Repository & Project Structure

🧱 Key Technical Deep Dives

1. Unified Single-Domain Routing with CloudFront

2. Zero Secrets in GitHub via AWS OIDC

🌐 Custom Domain, Subdomain Setup (dev.ideategudy.tech) & SSL Configuration

Why Use a Subdomain (dev.ideategudy.tech)?

Connecting Namecheap Subdomain (dev.ideategudy.tech) to AWS:

⚡ Automated CI/CD Pipeline (deploy.yml)

🚀 Step-by-Step Deployment Instructions

Step 1: Provision AWS Infrastructure with Terraform

Step 2: Configure GitHub Repository Secrets & Variables

Step 3: Trigger Automated Build & Deployment

🎉 Live Application Demo

⚡ Key Benefits & Architectural Trade-Offs

🟢 Key Benefits

⚠️ Architectural Trade-Offs & Considerations

🎯 Conclusion

🔗 Related Documentation & Alternative Architecture

🤝 Connect & Follow Me

How I Built and Deployed a Full-Stack MERN App on AWS EC2 using Docker Compose, Terraform, and GitHub Actions 🚀

📱 What is This Project? (Application Overview)

📋 Prerequisites & Tools Required

🏛️ High-Level System Architecture

Key Architectural Highlights:

📁 Repository Structure Overview

🚀 Step-by-Step Deployment Walkthrough

Step 1: Local Development & Container Verification

Step 2: Provision Infrastructure using Terraform (IaC)

1. Configure AWS CLI & Security Key Pair

2. Provision with Terraform

Step 3: Configure Custom Domain & DNS Records (Optional but Recommended)

Step 4: Configure GitHub Repository Secrets & Variables

Step 5: Automated Deployment via GitHub Actions CI/CD

Step 6: Live Production Verification & Secure HTTPS

❓ Troubleshooting & Common Gotchas

🛡️ Production Best Practices Implemented

⚡ Key Benefits of This Architecture

🎯 Conclusion

🔗 Related Documentation & Alternative Architecture

🤝 Connect & Follow Me

Build Smart AI Agents with Mastra and TypeScript (Integrating with Telex.im)

Introduction

Telex:

Live agent on Telex: Tech Jobs Agent

What You'll Need

The Big Picture: How It All Fits Together

Walking Through the Code: Step by Step

Step 1: The Agent Asks a Question

Mastra Features Used

Step 2: Extracting Keywords

Step 3: The RSS Tool Tool Does the Heavy Lifting

Scorers in Mastra

Keyword Relevance & Tool Selection:

Jobs Response Quality:

Step 4: Feed Caching and Scheduling

Step 5: Auto-Refresh with a Scheduler

Step 6: Validation with Zod

Actually Running This Thing

Environment Setup

How to Extend This project

Add a New Tool

Add a New Agent

Add Observability

What I Learned

Next Steps

References

Flutter’s UI Architecture Explained for Beginners: Widgets, Elements, and Render Objects

Flutter Basics

Flutter Basics Overview

Prerequisites:

What is Flutter?

Dart

Declarative UI / Reactive Programming

Multiplatform Development

🌐 Custom Domain, Subdomain Setup (`dev.ideategudy.tech`) & SSL Configuration

Why Use a Subdomain (`dev.ideategudy.tech`)?

Connecting Namecheap Subdomain (`dev.ideategudy.tech`) to AWS:

⚡ Automated CI/CD Pipeline (`deploy.yml`)

- `CMD` is a Dockerfile instruction used to specify the default command to run when the container starts. These defaults include the executable to run.