DEV Community: Israel

AWS Ecommerce store

Israel — Wed, 09 Sep 2026 06:35:41 +0000

In a bid to understand more about the services AWS offers, it makes sense to finally build an E-Commerce store using just AWS services. What better way to understand how exactly they work and in what scenarios they work best.

A rough architecture would be something like this,

Terraform: A Guide to Deploying

Israel — Sat, 05 Sep 2026 09:55:35 +0000

In the previous article we manually built a production VPC, subnets, security groups, NAT Gateway, Application Load Balancer, and EC2 instance through the AWS Console. We deployed our Dockerized Smash Apartment application and made it accessible to via the ALB's DNS.

It worked perfectly. But it took a lot of time, was tedious and error prone, and tearing it down involved a tedious 12-step manual process that easily failed if you got the dependency order wrong.

Enter Terraform, it's the perfect solution to our problem, we can scaffold the entire architecture, plan to see changes to our architecture and destroy it easily.

In this article, we are going to rebuild the exact same infrastructure from Part 1, but this time we'll use Infrastructure as Code (IaC). The entire architecture will live in a few code files. One command to create it. One command to destroy it.

Introduction: Why Terraform?
Pre-requisites
Step 1: Project Structure and Foundation
- 1.1 Provider Configuration (main.tf)
- 1.2 Input Variables (variables.tf)
Step 2: Networking — VPC and Subnets
- 2.1 Defining the Network (vpc.tf)
Step 3: Security Groups
- 3.1 Firewall Rules (security_groups.tf)
Step 4: Application Load Balancer
- 4.1 ALB Configuration (alb.tf)
Step 5: EC2 Instance and Bootstrap
- 5.1 User Data Script (user_data.sh)
- 5.2 EC2 Configuration (ec2.tf)
Step 6: Outputs and Deployment
- 6.1 Outputs Configuration (outputs.tf)
- 6.2 Variable Assignment (terraform.tfvars)
- 6.3 Deploying the Infrastructure
Step 7: The Cleanup — One Command
Conclusion & Next Steps

Introduction: Why Terraform?

Terraform is an open-source tool that lets you define cloud infrastructure using a declarative configuration language (HCL). Instead of clicking through the AWS Console, you write code that says "I want a VPC with this CIDR block."

Why does this beat the manual console method?

Repeatable: The same configuration produces the exact same infrastructure every time. Need a staging environment? Just copy the folder, change the environment variable, and deploy.
Version Controlled: Infrastructure changes go through git, pull requests, and code reviews, just like application code.
Self-Documenting: The .tf files act as the ultimate source of truth. No more guessing which security group allows what traffic.
Automated Dependency Management: Terraform knows the NAT Gateway needs the Elastic IP, and it knows the subnets need the VPC. It creates them in the exact right order.

Pre-requisites

Before we begin, ensure you have the following ready:

AWS CLI configured: Configured with Administrator access.
Terraform installed: Download and install Terraform (v1.5+).
EC2 Key Pair: A key pair created in AWS (e.g., apartment-key), same as Part 1.
The Application Code:

   git clone https://github.com/Israel-dot-com/apartment-deployment-main

Step 1: Project Structure and Foundation

Let's look at the structure of our Terraform configuration. Splitting the configuration by concern makes it much easier to maintain.

terraform/
├── main.tf                  # AWS Provider config and default tags
├── variables.tf             # All configurable inputs
├── vpc.tf                   # VPC, subnets, gateways, route tables
├── security_groups.tf       # Security groups for ALB and EC2
├── alb.tf                   # Load balancer, target group, listeners
├── ec2.tf                   # EC2 instance, AMI lookup, IAM role
├── user_data.sh             # Bash script that installs Docker on boot
├── outputs.tf               # Prints the ALB URL and SSH commands after deploy
└── terraform.tfvars.example # Example variable values

1.1 Provider Configuration (`main.tf`)

First, we tell Terraform we are working with AWS and define our default tags.

# main.tf
terraform {
  required_version = ">= 1.5"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.aws_region

  default_tags {
    tags = {
      Project     = var.project_name
      Environment = var.environment
      ManagedBy   = "terraform"
    }
  }
}

Why default tags? The default_tags block automatically applies these tags to every resource Terraform creates. This is incredibly useful for billing and resource tracking.

1.2 Input Variables (`variables.tf`)

Next, we define the inputs. These are the exact same CIDR blocks and values we typed into the console in Part 1.

# variables.tf (abridged for length)
variable "aws_region" {
  description = "AWS region to deploy into"
  default     = "us-east-1"
}

variable "project_name" {
  default     = "apartment"
}

variable "vpc_cidr" {
  default     = "10.0.0.0/16"
}

variable "public_subnet_cidrs" {
  default     = ["10.0.1.0/24", "10.0.2.0/24"]
}

variable "private_subnet_cidrs" {
  default     = ["10.0.11.0/24", "10.0.12.0/24"]
}

variable "availability_zones" {
  default     = ["us-east-1a", "us-east-1b"]
}

variable "key_pair_name" {
  description = "Name of an existing EC2 key pair for SSH access"
  type        = string
}

variable "domain_name" {
  description = "Domain name for the ALB HTTPS listener (leave empty to skip HTTPS)"
  default     = ""
}

Step 2: Networking — VPC and Subnets

Remember the 10+ manual console steps from Part 1? Creating the VPC, enabling DNS hostnames, creating four subnets, allocating an EIP, creating the NAT Gateway, and setting up route tables? Here is all of that, codified.

2.1 Defining the Network (`vpc.tf`)

# vpc.tf
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true
  tags = { Name = "${var.project_name}-vpc" }
}

resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id
  tags   = { Name = "${var.project_name}-igw" }
}

# Creates 2 Public Subnets dynamically using count
resource "aws_subnet" "public" {
  count                   = length(var.public_subnet_cidrs)
  vpc_id                  = aws_vpc.main.id
  cidr_block              = var.public_subnet_cidrs[count.index]
  availability_zone       = var.availability_zones[count.index]
  map_public_ip_on_launch = true
  tags = { Name = "${var.project_name}-public-${count.index + 1}" }
}

# Creates 2 Private Subnets dynamically using count
resource "aws_subnet" "private" {
  count             = length(var.private_subnet_cidrs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnet_cidrs[count.index]
  availability_zone = var.availability_zones[count.index]
  tags = { Name = "${var.project_name}-private-${count.index + 1}" }
}

resource "aws_eip" "nat" {
  domain = "vpc"
}

resource "aws_nat_gateway" "main" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.public[0].id
  depends_on    = [aws_internet_gateway.main]
}

Notice the depends_on block in the NAT Gateway. This tells Terraform it must wait for the Internet Gateway to exist before creating the NAT Gateway. Terraform maps out a dependency graph for everything automatically, but occasionally explicit dependencies are helpful.

Step 3: Security Groups

In Part 1, we made sure the EC2 instance only accepted traffic from the ALB. Let's replicate that.

3.1 Firewall Rules (`security_groups.tf`)

# security_groups.tf
resource "aws_security_group" "alb" {
  name        = "${var.project_name}-sg-alb"
  description = "Allow HTTP/HTTPS inbound to ALB"
  vpc_id      = aws_vpc.main.id
}

resource "aws_vpc_security_group_ingress_rule" "alb_http" {
  security_group_id = aws_security_group.alb.id
  from_port         = 80
  to_port           = 80
  ip_protocol       = "tcp"
  cidr_ipv4         = "0.0.0.0/0"
}

resource "aws_security_group" "ec2" {
  name        = "${var.project_name}-sg-ec2"
  description = "Allow traffic from ALB and SSH"
  vpc_id      = aws_vpc.main.id
}

resource "aws_vpc_security_group_ingress_rule" "ec2_from_alb" {
  security_group_id            = aws_security_group.ec2.id
  from_port                    = 80
  to_port                      = 80
  ip_protocol                  = "tcp"
  referenced_security_group_id = aws_security_group.alb.id
}

Look at referenced_security_group_id = aws_security_group.alb.id. This is the exact Terraform equivalent of selecting the ALB security group as the source in the AWS Console.

Step 4: Application Load Balancer

Our ALB configuration includes a powerful feature: conditional HTTPS.

4.1 ALB Configuration (`alb.tf`)

# alb.tf
resource "aws_lb" "main" {
  name               = "${var.project_name}-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = aws_subnet.public[*].id
}

resource "aws_lb_target_group" "app" {
  name     = "${var.project_name}-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id

  health_check {
    path    = "/"
    matcher = "200-399"
  }
}

resource "aws_lb_listener" "http" {
  load_balancer_arn = aws_lb.main.arn
  port              = 80
  protocol          = "HTTP"

  default_action {
    type = var.domain_name != "" ? "redirect" : "forward"

    # Forward to EC2 if no domain is provided
    dynamic "forward" {
      for_each = var.domain_name == "" ? [1] : []
      content {
        target_group {
          arn = aws_lb_target_group.app.arn
        }
      }
    }

    # Redirect to HTTPS if domain is provided
    dynamic "redirect" {
      for_each = var.domain_name != "" ? [1] : []
      content {
        port        = "443"
        protocol    = "HTTPS"
        status_code = "HTTP_301"
      }
    }
  }
}

If you leave domain_name = "" in your variables, it provisions a standard HTTP load balancer. Once you are ready for production, you just update that variable to "yourdomain.com". Run terraform apply again, and Terraform will dynamically generate an ACM certificate and update the ALB to redirect HTTP to HTTPS.

Step 5: EC2 Instance and Bootstrap

In Part 1, we manually SSH'd into the instance to install Docker and Git. Let's automate that using an EC2 user_data script.

5.1 User Data Script (`user_data.sh`)

This script runs automatically the very first time the EC2 instance boots up.

#!/bin/bash
set -euo pipefail
exec > /var/log/user-data.log 2>&1

apt-get update -y && apt-get upgrade -y

# Install Docker
curl -fsSL https://get.docker.com | sh
usermod -aG docker ubuntu

# Install Git
apt-get install -y git

# Clone application repository
sudo -u ubuntu git clone "${app_repo_url}" /home/ubuntu/apartment-deployment

5.2 EC2 Configuration (`ec2.tf`)

# ec2.tf
data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"] # Canonical
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-*"]
  }
}

resource "aws_instance" "app" {
  ami                    = data.aws_ami.ubuntu.id
  instance_type          = var.instance_type
  key_name               = var.key_pair_name
  subnet_id              = aws_subnet.private[0].id
  vpc_security_group_ids = [aws_security_group.ec2.id]

  user_data = base64encode(templatefile("${path.module}/user_data.sh", {
    app_repo_url = var.app_repo_url
  }))

  tags = { Name = "${var.project_name}-server" }
}

# Instance Connect Endpoint for secure, bastion-less SSH
resource "aws_ec2_instance_connect_endpoint" "main" {
  subnet_id          = aws_subnet.private[0].id
  security_group_ids = [aws_security_group.ec2.id]
}

The data "aws_ami" block dynamically fetches the latest Ubuntu 24.04 AMI ID. You no longer have to hardcode AMI IDs that break when you switch AWS regions.

Step 6: Outputs and Deployment

6.1 Outputs Configuration (`outputs.tf`)

Outputs print useful information to your terminal after the deployment finishes.

# outputs.tf
output "alb_dns_name" {
  description = "DNS name of the Application Load Balancer"
  value       = aws_lb.main.dns_name
}

output "ssh_command" {
  description = "Command to SSH into the EC2 instance"
  value       = "aws ec2-instance-connect ssh --instance-id ${aws_instance.app.id} --os-user ubuntu"
}

6.2 Variable Assignment (`terraform.tfvars`)

Copy the example file to .tfvars (which is ignored by Git, keeping your secrets safe):

cp terraform.tfvars.example terraform.tfvars
nano terraform.tfvars

Update it with your values:

aws_region    = "us-east-1"
key_pair_name = "apartment-key"
app_repo_url  = "https://github.com/your-repo/apartment-deployment.git"
# domain_name = "yourdomain.com"

6.3 Deploying the Infrastructure

Initialize Terraform. This downloads the necessary AWS provider plugins.

terraform init

Run a plan to see exactly what Terraform is going to create.

terraform plan

You'll see a list of 31 resources that Terraform plans to create (VPC, Subnets, ALB, EC2, etc.).

Finally, apply the configuration:

terraform apply

Type yes when prompted.

Terraform will create everything in the right order. It automatically waits the 2 minutes required for the NAT Gateway to provision before attaching routes to it.

When it finishes, it will print your outputs:

Outputs:

alb_dns_name = "apartment-alb-xxxxxxxxxx.us-east-1.elb.amazonaws.com"
ssh_command = "aws ec2-instance-connect ssh --instance-id i-0123456789abcdef0 --os-user ubuntu"

Copy that SSH command, connect to your server, configure your .env files (just like we did in Part 1), and run docker compose up -d --build.

Everything we spent an entire article building manually was just created in about 2 minutes.

Step 7: The Cleanup — One Command

In Part 1, tearing down this infrastructure required manually deleting 12 different resources in exactly the right order, waiting for timeouts, and dealing with DependencyViolation errors.

Here is the Terraform version:

terraform destroy

Type yes.

Terraform looks at its state file, maps the reverse dependencies, and destroys everything flawlessly. It detaches the IGW before deleting the VPC. It waits for the NAT Gateway to delete before releasing the EIP.

Conclusion & Next Steps

This setup gets you a very solid production foundation. But cloud architecture never stops evolving. Our next steps for this platform would include:

Auto-Scaling (ASG): Moving from a single EC2 instance to an Auto Scaling Group behind the ALB to handle traffic spikes.

CI/CD Pipeline: Using GitHub Actions to automatically build the Docker images and trigger rolling updates on EC2 via AWS CodeDeploy.

If you found this helpful, drop a like! You can find the full source code (including all the Terraform files) on the terraform directory of Github.

Deploying a Full-Stack Production Application on AWS How-To-Guide

Israel — Sat, 05 Sep 2026 09:24:29 +0000

REPO:https://github.com/Israel-dot-com/apartment-deployment-main

This is the first article in my DevOps Porfolio series. We'll deploy a Full Stack Application, It currently runs perfectly locally with docker compose up.

Now we want it on the internet.

It's a React + FastAPI + PostgreSQL project, to get it up and running via the cloud, We'll need to create a proper isolated network, a load balancer, and security groups & we'll do it all through the AWS Console, it looks tedious and there has to be a better way but we'll persevere through it.

Introduction
Pre-requisites
Step 1: Networking — Build the VPC Foundation
- 1.1 Create the VPC
- 1.2 Create the Subnets
- 1.3 Create and Attach the Internet Gateway
- 1.4 Create the NAT Gateway
- 1.5 Create and Configure Route Tables
Step 2: Security Groups
- 2.1 Create ALB Security Group
- 2.2 Create EC2 Security Group
Step 3: Launch EC2 Instance
- 3.1 Launch the Instance
- 3.2 SSH Access via Instance Connect Endpoint
Step 4: Install Prerequisites on EC2
Step 5: Deploy the Application
- 5.1 Clone the Repository
- 5.2 Configure Environment Files
- 5.3 Build and Start the Stack
- 5.4 Debugging and Fixes
Step 6: Application Load Balancer
- 6.1 Create Target Group
- 6.2 Create the ALB
- 6.3 Test the Application
Step 7: The Cleanup Problem
Next Steps

Introduction

I'll be using a previous unfinished project, a hospitality and car rental marketplace. Vendors list short-let apartments and vehicles, complete identity verification, and manage bookings. Admins moderate listings and track analytics through a dashboard. Users browse, book, and manage support tickets.

The architecture looks like this:

A custom VPC with public and private subnets across 2 availability zones
Two EC2 instances running the Docker Compose stack in a private subnet
An Application Load Balancer handling all incoming traffic
Layered security groups so the EC2 never communicates directly with the internet
A fully functional application accessible via the ALB DNS name

Pre-requisites

Before deploying, make sure the following are ready:

1. AWS Account

An AWS account with administrative access
AWS CLI configured (optional — we'll use the Console for everything)

2. Application Code

The application repository with the Docker Compose configuration:

git clone https://github.com/Israel-dot-com/apartment-deployment-main

3. EC2 Key Pair

You'll need an EC2 key pair for SSH access:

EC2 Console → Key Pairs → Create key pair
Name: apartment
Key pair type: RSA
Private key format: .pem
Download and save the .pem file securely

Step 1: Networking — Build the VPC Foundation

Overview

We are going to create a custom VPC with public and private subnets across 2 availability zones for the application. Using the default VPC would put everything in public subnets with wide-open routing — fine for a quick test, not suitable for anything production-facing.

What we'll create:

We can create these a the same time from one interface on the Create VPC console.

VPC — Virtual Private Cloud with 10.0.0.0/16 CIDR (65,536 IPs)
Public Subnets — 2 subnets for internet-facing resources (ALB, NAT Gateway)
Private Subnets — 2 subnets for the application server
Internet Gateway — Internet access for public subnets
NAT Gateway — Outbound-only internet for private subnets (Docker pulls, system updates)
Route Tables — Traffic routing configuration

1.1 Create the VPC

1.2 Create the Subnets

We need 4 subnets across 2 availability zones. The ALB requires subnets in at least 2 AZs, and the second private subnet provides room for future scaling.

VPC Console → Subnets → Create subnet

Select VPC: apartment-vpc

Public Subnet A:

Setting	Value
Subnet name	`apartment-public-a`
Availability Zone	us-east-1a
IPv4 CIDR block	`10.0.1.0/24`

Click Add new subnet to add the remaining three in one go:

Public Subnet B:

Setting	Value
Subnet name	`apartment-public-b`
Availability Zone	us-east-1b
IPv4 CIDR block	`10.0.2.0/24`

Private Subnet A:

Setting	Value
Subnet name	`apartment-private-a`
Availability Zone	us-east-1a
IPv4 CIDR block	`10.0.11.0/24`

Private Subnet B:

Setting	Value
Subnet name	`apartment-private-b`
Availability Zone	us-east-1b
IPv4 CIDR block	`10.0.12.0/24`

Click Create subnet.

Enable auto-assign public IPv4 for public subnets:

For each public subnet (apartment-public-a and apartment-public-b):

Select the subnet → Actions → Edit subnet settings
Check Enable auto-assign public IPv4 address
Save

1.3 Create and Attach the Internet Gateway

The Internet Gateway gives your public subnets a path to the internet. Without it, nothing in the VPC can reach the outside world.

VPC Console → Internet Gateways → Create internet gateway

Setting	Value
Name tag	`apartment-igw`

Click Create internet gateway.

Now attach it to the VPC:

Select apartment-igw → Actions → Attach to VPC → select apartment-vpc → Attach

Verify:

State should show: Attached
Attached VPC: apartment-vpc

1.4 Create the NAT Gateway

The EC2 instance lives in a private subnet, no direct internet access. But it still needs to pull Docker images, install system packages, and download updates. The NAT Gateway provides outbound-only internet access. Traffic goes out, but nothing can initiate a connection in.

VPC Console → NAT Gateways → Create NAT gateway

Setting	Value
Name	`apartment-nat`
Subnet	`apartment-public-a` (must be a public subnet)
Connectivity type	Public
Elastic IP allocation ID	Click Allocate Elastic IP

Click Create NAT gateway.

Important: The NAT Gateway takes 1-2 minutes to become available. Wait for the status to change from Pending to Available before proceeding to route tables.

Save This Value:

Elastic IP address (you'll need this for cleanup)

1.5 Create and Configure Route Tables

We need two route tables with different routing rules:

Public route table — sends internet traffic through the Internet Gateway
Private route table — sends internet traffic through the NAT Gateway

Public Route Table

VPC Console → Route Tables → Create route table

Setting	Value
Name	`apartment-rt-public`
VPC	`apartment-vpc`

Click Create route table.

Add route to Internet Gateway:

Select apartment-rt-public → Routes tab → Edit routes → Add route

Destination	Target
`0.0.0.0/0`	Select Internet Gateway → `apartment-igw`

Click Save changes.

Associate public subnets:

Subnet associations tab → Edit subnet associations → select both apartment-public-a and apartment-public-b → Save associations

Private Route Table

VPC Console → Route Tables → Create route table

Setting	Value
Name	`apartment-rt-private`
VPC	`apartment-vpc`

Click Create route table.

Add route to NAT Gateway:

Select apartment-rt-private → Routes tab → Edit routes → Add route

Destination	Target
`0.0.0.0/0`	Select NAT Gateway → `apartment-nat`

Click Save changes.

Associate private subnets:

Subnet associations tab → Edit subnet associations → select both apartment-private-a and apartment-private-b → Save associations

[screenshot: route tables showing public→IGW and private→NAT routes]

Verify — Route Table Validation:

Route Table	Route `0.0.0.0/0` →	Associated Subnets
apartment-rt-public	apartment-igw	apartment-public-a, apartment-public-b
apartment-rt-private	apartment-nat	apartment-private-a, apartment-private-b

That's the entire network foundation done. We have a VPC with proper separation between public and private resources, internet access through the IGW, and outbound-only access through the NAT for our private subnets.

Step 2: Security Groups

Overview

We need two security groups that work together as layers. The key principle: the EC2 instance only accepts traffic from the ALB, never directly from the internet.

2.1 Create ALB Security Group

This security group allows HTTP and HTTPS traffic from anywhere — the ALB is the public-facing entry point.

VPC Console → Security Groups → Create security group

Setting	Value
Security group name	`apartment-sg-alb`
Description	Allow HTTP/HTTPS inbound to ALB
VPC	`apartment-vpc`

Inbound rules — Add rules:

Type	Port	Source	Description
HTTP	80	`0.0.0.0/0`	HTTP from internet
HTTPS	443	`0.0.0.0/0`	HTTPS from internet

Outbound rules: Leave default (All traffic → 0.0.0.0/0)

Click Create security group.

2.2 Create EC2 Security Group

This security group only allows traffic from the ALB — not from the public internet. This is the key security benefit of the architecture.

VPC Console → Security Groups → Create security group

Setting	Value
Security group name	`apartment-sg-ec2`
Description	Allow traffic from ALB and SSH
VPC	`apartment-vpc`

Inbound rules — Add rules:

Type	Port	Source	Description
HTTP	80	Select `apartment-sg-alb` (security group)	Traffic from ALB only
SSH	22	My IP (or your specific IP/32)	SSH access

Outbound rules: Leave default (All traffic → 0.0.0.0/0)

Click Create security group.

Important: For the HTTP rule, the source is the ALB security group ID, not a CIDR block. This means even if someone discovers the EC2's private IP address, they cannot reach it directly. All traffic must flow through the load balancer.

[screenshot: EC2 security group showing port 80 source as apartment-sg-alb]

Verify — Security Group Validation:

Security Group	Inbound Rules
apartment-sg-alb	80 from `0.0.0.0/0`, 443 from `0.0.0.0/0`
apartment-sg-ec2	80 from `apartment-sg-alb`, 22 from your IP

Step 3: Launch EC2 Instance

3.1 Launch the Instance

EC2 Console → Instances → Launch instances

Setting	Value
Name	`apartment-server`
Application and OS Images	Ubuntu Server 24.04 LTS (HVM), SSD
Architecture	64-bit (x86)
Instance type	`t3.medium`
Key pair	`apartment` (created in pre-requisites)

Network settings → Click Edit:

Setting	Value
VPC	`apartment-vpc`
Subnet	`apartment-private-a`
Auto-assign public IP	Disable
Security group	Select existing → `apartment-sg-ec2`

Configure storage:

Setting	Value
Size	30 GiB
Volume type	gp3
Encrypted	Yes

Click Launch instance.

Verify:

Instance state: Running
Private IPv4: Should be in the 10.0.10.x range
Public IPv4: None (this is correct — it's in a private subnet)
Security group: apartment-sg-ec2

3.2 SSH Access via Instance Connect Endpoint

Since the EC2 is in a private subnet with no public IP, we cannot SSH directly. We'll use an EC2 Instance Connect Endpoint — no bastion host required, no public IP needed.

VPC Console → Endpoints → Create endpoint

Setting	Value
Name tag	`apartment-eice`
Service category	EC2 Instance Connect Endpoint
VPC	`apartment-vpc`
Subnet	`apartment-private-a`
Security group	`apartment-sg-ec2`

Click Create endpoint. Wait for the status to become Available (takes 2-3 minutes).

Connect to the instance via the Instance Endpoint Connect Endpoint

Step 4: Install Prerequisites on EC2

All we need on the server is Docker, Docker Compose, and Git. We can use this script to install everything:

#!/bin/bash

# Update system
sudo apt update && sudo apt upgrade -y

# Install Docker
curl -fsSL https://get.docker.com | sudo sh

# Allow current user to run Docker without sudo
sudo usermod -aG docker $USER
newgrp docker

# Install Git
sudo apt install -y git

# Verify installations
docker --version
docker compose version
git --version

Save this as install.sh, give it permission with chmod +x install.sh, and run it. Or just paste the commands directly.

Verify Installation:

docker --version
# Docker version 28.x.x

docker compose version
# Docker Compose version v2.x.x

git --version
# git version 2.x.x

Step 5: Deploy the Application

5.1 Clone the Repository

git clone https://github.com/Israel-dot-com/apartment-deployment-main

The repository structure:

apartment-deployment/
├── be-apartment/          # FastAPI backend
│   ├── api/               # Routes, models, schemas, services
│   ├── alembic/           # Database migrations
│   ├── Dockerfile
│   ├── .env.sample        # Example backend config
│   └── entrypoint.sh      # Runs migrations then starts Uvicorn
├── fe-apartment/          # React frontend
│   ├── src/
│   └── Dockerfile         # Multi-stage build → Nginx
├── nginx/                 # Reverse proxy config
│   └── nginx.conf
├── docker-compose.yml     # Orchestrates all services
└── .env                   # Root env (DB credentials)

5.2 Configure Environment Files

Here's the first gotcha. .env files are in .gitignore, as they should be, so they don't exist after cloning. If you skip this step and run docker compose up directly, you'll see:

WARN[0000] The "DB_NAME" variable is not set. Defaulting to a blank string.
WARN[0000] The "DB_USER" variable is not set. Defaulting to a blank string.
WARN[0000] The "DB_PASSWORD" variable is not set. Defaulting to a blank string.

PostgreSQL starts with blank credentials, fails its health check, and every dependent service collapses. Not helpful.

Create the root .env (used by the PostgreSQL service in docker-compose.yml):

cat > .env << 'EOF'
PYTHON_ENV=prod

DB_TYPE=postgresql
DB_NAME=apartment
DB_USER=apartment
DB_PASSWORD=YourSecurePasswordHere

SECRET_KEY=generate-a-random-string-here
ALGORITHM=HS256
ACCESS_TOKEN_EXPIRE_MINUTES=600
JWT_REFRESH_EXPIRY=30

APP_URL=http://localhost
FRONTEND_URL=http://localhost
EOF

Generate a strong secret key:

openssl rand -hex 32

Use the output as your SECRET_KEY and DB_PASSWORD values.

Create the backend .env (used by the FastAPI application):

Copy the sample file and update it:

cp be-apartment/.env.sample be-apartment/.env
nano be-apartment/.env

At minimum, make sure these values are set and match the root .env:

DB_URL=postgresql://apartment:YourSecurePasswordHere@postgres:5432/apartment
SECRET_KEY=generate-a-random-string-here

Important: The DB_PASSWORD in the root .env must match the password in the DB_URL in be-apartment/.env. The hostname in DB_URL must be postgres — this is the Docker Compose service name, not localhost.

5.3 Build and Start the Stack

docker compose up -d --build

The first build takes a few minutes — Docker is pulling base images, installing Python dependencies (pip install), building the React frontend (npm run build), and creating all four container images. Subsequent builds use Docker's cache and are much faster.

Wait about 30 seconds for health checks to complete, then check the status:

docker compose ps

Expected output:

NAME                    STATUS          PORTS
apartment-postgres      Up (healthy)    5432/tcp
apartment-backend-1     Up (healthy)    8000/tcp
apartment-frontend      Up              80/tcp
apartment-nginx         Up              0.0.0.0:80->80/tcp

All four services should show Up with the postgres and backend containers showing (healthy).

NAME                    STATUS          PORTS
apartment-postgres      Up (healthy)    5432/tcp
apartment-backend-1     Up (healthy)    8000/tcp
apartment-frontend      Up              80/tcp
apartment-nginx         Up              0.0.0.0:80->80/tcp

Check the backend logs to confirm migrations ran successfully:

docker compose logs backend --tail 20

backend-1  | Running database migrations...
backend-1  | INFO  [alembic.runtime.migration] Running upgrade  -> 22962e293a83, apply existing migrations
backend-1  | INFO  [alembic.runtime.migration] Running upgrade 22962e293a83 -> a1b2c3d4e5f6, add phone_number and avatar_url
backend-1  | ...
backend-1  | INFO  [alembic.runtime.migration] Running upgrade 486419238951 -> c8f1b2e9a7d0, set property status default
backend-1  | Starting FastAPI...
backend-1  | INFO:     Uvicorn running on http://0.0.0.0:8000

All migrations applied. FastAPI is running. But we still can't access the application from a browser — the EC2 is in a private subnet with no public IP. We need the load balancer.

Step 6: Application Load Balancer

Overview

The ALB sits in the public subnets and forwards traffic to the EC2 in the private subnet. This is how the application becomes accessible from the internet while keeping the server isolated.

6.1 Create Target Group

The target group tells the ALB where to send traffic and how to check if the target is healthy.

EC2 Console → Load Balancing → Target Groups → Create target group

Setting	Value
Target type	Instances
Target group name	`apartment-tg`
Protocol	HTTP
Port	80
VPC	`apartment-vpc`
Protocol version	HTTP1

Health checks:

Setting	Value
Health check protocol	HTTP
Health check path	`/`
Healthy threshold	3
Unhealthy threshold	3
Timeout	10 seconds
Interval	30 seconds
Success codes	200-399

Click Next.

Register targets:

Select your apartment-server instance → click Include as pending below → click Create target group.

Wait 30-60 seconds, then verify the target shows as healthy in the Targets tab.

6.2 Create the ALB

EC2 Console → Load Balancing → Load Balancers → Create load balancer → Application Load Balancer → Create

Setting	Value
Load balancer name	`apartment-alb`
Scheme	Internet-facing
IP address type	IPv4

Network mapping:

Setting	Value
VPC	`apartment-vpc`
Mappings	Select both: `apartment-public-a` (us-east-1a) and `apartment-public-b` (us-east-1b)

Security groups:

Remove the default security group. Select apartment-sg-alb.

Listeners and routing:

Protocol	Port	Default action
HTTP	80	Forward to `apartment-tg`

Click Create load balancer.

Wait for the ALB state to change from Provisioning to Active (takes 2-3 minutes).

Optional: Add HTTPS

If you have a domain name, you can add HTTPS with a free AWS certificate:

ACM Console (switch to us-east-1 if using CloudFront, otherwise use your ALB's region) → Request certificate → Request a public certificate
Add your domain name(s) → DNS validation → Request
Click Create records in Route 53 to validate automatically
Wait for status: Issued
Go back to your ALB → Listeners → Add listener
- Protocol: HTTPS, Port: 443
- Default action: Forward to apartment-tg
- Default SSL/TLS certificate: Select your ACM certificate
Edit the HTTP:80 listener → change action to Redirect to HTTPS port 443

6.3 Test the Application

Open the ALB DNS name in your browser:

http://apartment-alb-1060582062.us-east-1.elb.amazonaws.com

Frontend loads
Backend API responds at /api/v1/
User registration and login

Step 7: The Cleanup Problem

The application is deployed and working. But now let's say we're done testing and want to tear everything down to stop paying for it.

Here's what we have to delete, manually, in the correct dependency order:

#	Resource	Console Location	Wait Required?
1	EC2 Instance	EC2 → Instances → Terminate	Wait for termination
2	Load Balancer	EC2 → Load Balancers → Delete	—
3	Target Group	EC2 → Target Groups → Delete	—
4	NAT Gateway	VPC → NAT Gateways → Delete	⏳ Wait 1-2 minutes
5	Elastic IP	VPC → Elastic IPs → Release	Must wait for NAT GW deletion
6	Instance Connect Endpoint	VPC → Endpoints → Delete	⏳ Wait 2-3 minutes
7	Internet Gateway	VPC → IGWs → Detach → Delete	Must detach before deleting
8	Security Groups	VPC → Security Groups → Delete	Can't delete while ALB/EC2 exist
9	Subnets	VPC → Subnets → Delete	—
10	Route Tables	VPC → Route Tables → Delete	Must remove associations first
11	VPC	VPC → Your VPCs → Delete	Everything above must be gone

You have to delete them in order or the VPC deletion fails with a dependency error. Delete things in the wrong order and you get DependencyViolation: resource has a dependent object. Try to delete the NAT Gateway and the Elastic IP at the same time and the EIP release fails because the NAT Gateway is still in the deleting state.

I spent a lot of time manually creating resources through the console, waiting for resources to finish deleting, and retrying failed deletions.

It's tedious doing this every time you need to to scaffold the entire architecture. That's where Terraform comes in, Terraform is an infrastructure as code that lets you build, change, and version our target infrastructure safely and efficiently, in our next article we'll look into spinning up this project with Terraform

Reviving DevOps

Israel — Mon, 31 Aug 2026 14:59:46 +0000

Okay, welcome back.
Sometimes last week i built a quick project on AWS, a serverless data analysis platform using S3,AWS Glue, Athena and Quicksight. It was a refresher on AWS services.

Gone back to the basics properly and for practice, i'll be building and writing about 6 small production-shaped projects exercising the almighty DevOps Lifecycle.

First will be a production three tier Application then
A CI/CD Production Pipeline
A Highly Available Web Platform
An Observability and Operations Platform
An Infrastructure + GitOps Style Workflow
& for my Magnum Opus, the Highly Available MedusaJS store i promised back last year here.

See you.

Building a Serverless Netflix Data Analytics Platform with AWS Glue, Athena and QuickSight.

Israel — Mon, 17 Aug 2026 08:04:50 +0000

Quick Data & Cloud Engineering project

Hey Guys, Today we'll be building a serverless data analytics platform using AWS services.

Our goal is pretty straight forward, We want to take a Netflix dataset in CSV format, store it in Amazon S3, catalogue and transform it using AWS Glue, query the processed data using Amazon Athena, and finally create interactive dashboards using Amazon QuickSight, now called Quick, i think.

The idea is to simulate how companies handle analytics workloads without managing servers or traditional database infrastructure and to get a personal feel of how these services work.

Again, First, we store our raw Netflix dataset inside Amazon S3. Then we use AWS Glue to discover the structure of the data and create metadata using the Glue Data Catalog.

After that, we create an ETL pipeline that cleans the dataset and converts it from CSV into Parquet format. Parquet is much better suited for analytics workloads because it is compressed and column-based and it takes less time to query than CSV as we'll see.

Once the data is processed, Amazon Athena allows us to query it using SQL. Finally, Amazon QuickSight connects to Athena and turns those queries into dashboards and visual insights.

Simple enough.

Introduction
Step-by-Step Setup
- STEP 1) Setting Up the S3 Data Lake
- STEP 2) Creating the AWS Glue Data Catalog and Crawler
- STEP 3) Building the AWS Glue ETL Pipeline
- STEP 4) Building Analytics with Athena and QuickSight
- STEP 5) Next Steps (Automate with S3 Event Notification and EventBridge)

1. Setting Up the S3 Data Lake

The first step is creating the storage layer.

Amazon S3 will act as our data lake.

We separate our data into different stages on the S3 Bucket

Raw data
Processed data
Athena query results

This makes the workflow easier to understand and maintain.

Our bucket structure looks like

netflix-analytics-data-lake/

├── raw/
│   └── netflix_titles.csv
│
├── processed/
│
└── athena-results/

The raw folder contains the original csv file.

After creating your S3 Bucket

Block all public access
Enable Bucket versioning &
Server-side encryption

The dataset is uploaded into raw/netflix_titles.csv

Creating the AWS Glue Data Catalog and Crawler

Create a database, netflix_analytics

This database will contain our tables.

Create an IAM Role for Glue

The role requires permissions to:

Read from S3
Write metadata
Create Glue tables

You should ideally use the least privilege required for the task but for now we'll use Full Access.

AmazonS3FullAccess

Creating the Glue Crawler

A crawler automatically discovers the structure of our dataset.

Navigate to:

AWS Glue and create a Crawler and name it netflix-raw-data-crawler

The Data source would be the S3 Bucket you created earlier, netflix_analytics

Table prefix, raw_

Run the crawler.

Glue scans the CSV file and creates a table.

Next, you Test the Glue Table with Athena

Before building the ETL(Extract, Transform, Load) pipeline, we verify that Athena can read the table.

Open Athena and select the database and run,

SELECT * FROM raw_netflix_titles LIMIT 10;

If everything works, we should see Netflix records.

At this point, we have successfully connected:

S3 to Glue and Glue to Athena

Building the AWS Glue ETL Pipeline

Now we move from transforming the raw data into processed data.
The Goal in this step is to convert, the CSV file into Parquet format/file.

Creating the Glue Visual ETL Job

On the AWS Glue page, navigate to Visual ETL on the sidebar,

Create a new job. netflix-csv-to-parquet

The default IAM role it suggests is missing a couple roles, s3:GetObject s3:PutObject s3:ListBucket add these and you won't run into the error i ran into.

AWSGlueServiceRole-netflix-analytics

Here we want to add a source, our S3 bucket take the table, apply a mapping to it, drop empty fields, and add a destination to drop the finished parquet file

Adding the Source

Applying Schema Mapping

This mapping handles our schema changes.

DropNullFields

Optional but this removes fields where every value is empty.

Configuration:

Enable: Empty String "null" String

Writing Parquet Output

s3://your-bucket/processed/netflix_titles/

Run the Glue job and the output should look like this after a few minutes

processed/netflix_titles/part-00000-snappy.parquet

A Small IAM Challenge

During the first run, the Glue job might fail.

The error:

not authorized to perform: s3:PutObject

Easily fixable by adding s3:GetObject s3:PutObject s3:ListBucket to your gluerole
Fixed and it works perfectly.

4. Building Analytics with Athena and QuickSight

Now we have clean Parquet data.

The Next step is Querying the Processed Data with Athena

This Query tells us the Top Producing countries.

SELECT
country,
COUNT(*) AS total_titles
FROM processed_netflix_titles
GROUP BY country
ORDER BY total_titles DESC
LIMIT 10;

If you run a query with the raw csv vs the parquet file, you'll see the parquet is faster which is the entire point of the transformation.

Now we create the dashboard layer.

Create a Quick Account,

Add a New Dataset, Select Athena, Choose the database and processed table

Import into SPICE and you can now you can create your dashboard

You can create visualisations here that answer specific questions.

Visual 1: Content Distribution

Question:

What type of content dominates Netflix?

Next Steps

The current pipeline is a batch analytics workflow.

The next step would be automating this workflow with EventBridge and S3 Event Notifications. I'll do that in a seperate article. See you soon.

Deploying a MedusaJS 2.0 Store on AN AWS EC2 Instance.

Israel — Fri, 26 Sep 2025 20:36:27 +0000

So you have decided to set up an online store and you would rather set it up your self, you're in the right place.

We'll Deploy a MedusaJS Backend and Storefront on an Ubuntu Server. In a later article we'll look at using other AWS services to build a more resilient version. I'll link it here when it's ready [link]

Introduction
Pre-requisites
Step-by-Step Deployment
- STEP 1) Server Provisioning
- STEP 2) Installing Prerequisites
- STEP 3) Running the Medusa Backend
- STEP 4) Reverse Proxy with Nginx
- STEP 5) Setting up the Frontend
- STEP 6) Debugging and Fixes
- STEP 7) Next Steps (Future Work)
Why Deploy MedusaJS on a Scalable Server?

There are many modern, headless commerce platforms, and MedusaJS is one of the most versatile for building full-featured online stores. Medusa makes store development seamless but deploying a production-ready application can be challenging without the right setup and automation practices.

That’s what this article will focus on, configuring an Ubuntu server to handle it and serving it through Nginx so safe to say that by the end we'll have

A live MedusaJS application running on your server

Clearly separated and functional routes for admin, API, authentication, and storefront

A persistent frontend using PM2 for reliability

Nginx properly configured to handle the admin panel, country-specific routes and SSL

So whether you’re a developer looking to build more features for a specific use-case or just exploring headless commerce, this step-by-step guide will give you everything you need to host Medusa yourself.

Server Provisioning

Start by provisioning an ubuntu server, we'll create a new security group with inbound rules; 22 from your IP, 80 and 443 from anywhere.
You should have something like this

A t3 medium server with about 30GB of storage space should do just fine.

Installing the Prerequisites

All we need is a Server, a domain and a stripe account.

We'll need to install quite a few things to get our Medusa Store up and running.

Node
Docker & Docker Compose
Curl & Git
PM2
Nginx
Certbot

We can use this script to install everything we need.
We'll install the Certbot later since it requires interaction

#!/bin/bash

# Update system
sudo apt update && sudo apt upgrade -y

# Install prerequisites
sudo apt install -y ca-certificates curl gnupg lsb-release

# Add Docker’s official GPG key
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Add Docker’s APT repository
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Install Docker Engine, CLI, containerd, and Docker Compose plugin
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

# Enable and start Docker
sudo systemctl enable docker
sudo systemctl start docker

# Allow current user to run Docker without sudo
sudo usermod -aG docker $USER
newgrp docker

# Verify Docker
docker --version
docker compose version

# Install Git
sudo apt install -y git

# Install Nginx
sudo apt install -y nginx
sudo systemctl enable nginx
sudo systemctl start nginx

# Install Node.js (LTS) and npm
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt install -y nodejs

# Install PM2 globally
sudo npm install -g pm2

# Setup PM2 startup (so it restarts apps on reboot)
pm2 startup systemd -u $USER --hp $HOME

Running the Backend Server

We'll set up the Medusa Backend using Docker.

Let's begin by cloning the Repo

git clone https://github.com/medusajs/medusa-starter-default.git --depth=1 medusa-server
Next, create a Docker compose file, docker-compose.yml in the new repo

services:
  # PostgreSQL Database
  postgres:
    image: postgres:15-alpine
    container_name: medusa_postgres
    restart: unless-stopped
    environment:
      POSTGRES_DB: medusa-store
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - medusa_network

  # Redis
  redis:
    image: redis:7-alpine
    container_name: medusa_redis
    restart: unless-stopped
    ports:
      - "6379:6379"
    networks:
      - medusa_network

  # Medusa Server
  # This service runs the Medusa backend application
  # and the admin dashboard.
  medusa:
    build: .
    container_name: medusa_backend
    restart: unless-stopped
    depends_on:
      - postgres
      - redis
    ports:
      - "9000:9000"
    environment:
      - NODE_ENV=production
      - DATABASE_URL=postgres://postgres:postgres@postgres:5432/medusa-store
      - REDIS_URL=redis://redis:6379
    env_file:
      - .env
    volumes:
      - .:/app
      - /app/node_modules
    networks:
      - medusa_network

volumes:
  postgres_data:

networks:
  medusa_network:
    driver: bridge

This creates three new services we'll need, Redis, Postgres and Medusa

Create a Dockerfile, Dockerfile

# Development Dockerfile for Medusa
FROM node:20-alpine

# Set working directory
WORKDIR /server

# Copy package files and npm config
COPY package.json package-lock.json ./

# Install all dependencies using npm
RUN npm install

# Copy source code
COPY . .

# Expose the port Medusa runs on
EXPOSE 9000

# Start with migrations and then the development server
CMD ["./start.sh"]

Now create the start script start.sh and give it permission to run with chmod u+x start.sh

#!/bin/sh

# Run migrations and start server
echo "Running database migrations..."
npx medusa db:migrate

echo "Seeding database..."
npm run seed || echo "Seeding failed, continuing..."

echo "Starting Medusa development server..."
npm run dev

Run npm install to install the dependencies we'll be working with.

Replace the medusa-config.ts file with this

import { loadEnv, defineConfig } from '@medusajs/framework/utils'

loadEnv(process.env.NODE_ENV || 'production', process.cwd())

module.exports = defineConfig({
  projectConfig: {
    databaseUrl: process.env.DATABASE_URL,
    databaseDriverOptions: {
      ssl: false,
      sslmode: "disable",
    },

    http: {
      storeCors: process.env.STORE_CORS!,
      adminCors: process.env.ADMIN_CORS!,
      authCors: process.env.AUTH_CORS!,
      jwtSecret: process.env.JWT_SECRET || "supersecret",
      cookieSecret: process.env.COOKIE_SECRET || "supersecret",
    },
  },

  admin: {
    vite: () => {
      return {
        server: {
          allowedHosts: [".domainhere.com"], // add your domain here
        },
      }
    },
  },
})

Don't forget to replace with your domain name where i indicated

In the package.json script section add this

{ "scripts": { // Other scripts... "docker:up": "docker compose up --build -d", "docker:down": "docker compose down" } }

Create a .dockerignore file and add these to it

node_modules npm-debug.log* yarn-debug.log* yarn-error.log* .git .gitignore README.md .env.test .nyc_output coverage .DS_Store *.log dist build

Next create a .env file and add these, replacing with your domain where necessary

STORE_CORS=http://localhost:8000,https://docs.medusajs.com,https://domainhere.com,https://www.domainhere.com
ADMIN_CORS=http://localhost:5173,http://localhost:9000,https://docs.medusajs.com,https://domainhere.com,https://domainhere.com/app
AUTH_CORS=http://localhost:5173,http://localhost:9000,https://docs.medusajs.com,https://domainhere.com,https://domainhere.com/app
REDIS_URL=redis://redis:6379
JWT_SECRET=supersecret
COOKIE_SECRET=supersecret
DATABASE_URL=postgres://postgres:postgres@postgres:5432/medusa-store
DB_NAME=medusa-v2

Never expose your secrets but it should look like this

To start your application use npm run docker:up

To create a new admin user run

docker compose run --rm medusa npx medusa user -e admin@example.com -p supersecret

Replace with your email and password

To check your logs if everything runs smoothly
docker compose logs -f

Reverse Proxy with Nginx

Now let's setup Nginx

We've installed Nginx previously so we should be seeing the "Welcome to Nginx page" on the server's url

Create a Config file in /etc/nginx/sites-available and name it anything you want. I used the name of my domain, workrate.online

This config file sets up redirects to your Admin dashboard, frontend and API
Just replace my domain name, workrate.online with yours

server {
    listen 80;
    server_name workrate.online www.workrate.online;

    # --- Frontend (Next.js Storefront) ---
    location ~ ^/(dk|us|ng)(/.*)?$ {
        proxy_pass http://localhost:8000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }

    # Root frontend fallback
    location / {
        proxy_pass http://localhost:8000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }

    # --- Medusa Backend Routes ---
    location /store/ {
        proxy_pass http://localhost:9000/store/;
    }

    location /admin/ {
        proxy_pass http://localhost:9000/admin/;
    }

    location /auth/ {
        proxy_pass http://localhost:9000/auth/;
    }

    location /app/ {
        proxy_pass http://localhost:9000/app/;
    }
}

Enable the newly created config with
sudo ln -s /etc/nginx/sites-available/yourfilenamehere/etc/nginx/sites-enabled/

Remove the default config, it sometimes interfere
sudo rm /etc/nginx/sites-enabled/default

Test and reload your config

sudo nginx -t sudo systemctl reload nginx

Don't forget to point your domain to your server with your DNS provider.

Also you should set up Certbot to provide HTTPS by running

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomainname.com -d www.yourdomainname.com

You should now be able to access your Admin panel from your domain

Setting up the frontend

We'll be setting up a GitHub Actions pipeline with the frontend because it seems more practical, the backend almost never changes but the frontend will require a lot of UI work and therefore constant pushing.

Anyways, let's start by cloning the storefront

git clone https://github.com/medusajs/nextjs-starter-medusa medusa-storefront

Run npm install to install all dependencies

Create a .env file

#Your Medusa backend, should be updated to where you are hosting your server. Remember to update CORS settings for your server. See – https://docs.medusajs.com/learn/configurations/medusa-config#httpstorecors
MEDUSA_BACKEND_URL=http://localhost:9000

# Your publishable key that can be attached to sales channels. See - https://docs.medusajs.com/resources/storefront-development/publishable-api-keys
NEXT_PUBLIC_MEDUSA_PUBLISHABLE_KEY=

# Your store URL, should be updated to where you are hosting your storefront.
NEXT_PUBLIC_BASE_URL=http://localhost:8000

# Your preferred default region. When middleware cannot determine the user region from the "x-vercel-country" header, the default region will be used. ISO-2 lowercase format. 
NEXT_PUBLIC_DEFAULT_REGION=dk

# Your Stripe public key. See – https://docs.medusajs.com/resources/commerce-modules/payment/payment-provider/stripe
NEXT_PUBLIC_STRIPE_KEY=pk_test_dQZtCPCXzFgnPf7YRp1ETSs7

# Your Next.js revalidation secret. See – https://nextjs.org/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating#on-demand-revalidation
REVALIDATE_SECRET=supersecret

NEXT_PUBLIC_MEDUSA_BACKEND_URL=http://localhost:9000

You'll need your Publishable key and Stripe Key {You can use the test one i attached for development purpose only}

You can use SSH tunnelling to access your port 9000 through your browser, login and get your Publishable Key. Run this on your local machine not the server

Or just go through your domain/app

ssh -i /path/to/your-key.pem -L 9000:localhost:9000 ubuntu@<your-ec2-public-ip>

You should then be able to go to http://localhost:9000/app/settings/publishable-api-keys to retrieve your own keys

Use npm run dev to make sure everything is running smoothly

GitHub Action

Generate new secret keys on your local machine with
ssh-keygen -t rsa -b 4096 -C "example@email.com"
Follow the prompt and manually append your generated .pub keys to ~/.ssh/authorized_keys

Create a GitHub repo, Medusa-storefront

Copy the private keys and go over to your Github Repo

Navigate to Settings -> Secrets & Variables -> Actions

Create a new repository secret named SSH_PRIVATE_KEY and enter the keys you copied earlier.

Remember the values from the .env files, we'll create some secrets and variables so we can SSH into over server, build the frontend and deploy it every time it detects a push.

SSH_PRIVATE_KEY Secret SERVER_HOST Secret Your Public IPv4 Address SERVER_USER Secret ubuntu APP_DIR Secret /var/www/storefront NEXT_PUBLIC_MEDUSA_PUBLISHABLE_KEY Secret NEXT_PUBLIC_STRIPE_KEY Secret REVALIDATE_SECRET Secret MEDUSA_BACKEND_URL Variable https://domainname NEXT_PUBLIC_MEDUSA_BACKEND_URL Variable https://domainname NEXT_PUBLIC_BASE_URL Variable https://domainname NEXT_PUBLIC_DEFAULT_REGION Variable dk

Next in your server create a file in the store-front directory in .github/workflows/deploy.yml

Add this to the file save and push to your own local repo

name: Deploy Frontend

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    env:
      MEDUSA_BACKEND_URL: ${{ vars.MEDUSA_BACKEND_URL }}
      NEXT_PUBLIC_MEDUSA_BACKEND_URL: ${{ vars.NEXT_PUBLIC_MEDUSA_BACKEND_URL }}
      NEXT_PUBLIC_BASE_URL: ${{ vars.NEXT_PUBLIC_BASE_URL }}
      NEXT_PUBLIC_DEFAULT_REGION: ${{ vars.NEXT_PUBLIC_DEFAULT_REGION }}
      NEXT_PUBLIC_MEDUSA_PUBLISHABLE_KEY: ${{ secrets.NEXT_PUBLIC_MEDUSA_PUBLISHABLE_KEY }}
      NEXT_PUBLIC_STRIPE_KEY: ${{ secrets.NEXT_PUBLIC_STRIPE_KEY }}
      REVALIDATE_SECRET: ${{ secrets.REVALIDATE_SECRET }}

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 20

      - name: Create .env file
        run: |
          cat > .env << EOF
          MEDUSA_BACKEND_URL=${{ vars.MEDUSA_BACKEND_URL }}
          NEXT_PUBLIC_MEDUSA_BACKEND_URL=${{ vars.NEXT_PUBLIC_MEDUSA_BACKEND_URL }}
          NEXT_PUBLIC_BASE_URL=${{ vars.NEXT_PUBLIC_BASE_URL }}
          NEXT_PUBLIC_DEFAULT_REGION=${{ vars.NEXT_PUBLIC_DEFAULT_REGION }}
          NEXT_PUBLIC_MEDUSA_PUBLISHABLE_KEY=${{ secrets.NEXT_PUBLIC_MEDUSA_PUBLISHABLE_KEY }}
          NEXT_PUBLIC_STRIPE_KEY=${{ secrets.NEXT_PUBLIC_STRIPE_KEY }}
          REVALIDATE_SECRET=${{ secrets.REVALIDATE_SECRET }}
          EOF
      - name: Install dependencies and build
        run: |
          npm install
          npm run build
      - name: Copy build files and .env to server
        uses: appleboy/scp-action@v0.1.7
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          source: ".,!.git"
          target: "${{ secrets.APP_DIR }}"

      - name: Restart app
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd ${{ secrets.APP_DIR }}
            # Install production dependencies
            sudo npm install
            # Restart PM2 process
            sudo pm2 delete medusa-storefront || true
            sudo pm2 start npm --name medusa-"storefront" -- run start
            sudo pm2 save

Use these commands to make sure the APP_DIR exists and has the correct permission to run

sudo mkdir -p /var/www/storefront sudo chown -R ubuntu:ubuntu /var/www/storefront

Debugging, Fixes and Additional Configs

All you have left to do is make a change to the frontend, i overhauled the Storefront landing page. Make a push, let it build and test to make sure everything works fine.
Check it out here.
https://github.com/aregbesolaisrael/medusa-storefront

Next Steps

While this setup works for small and medium businesses, in my next article i'll cover scaling Medusa with AWS services (ECS, RDS, CloudFront) and setting up monitoring and alerts.

Configuring Nginx on an EC2 Instance.

Israel — Thu, 30 Jan 2025 17:48:18 +0000

Introduction

Hey there, today we'll be doing a quick DevOps task, setting up Nginx (A web server) on an Ubuntu server. Nothing too fancy.
If you're new welcome to my Blog, I'm Israel, a developer and DevOps Engineer looking for excitement and challenges.

The Task

The task is to set up an Ubuntu server, configure Nginx on it and have it serve a custom page as it's default page. .

The Plan

We are going to use an AWS account to provision the Ubuntu server, login to the instance via SSH, install Nginx on it then create the custom page to be displayed then finally test it to see if it works. Simple enough, let's get to it.

Musing

A big part about being a DevOps engineer is optimization. That's almost the entire thing, optimization and efficiency and continuously improving and reevaluating said process. I wrote an article about what DevOps engineers do, you can check it out at The Big Picture and if you're looking for engineers you can check out DevOps Engineers & Cloud Engineers for rockstar professionals.

1. Setting up the Ubuntu server with AWS

To do this we'll head over to AWS's Website then find your way to the console at the top right hand corner. It should look like this.

Now we're going to search for EC2 and launch an Ubuntu instance with settings that'll serve our purpose and cost the least, cost optimization, remember ;).

Name the instance and select Ubuntu on the quick start tab
Select t2.micro and create a keypair, I like to use .pem ones.
Next i created a security group and allowed HTTP/HTTPS traffic from the internet and ssh traffic from my IP.
create and access the server with

 ssh -i <yourkeypair.pem> ubuntu@<serveripaddress>

but don't forget to give execution permissions with chmod u+x keypair.pem

2. Installing and configuring Nginx

Now we are in the server we can install Nginx with these commands.
you can just run them in a script but it's advisable to first put them in one by one to get a feel of how it's done
sudo apt update && sudo apt install -y nginx sudo systemctl start nginx sudo systemctl enable nginx
These will install Nginx, confirm it's running and make sure it automatically runs when you restart.
Navigate to the Nginx web directory with
cd /var/www/html
open a new index.html file with
vi index.html
and paste a basic html file

save and exit vim with :wq and the earlier command ensures Nginx automatically restarts and you can see changes to your site at once.

Challenges & Contribution to learning

This was a joy to work on, taking me back to my early days when tasks like these took me more than 5 mins to work on. I had trouble deciding whether to use a domain name or not, i went with no because it just was easier.
Now i had fun writing this article and it reignited the fire i once had for writing, so now i plan to write more articles and fully commit to a writing style. Thanks HNG

DEV Community: Israel

AWS Ecommerce store

Terraform: A Guide to Deploying

Table of Contents

Introduction: Why Terraform?

Pre-requisites

Step 1: Project Structure and Foundation

1.1 Provider Configuration (main.tf)

1.2 Input Variables (variables.tf)

Step 2: Networking — VPC and Subnets

2.1 Defining the Network (vpc.tf)

Step 3: Security Groups

3.1 Firewall Rules (security_groups.tf)

Step 4: Application Load Balancer

4.1 ALB Configuration (alb.tf)

Step 5: EC2 Instance and Bootstrap

5.1 User Data Script (user_data.sh)

5.2 EC2 Configuration (ec2.tf)

Step 6: Outputs and Deployment

6.1 Outputs Configuration (outputs.tf)

6.2 Variable Assignment (terraform.tfvars)

6.3 Deploying the Infrastructure

Step 7: The Cleanup — One Command

Conclusion & Next Steps

Deploying a Full-Stack Production Application on AWS How-To-Guide

Table of Contents

Introduction

Pre-requisites

1. AWS Account

2. Application Code

3. EC2 Key Pair

Step 1: Networking — Build the VPC Foundation

Overview

1.1 Create the VPC

1.2 Create the Subnets

1.3 Create and Attach the Internet Gateway

1.4 Create the NAT Gateway

1.5 Create and Configure Route Tables

Public Route Table

Private Route Table

Step 2: Security Groups

Overview

2.1 Create ALB Security Group

2.2 Create EC2 Security Group

Step 3: Launch EC2 Instance

3.1 Launch the Instance

3.2 SSH Access via Instance Connect Endpoint

Step 4: Install Prerequisites on EC2

Step 5: Deploy the Application

5.1 Clone the Repository

5.2 Configure Environment Files

5.3 Build and Start the Stack

Step 6: Application Load Balancer

Overview

6.1 Create Target Group

6.2 Create the ALB

Optional: Add HTTPS

6.3 Test the Application

Step 7: The Cleanup Problem

Reviving DevOps

Building a Serverless Netflix Data Analytics Platform with AWS Glue, Athena and QuickSight.

Table of Contents

1. Setting Up the S3 Data Lake

Adding the Source

Applying Schema Mapping

DropNullFields

Writing Parquet Output

4. Building Analytics with Athena and QuickSight

Deploying a MedusaJS 2.0 Store on AN AWS EC2 Instance.

So you have decided to set up an online store and you would rather set it up your self, you're in the right place.

Table of Contents

Server Provisioning

Installing the Prerequisites

Running the Backend Server

Reverse Proxy with Nginx

Setting up the frontend

GitHub Action

Debugging, Fixes and Additional Configs

Next Steps

Configuring Nginx on an EC2 Instance.

1.1 Provider Configuration (`main.tf`)

1.2 Input Variables (`variables.tf`)

2.1 Defining the Network (`vpc.tf`)

3.1 Firewall Rules (`security_groups.tf`)

4.1 ALB Configuration (`alb.tf`)

5.1 User Data Script (`user_data.sh`)

5.2 EC2 Configuration (`ec2.tf`)

6.1 Outputs Configuration (`outputs.tf`)

6.2 Variable Assignment (`terraform.tfvars`)