DEV Community: Israel

Automating Deployment with Github Actions

Israel — Sun, 20 Sep 2026 22:49:56 +0000

Deploying to a Server You Can't Reach: Building a CI/CD Pipeline with AWS SSM and OIDC

From pushing code manually to building, testing, containerizing, and deploying every change automatically.

In the previous article, we learned how to spin up a functioning network and compute resources on AWS, and deploy our application on them. Let's remember a key architectural decision: our EC2 instance is in a private subnet, shielded from the internet.

Now we have a problem. It gets tedious to log in, pull code, and build our Docker images every time we make changes to our codebase.

Enter CI/CD.

CI/CD stands for Continuous Integration and Continuous Delivery/Deployment. It aims to streamline and accelerate the software development lifecycle.

Continuous Integration (CI) refers to the practice of automatically integrating code changes into a shared source code repository. Continuous Delivery and/or Deployment (CD) is a two-part process that refers to the integration, testing, and delivery of code changes. Continuous delivery stops short of automatic production deployment, while continuous deployment automatically releases the updates into the production environment. This means our deployment should happen every time we push code to our GitHub repo.

(If you need a refresher on our setup, check it out here: Terraform Deployment)

Here is the catch: our server has no public IP address. It sits in a private subnet behind a load balancer. GitHub Actions cannot SSH into it. There is no port 22 open to the internet. There is no bastion host.

So how do you deploy to a server you can't reach from the internet?

Why This is More Complex Than a Typical CI/CD Setup

Typically, we would set up a pipeline that builds a Docker image, pushes it to a registry, then SSHes into a server with a stored SSH key to pull the image and restart the container.

None of that works for this setup.

The First Problem: The server is unreachable. The EC2 instance lives in a private subnet (10.0.10.0/24). Traffic from the internet goes through the Application Load Balancer, not directly to the server. There is no public IP. GitHub Actions cannot SSH in.

The Second Problem: Four containers, not one. This is not a single Docker image deployment. It is a docker-compose.yml stack with four interdependent services:

PostgreSQL → (health check passes) → Backend → (health check passes) → Frontend → Nginx

If the backend starts before PostgreSQL is healthy, the Alembic database migrations crash. If Nginx starts before the backend is healthy, it throws a 502 Bad Gateway. Docker Compose manages this dependency chain with health checks and depends_on conditions. So the deployment tool needs to orchestrate Docker Compose on the server, not just swap one container.

Problem 3: No stored credentials. I did not want AWS access keys sitting in GitHub Secrets. Keys do not expire. If they leak, they are valid until someone notices and manually revokes them. That could be weeks. Or months. In a personal project, probably never.

I needed a solution that was:

Keyless (no stored AWS credentials)
Reachable (can talk to a private subnet server)
Composable (can orchestrate a multi-container stack)

The answer turned out to be three AWS services I had already partially set up: IAM OIDC, Systems Manager (SSM), and Terraform.

The Architecture

Here is how the pipeline works end to end.

Developer pushes to main
         │
         ▼
┌─────────────────────────────┐
│  GitHub Actions CI Workflow  │
│  ┌───────────────────────┐  │
│  │ Docker Compose Build  │  │
│  │ Frontend Build (Vite) │  │
│  │ Backend Lint (Flake8) │  │
│  └───────────────────────┘  │
└──────────────┬──────────────┘
               │ (all checks pass)
               ▼
┌─────────────────────────────┐
│  GitHub Actions CD Workflow  │
│                             │
│  1. Request OIDC token from │
│     GitHub's token service  │
│                             │
│  2. Present token to AWS    │
│     STS: "I am repo X,      │
│     running workflow Y"     │
│                             │
│  3. AWS returns temporary   │
│     credentials (1 hour)    │
│                             │
│  4. Use AWS CLI to send     │
│     SSM command to EC2      │
│                             │
│  5. EC2 executes deploy.sh  │
│     (git pull, compose up)  │
│                             │
│  6. Fetch logs, verify      │
│     success or fail build   │
└─────────────────────────────┘

No SSH. No stored keys. No open ports. The only thing stored in GitHub Secrets is the ARN of an IAM role — a reference, not a credential.

Part 1: The CI Pipeline — Catching Problems Before They Reach the Server

The CI workflow runs on every push to main and every pull request. Its job is simple: make sure the code is not broken before we even think about deploying.

name: CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest

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

    - name: Set up Docker Buildx
      uses: docker/setup-buildx-action@v3

    - name: Validate Docker Compose build
      run: docker compose build

    - name: Set up Node.js for Frontend
      uses: actions/setup-node@v4
      with:
        node-version: '20'

    - name: Check Frontend build
      working-directory: ./fe-apartment
      run: |
        npm install
        npm run build

    - name: Set up Python for Backend
      uses: actions/setup-python@v5
      with:
        python-version: '3.12'

    - name: Lint Backend (Flake8)
      working-directory: ./be-apartment
      run: |
        python -m pip install --upgrade pip
        pip install flake8
        flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
        flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics

Three things happen:

Docker Compose build validation. This builds all four container images. If a Dockerfile is broken, a requirements.txt has a bad package, or Nginx config has a syntax error — it fails here, not on the server.
Frontend build. React with Vite. npm install then npm run build. If someone introduces a TypeScript error or a bad import, the build fails. The CI catches it.
Backend lint. Flake8 on the FastAPI codebase. The first pass (--select=E9,F63,F7,F82) catches hard errors — syntax errors, undefined names, things that will crash at runtime. The second pass reports style warnings without failing the build. I am strict on things that break. I am lenient on things that are ugly.

Why run Flake8 in two passes? Because if you block every single style violation from day one on a codebase that was not linted before, you will spend your first week fixing hundreds of trailing whitespace warnings instead of shipping features. The first pass is a wall. The second pass is a nudge.

Part 2: No Stored Keys — The OIDC Trust Relationship

This is the part I am most proud of.

To deploy, the pipeline needs to talk to AWS. The traditional approach: create an IAM user, generate access keys, store them as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in GitHub Secrets.

That works. But those keys never expire. If they leak through a log, a screenshot, or a misconfigured workflow that echoes environment variables, they are valid forever. Or until someone remembers to rotate them. On a personal project? That is never.

OIDC flips the model. Instead of storing a key, you set up a trust relationship. GitHub says: "I am the repository Israel-dot-com/apartment-deployment-main, running a workflow on the main branch." AWS checks its trust policy and says: "I trust that repository. Here are temporary credentials that expire in one hour."

No keys stored anywhere. If the token somehow leaks, it is useless in 60 minutes. And it only works from my specific repository — not from a fork, not from a different org, not from someone who copied my workflow file.

Setting It Up With Terraform

I did not want to click through the AWS Console to set this up. The whole point of this project is Infrastructure as Code. So the OIDC provider and IAM role live in Terraform:

# terraform/github_oidc.tf

resource "aws_iam_openid_connect_provider" "github" {
  url             = "https://token.actions.githubusercontent.com"
  client_id_list  = ["sts.amazonaws.com"]
  # AWS recommends these official GitHub thumbprints
  thumbprint_list = [
    "6938fd4d98bab03faadb97b34396831e3780aea1",
    "1c58a3a8518e8759bf075b76b750d4f2df264fcd",
    "06d927fecd0a84aeba28aad1d808139470fe95c3"
  ]
}

resource "aws_iam_role" "github_actions" {
  name = "${var.project_name}-github-actions-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = {
        Federated = aws_iam_openid_connect_provider.github.arn
      }
      Action    = "sts:AssumeRoleWithWebIdentity"
      Condition = {
        StringEquals = {
          "token.actions.githubusercontent.com:aud" = "sts.amazonaws.com"
        }
        StringLike = {
          # Pro-Tip: Add wildcards around your org/repo names! 
          # GitHub occasionally appends internal numeric IDs to the claim.
          "token.actions.githubusercontent.com:sub" = "repo:Israel-dot-com*/apartment-deployment-main*"
        }
      }
    }]
  })
}

The Condition block is critical. StringLike on the sub claim locks this role to my specific repository. No other GitHub repository in the world can assume it. If someone forks my repo and runs the workflow, AWS rejects the token.

(Pro Tip:* Notice the * after the organization and repository names! GitHub recently started occasionally appending internal numeric IDs to OIDC tokens, so a strict StringEquals might randomly fail. Using StringLike with wildcards saves you hours of debugging!)*

Least Privilege: Only What the Pipeline Needs

The role gets exactly three permissions. Notice how we split the ssm:SendCommand resource array to properly accommodate tag conditions:

resource "aws_iam_role_policy" "github_actions_ssm" {
  role = aws_iam_role.github_actions.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = ["ec2:DescribeInstances"]
        Resource = "*"
      },
      {
        # Allow running SSM commands on our specific tagged instance
        Effect   = "Allow"
        Action   = ["ssm:SendCommand"]
        Resource = ["arn:aws:ec2:${var.aws_region}:${data.aws_caller_identity.current.account_id}:instance/*"]
        Condition = {
          StringEquals = {
            "ssm:ResourceTag/Name" = "${var.project_name}-server"
          }
        }
      },
      {
        # Allow access to the AWS managed shell script document
        Effect   = "Allow"
        Action   = ["ssm:SendCommand"]
        Resource = ["arn:aws:ssm:${var.aws_region}::document/AWS-RunShellScript"]
      },
      {
        # Allow retrieving the command logs
        Effect   = "Allow"
        Action   = ["ssm:GetCommandInvocation"]
        Resource = "arn:aws:ssm:${var.aws_region}:${data.aws_caller_identity.current.account_id}:*"
      }
    ]
  })
}

That is it. The role cannot create resources. It cannot delete infrastructure. It cannot read secrets. It cannot modify IAM. It can do exactly one thing: tell one specific server to run a shell script, and read the result.

Part 3: Deploying to a Server Nobody Can Reach

Here is the problem again: the EC2 instance has no public IP. It lives in a private subnet. GitHub Actions cannot SSH into it.

AWS Systems Manager (SSM) solves this. The SSM Agent runs on the EC2 instance and maintains a persistent outbound connection to the AWS SSM service. When you send a command through the AWS API, SSM relays it to the agent on the instance. The server reaches out. Nobody reaches in.

No open inbound ports. No SSH keys. No bastion hosts. And every command is logged in CloudTrail — who ran what, when, and what happened.

The EC2 instance already had the AmazonSSMManagedInstanceCore policy attached from when I built the Terraform infrastructure, and the SSM Agent comes pre-installed on Ubuntu AMIs. So this just worked.

The Deploy Script

The script that actually runs on the server is deliberately simple:

#!/bin/bash
set -euo pipefail

echo "========================================="
echo "Starting deployment at $(date)"
echo "========================================="

PROJECT_DIR="/home/ubuntu/apartment-deployment"
cd "$PROJECT_DIR"

# Pull the latest code
echo "--> Pulling latest code from main branch..."
git fetch origin main
git checkout main
git reset --hard origin/main

# Build and start the containers
echo "--> Rebuilding and starting Docker containers..."
docker compose build
docker compose up -d

# Clean up dangling images to free up space
echo "--> Cleaning up unused Docker images..."
docker image prune -f

echo "========================================="
echo "Deployment completed successfully at $(date)"
echo "========================================="

set -euo pipefail is important. If any command fails — git fetch times out, docker compose build hits a bad Dockerfile, docker compose up crashes — the script exits immediately with a non-zero status. SSM reports it as a failure, the GitHub Action fails, and I get notified.

git reset --hard origin/main instead of git pull is intentional. The server is not a workspace; it is a deployment target. It should always precisely mirror main.

docker image prune -f is the line that saves you at 3am. Every docker compose build creates new images. On a standard EBS volume, it takes about two weeks of deploys before the disk fills up and Docker refuses to build anything. Pruning after every deploy prevents that.

The CD Workflow

name: CD

on:
  push:
    branches: [ "main" ]

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

jobs:
  deploy:
    name: Deploy to EC2
    runs-on: ubuntu-latest

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

    - name: Configure AWS Credentials
      uses: aws-actions/configure-aws-credentials@v4
      with:
        role-to-assume: ${{ secrets.AWS_OIDC_ROLE_ARN }}
        aws-region: us-east-1

    - name: Deploy via AWS Systems Manager
      run: |
        INSTANCE_ID=$(aws ec2 describe-instances \
          --filters "Name=tag:Name,Values=apartment-server" \
                    "Name=instance-state-name,Values=running" \
          --query "Reservations[*].Instances[*].InstanceId" \
          --output text)

        if [ -z "$INSTANCE_ID" ]; then
          echo "Error: Could not find apartment-server"
          exit 1
        fi

        # Note: We run the command as the 'ubuntu' user to avoid Git 
        # "dubious ownership" errors caused by SSM running as root.
        COMMAND_ID=$(aws ssm send-command \
          --instance-ids "$INSTANCE_ID" \
          --document-name "AWS-RunShellScript" \
          --parameters 'commands=["sudo -i -u ubuntu bash /home/ubuntu/apartment-deployment/deploy.sh"]' \
          --query "Command.CommandId" \
          --output text)

        echo "Waiting for deployment to complete (timeout: 10 minutes)..."
        # We use a custom polling loop here because the default 'aws ssm wait' 
        # times out after 100 seconds, which isn't long enough for Docker builds!
        for i in {1..60}; do
          STATUS=$(aws ssm get-command-invocation --command-id "$COMMAND_ID" --instance-id "$INSTANCE_ID" --query "Status" --output text)
          if [[ "$STATUS" != "InProgress" && "$STATUS" != "Pending" && "$STATUS" != "Delayed" ]]; then
            break
          fi
          sleep 10
        done

        echo "Deployment Output:"
        aws ssm get-command-invocation \
          --command-id "$COMMAND_ID" \
          --instance-id "$INSTANCE_ID" \
          --query "StandardOutputContent" --output text

        if [ "$STATUS" != "Success" ]; then
          echo "Error log:"
          aws ssm get-command-invocation \
            --command-id "$COMMAND_ID" \
            --instance-id "$INSTANCE_ID" \
            --query "StandardErrorContent" --output text
          echo "Deployment failed with status: $STATUS"
          exit 1
        fi

        echo "Deployment completed successfully!"

Let me walk through what happens:

OIDC authentication. aws-actions/configure-aws-credentials@v4 handles the entire OIDC handshake. It requests a token from GitHub, presents it to AWS STS, receives temporary credentials, and configures the AWS CLI. One action. Zero stored keys.
Find the server by tag. The pipeline does not hardcode an instance ID. If I destroy and recreate the infrastructure with Terraform, the pipeline finds the new instance dynamically using its name tag.
Send the command. ssm:SendCommand tells the EC2 instance to run deploy.sh. (Notice we use sudo -i -u ubuntu to ensure we execute as the correct user).
Wait and verify. Because docker compose build can take a few minutes, we use a custom bash loop to poll SSM for up to 10 minutes. Once it completes, we fetch the logs.

The only thing stored in GitHub Secrets is AWS_OIDC_ROLE_ARN — the ARN of the IAM role. This is not a credential. It is a reference. AWS will reject the OIDC token from any other source.

Part 4: What Happens When It Breaks

A green pipeline does not mean your application works. It means your code compiled, your images built, and the deploy script exited with status 0. But Docker Compose reporting healthy containers and your load balancer agreeing are two different things.

The ALB health check hits / every 30 seconds. If the Nginx container is up but the backend behind it is crashing, the ALB marks the target as unhealthy. Users get a 502. The pipeline is green. The app is down.

This is why monitoring exists alongside CI/CD. The pipeline catches code problems. Monitoring catches runtime problems. They are complementary, not interchangeable.

The Rollback

When a bad deploy makes it through, the rollback is fast. Identify the bad commit and revert it:

git revert <bad-commit-sha> --no-edit
git push origin main

That is it. git revert creates a new commit that undoes the bad change. The push triggers the CD pipeline. The pipeline authenticates with OIDC, sends the SSM command, the server pulls the reverted code, rebuilds the containers, and Docker Compose brings everything back up in the correct dependency order.

What I Learned Building This

1. The server should not be special

Before CI/CD, the server accumulates manual changes. Over time, the server drifts from what the code says it should be. git reset --hard origin/main enforces the truth: the server is a mirror of the main branch. Nothing more. If it is not in git, it does not exist.

2. Security and convenience are not a trade-off

I expected the OIDC setup to be painful. It was about 50 lines of Terraform and one GitHub Secret. And now I never think about key rotation, key expiration, or key leakage. The credentials do not exist until the pipeline needs them, and they stop existing an hour later.

SSM was similar. No port 22 open. No SSH keys to distribute. No bastion host to maintain. And I get a full audit trail in CloudTrail for free.

3. Health check chains are the real deployment logic

My docker-compose.yml has a strict dependency chain:

postgres (healthy) → backend (healthy) → frontend (started) → nginx

Each service waits for the previous one to pass its health check before starting. This means docker compose up -d is not just "start everything." It is an orchestrated, ordered, health-verified rollout.

4. Disk space kills you silently

Every docker compose build creates new image layers. docker image prune -f after every deploy is not optional. It is the difference between a pipeline that works for a month and one that works forever.

The Full Picture

Terraform creates:                     GitHub Actions uses:
├── VPC + Private Subnets              ├── OIDC → Temporary AWS credentials
├── ALB (public-facing)                ├── SSM → Deploy to private EC2
├── EC2 (private, no public IP)        ├── CI  → Build + Lint + Validate
├── NAT Gateway (outbound only)        └── CD  → git pull + compose up
├── IAM Role for EC2 (SSM Agent)
├── OIDC Provider (GitHub trust)
└── IAM Role for GitHub (SSM perms)

Clean separation.

Next Steps

This pipeline deploys on every push to main. That is continuous deployment. For a production application with real users, I would add:

A staging environment. Deploy to a staging EC2 first. Run integration tests against it. Only promote to production after validation.
Manual approval gates. A github_environment with required reviewers. The pipeline pauses and waits for a human to click "Approve" before deploying to production.
Container image registry. Push built images to AWS ECR with commit-hash tags. Instead of building on the server, pull pre-built images. Build once, deploy many times.
Secrets in Parameter Store. Move .env values into AWS Systems Manager Parameter Store. The deploy script pulls them at runtime instead of relying on manually created files on the server.

Each of these is a future article. I'll link them here when they're ready.

The full infrastructure code (Terraform), CI/CD workflows, and Docker Compose configuration are all available on GitHub. If this helped you, drop a like or leave a comment — I'd love to hear how you're solving deployment to private subnets.

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

Automating Deployment with Github Actions

Deploying to a Server You Can't Reach: Building a CI/CD Pipeline with AWS SSM and OIDC

Why This is More Complex Than a Typical CI/CD Setup

The Architecture

Part 1: The CI Pipeline — Catching Problems Before They Reach the Server

Part 2: No Stored Keys — The OIDC Trust Relationship

Setting It Up With Terraform

Least Privilege: Only What the Pipeline Needs

Part 3: Deploying to a Server Nobody Can Reach

The Deploy Script

The CD Workflow

Part 4: What Happens When It Breaks

The Rollback

What I Learned Building This

1. The server should not be special

2. Security and convenience are not a trade-off

3. Health check chains are the real deployment logic

4. Disk space kills you silently

The Full Picture

Next Steps

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

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`)