DEV Community: Breindel Medina

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:aws:ecs:ap-southeast-1:<AWS ACC ID>:task-definition/codedeploy-workshop-task:1"
        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

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

Rollbacks are just "Forward" Deployments

In AWS CodeDeploy, a rollback isn't a "undo" button that rewinds time—it is a new, automated deployment that treats your last stable version as the "replacement." This ensures that even reverting a change follows a monitored, safe process.

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!