DEV Community: Breindel Medina

OverTheWire Wargames : Natas - LOTS OF DOCS, LOTS OF VULNS

Breindel Medina — Fri, 26 Jun 2026 16:00:17 +0000

I recently tackled the Natas Wargames by OverTheWire, following my completion of the Bandit series. While Bandit focused on the fundamentals of Linux and system administration, Natas shifted its focus toward Web Application Security. This transition provided deep insight into how modern web servers and applications function under the hood. Throughout this challenge, I explored fundamental server-side vulnerabilities, HTTP request manipulation, and gained an appreciation for secure coding practices. I would like to share my journey, the concepts I mastered, and the highlights and challenges I encountered along the way.

Highlights

In the process of trying to solve the problems, going over resources on web vulnerabilities, and reading documentation and write ups on certain levels, I frequently saw Burp Suite being used as an essential tool for analysis and for intercepting or manipulating network traffic and requests. Seeing that some of these levels utilized Burp Suite, I had to learn how to navigate the software, and I found it genuinely enjoyable to master its features. Getting hands-on experience with intercepting traffic and applying concepts like URL encoding to bypass client-side input restrictions was a fun and highly educational process.

I was also able to learn a lot of concepts regarding web vulnerabilities and strategies to exploit these vulnerabilities such as the robots.txt used in websites to avoid web crawling, Session Injections, Command Injections, SQL Injections as well as Blind SQL Injections, Brute Forcing, Deserialization, and a little bit of Cryptography which was used in some levels.

As I progressed toward the later levels, the challenges shifted to the Perl programming language, which forced me to learn its specific syntax and functions. Through this, I realized that programming languages are functionally similar in many ways. The vulnerabilities I encountered in levels that used PHP were often present in Perl as well, simply manifesting through different mechanisms. This series also taught me the vital importance of reading official documentation, as many solutions hinged on understanding the specific security implications of a language's syntax and how it can be misused.

Lowlights

I found my self being stuck on a lot of these levels without really knowing what to do next apart from what I already knew. So, I found myself relying on solutions and write ups made by people who tried and solve these problems as well. What I realized was that reading how people approached these problems gave a lot more insight than AI ever could. It showed their very unique thought processes and showed technique that differed from one another which also made me realize another thing, Problems can be approached a whole lot of different ways.

On the note of being stuck on many different levels, I realized that I really still lacked a lot of knowledge on how web servers worked which made me wake up to the technical level that I am currently at. That fact gives me a lot of hope, it signifies that I still have a lot to learn and a lot ahead of me in terms of exploration and discovery.

Conclusion

Finishing Natas really changed how I look at websites and, more importantly, how I approach creating them. I stopped seeing them as just static pages to click through and started seeing them as interconnected puzzles where every single input field is a potential vulnerability.

Ultimately, this challenge made me a better developer by forcing me to learn the ins and outs of security. Understanding these vulnerabilities from the inside out has changed how I write code, I’m no longer just building for functionality, but also keeping in the back of my mind that it could be penetrated maliciously. Being aware of these common pitfalls and knowing how to prevent them allows me to design more secure applications.

OverTheWire Wargames : Bandit - LOTS OF UNIX AND NETWORKING GOODNESS

Breindel Medina — Tue, 16 Jun 2026 13:07:52 +0000

I recently took the challenge of one of the OverTheWire Wargames which is Bandit. It tackled a lot of concepts on UNIX and Networking which could help in actually being able to play the other Wargames that they have. In the process of trying to progress through the levels in Bandit, I have learned a lot on the basics of UNIX/Linux and the Networking on these systems (and a little bit of Git as well) and I would like to share the concepts I have learned throughout the challenge

ssh

The first concept that was apparent throughout the levels to progress is ssh. The whole game was located on their SSH server, which players needed to access through their CLIs using the ssh command. Every level transition essentially boiled down to connecting to the next user with a password obtained from the previous level, so getting comfortable with the syntax ssh bandit0@bandit.labs.overthewire.org -p 2220 became second nature fairly quickly.

As the levels progressed, password-based authentication wasn't always the way in. Some levels handed over an RSA private key instead of a plaintext password, which meant using the -i flag to point ssh to that identity file (e.g. ssh -i bandit_key bandit14@bandit.labs.overthewire.org -p 2220). This tied directly into the broader concept of key-based authentication, where the private key proves identity in place of typing a password.

There were also levels where the goal wasn't just to log in, but to execute a specific command or drop into a different shell on the remote end as part of the solution. This is where the -t flag came in, forcing pseudo-terminal allocation so that interactive programs (like another shell) would behave correctly when invoked through ssh rather than just running non-interactively and returning.

Unix/Linux Commands, Features and Their Intricacies

This is where I had the most of the fun stuff and most of my learning happened when trying to perform these commands. These are some of the core commands and features I picked up when trying to progress through the levels and how it actually was used in some of the levels:

`cat`, `ls`, `more`

These commands are the bread and butter for viewing files and directory contents, including handling tricky filenames (spaces, dashes, hidden files) which was present on the levels. One of the most notable parts of the game in which I had to use this command was at Level 2 -> Level 3. The level contained a file named --spaces in this filename--, the problem of a hyphen on the filename appears which typically means that there will be a flag to be passed to the command which causes it to wait an extra flag input. There are also spaces on the file name so the way to solve those problems is to utilize ./ when calling the file and also use \ before the spaces to indicate that there are spaces on the file name like so:

These types of problems appear on the levels which really helped me master these concepts especially on the commands I have mentioned.

`find`

This command is for locating files based on size, permissions, type, and timestamps, which was crucial for levels that hid passwords deep in directory trees or filtered by file attributes. Level 5 -> Level 6 highlighted the power of this command when trying to find a certain file. That is because in this level, the file that needs to be found should be searched from many directories with many different files inside as well. With the given limits to where the password could be, the power of the find command was shown in solving that particular problem.

`grep`

This command searching file contents for patterns, especially useful when a password was buried among thousands of words and characters. grep was used in some of the problems by piping the cat command's output into grep like so:

Pipe commands

As said earlier, piping chains commands together (cmd1 | cmd2 | cmd3) to filter and transform output instead of relying on a single command to do everything. The grep example from earlier is a good illustration of this:

Here, cat data.txt reads and outputs the entire contents of the file, and instead of dumping all of that to the terminal, the pipe (|) takes that output and feeds it directly into grep as input. grep "millionth" then filters through every line it receives and only prints the lines that contain the word "millionth", discarding everything else. This meant that instead of scrolling through potentially thousands of lines of junk data, the pipe let two simple commands work together to instantly narrow down the output to just the relevant line, which was often where the password for the next level was hiding.

`sort` and `uniq`

These commands together is used to isolate unique lines, which came up in levels where the password was the one line in a file that didn't repeat. One level's data.txt contained thousands of duplicated lines with only a single line appearing once, so the approach was to first sort the file (since uniq only detects duplicates that are adjacent to each other) and then pipe that sorted output into uniq -u, which prints only the lines that have no duplicates:

`strings`

This command is used to extract readable text from binary files, useful when the password was embedded in something not meant to be read directly. One level's data.txt contained a mix of binary data and human-readable text, which meant cat would just spit out a mess of unreadable characters. Running strings on the file filtered out the unreadable contents and printed only the human-readable strings, but the output was still cluttered with other text fragments unrelated to the password. To narrow it down further, the output was piped into grep to search specifically for lines containing an equals sign, since the password in this file appeared preceded by several rows of =:

`base64`

This command was used to decode data, since some levels layered multiple encodings on top of each other. One level's data.txt contained a string that, when viewed with cat, was base64-encoded. Running it through base64 -d to decode it revealed the readable line, giving the password needed to progress to the next level:

`chmod`

This command is used in manipulating file permissions. It was used both for solving levels and for understanding why certain access was blocked or allowed. chmod came up in a few different contexts throughout the game:

giving execute permissions to scripts or files that needed to be run
restricting the permissions on private key files (since ssh refuses to use a key that's readable by others, requiring something like chmod 600 key_file before it would work)
adjusting permissions on output files to make sure they could actually be written to or read from when a level's solution involved redirecting output to a file.

`tr`

Used to translating or substituting characters. I used this in a level where the password was hidden using a ROT13-style letter rotation. Viewing data.txt directly with cat showed scrambled, unreadable text. Piping that output into tr with the mapping 'A-Za-z' 'N-ZA-Mn-za-m' shifted every letter by 13 places, decoding it back into plain English:

`diff`

Used in comparing two files to spot the difference between them, useful when a level asked to compare two large, mostly-identical files. This level provided two password files, passwords.old and passwords.new, each containing thousands of lines. Running diff between them isolated the exact line that had changed:

Shells

Getting comfortable with how different shells behave, and at times needing to specify or switch shells to get a command to execute properly. Linux systems support multiple shell types (bash, sh, rbash, etc.), each with different behaviors, capabilities, and restrictions. One level specifically required logging into a different, more restricted shell than the default in order to interact with the level correctly.

`setuid`

Understanding how the setuid bit allows a program to run with the file owner's privileges rather than the executing user's, which was central to several privilege-escalation-style levels. Normally, when a program is executed, it runs with the permissions of the user who launched it. A binary with the setuid bit set, however, runs with the permissions of the file's owner instead, regardless of who actually executes it. This was the mechanism that made several levels solvable: the current user didn't have direct read access to the next level's password file, but a setuid binary owned by the next-level user could be executed to read or output that password on the user's behalf, effectively borrowing the owner's privileges just long enough to retrieve the credential needed to progress.

CRON/scripting

This concept is important in reading and understanding scheduled jobs and the scripts they run, including spotting vulnerabilities in how those scripts handled permissions or input. One of the most satisfying levels in the whole game involved a cron job that was set to automatically run on a fixed schedule. The task here wasn't just to find a password sitting in a file, but to actually read and analyze the script that cron was executing in order to understand what it did, what permissions it ran with, and where it pulled its input from. Once it became clear that the script would execute anything placed in a certain location with the privileges of the cron job's owner, the solution was to write a custom script designed to take advantage of that behavior, drop it where the cron job would pick it up, and let the next scheduled run execute it automatically. Waiting for cron to fire and seeing the payload execute with elevated privileges, handing over the next password, was one of the more rewarding moments for me.

Networking and Communication

`scp`

Securely copying files to and from the remote server, which was necessary for levels requiring local processing of a file. One level provided an RSA private key for authentication, which first needed its permissions locked down with chmod 600 sshkey.private before it could be used. From there, scp was used with the -i flag to authenticate with that key and pull a password file directly off the remote server's filesystem down to the local machine:

Once the file landed locally, a simple cat on the transferred file through scp revealed the password.

`nmap`

Used for scanning for open ports and identifying services running on a target machine. One level only stated that the next password was being served somewhere on a port within a specific range, with no further details on which exact port. Running nmap against that range on localhost scanned through the possibilities and returned the open ports:

This narrowed things down from a thousand possible ports to just five open ones, each running an unknown service. From there, it was a matter of connecting to each open port individually to inspect what was being served and figure out which one actually held the password.

`netcat` or `nc`

Both of these commands is a way to connect to arbitrary ports/services and as a lightweight way to send and receive raw data. One level was one of the most interesting to me out of the whole game. It involved a setuid binary, suconnect, that would connect locally to a given port, read a password from whoever was listening there, and if that password matched the current level's password, it would send back the next level's password in response. The challenge was that this required something to actually be listening on a port to feed suconnect the correct password in the first place.

To pull this off, I used tmux to split my terminal so I could run multiple things simultaneously: in one pane, nc -lp 1112 was set up to listen on a port and send out the current password using echo -n "password" | nc -lp 1112 &, running it in the background so the terminal stayed free. In the other pane, ./suconnect 1112 was run to connect to that same port, read the password being served, confirm the match, and print "Password matches, sending next password," followed by the actual password for the next level. Seeing both sides of that handshake play out across split panes made this one of the more hands-on, satisfying levels to work through, since it wasn't just about reading a file, it was about actively setting up the communication myself.

Brute forcing

Brute forcing is a method of solving a problem by systematically trying every possible combination or option until the correct one is found, rather than deducing or calculating the answer directly. This level required a known password plus a 4-digit pincode to authenticate over a port, but the pincode itself wasn't given, only that it was somewhere within the 0000-9999 range. Manually guessing wasn't feasible, so the approach was to script the brute force instead. A small bash script was written to loop through every possible 4-digit combination, appending the known password plus each candidate pincode to a file:

After making the script executable with chmod 700 scriptBRUTE.sh and running it, the resulting possibilities.txt contained every possible password-pincode combination. That file was then piped directly into nc to send each line to the listening service on port 30002. It eventually responded with "Correct!" once it hit the right pincode, revealing the password for the next level.

`openssl`

Used to communicate over encrypted SSL/TLS connections, since some levels served their next password over a port that expected SSL/TLS rather than plain text, making plain nc insufficient. One level required sending the current password to a service listening on port 30001, but that port specifically expected an SSL connection. The openssl s_client command handled establishing that encrypted connection, connecting to the target with -connect localhost:30001, using -ign_eof to keep the connection open after sending input instead of closing immediately, and redirecting the password file as input:

Git

`git clone` (SSH)

Cloning repositories over SSH rather than HTTPS, tying back into the SSH concepts learned earlier. Several of the later levels each provided a Git repository accessible over SSH on a specific port, and the password for that level was hidden somewhere within the repository's history rather than sitting in a plain file. Cloning it locally was the first step before any of the repository's contents or history could actually be inspected.

`git diff`

Inspecting changes between commits or branches to find where a password may have been added and later removed. In one level, the current state of the repository didn't contain the password at all, but comparing two commits with git diff <commit1> <commit2> revealed that a line containing the password had been added in an earlier commit and then deleted in a later one, exposing it despite no longer being present in the latest version of the files.

Git branching

Understanding that information can exist on branches other than the one currently checked out. Not every branch in a repository is necessarily the default one checked out after cloning, and one level required listing all branches with git branch -a and switching into a non-default branch to find a password that simply wasn't present anywhere on the main branch.

Git tagging

Recognizing that tags can point to commits containing information not visible in the default branch history. Tags can reference commits that aren't part of any branch's regular history at all, so a level here meant running git tag to list available tags and then checking out or inspecting the commit a particular tag pointed to, where the password had been stored.

Git history

Digging through past commits, since deleted or modified content often still exists somewhere in the log. Using git log to walk back through the full commit history made it possible to find commits that had been effectively "hidden" by later changes, reinforcing the idea that removing content from the latest version of a file doesn't erase it from the repository's history.

Git Pushing (with `.gitignore`)

Understanding how .gitignore controls what does and doesn't get tracked, and how that can be exploited or worked around when searching for hidden information. One level involved a .gitignore file configured to exclude the very file that contained the password, meaning a plain git add . and commit wouldn't track it. Getting around this meant removing the ignored file from the .gitignore so it could be committed and pushed, revealing that .gitignore only prevents automatic tracking and doesn't actually make a file's content inaccessible if you choose to override it.

Closing Thoughts

Working through Bandit gave me a much more hands-on understanding of UNIX fundamentals and networking basics than reading about them ever could. More importantly, it built the muscle memory and problem-solving instincts needed to approach the other OverTheWire Wargames and also system tinkering in general with more confidence.

Visit OverTheWire Wargames : Bandit to try it out for yourself!

overthewire.org

Modern Deployment Strategies with AWS: Blue/Green and Canary with CodeDeploy

Breindel Medina — Tue, 12 May 2026 14:02:58 +0000

When deploying applications to production, the method you use to replace the old code with the new code dictates your risk level. Historically, deployments meant overwriting the live server. Today, modern architectures use load balancers to shift traffic dynamically, drastically reducing the blast radius of a bad release.

Here is an in-depth look at how these deployment strategies work, complete with architectural flows, followed by a manual, CLI-driven hands-on guide to deploying a FastAPI container from Amazon ECR to ECS using AWS CodeDeploy.

The Danger of "In-Place" Deployments

Deploying without traffic shifting is known as an In-Place Deployment.

In practice, this means your server stops serving the current version (Version 1) and replaces it with the new version (Version 2) on the same machine or instance. There is no buffer, no parallel environment, just a direct swap.

The Risk: During the replacement, your server is either down or running in a partially updated state. If Version 2 contains a fatal bug, every single user hitting your server experiences the failure immediately. There is no subset of users, it is all or nothing.
The Rollback: You must manually re-deploy the old version, wait for it to boot, and wait for it to pass health checks. Depending on your setup, this can mean minutes of active downtime while you scramble to fix it.

The Traffic Shifting Alternatives

Traffic shifting decouples the infrastructure provisioning from the release. Instead of swapping the running server, you spin up the new version completely in the background. A Load Balancer sits in front of your servers and acts as a traffic cop, you manipulate its routing rules to control which users see which version, without ever taking the old version offline.

Blue/Green Deployment

Blue/Green provisions a completely identical, parallel server environment alongside the live one.

Blue is your current live server, it is serving 100% of your users right now.
Green is the new server, it is fully provisioned and running, but the load balancer is not sending anyone to it yet.

The steps are:

Provision: Spin up the Green server with Version 2. Users still hit Blue.
Test: Send internal or test traffic directly to Green to verify it works correctly.
Shift: Instruct the load balancer to swap: Blue receives 0% of traffic, Green receives 100%. The switch is instant.

Rollback: If something goes wrong, the load balancer just points back to Blue. Blue was never torn down, so the rollback is instant with zero re-provisioning.

Canary Deployment

Canary deployments use the same two-server setup as Blue/Green, but instead of an instant full switch, the load balancer gradually bleeds a small percentage of real user traffic to the new version while the majority stays on the old one.

The name comes from the old mining practice of sending a canary into a coal mine first, if it survives, it's safe for everyone else.

The steps are:

Provision: Spin up the new server with Version 2 in the background.
Shift: The load balancer routes 10% of real user traffic to the new server, and 90% stays on the old one.
Monitor: Watch your error rates, latency, and logs during this window. Only a small fraction of users are exposed to any potential bug.

Complete: If the 10% remains stable for a set bake time (e.g., 5 minutes), the load balancer shifts the remaining 90%. If errors spike, traffic is shifted back to the original server before the damage spreads.

The key difference from Blue/Green is the graduated exposure. Instead of betting everything on a single switch, you use real user traffic as a controlled test, with an automatic escape hatch if things go wrong.

AWS CodeDeploy

These deployment strategies can easily be implemented with the use of AWS CodeDeploy, but before that, what is AWS CodeDeploy?

AWS CodeDeploy is the delivery fleet. CodeDeploy does not build your code, and it does not run your tests. Its entire job is to take a finished, ready-to-go artifact (like a Docker image or a ZIP file) and place it onto your servers (EC2, ECS, or Lambda) safely.

Why CodeDeploy?

Without CodeDeploy, you would have to write custom, complex scripts to tell your load balancer to shift traffic, wait 5 minutes, check for errors, and then shift more traffic. CodeDeploy abstracts all of that. You just give it an appspec.yaml file, and it acts as the conductor—coordinating the load balancers, the containers, and the health checks to execute those advanced Blue/Green and Canary strategies automatically.

Hands-On: ECR to ECS via CodeDeploy (CLI Workflow)

Prerequisites:

AWS CLI installed and configured (aws configure)
Docker CLI installed
jq installed
An AWS account with permissions to create CloudFormation stacks

Provision stack using CloudFormation Templates

In CloudFormation, Press Create Stack then press With new resources (standard)

Input this link https://codedeploy-canary-bluegreen-template.s3.ap-southeast-1.amazonaws.com/CanaryBlueGreenWorkshopStack.template.json into the Amazon S3 URL input field so that it uses this template for the stack

Provide a stackname, preferably CanaryBlueGreenWorkshopStack-<unique number> then click next

Scroll down to the very bottom under Capabilities and tick the checkbox then Next
In the next page, click submit

Understanding the Infrastructure Stack

Before we push code, let’s look at the "piping" provisioned in your AWS account. These resources work together as a single unit to enable traffic shifting:

Virtual Private Cloud (VPC): The isolated network where your application lives. To keep costs low, we use Public Subnets only and by assigning each Fargate task a public IP, containers can reach ECR and Docker Hub directly without expensive NAT Gateways
Application Load Balancer (ALB): The "Front Door." It receives all incoming traffic and uses Listener Rules to decide which Target Group gets the request.
Target Groups (Blue & Green): These are logical groupings of your containers.
- Blue: Holds the currently running production version (v1).
- Green: The staging area where the new version (v2) is deployed before anyone sees it.
ECS Cluster & Fargate Service: The "Compute." We use Fargate, which is serverless—you don't manage EC2 instances; you just provide the Docker image and AWS runs it.
CodeDeploy & CloudWatch Alarms: The "Safety Officer." CodeDeploy manages the ALB weights. It watches a CloudWatch Alarm (monitoring 5XX errors). If the alarm triggers during the 5-minute Canary window, CodeDeploy immediately shifts traffic back to Blue.

Key Definitions for the Manual Workflow

Task Definition (task-def.json): Think of this as the Blueprint for the ECS. It defines which Docker image to use, how much CPU/Memory it needs, and which ports are open.
AppSpec (appspec.yaml): This is the Instruction Manual for CodeDeploy. It tells CodeDeploy which Task Definition to move to and which container inside that definition should receive the load balancer traffic.

Give Permissions to ECS to get ECR Image for upload later

Search the Execution Role and click it

Press Attach policies and Give AmazonECSTaskExecutionRolePolicy
Copy the Execution Role for later steps

The FastAPI Application

To install the dependencies, spin up a virtual environment with python through python -m venv .venv and install dependencies using the command pip install fastapi uvicorn and freezing the dependencies to a requirements.txt using pip freeze > requirements.txt

main.py

from fastapi import FastAPI
app = FastAPI()

# ---------------------------------------------------------
# WORKSHOP INSTRUCTIONS:
# For Version 1: Set VERSION = "v1"
# For Version 2: Set VERSION = "v2"
# ---------------------------------------------------------
VERSION = "v2"

@app.get("/")
def read_root():
    return {"status": "success", "version": VERSION}

@app.get("/crash")
def crash():
    raise Exception("Intentional failure for workshop demo")

@app.get("/health")
def health_check():
    # Keep this as JSON for the AWS Load Balancer health check
    return {"status": "healthy", "version": VERSION}

Dockerfile

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "80"]

Build and Push the Docker Image to ECR

First, authenticate the Docker CLI to your Amazon ECR registry, build the image, and push it.

Click View Push Commands to see how to push your image to the ECR Registry, and perform the actions in your terminal ( Needs AWS CLI and Docker CLI for the commands to work )

In this case instead of being codedeploy-workshop:latest , use codedeploy-workshop:v2

Register the New ECS Task Definition

ECS needs to know about the new image. You define this in a JSON file.

task-def.json

{
  "family": "codedeploy-workshop-task",
  "executionRoleArn": "<The Execution Role from the Task Definition of ECS>",
  "networkMode": "awsvpc",
  "containerDefinitions": [
    {
      "name": "fastapi-container",
      "image": "<AWS_ACCOUNT_ID>.dkr.ecr.ap-southeast-1.amazonaws.com/codedeploy-workshop:v2",
      "portMappings": [
        {
          "containerPort": 80,
          "hostPort": 80,
          "protocol": "tcp"
        }
      ]
    }
  ],
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512"
}

aws ecs register-task-definition --cli-input-json file://task-def.json

You will see the task definition on the ECS Task Definitions page now

In another terminal, call the ALB URL to see which version is being delivered and keep it on until the CodeDeploy Trigger, but first you need to get the ALB URL

To get the ALB URL, Navigate to your CloudFormation Stack and go to outputs, in there you will see the LoadBalancerUrl, paste it in the command below to call the Load balancer

while true; do
  curl -s "http://<ALB_URL>/" 
  sleep 1
done

Trigger the CodeDeploy Deployment

CodeDeploy uses an appspec.yaml file to understand which Task Definition to deploy and how to map it to the load balancer.

Finding the Task Definition

Go to ECS Dashboard and in the sidebar, Navigate to Task Definitions

From there, click on the Task Definition with your stack name

From there, you will see the different revisions, click the most recent one

Copy the ARN and paste it to the TaskDefinition in appspec.yaml

appspec.yaml

version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        # Update this to the new revision you just generated in Step 3
        TaskDefinition: "<ARN recently copied>"
        LoadBalancerInfo:
          ContainerName: "fastapi-container"
          ContainerPort: 80

Blue/Green Deployment

First, Lets take a look at Blue/Green Deployment with CodeDeploy

aws deploy create-deployment \
  --application-name AppECS-workshop-cluster-fastapi-service \
  --deployment-group-name DgpECS-workshop-cluster-fastapi-service \
  --deployment-config-name CodeDeployDefault.ECSAllAtOnce \
  --revision "{\"revisionType\": \"AppSpecContent\", \"appSpecContent\": {\"content\": $(jq -Rs . appspec.yaml)}}"

You will now see the deployment being made for a Blue/Green Deployment Configuration
Now check what is returning from the while loop earlier

You will now see its redirecting the other container

In the CodeDeploy dashboard, it also shows the traffic shifted

Now lets go back to the original, use the original task definition for the v1 server and edit appspec.yaml and wait for the rollback

version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        # Update this to the new revision you just generated in Step 3
        TaskDefinition: "<Find Task Definition named CanaryBlueGreenWorkshopStackTaskDef>"
        LoadBalancerInfo:
          ContainerName: "fastapi-container"
          ContainerPort: 80

aws deploy create-deployment \
  --application-name AppECS-workshop-cluster-fastapi-service \
  --deployment-group-name DgpECS-workshop-cluster-fastapi-service \
  --deployment-config-name CodeDeployDefault.ECSAllAtOnce \
  --revision "{\"revisionType\": \"AppSpecContent\", \"appSpecContent\": {\"content\": $(jq -Rs . appspec.yaml)}}"

Call this again to start the roll back, call the while loop again and if it shows v1, the rollback has completed, then change the ARN again to the task definition named codedeploy-workshop-task

Canary Deployment

After rolling back to v1 again, lets now try to deploy with canary, we will also look at how CodeDeploy automatically stop traffic shift to the replacement server once there are errors being seen

aws deploy create-deployment \
  --application-name AppECS-workshop-cluster-fastapi-service \
  --deployment-group-name DgpECS-workshop-cluster-fastapi-service \
  --deployment-config-name CodeDeployDefault.ECSCanary10Percent5Minutes \
  --revision "{\"revisionType\": \"AppSpecContent\", \"appSpecContent\": {\"content\": $(jq -Rs . appspec.yaml)}}"

Once this command executes, CodeDeploy takes over. It spins up the the replacement container, waits for the /health endpoint to pass, and instructs the ALB to send 10% of traffic to the new containers. If CloudWatch Alarms remain quiet for 5 minutes, it routes the remaining 90%, gracefully terminating the old containers

See the Deployment in action during the 5 min window

while true; do
  curl -s "http://<ALB_URL>/" 
  sleep 1
done

As you can see, it switches occasionally to v2 since there will 10% that will be redirected to the replacement server

Call the crash endpoint in another terminal

while true; do
  curl -s "http://<ALB_URL>/crash"
  sleep 0.5
done

This triggers the CloudWatch alarm for 5XX errors

This then triggers CodeDeploy to start the rollback and stop the full rerouting to the replacement task and stay 100% to the original

As you can see in the Deployment Details, it succeeded in the rollback upon seeing the alarm

You might wonder why its 100% to replacement when it is supposed to be 100% to the original?
Its because in the rollback process, the replacement is the original instance ( the 90% ) and the original here is the one being routed 10% earlier which was the replacement

Clean Up

Navigate to our stack in CloudFormation and press Delete Stack . This will start deleting the resources you used effectively cleaning up your environment and avoid incurring more cost.

Takeaways

Deployment is a Spectrum of Risk

Standard "In-Place" deployments are the riskiest because they lack a safety buffer. Blue/Green and Canary strategies move the risk from the infrastructure (will it boot?) to the traffic (will it work for users?), allowing for zero-downtime releases.

Health Checks vs. CloudWatch Alarms

Modern CI/CD requires two layers of defense:

Target Group Health Checks: Ensure the container is "alive" before shifting any traffic (prevents Dead-on-Arrival deployments).
CloudWatch Alarms: Monitor the application's "behavior" during the shift (prevents runtime bugs from affecting 100% of users).

Automation Reduces "Human Error" Burnout

By using appspec.yaml and CodeDeploy, you remove the need for manual Load Balancer manipulation. This allows developers to focus on the code while the infrastructure handles the "bake time" and safety monitoring automatically.

Automating Serverless: A Guide to CI/CD for AWS Lambda with GitHub Actions

Breindel Medina — Tue, 11 Nov 2025 08:00:32 +0000

Deploying serverless applications to the cloud has never been easier with AWS. You just upload your files as a zip to Lambda, turn on the function URL or integrate with an API Gateway, and voila! you are able to deploy your serverless app.

But, this manual process has risks. You still have to manually check if the code is right. It might be that what you deploy is faulty, which causes your application to break.

Since most developers upload their code to GitHub, what if there was a way to automate all of this checking and deployment with a single push to your repository?

This is where GitHub Actions comes in.

What is GitHub Actions?

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform built directly into GitHub. It allows you to automate your software development workflows right from where your code lives.

At its core, GitHub Actions uses the following concepts:

Workflows: These are automated processes defined in a YAML file (e.g., .github/workflows/deploy.yml). A workflow can be triggered by an event.

Events: An event is a specific activity in your repository that triggers a workflow. The most common event is a push to a branch, but it can also be a pull_request, a new issue, or even a scheduled cron job.

Jobs: A workflow is made up of one or more jobs. By default, jobs run in parallel. You can also configure them to run sequentially (e.g., a deploy job that runs only if a test job succeeds).

Runners: A runner is a server (a fresh virtual machine) that runs your workflow's jobs. GitHub provides runners for Linux, Windows, and macOS.

Steps: A job is a series of steps. A step can be a simple shell command (like pip install -r requirements.txt) or a pre-built, reusable command called an Action (like actions/checkout to check out your code).

By combining these, you can create a workflow that, upon a push to your main branch, automatically:

Sets up a clean environment.
Installs your dependencies.
Runs your unit tests.
If the tests pass, it securely deploys your code to AWS Lambda.

Demonstration

Let's first start with a very simple code snippet which we will use in this demonstration

import json

def lambda_handler(event, context):
    return {
        "statusCode": 200,
        "body": json.dumps({
            "message": "Hello dev.to article!",
        })
    }

Code Breakdown (app.py):

def lambda_handler(event, context)

This is the main function that AWS Lambda will call. event contains data about the trigger (e.g., from an API call), and context contains runtime information.

return { ... }

The function returns a dictionary. For a Lambda function responding to an HTTP request (like from a Function URL or API Gateway), it must include statusCode (like 200 for "OK") and a body (which must be a string, hence json.dumps).

Prerequisite 2: Your Test File

Let's now create our test file which our CI will use

test_app.py

import app
import json

def test_simple_lambda_handler():
    # Call the handler
    event = {}
    context = {}
    response = app.lambda_handler(event, context)

    # Check the response
    assert response['statusCode'] == 200
    body = json.loads(response['body'])
    assert "Hello dev.to article!" in body['message']

# We run the test function directly
test_simple_lambda_handler()

print("All tests passed!")

Code Breakdown (test_app.py):

import app

This line imports our app.py file so we can access its lambda_handler function.

response = app.lambda_handler(event, context)

We call our Lambda handler directly, passing in empty event and context objects (since our simple function doesn't use them).

assert response['statusCode'] == 200

This is the core of the test. assert checks if a statement is true. If it's false, the test fails and stops. Here, we check if the statusCode is 200.

assert "..." in body['message']

We check if the response message contains the text we expect.

test_simple_lambda_handler()

We call the test function to run it.

print("All tests passed!")

If all the assert statements pass, this line will run, letting us know our code works as expected.

Upload Your Code to GitHub

Before we can set up GitHub Actions, our code needs to live in a GitHub repository. We'll assume you've already:

Created a new repository on GitHub.
Committed your files (app.py, test_app.py, requirements.txt).
Pushed your code to the main branch.

Create AWS IAM User & Get Keys

Now, let's get the AWS credentials GitHub Actions will use. We'll assume you're familiar with the AWS IAM console.

You'll need to create a new IAM User with CLI access. Give it a descriptive name like github-lambda-deployer.

For permissions, attach the AWSLambda_FullAccess policy.

(Note: For a real-world project, it's best practice to create a more restrictive custom policy that only allows the lambda:UpdateFunctionCode and lambda:UpdateFunctionConfiguration actions on your specific function's ARN.)

After creating the user, generate an Access key and Secret access key. Copy these immediately; you will need them for the next step.

Add Access Keys to GitHub Secrets

Now let's securely store those keys in GitHub.

In your GitHub repository, go to Settings.

In the left sidebar, navigate to Secrets and variables > Actions.

Click the New repository secret button.

Create two secrets, one for the Access Key, and one for the Secret Access Key:

Click Add secret.

Create the second secret:

Click Add secret.

You should now have two secrets, AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, listed under "Repository secrets." GitHub Actions can now access them using the ${{ secrets.NAME }} syntax.

Create Lambda Function

Let's now create the AWS Lambda function that we will use.

Create a function with name "blog-func" and Python 3.13 runtime
After it is done creating, Edit the handler from lambda_handler.lambda_handler to app.lamba_handler

Create the GitHub Actions Workflow (CI/CD)

This is the heart of our pipeline. In your repository, create a new directory .github, and inside that, another directory workflows. Finally, create the file deploy.yml inside it. Replace the placeholders in this file before you commit.

aws-region

Set this to the region where your Lambda function exists (e.g., us-west-2, ap-southeast-1).

--function-name

Change YOUR-LAMBDA-FUNCTION-NAME to the exact name of your function in AWS.

File Path: .github/workflows/deploy.yml

# Name of your workflow
name: CI-CD for AWS Lambda

# When this workflow is triggered
on:
  push:
    branches:
      - main  # Run on pushes to the main branch
  pull_request:
    branches:
      - main  # Run on pull requests targeting main

# A workflow run is made up of one or more jobs
jobs:
  # The "test" job (Continuous Integration)
  test:
    name: Run Unit Tests
    runs-on: ubuntu-latest # Use a Linux runner

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4 # Action to check out your code

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11' # Use a specific Python version

      - name: Install test dependencies
        run: |
          # No dependencies needed for this simple handler
          echo "No test dependencies to install."

      - name: Run tests (CI)
        run: |
          python test_app.py

  # The "deploy" job (Continuous Deployment)
  deploy:
    name: Deploy to AWS Lambda
    runs-on: ubuntu-latest
    needs: test # This job will ONLY run if the "test" job succeeds

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

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

      - name: Create Zip File
        run: |
          zip lambda_function.zip app.py

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          # Use the secrets you created in Step 3
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-southeast-1 # Change to your Lambda's region

      - name: Deploy to AWS Lambda (CD)
        run: |
          aws lambda update-function-code \
            --function-name blog-func \ # Change to Lambda Name
            --zip-file fileb://lambda_function.zip

Workflow Breakdown

Let's break down that YAML file.

The Triggers:

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

This tells GitHub when to run the workflow. It will run on any push to the main branch, and also on any pull_request that targets the main branch. This is great for checking if a new change breaks the tests before you merge it.

Job 1: test (The "CI" part)

This job is our Continuous Integration check.

name: Run Unit Tests

The display name in the Actions tab.

runs-on: ubuntu-latest

It runs on a fresh Ubuntu virtual machine.

uses: actions/checkout@v4

This action checks out your repository code onto the runner.

uses: actions/setup-python@v5

This action sets up the Python version we want.

run: python test_app.py

This is the key CI step. It runs our test file. If test_app.py fails (e.g., an assert is false), it will exit with an error, which fails the job and stops the entire pipeline.

Job 2: deploy (The "CD" part)

This job is our Continuous Deployment step.

needs: test

This is the most important line for safety. It tells GitHub: Do not even start this job unless the test job finished successfully. This is what prevents you from deploying broken code.

run: zip lambda_function.zip app.py

This bundles our app.py into the .zip file that Lambda requires.

uses: aws-actions/configure-aws-credentials@v4

This is an official action from AWS. It uses the aws-access-key-id and aws-secret-access-key you provide to configure the AWS CLI on the runner.

with: ... ${{ secrets.AWS_ACCESS_KEY_ID }}

This is how you securely pass your GitHub Secrets to the action. They are injected at runtime and never printed in the logs.

run: aws lambda update-function-code ...

This is the final AWS CLI command that actually performs the deployment, uploading your new lambda_function.zip to the function you specified.

Commit and Push

Commit all your new files (specifically .github/workflows/deploy.yml) and push them to your main branch. Go to the "Actions" tab in your GitHub repository.

You will see your "CI-CD for AWS Lambda" workflow start.

It will first run the test job. You can click to see the output, including "All tests passed!".

Once the test job succeeds, the deploy job will begin. You will see it zip the code, configure credentials, and run the aws lambda update-function-code command.

Check AWS: Go to your Lambda function in the AWS Console. You should see that the "Last modified" time has just updated. If you test your function in the console, it will now be running the code from your repository!

You can also see the result by turning on the Function URL and opening it!

Conclusion and Next Steps

You now have a robust and automated CI/CD pipeline. Any time you push a change to your main branch, your code will be automatically tested, and if the tests pass, it will be securely deployed to AWS Lambda. This directly solves the problem of "manially checking" and deploying "faulty" code.

From here, you can expand this pipeline to:

Use different branches for staging and production environments.
Store your Lambda function name as a GitHub Secret instead of hard-coding it.
Add a build step that installs requirements.txt into a folder before zipping.
Run more complex integration tests that actually invoke the Lambda URL.

That is it for this demonstration! Thank you for reading this informative blog, you can check out the code for this in my github

kindadailybren / CI-CD-for-AWS-Lambda-with-GitHub-Actions-Blog

Build a Simple Grocery Tracker App using Vue JS and Supabase

Breindel Medina — Tue, 11 Nov 2025 07:58:29 +0000

Sometimes, the best way to learn a new technology is to start building something

What better way to do this than to pick a stack, spin up a project, and figure things out along the way?

For this project, the stack is simple but powerful: Vue for the frontend and Supabase for the backend. Vue makes it easy to create responsive, dynamic interfaces, while Supabase handles the database, API, and even real-time functionality — all without needing to write a full backend from scratch.

This article walks through the entire process — from setting things up to building core features like adding, updating, and deleting data, and finally exploring what could be improved or added next. Along the way, you’ll find practical examples, key takeaways, and code snippets that break down how each component works, helping you build a solid grasp of these technologies. By the end, you’ll (hopefully) feel confident enough to take what you’ve learned and start building your own projects using Vue and Supabase.

Stack Breakdown

This project is built using two main technologies: Vue and Supabase.

Vue is a progressive JavaScript framework that is great for building reactive user interfaces. It’s lightweight, easy to learn, and provides a clean syntax that makes frontend development feel intuitive.

Supabase is an open-source Firebase alternative that provides a full backend out of the box — including a PostgreSQL database, authentication, file storage, and auto-generated APIs. It’s developer-friendly, easy to set up, and integrates smoothly with frontend frameworks like Vue.

Together, Vue and Supabase make a solid stack for quickly building modern web apps — without needing to spin up an entire backend from scratch.

Vue, Supabase, and Why We Chose Them

When trying to dive into something new, we knew we wanted a stack that was both easy to use and powerful enough to build something real. Vue and Supabase ended up being the perfect combo for that.

We picked Vue because of how intuitive it is — the syntax is clean, straightforward, and just makes sense. It didn’t feel overwhelming to dive into, and building dynamic UIs felt smooth from the start.

For the backend, we went with Supabase. It’s open source and super easy to set up — no complicated config or boilerplate. We got a fully functional backend out of the box, complete with a PostgreSQL database, authentication, file storage, and even real-time updates.

Together, these two tools let us focus on actually building the project instead of getting stuck on setup. They gave us a fast way to go from an idea to a working app, while learning a lot in the process.

Creating the Frontend

Alright, for this project, we’re keeping things light and fast by using Vite.

What is Vite? Think of it as a modern build tool that makes setting up and running your frontend super quick.

Difference between Vite and Vue?
Vite is just the tool that runs your Vue app behind the scenes. Vue handles the UI stuff, Vite handles the dev server and bundling.

We’ll be using npm as our package manager, so make sure that’s installed. To get started, run:

npm create vite@latest

Follow the prompts:

Next up, we’ll set up Pinia for state management (a fancy way of saying “shared data between components”):

npm install pinia

Once that's installed, use this code in the main.ts:

import { createPinia } from 'pinia'
const pinia = createPinia()
const app = createApp(App)
app.use(pinia)

This code sets up Pinia, which is a tool that helps your app share data between different components. First, it brings in Pinia, then creates a "store" (like a central place to keep your app's data). After that, it starts your Vue app and tells it to use that store so every part of the app can access and update shared data easily.

After that, feel free to do a little cleaning. Delete any of the default files you’re not using. And that's it. Your frontend is ready to roll!
Next up, backend!

Setting up Supabase

Create a Supabase Account
First, you'll need a Supabase account. Just sign up, it's quick and they are offering a free tier. Once you're in, create a new project from the dashboard. For this project, we are going to use just the Supabase dashboard to configure our database.

Configure the Database
Head over to the "Table Editor" section. Here you can create new tables. Make a table called “product”. Add a few attributes or columns: id (UUID), name (varchar), quantity (int4), and price (numeric).

Column Name     | Type
id          | UUID
name        | varchar
quantity    | int4
price       | numeric

That's all we need for this app.

Connect Supabase to Vue JS
Next, in your frontend project, make a directory called supabase and inside it, create a file named supabaseClient.ts. And, drop the following code:

import { createClient } from "@supabase/supabase-js";
const supabase_url = import.meta.env.VITE_SUPABASE_URL;
const supabase_key = import.meta.env.VITE_SUPABASE_KEY;
export const supabase = createClient(supabase_url, supabase_key);

What this does is it sets up a connection between your app and your Supabase backend by creating a client using the project URL and API Key (p.s. store the url and key in your .env file for security). With that client, you are now connected to your hosted Supabase backend.

Components Structure

In this section, you will see how the main components of the web app are implemented. Each code snippet is followed by an explanation to help you understand how the components work together to build interactive UI features.

Button Component:

<script lang="ts" setup>
defineProps<{ msg?: string }>()
</script>

<template>
    <button class="border-[1px] border-dashed px-4 py text-2xl cursor-pointer hover:bg-gray-300 transition-all duration-150">{{ msg }}</button>
</template>

This is a reusable button component. It accepts an optional msg prop to display text on the button. The button is styled with a dashed border, padding, large text, and a hover effect that changes the background color. It is used across different components for consistent styling and interactivity.

Forms Component:

<template>
  <section>
    <div>
      <div class="flex flex-col gap-4">
        <div class="flex justify-between text-2xl xl:text-3xl items-center">
          <p>{{ nameRef }}</p>
          <div class="flex gap-10">
            <div class="flex gap-2 xl:gap-4">
              <p>&#x20B1 {{ priceRef }}</p>
              <p>x</p>
              <p>{{ quantityRef }}</p>
            </div>
            <div>
              <button class="hover:cursor-pointer" @click="isEditing = !isEditing">
                Edit
              </button>
            </div>
          </div>
        </div>
      </div>
    </div>
  </section>
</template>

This part of the Forms component displays the product's name, price, and quantity in a well-structured layout. There’s an "Edit" button that toggles the editing mode by changing the isEditing value.

<!-- edit state -->
<div v-if="isEditing" class="flex flex-col gap-2">
  <div class="flex items-center justify-between text-2xl gap-4">
    <input v-model="nameRef" type="text" :placeholder="product?.name" class="w-full border-b border-dashed px-4" @keydown.enter="update" />
    <div class="flex items-center justify-center gap-1">
      <Button @click="decrement" msg="-" />
      <Button @click="quantityRef++" msg="+" class="hover:bg-green-400" />
      <button @click="deleteProd" class="border-[1px] border-dashed px-4 py-1 text-2xl cursor-pointer hover:bg-red-400 transition-all duration-150">
        <Trash class="w-6 h-6" />
      </button>
    </div>
  </div>
  <Button @click="update" msg="Save" class="hover:bg-green-400" />
</div>

When editing is enabled, the user can change the product name, increase or decrease the quantity, or delete the product. It uses the Button component for interactivity and consistent styling.

<script setup lang="ts">
import { ref, computed } from 'vue'
import { updateProduct, deleteProduct } from '../utils/actions.ts'
import Button from './Button.vue'
import Trash from './Trash.vue'
import { useAllProductsStore } from '../stores/allProducts.ts'

const productStore = useAllProductsStore()

const props = defineProps({
  id: { type: String, required: true },
});

const product = computed(() =>
  productStore.products.find((p) => p.id === props.id)
)

const nameRef = ref(product.value?.name ?? "")
const priceRef = ref(product.value?.price ?? 0)
const quantityRef = ref(product.value?.quantity ?? 0)

const update = async () => {
  isEditing.value = !isEditing.value
  if (!product.value) return;
  await updateProduct(product.value.id, nameRef.value, quantityRef.value, priceRef.value)
  isEditing.value = false
}

const deleteProd = async () => {
  await deleteProduct(props.id);
};

const decrement = () => {
  if (quantityRef.value > 1) quantityRef.value--
}
const isEditing = ref(false)
</script>

This script defines the reactive variables and functions used in the component. It connects with the Pinia store to find and update products. It also handles product deletion and quantity adjustment, toggled by the edit state.

Music Player Component:

<template>
  <div class="flex gap-10">
    <div>
      <button v-if="isPlaying" @click="() => { play(); isPlaying = false; }" class="bg-green-400 px-8 py-2 hover:bg-green-500 cursor-pointer">PLAY</button>
      <button v-else @click="() => { stop(); isPlaying = true; }" class="bg-red-400 px-8 py-2 hover:bg-red-500 cursor-pointer">STOP</button>
    </div>
    <div>
      <button v-if="isPlaying2" @click="() => { play2(); isPlaying2 = false; }" class="bg-yellow-400 px-8 py-2 hover:bg-orange-500 cursor-pointer">PLAY</button>
      <div v-else class="flex flex-col justify-center">
        <button @click="() => { pause(); isPlaying2 = true; }" class="bg-red-400 px-8 py-2 hover:bg-red-500 cursor-pointer">PAUSE</button>
        <div class="flex-col text-center text-white hidden">
          <p class="text-2xl">Playing Naaalala Ka</p>
          <p>by</p>
          <p class="text-2xl">Rey Valera</p>
        </div>
      </div>
    </div>
  </div>
</template>

This component provides buttons to control two separate audio tracks. One plays background music, and the other plays a specific song. Buttons toggle between play and stop/pause modes

<script lang="ts" setup>
import { ref } from 'vue';
import { useSound } from '@vueuse/sound';
import bgMusic from '../assets/sound/bg-music-grocery-store.mp3'
import reyValera from '../assets/sound/naaalala-ka-rey-valera.mp3'

const isPlaying = ref(true);
const isPlaying2 = ref(true);

const { play, stop } = useSound(bgMusic, {
  volume: 0.5,
  loop: true,
  autoplay: true,
})

const { play: play2, pause } = useSound(reyValera, {
  volume: 0.2,
  loop: false,
  autoplay: true,
})
</script>

This music player provides play/pause functionality for two audio tracks. It uses the @vueuse/sound library to control audio playback and manages playback states with Vue's reactivity system.

View, Add, Update, Delete Functionality

In this section of the article, you will see how the CRUD functionalities of the web app are implemented with the following code. The code may look intimidating, but this section will also explain key terms and syntax for your understanding.

An important concept and syntax that needs to be understood to fully grasp the code is async and await.

async is a keyword used to declare a function as asynchronous. It allows the use of await inside it and ensures the function returns a promise.

await is used inside an async function to pause the execution of the function until the awaited promise is resolved or rejected. This helps write asynchronous code in a cleaner, more readable way, as if it were synchronous.

Now that you know the basics of async and await, let's proceed with the code implementation of the CRUD.

View All Items:

async fetchProducts() {
  this.loading = true;
  const { data, error } = await supabase.from("product").select("*");
  if (error) {
    console.error("Error fetching products:", error);
    this.loading = false;
    return;
  }
  this.products = data as Product[];
  this.loading = false;
};

This function retrieves all items from the product table using Supabase. It sets a loading flag to true while fetching and resets it afterward. If there's an error during the fetch, it logs the error; otherwise, it stores the result in the products variable.

Add Items:

export const addItem = async (
  name: string,
  price: number,
  quantity: number,
) => {
  const { data, error } = await supabase
    .from("product")
    .insert([{ name, price, quantity }]);
  if (error) console.error("Insert failed", error);
  else console.log("Inserted item", data);
};

This function inserts a new product into the product table. It accepts the item's name, price, and quantity as arguments. If the insertion fails, it logs an error; otherwise, it confirms the item was successfully inserted.

Update Items:

export const updateProduct = async (
  id: string,
  productName: string,
  quantity: number,
  price: number,
) => {
  const { data, error } = await supabase
    .from("product")
    .update({
      name: productName,
      quantity: quantity,
      price: price,
    })
    .eq("id", id);

  if (error) {
    console.error("Update error:", error.message);
  } else {
    console.log("Updated successfully:", data);
  }
};

This function updates an existing product in the table. It uses the product's id to find the specific item and updates its name, quantity, and price. An error message is shown if the update fails, otherwise it logs the updated data.

Delete Items:

export const deleteProduct = async (id: string) => {
  const { data, error } = await supabase
    .from("product") // your table name
    .delete()

    .eq("id", id);

  if (error) {
    console.error("Delete error:", error.message);
  } else {
    console.log("Deleted row:", data);
  }
};

This function deletes a product from the table using its id. It filters the product to delete using the .eq("id", id) method. If an error occurs, it logs the error message; otherwise, it confirms the deletion.

Wrapping Up

Now that you've seen the essential features of this app, here are some ideas you can implement on your own to go even further. They're great opportunities to deepen your knowledge of Vue and Supabase:

Authentication System (Auth): Try adding user login and registration. It’s a great way to learn about route protection and Supabase auth integration.
Advanced Filtering and Sorting: Add features like search bars or dropdowns to filter and sort items by name, price, or quantity.
Different Lists for Different Users: Modify your database structure to include a column that assigns each item to a specific user. Then filter data based on who's logged in so each user sees only their own list.

Thanks for checking out our article! We hope this gave you not just insight into building with Vue and Supabase, but also ideas you’re excited to try out.

If you're curious to explore the actual code or want to see the app in action, feel free to check out our GitHub repository and live demo:

GitHub Repo:

kindadailybren / groceryTracker_SPARCS

🛒 groceryTracker_SPARCS

A simple and efficient grocery tracking app built with Vue 3, TypeScript, and Vite. This project is designed to help users manage grocery items through a clean interface, with fast performance powered by Vite and strong type safety from TypeScript.

🚀 Features

✅ Add and remove grocery items 📦 View list of tracked items

📦 Tech Stack

Framework: Vue 3

Build Tool: Vite

Language: TypeScript

State Management: Pinia (planned/included)

Backend: Supabase (optional, based on context)

🛠️ Project Setup

# Clone the repository
git clone https://github.com/kindadailybren/groceryTracker_SPARCS.git
cd groceryTracker_SPARCS

# Install dependencies
npm install

# Start development server
npm run dev

🧪 Scripts

Command Description npm run dev Start local dev server npm run build Build for production npm run lint Lint the code

👨‍💻 Author

Errol Minguez
UP Mindanao · BS Computer Science
Breindel Medina
UP Mindanao · BS Computer Science

📄 License

This project is licensed under the…

View on GitHub

Live Demo:

grocery-tracker-sparcs.vercel.app

Explore the codebase, try running it locally, or even fork it and start building your own version!

DEV Community: Breindel Medina

OverTheWire Wargames : Natas - LOTS OF DOCS, LOTS OF VULNS

Highlights

Lowlights

Conclusion

OverTheWire Wargames : Bandit - LOTS OF UNIX AND NETWORKING GOODNESS

ssh

Unix/Linux Commands, Features and Their Intricacies

cat, ls, more

find

grep

Pipe commands

sort and uniq

strings

base64

chmod

tr

diff

Shells

setuid

CRON/scripting

Networking and Communication

scp

nmap

netcat or nc

Brute forcing

openssl

Git

git clone (SSH)

git diff

Git branching

Git tagging

Git history

Git Pushing (with .gitignore)

Closing Thoughts

Visit OverTheWire Wargames : Bandit to try it out for yourself!

Modern Deployment Strategies with AWS: Blue/Green and Canary with CodeDeploy

The Danger of "In-Place" Deployments

The Traffic Shifting Alternatives

Blue/Green Deployment

Canary Deployment

AWS CodeDeploy

Why CodeDeploy?

Hands-On: ECR to ECS via CodeDeploy (CLI Workflow)

Prerequisites:

Provision stack using CloudFormation Templates

Understanding the Infrastructure Stack

Key Definitions for the Manual Workflow

Give Permissions to ECS to get ECR Image for upload later

The FastAPI Application

Build and Push the Docker Image to ECR

Register the New ECS Task Definition

Trigger the CodeDeploy Deployment

Finding the Task Definition

Blue/Green Deployment

Canary Deployment

See the Deployment in action during the 5 min window

Call the crash endpoint in another terminal

Clean Up

Takeaways

Deployment is a Spectrum of Risk

Health Checks vs. CloudWatch Alarms

Automation Reduces "Human Error" Burnout

Automating Serverless: A Guide to CI/CD for AWS Lambda with GitHub Actions

What is GitHub Actions?

Demonstration

Prerequisite 2: Your Test File

Upload Your Code to GitHub

Create AWS IAM User & Get Keys

Add Access Keys to GitHub Secrets

Create Lambda Function

Create the GitHub Actions Workflow (CI/CD)

Workflow Breakdown

Job 1: test (The "CI" part)

Job 2: deploy (The "CD" part)

Commit and Push

Conclusion and Next Steps

kindadailybren / CI-CD-for-AWS-Lambda-with-GitHub-Actions-Blog

Build a Simple Grocery Tracker App using Vue JS and Supabase

Stack Breakdown

`cat`, `ls`, `more`

`find`

`grep`

`sort` and `uniq`

`strings`

`base64`

`chmod`

`tr`

`diff`

`setuid`

`scp`

`nmap`

`netcat` or `nc`

`openssl`

`git clone` (SSH)

`git diff`

Git Pushing (with `.gitignore`)