deployment - freeCodeCamp.org

Why Your “Simple Deploy” Turned Into a Week of Infrastructure Work

Manish Shivanandhan — Mon, 11 May 2026 18:31:13 +0000

If you're running production workloads, this guide is for you.

It's not about side projects, early-stage experiments, or a single-service app with low traffic.

This is for teams shipping real systems. Systems with users, uptime expectations, and release pressure.

Because at that stage, your deploy process is no longer a convenience. It's part of your product.

And right now, for most teams, it's the weakest part.

In this article, we'll look at why deployment complexity keeps growing as systems scale, how modern tooling unintentionally pushes teams into platform engineering work, and why many production teams are rethinking the infrastructure they manage themselves.

We'll also look at where Platform as a Service (PaaS) fits into this shift, what trade-offs it introduces, and when adopting one actually makes sense.

What We'll Cover:

The Promise You Were Sold
The Hidden Contract You Are Already Operating Under
You Are Already Acting Like a Platform Team
The Cost Is Not Complexity. It Is Time
Why “It Works on My Machine” Still Exists
Fragmentation Is the Root Problem
This Model Breaks as You Scale
The Shift Toward Platforms
What You Stop Paying For
From Infrastructure Work Back to Product Work
Collapsing the Stack
The Trade-Off You Are Actually Making
When This Becomes Urgent
What a “Simple Deploy” Actually Means
Closing Thought

The Promise You Were Sold

Every modern stack makes the same promise: Shipping is easy. Deploying is automated. Infrastructure is abstracted away. Push your code. Watch it go live.

That promise works , until it doesn’t.

And when it breaks, it doesn't fail gracefully. It expands.

A “simple deploy” turns into a multi-day investigation across systems you never intended to own.

Not because your team is careless. Because the model itself assumes you'll take on more responsibility than it admits.

The Hidden Contract You Are Already Operating Under

When you deploy today, you're not just shipping code. You're agreeing to run a distributed system of tools.

You own the build pipeline, the container lifecycle, the runtime configuration, the network rules, the secrets layer, the scaling logic, and the observability stack.

Each of these is presented as a separate concern. In reality, they're tightly coupled.

And you're the only layer holding them together. That's the hidden contract.

You Are Already Acting Like a Platform Team

If your deploy process involves CI pipelines, container registries, cloud services, environment variables, and monitoring tools, you're not just an application team anymore. You're running a platform.

You're defining how code moves from commit to production. You're deciding how failures are handled. And you're shaping how services communicate.

That's platform engineering work.

The issue isn't that this work exists. The issue is that most teams take it on unintentionally, without the structure, tooling, or dedicated ownership a real platform team would require.

The Cost Is Not Complexity. It Is Time

It's easy to describe this problem as “complexity.” But that undersells it.

The real cost shows up in how your team spends its time.

Deploys that should take minutes stretch into hours. Then days. Engineers context-switch from product work into debugging CI caches, fixing misconfigured secrets, or tracing network failures across services.

Releases slow down. Not because your team can't build features, but because shipping them becomes unpredictable.

Onboarding gets harder. New engineers don't just learn the codebase. They have to learn your deployment system.

None of this appears on a roadmap. But it directly impacts how fast you can move.

Why “It Works on My Machine” Still Exists

We were supposed to have solved this: Containers. Infrastructure as code. Reproducible builds.

Yet the gap between local and production still shows up at the worst possible moment.

Because the problem was never just environment parity. It's system parity.

Your local setup doesn't include the same limits, permissions, network paths, or scaling behavior as production.

Those differences only surface when everything is wired together. Which means they surface during deploys.

Fragmentation Is the Root Problem

Modern tooling didn't remove infrastructure complexity. It redistributed it.

Instead of managing servers, you manage integrations between services. Instead of a single failure domain, you have many.

A deploy can fail because of a CI issue, a registry timeout, a secret misconfiguration, a networking rule, or a scaling limit.

Each lives in a different system. Each requires different context.

Individually, these tools are well-designed. Collectively, they form a system that's hard to reason about under pressure.

This Model Breaks as You Scale

This only works while your system is small. But production systems don't stay small.

More services mean more pipelines. More configurations. More failure points.

Over time, the effort required to maintain your deployment system grows faster than the product itself.

That is the inflection point: where engineering time shifts away from building features and toward maintaining the machinery that ships them.

If you're already feeling that shift, it's not temporary. It's structural.

At some point, there's a question that becomes hard to ignore: Why are you still managing this yourself?

Not because you can't. But because it's no longer clear that you should.

The Shift Toward Platforms

This is where Platform as a Service changes the model. Not by adding more tools, but by taking ownership of the system those tools create.

A PaaS defines a path from code to production. That path is opinionated, constrained, and consistent.

Those constraints aren't limitations. They're what remove entire categories of failure.

Instead of assembling a deployment pipeline, you adopt one.

What You Stop Paying For

Moving to a PaaS is often framed as convenience. For production teams, it's closer to cost removal.

You stop spending time deciding how builds run, how services are exposed, how scaling is configured, and how logs are collected.

You stop debugging the integration points between those decisions. You trade flexibility for predictability.

And for most teams, predictability is the constraint that actually matters.

From Infrastructure Work Back to Product Work

The biggest change isn't in your architecture. It's in your allocation of engineering effort.

Time spent debugging deploys shifts back to building features. Time spent maintaining pipelines shifts to improving the product.

Deploys become routine again. Not because they're simpler in theory, but because the system around them is controlled.

Collapsing the Stack

The advantage of a PaaS isn't abstraction. It's consolidation.

Build, deploy, runtime, and observability are integrated into a single system.

There are fewer layers to coordinate. Fewer places to look when something fails. And fewer decisions to get wrong.

Platforms like Sevalla, Railway, and Render are pushing this further by tightening the loop between code and production, reducing both the number of systems involved and the surface area developers need to understand.

The goal is operational clarity.

The Trade-Off You Are Actually Making

The common objection is control. And it's valid. You give up the ability to customize every layer of your infrastructure.

But in practice, most teams aren't using that control to create differentiation. They're using it to keep a fragile system running, and it’s what keeps teams stuck maintaining systems they shouldn’t own.

Every custom configuration adds another failure point. Another dependency. Another thing to maintain under pressure.

The trade-off isn't control versus convenience. It's control versus reliability.

When This Becomes Urgent

You don't need a major outage to justify a change. The signals show up earlier.

Deploys feel unpredictable. Releases slow down. Engineers spend more time on pipelines than product logic. Onboarding takes longer than it should.

These aren't isolated issues. They are indicators that your current model isn't scaling with your system.

When Managing Infra Still Makes Sense

A PaaS may not right for every team.

If your app is still small, deployments are smooth, and your team isn't spending much time on infrastructure, you may not need a PaaS yet.

Some large companies also choose to build and manage their own platforms. For them, infrastructure is an important part of the business, so the extra work is worth it.

The important thing is making that choice on purpose.

Managing infrastructure is not always a bad thing. The real problem starts when app teams slowly take on platform work without enough people, clear ownership, or the right experience to handle it well.

What a “Simple Deploy” Actually Means

A simple deploy isn't one that feels easy when everything works. It's one that continues to work as your system grows.

It's predictable. Failures are rare. When they happen, they're easy to diagnose.

And most importantly, it doesn't require your engineers to think about infrastructure to ship code.

That outcome isn't achieved by adding more tools. It's achieved by reducing the system you have to manage.

Closing Thought

Your deploy didn't turn into a week of infrastructure work because you missed something. It turned into that because you're operating a model that expects you to.

You can continue investing in that model. Or you can adopt one where deploying is a solved problem.

For production teams, that's no longer a philosophical choice. It's an operational one.

Join my Applied AI newsletter to learn how to build and ship real AI systems. Practical projects, production-ready code, and direct Q&A. You can also connect with me on LinkedIn.

How to Build and Deploy a Fitness Tracker Using Python Django and PythonAnywhere - A Beginner Friendly Guide

Prabodh Tuladhar — Fri, 03 Apr 2026 17:57:00 +0000

If you've learned some Python basics but still feel stuck when it comes to building something real, you're not alone. Many beginners go through tutorials, learn about variables, functions, and loops, and then hit a wall when they try to create an actual project.

The gap between "I know Python syntax" and "I can build a working web app" can feel enormous. But it does not have to be.

In this tutorial, you'll build a fitness tracker web application from scratch using Django, one of the most popular Python web frameworks. By the end, you'll have a fully functional app running live on the internet – something you can show to friends, add to your portfolio, or keep building on.

Here's what you'll learn:

How Django projects and apps are structured
How to define database models to store workout data
How to create views that handle user requests
How to build HTML templates that display your data
How to connect URLs to views so users can navigate your app
How to deploy your finished app to PythonAnywhere so anyone can access it

The app itself is straightforward: you can log a workout by entering an activity name, duration, and date. You can then view all your logged workouts on a separate page. It's simple, but it covers the core Django concepts you need to build much bigger things later.

Let's get started.

Prerequisites
What You Are Going Build
Step 1: How to Set Up Your Django Project
Step 2: How to Create a Django App
- 2.1 How to Generate the App
- 2.2 How to Register the App
Step 3: How to create a Workout Model
- 3.1 How to Define the Model
Step 4: How to Apply Migrations
- 4.1 How to Generate the Migration
- 4.2 How to Apply the Migration
Step 5: How to Register the Model in the Admin Panel
- 5.2 How to Create a Superuser
- 5.3 How to Access the Admin Panel
Step 6: How to Create Views for the App
- 6.1 How to Create a Form Class
- 6.2 How to Write Views
Step 7: How to Create Templates
Step 8: How to Connect URLs
- 8.1 How to Create App Level URLs
- 8.2 How to Link App URLs to project
Step 9: How to Test the Application Locally
Step 10: How to Prepare for Deployment
- 10.1 How to Update Settings for Production
Step 11: How to Deploy Your Django App on PythonAnywhere
Common Mistakes and How to Fix Them
How You Can Improve This Project
Conclusion

Prerequisites

Before you begin, make sure you are comfortable with the following:

Python fundamentals: You should understand variables, functions, lists, dictionaries, and basic control flow (if/else statements and loops).

Basic command line usage: You'll be running commands in your terminal throughout this tutorial. You should know how to open a terminal, navigate between folders, and run commands. If you're on Windows, you can use Command Prompt or PowerShell. On macOS or Linux, the default Terminal app works well.

Tools you'll need installed:

Python 3.8 or higher. You can check your version by running python --version or python3 --version in your terminal. If you don't have Python installed, download it from python.org
pip. This is Python's package manager. It usually comes bundled with Python. You can verify by running pip --version or pip3 --version. Note the commands python3 and pip3 tell the terminal that you are explicitly using Python Version 3
A code editor. Visual Studio Code is a great free option, but you can use any editor you're comfortable with.

That's everything. You don't need prior Django experience or web development knowledge. This tutorial will walk you through each step.

What You Are Going Build

The fitness tracker you will build has two main features:

A form to log workouts. You will enter the name of an activity (like "Running" or "Push-ups"), how long you did it (in minutes), and the date. When you submit the form, Django saves that workout to a database.

A page to view all your workouts. This page displays every workout you have logged, showing the activity, duration, and date in a clean list.

Here's how data flows through the app at a high level:

You fill out the workout form in your browser and click submit.
Your browser sends that data to Django.
Django's view function receives the data, validates it, and saves it to the database.
When you visit the workouts page, Django's view function pulls all saved workouts from the database.
Django passes that data to an HTML template, which renders it as a page your browser can display.

This request-response cycle is the foundation of how Django works. Once you understand it, you can build almost anything.

Step 1: How to Set Up Your Django Project

Every Django project starts with a few setup steps. You'll create an isolated Python environment, install Django, and generate the initial project structure.

1. 1 How to Create a Virtual Environment

A virtual environment is a self-contained folder that contains its own Python interpreter and installed packages for a specific project. This keeps your project's dependencies separate from other Python projects on your computer. This separation prevents version conflicts and keeps setups consistent.

For example, one project might require an older version of Django, while another needs the latest version, and a virtual environment allows both to work smoothly on the same system.

Without it, global installations can clash, break projects, and make setups hard to reproduce. Over time, the system environment becomes cluttered with unused or incompatible packages making debugging and maintenance more difficult.

Now let's set it up.

Open your terminal, and navigate to where you want your project to live and run the following command

mkdir fitness-tracker
cd fitness-tracker

The first command creates a new folder called fitness-tracker. The second command moves you into that folder.

You'll create the Python virutal environment here.

python3 -m venv venv

The above command creates a virtual environment inside a folder called venv. The first venv is the command and the second venv represents the name of the folder. You can name the folder anything though venv is usually preferred.

By using the ls command, you can see that we've created the virtual environment folder.

To activate the virtual environment, we need to use the following command:

On macOS/Linux:

source venv/bin/activate

On Windows:

venv\Scripts\activate

You'll know it worked when you see (venv) at the beginning of your terminal prompt. From this point on, any Python packages you install will only exist inside this virtual environment.

1.2 How to Install Django

With your virtual environment activated, install Django using pip:

pip install django

This downloads and installs the latest stable version of Django. You can verify the installation by running:

python3 -m django --version

After running both these commands, you should see Django being installed and the version number:

1.3 How to Create the Project

We have finished installing Django. Now let's create a Django project. Django provides a command line utility that generates the boilerplate files that you need. Type the following command:

django-admin startproject fitness_project .

The command creates a folder named fitness-project. Notice the dot at the end of the command. The dot at the end is important. It tells Django to create the project files in your current directory instead of creating an extra nested folder.

Now that we've created our Django project, let's open the project in your favourite text editor and look at folder structure.

You'll notice that the folder already comes with a bunch of files.

1.4 How to Run the Development Server

Now let's make sure everything is working. You'll need to run a server for this. Type the following command:

python manage.py runserver

You can type this command in the terminal with the virtual environment activated or you can use the integrated terminal if you're using VS Code. I'll be using the integrated terminal from this point on.

Open your browser and go to http://127.0.0.1:8000/. You should see Django's default welcome page with a rocket ship graphic confirming that your project is set up correctly.

Press Ctrl + C in your terminal to stop the server when you're ready to move on.

Step 2: How to Create a Django App

In Django, a project is the overall container for your entire web application, while an app is a smaller, self-contained module inside that project that focuses on a specific piece of functionality.

A useful way to picture this is to think of a house. The project is the whole house. Each app is like a room inside that house. One room might be a kitchen, another a bedroom, each designed with a clear purpose. In the same way, a Django app is built to handle one responsibility, such as authentication, payments, or in this case, workout tracking.

Now, here's the important part: why not just put everything into one big project instead of using apps? You technically could, especially for very small projects. But as your application grows, that approach quickly becomes difficult to manage.

By using apps, you naturally separate concerns. It also makes collaboration smoother, since different people can work on different apps without constantly stepping on each other’s code.

Another major benefit is reusability. Since apps are modular, you can take an app from one project and reuse it in another.

For example, if you build a workout tracking app once, you could plug it into a completely different Django project later without rebuilding it from scratch. Later, you might create a completely different project, say a fitness coaching platform or a health dashboard. Instead of rebuilding the tracking feature from scratch, you can reuse the same app.

For this project, you'll create a single app called tracker that handles everything related to logging and displaying workouts.

2.1 How to Generate the App

Make sure you're in the same directory as the manage.py file, then run the following code:

python manage.py startapp tracker

This create a new folder called tracker with the following following structure:

Each file has its own purpose. You'll work with models.py, views.py and admin.py throughout this project.

2.2 How to Register the App

Django doesn't automatically know about your new app. You need to tell it by adding the app to the INSTALLED_APPS list in settings.py file.

Open fitness_project/settings.py and find the INSTALLED_APPS list. Add the name of the app, that is tracker, to the end of the list:

You'll notice that a number of apps have already been installed automatically by Django. This is part of Django’s “batteries-included” philosophy, where many common features are ready to use out of the box.

Here is a short summary of what each of the apps does.

App Name	Purpose
django.contrib.admin	Powers the built-in admin dashboard, letting you manage your data through a web interface.
django.contrib.auth	Handles users, login systems, permissions, and password management.
django.contrib.contenttypes	Helps Django track and manage relationships between different models.
django.contrib.sessions	Stores user session data, so users stay logged in across requests.
django.contrib.messages	Lets you show temporary notifications like success or error messages.
django.contrib.staticfiles	Manages static assets such as CSS, JavaScript, and images

Now Django knows your tracker app exists and will include it when running the project.

Step 3: How to Create a Workout Model

A model in Django is a Python class that defines the structure of your data. Each model maps directly to a table in your database. Each attribute on the model becomes a column in that table.

Think of a model as a blueprint for a spreadsheet. The class name is the name of the spreadsheet, and each field is a column header. Every time you save a new workout, Django creates a new row in that spreadsheet.

3.1 How to Define the Model

Open tracker/models.py and replace its contents with this code:

from django.db import models

class Workout(models.Model):
    activity = models.CharField(max_length=200)
    duration = models.IntegerField(help_text="Duration in minutes")
    date = models.DateField()

    def __str__(self):
        return f"{self.activity} - {self.duration} min on {self.date}"

Let's discuss what each part does:

activity = models.CharField(max_length=200) creates a text fields that can hold up to 200 characters. This is where you'll store the name of the exercise like "Running" or "Cycling".
duration = models.IntegerField(help_text="Duration in minutes") creates a whole number field for storing how many minutes the workout lasted. The help_text parameter adds a hint that will appear in forms and the admin panel.
date = models.DateField() creates a date field for recording when the workout happened.

The __str__() method defines how a Workout object appears when printed or displayed in the admin panel. Instead of seeing something unhelpful like "Workout object (1)," you will see "Running - 30 min on 2025-03-15."

Step 4: How to Apply Migrations

You've defined your model, but Django hasn't created the actual database table yet. To do that, you need to run migrations.

Migrations are Django's way of translating your Python model definitions into database instructions. Migrations are done in two steps.

When you change a model – maybe by adding a field, removing a field, or renaming one – you create a new migration that describes that change. You can do this using the makemigrations command.

Then you apply the migration using the migrate command and Django updates the database to match.

This two-step process of first detecting the change and then applying the change gives you a reliable record of every change to your database structure over time.

4.1 How to Generate the Migration

Run the following command in the integrated terminal:

python manage.py makemigrations

You should see output like this:

Migrations for 'tracker': tracker/migrations/0001_initial.py 
    + Create model Workout

Django inspected your Workout model and created a migration file that describes how to build the corresponding database table. You can find this file at tracker/migrations/0001_initial.py if you want to look at it, but you don't need to edit it.

4.2 How to Apply the Migration

Now tell Django to execute that migration and actually create the table in the database:

python manage.py migrate

You'll see several lines of output as Django applies not just your migration, but also the default migrations for Django's built-in apps (authentication, sessions, and so on).

When it finishes, your database has a table ready to store workouts.

When the migrate command runs, we can see the exact SQL commands that Django used to build and change the database. Though this isn't required for creating the application, it's always good to know what's happening under hood.

Run this command:

python manage.py sqlmigrate tracker 001

And you should get this output:

The 001 you added at the end is the migration number and represents first version of the database schema.

In practice, your workflow usually looks like this: you change your models, run makemigrations to generate the migration files, and then run the migrate command to apply those changes to the database.

Step 5: How to Register the Model in the Admin Panel

Django comes with a powerful admin interface built in. It gives you a graphical way to view, add, edit, and delete records in your database without writing any extra code. This is incredibly useful during development because you can quickly test your models and see your data.

But by default, it doesn’t know:

Which models you want to manage
How you want them displayed

So you register models in admin.py to tell Django to include the specific model in the admin interface.

5.1 How to Add Model to Admin

Open tracker/admin.py and add the following code:

from django.contrib import admin
from .models import Workout

admin.site.register(Workout)

This single line tells Django to include the Workout model in the admin interface.

5.2 How to Create a Superuser

To access the admin panel, you need an admin account. Create one by running:

python manage.py createsuperuser

Django will prompt you for a username, email address, and password. Choose something you will remember. The email is optional – you can press Enter to skip it.

5.3 How to Access the Admin Panel

Start the development server:

python manage.py runserver

Then navigate to http://127.0.0.1:8000/admin/ in your browser. Log in with the credentials you just created.

You should see the Django administration dashboard with a "Tracker" section containing your "Workouts" model.

Try clicking "Add" to create a couple of test workouts. This will confirm that your model is working correctly before you build the rest of the app.

Step 6: How to Create Views for the App

A view in Django is a Python function (or class) that receives a web request and returns a web response. That response could be an HTML page, a redirect, a 404 error, or anything else a browser can handle.

Views are where your application logic lives. They decide what data to fetch, what processing to do, and what to show the user.

For this app, you need two views: one to display the form where users add a workout, and one to display the list of all saved workouts.

6.1 How to Create a Form Class

Before writing the views, you need a Django form that handles the workout input.

Django forms are a built-in way to handle user input like login forms, contact forms, or anything that collects data from a user. Instead of manually writing HTML, validating inputs, and handling errors, Django gives you a structured way to do all of that in one place.

Most user inputs are based on the models you’ve created, and Django can automatically generate forms from those models using ModelForms, which speeds things up significantly.

Let's create a new file called forms.py in the tracker folder and add the following code:

from django import forms
from .models import Workout

class WorkoutForm(forms.ModelForm):

    class Meta:
        model = Workout
        fields = ['activity', 'duration', 'date']
        widgets = {
            'date': forms.DateInput(attrs={'type': 'date'}),
        }

In the above code, the ModelForm automatically generates form fields based on the Workout model. The widgets dictionary tells Django to render the date field as an HTML date picker instead of a plain text input.

We can actually see the forms being automatically created by Django. For this we need to enter the shell. In the terminal, type the following command:

python manage.py shell

Now lets import the WorkoutForm class that we just created.

Type the following code:

from tracker.forms import WorkoutForm

Notice that we've given the name of the app as well when we imported the form.

Then create an object of the WorkoutForm class and print it.

from tracker.forms import WorkoutForm
workoutform = WorkoutForm()
print(workoutform)

You should get the following output:

You can see that all the model fields have been renderd as HTML forms and the date field has been created as a date type that is type="date" instead of plain text.

6.2 How to Write Views

As we've discussed above, our project has two views: one to add a workout and the other to display all the saved workouts.

First, let's create a view to add a workout. In the tracker/views.py file, type the following code:

from django.shortcuts import render, redirect
from .models import Workout

# view to list all workouts
def workout_list(request):
    workouts = Workout.objects.all().order_by('-date')
    return render(request, 'tracker/workout_list.html', {'workouts': workouts})

Let's walk through this view:

The workout_list view handles the page that displays all workouts.
It queries the database for every Workout object, orders them by date (most recent first, thanks to the - prefix), and passes that list to a template called workout_list.html.
The render function combines the template with the data and returns the finished HTML page.

To create the logic to add a workout, first add the Workout form import at the end of the import section. Then add the following code after the workout_list view:

from django.shortcuts import render, redirect
from .models import Workout
from .forms import WorkoutForm

# view to list all the workouts
def workout_list(request):
    workouts = Workout.objects.all().order_by('-date')
    return render(request, 'tracker/workout_list.html', {'workouts': workouts})

# view to add a workout
def add_workout(request):
    if request.method == 'POST':
        form = WorkoutForm(request.POST)
        if form.is_valid():
            form.save()
            return redirect('workout_list')
    else:
        form = WorkoutForm()
    return render(request, 'tracker/add_workout.html', {'form': form})

The add_workout view handles both displaying the empty form and processing submitted form data.
When a user first visits the page, the request method is GET, so Django creates a blank form and renders it.
When the user fills out the form and clicks submit, the request method is POST. Django then validates the submitted data, saves it to the database if everything is correct, and redirects the user to the workout list page.
If the data isn't valid, Django re-renders the form with error messages.

Here is the complete views code:

from django.shortcuts import render, redirect
from .models import Workout
from .forms import WorkoutForm

# view to list all workouts
def workout_list(request):
    workouts = Workout.objects.all().order_by('-date')
    return render(request, 'tracker/workout_list.html', {'workouts': workouts})

# view to add a workout
def add_workout(request):
    if request.method == 'POST':
        form = WorkoutForm(request.POST)
        if form.is_valid():
            form.save()
            return redirect('workout_list')
    else:
        form = WorkoutForm()
    return render(request, 'tracker/add_workout.html', {'form': form})

Step 7: How to Create Templates

Templates are HTML files that Django fills in with dynamic data. They're the front end of your application: the part users actually see in their browser.

7.1 How to Set Up the Template Directory

Django looks for templates inside a templates folder within each app. Create the following folder structure inside your tracker app.

tracker/templates/tracker

The double tracker folder name might look redundant, but it's a Django convention called template namespacing. It prevents naming conflicts if you have multiple apps with templates that share the same filename.

7.2 How to Create the Workout List Template

Create a file called tracker/templates/tracker/workout_list.html and add the following code:




    
    
    My Workouts
    



    
        My Workouts
        + Log a Workout
        {% if workouts %}
            {% for workout in workouts %}
                
                    
                        {{ workout.activity }}
                        {{ workout.duration }} minutes
                    
                    {{ workout.date }}
                
            {% endfor %}

        {% else %}
            
                No workouts logged yet. Start by adding one!
            
        {% endif %}

There are a few things worth noting here:

If you look closely at the HTML, you'll spot some weird-looking tags wrapped in curly braces ( {% %} and {{ }} ). Think of them as special instructions for Django.

You use the double curly braces ({{ }}) when you want to output or display a piece of data directly on the page.

On the other hand, you use the brace-and-percent-sign combo ( {% %} ) when you need Django to actually perform an action or apply logic, like running a loop or checking a condition.

They allow us to inject dynamic data straight from our Python backend right into our otherwise static HTML.

Lets look at this code snippet for the workout_list.html


    
        My Workouts
        + Log a Workout
        {% if workouts %}
            {% for workout in workouts %}
                
                    
                        {{ workout.activity }}
                        {{ workout.duration }} minutes
                    
                    {{ workout.date }}
                
            {% endfor %}

        {% else %}
            
                No workouts logged yet. Start by adding one!
            
        {% endif %}

There are a few things worth noting here.

Right under the main heading, you'll see this line:

Instead of hardcoding a web link like href="/add-workout/", Django uses the {% url %} tag to generate the link dynamically. You pass it the name of the route (in this case, add_workout), and Django automatically figures out the correct URL path.

If you ever change the URL structure in your Python code later, Django updates this link automatically. You never have to hunt through HTML files to fix broken links!

The {% if workouts %} block checks whether there are any workouts to display. If the list is empty, it shows a friendly message instead of a blank page.

The {% for workout in workouts %} loop iterates over every workout in the list and renders a card for each one. The double curly braces {{ workout.activity }} insert the value of each field into the HTML

Inside the loop, you'll notice tags that look like this:

{{ workout.activity }}
{{ workout.duration }}
{{ workout.date }}

As Django loops through each workout object, it uses dot notation to peek inside that specific object and grab its details. It grabs the activity type (like "Running"), the duration ("30"), and the date ("March 30"), and prints that exact text directly onto the webpage for the user to see.

7.3 How to Create Add Workout Template

Create a file called tracker/templates/tracker/add_workout.html and add the following code:




    
    
    Log a Workout
    


    
       Log a Workout
        
            {% csrf_token %}
            
                Activity
                {{ form.activity }}
                {% if form.activity.errors %}
                    {{ form.activity.errors }}
                {% endif %}
            
            
                Duration (minutes)
                {{ form.duration }}
                {% if form.duration.errors %}
                    {{ form.duration.errors }}
                {% endif %}
            

            
                Date
                {{ form.date }}
                {% if form.date.errors %}
                    {{ form.date.errors }}
                {% endif %}
            

            
                
                Cancel

In the previous template, we learned how to display data. Now, we're looking at a form that actually collects data. Handling forms manually in web development can get messy, but Django provides some powerful template tags to do the heavy lifting for us.

Let's look at the Django-specific logic powering this form:

First, right after opening the

tag, you'll spot a very important line: {% csrf_token %}. Whenever you submit data to a server using a "POST" method, malicious sites can potentially intercept or forge that request.

By including this {% csrf_token %}, you tell Django to generate a unique, hidden security key for the form. When the user clicks "Save Workout," Django checks this token to guarantee the request is legitimate. If you forget this tag, Django will simply reject your form!


            {% csrf_token %}
            
                Activity
                {{ form.activity }}
                {% if form.activity.errors %}
                    {{ form.activity.errors }}
                {% endif %}
            
            
                Duration (minutes)
                {{ form.duration }}
                {% if form.duration.errors %}
                    {{ form.duration.errors }}
                {% endif %}
            

            
                Date
                {{ form.date }}
                {% if form.date.errors %}
                    {{ form.date.errors }}
                {% endif %}
            

            
                
                Cancel

Now let's talk about automatically generating the form fields. Instead of manually typing out all the HTML tags for the activity, duration, and date, we let Django do it for us using display tags ({{ }}).

Each {{ form.activity }}, {{ form.duration }}, and {{ form.date }} tag renders the corresponding form input. Django handles the HTML attributes, input types, and validation for you based on the model and form definitions.

The error blocks below each field display validation messages if a user submits invalid data, like entering text in the duration field instead of a number. Users make mistakes. They might leave a required field blank or type text into a number field. Fortunately, Django validates the data for you and sends back errors if something goes wrong.

Underneath each input field, we use a logic block that looks like this:
{% if form.activity.errors %}

This code checks a simple condition: Did the user mess up this specific field? If Django found an error with the "activity" input, the code drops into the if block and uses{{ form.activity.errors }} block to print the exact error message (like "This field is required") right below the input box.

You may notice that both templates include inline CSS rather than a separate stylesheet. For a small project like this, inline styles keep things simple and self-contained. In a larger project, you would use Django's static files system to manage CSS separately.

Step 8: How to Connect URLs

You have views and templates, but Django doesn't know when to use them yet. You need to map URLs to views so that visiting a specific address in the browser triggers the right view function.

8.1 How to Create App Level URLs

Create a new file called tracker/urls.py and add the following code:

from django.urls import path
from . import views

urlpatterns = [ 
    path('', views.workout_list, name='workout_list'), 
    path('add/', views.add_workout, name='add_workout'), 
]

Each path function takes three arguments.

The first is the route string that represents a URL pattern (an empty string means the root of the app).

The second is the view function to call when that URL is visited.

The third is a name you can use to reference this URL elsewhere in your code, like in the {% url %} template tags you used earlier.

8.2 How to Link App URLs to project

Now that your app-level URLs are set up, the next step is to connect them to the main project so Django knows where to start routing requests. Think of it like linking a smaller map (your app) to a bigger map (your project), so everything works together smoothly.

Open fitness_project.urls.py and update it to include your app's URLs:

from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('', include('tracker.urls')),
]

The include() function tells Django to look at the URL patterns defined in the tracker/urls.py file whenever someone visits your site. The empty string prefix means your tracker app handles requests at the root of the site.

Here's the full picture of how a request flows through the URL system.

When someone visits http://127.0.0.1:8000/add/, Django first checks fitness_project/urls.py. It matches the empty prefix and delegates to tracker/urls.py. There, it matches add/ and calls the add_workout view.

Step 9: How to Test the Application Locally

At this point, your app has everything it needs to work. Let's test it.

Start the development server by running the command:

python manage.py runserver

Open your browser and visit http://127.0.0.1:8000/. You should see the workout list page with the heading "My Workouts" and a button that says "+ Log a Workout."

Click that button. You should see the workout form with fields for activity, duration, and date.

Fill in some test data:

Activity: Skipping
Duration: 25
Date: Pick today's date from the date picker

Click "Save Workout" You should be redirected back to the workout list page, and your new workout should appear as a card.

Try adding a few more workouts with different activities and dates. Make sure they all show up on the list page in the correct order (most recent first).

This is also a good time to experiment. Try submitting the form with missing fields and see how Django handles validation.

Try accessing the admin panel at http://127.0.0.1:8000/admin/ to see your workouts there as well.

If everything works as expected, you're ready to put your app on the internet.

Step 10: How to Prepare for Deployment

Running your app on localhost is great for development, but nobody else can see it. Deployment means putting your app on a server that's accessible from anywhere on the internet.

Before you deploy, you'll need to make a few changes to your project's settings.

10.1 How to Update Settings for Production

Open fitness_project/settings.py and make the following changes.

First, set DEBUG to False.

During development, DEBUG = True shows detailed error pages that help you fix problems. In production, these error pages would expose sensitive information about your code and server to anyone who triggers an error.

Next, update ALLOWED_HOSTS to include PythonAnywhere's domain.

This setting tells Django which domain names are allowed to serve your app. Replace yourusername with the actual PythonAnywhere username you will create in the next step.

ALLOWED_HOSTS = ['yourusername.pythonanywhere.com']

Finally, add a STATIC_ROOT setting so Django knows where to collect your static files (CSS, JavaScript, images) for production:

import os
STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')

These are the minimum changes needed for a basic deployment.

💡 For a production app handling real user data, you would also want to set a secure SECRET_KEY, configure a proper database like PostgreSQL, and set up HTTPS. But for a learning project, these changes are enough.

Step 11: How to Deploy Your Django App on PythonAnywhere

PythonAnywhere is a hosting platform designed specifically for Python web applications. It offers a free tier that's perfect for beginner projects, and it handles much of the server configuration that would otherwise be complex to set up on your own.

11.1 How to Create a PythonAnywhere Account

Go to pythonanywhere.com and sign up for a free "Beginner" account. Remember the username you choose, because your app will be available at yourusername.pythonanywhere.com.

Now signup to the website. Fill in the username, email and password and click on the free tier or now.

11.2 How to Upload Your Project Files

After logging in, you have two options for getting your project files onto PythonAnywhere.

Option A: Upload using Git

If your project is in a Git repository, open a Bash console from the PythonAnywhere dashboard by clicking "Consoles" and then "Bash." Then clone your repository:

git clone https://github.com/yourusername/fitness-tracker.git

In this tutorial, we won't be using Git. Instead we'll follow the second option.

Option B: Upload files manually

First go your project folder in your computer and created a compressed version of the project.

IMPORTANT NOTE: When you create the compressed file, make sure to first create a copy of the project somewhere and remove the venv and pycache folder before you compress it.

Navigate to your home directory and click on upload file tab and upload the compressed file.

Now we need to unzip the compressed file. To do this, go to the Consoles tab and click on Bash console.

The bash console should open. Then type the following command in the console to unzip the folder:

unzip fitness-tracker.zip

11.3 How to Set Up a Virtual Environment in PythonAnywhere

Open a Bash console from the PythonAnywhere dashboard. Navigate to your project directory and create a fresh virtual environment:

cd fitness-tracker

Type the following command to install a virtual environment as we've done before and then activate the virtual environment:

python3 -m venv venv

source venv/bin/activate

Now install Django as before using pip install django command:

11.4 How to Run Migrations and Create a SuperUser on PythonAnywhere

While you're still in the Bash console with your virtual environment activated, run the migrations to create the database tables on the server:

python manage.py makemigrations

python manage.py migrate

python manage.py createsuperuser

11.4 How to Configure the Web App in Pythonanywhere

Go to the "Web" tab on the PythonAnywhere dashboard and click "Add a new web app." Follow the setup wizard:

Click "Next" on the domain name step (remember the free tier uses yourusername.pythonanywhere.com).

Select "Manual configuration" (not "Django" – the manual option gives you more control).

Then choose the Python version that matches what you installed. In my case it's 3.13, so I'll choose 3.13

Click on Next button and a WSGI (Web Server Gateway Interface) will be created.

With this we've created the web app:

After you've set up the web app, you have to do two more things:

Set the virtual environment path
Configure the WSGI file

11.5 How to Set the Virtual Environment Path

On the Web tab, scroll down to the "Virtualenv" section and enter the path to your virtual enviroment. The path to the file should be like this:

/home/yourusername/fitness-tracker/venv

11.6 How to Configure the WSGI file

Still on the Web tab, scroll to the code section and click on the WSGI configuration file link:

Delete all the contents and replace them with the content below and save the file:

import os
import sys
path = '/home/prabodhtuladhardev/fitness-tracker' #replace with your username
if path not in sys.path:
    sys.path.append(path)

os.environ['DJANGO_SETTINGS_MODULE'] = 'fitness_project.settings'

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

11.7 How to Set Up Static Files

Still on the "Web" tab, scroll down to the "Static files" section. Add an entry:

URL: /static/
Directory: /home/yourusername/fitness-tracker/staticfiles

Then go back to your Bash console and run the following command:

python manage.py collectstatic

This copies all static files to the staticfiles directory so PythonAnywhere can serve them directly.

Go back to the "Web" tab and click the green "Reload" button at the top. This restarts your app with all the new configuration.

11.8 How to View Your Live Application

Open a new browser tab and visit https://yourusername.pythonanywhere.com. You should see your fitness tracker, live on the internet.

Try adding a workout.

Visit the admin panel at https://yourusername.pythonanywhere.com/admin/.

Everything should work just as it did on your local machine, but now anyone with the link can access it.

This is a meaningful milestone. You've gone from zero to a deployed Django application. Share the link with a friend or post it in a coding community. Seeing your work live on the internet is one of the most motivating experiences in learning to code.

Common Mistakes and How to Fix Them

Even when you follow each step carefully, things can go wrong. Here are the most common issues beginners run into and how to solve them.

"ModuleNotFoundError: No module named 'django'" – This usually means your virtual environment isn't activated. Run source venv/bin/activate (macOS/Linux) or venv\Scripts\activate (Windows) and try again. On PythonAnywhere, make sure the virtualenv path in the "Web" tab points to the correct location.

"DisallowedHost" error – You forgot to add your domain to ALLOWED_HOSTS in settings.py, or there's a typo. Double-check that it matches your PythonAnywhere URL exactly.

Static files not loading in production – Make sure you ran python manage.py collectstatic and that the static file mapping on PythonAnywhere points to the correct staticfiles directory. Also verify that STATIC_ROOT is set in settings.py.

"No such table" or migration errors – You probably forgot to run python manage.py migrate after cloning or uploading your project to PythonAnywhere. Run the migrate command in the Bash console.

Changes not showing up on PythonAnywhere – After making any code changes, you must click the "Reload" button on the "Web" tab. PythonAnywhere does not automatically detect file changes.

How You Can Improve This Project

The fitness tracker you built is intentionally simple. That's a feature, not a limitation. A working simple project is the perfect foundation for learning more.

Here are some ideas for expanding it.

Add user authentication: Right now, anyone who visits the site sees the same workout data. Django has a built-in authentication system that lets you add registration, login, and logout. Each user could then have their own private list of workouts.
Add the ability to edit and delete workouts. Currently, once a workout is saved, there's no way to change or remove it from the interface (you can do it through the admin panel, but not the main app). Try creating new views and templates for editing and deleting.
Add workout categories or tags. Let users categorize their workouts as "Cardio," "Strength," "Flexibility," and so on. This would involve adding a new field to the model or creating a separate Category model with a foreign key relationship.
Add charts and progress tracking. Use a JavaScript charting library like Chart.js to display workout trends over time. For example, you could show a bar chart of total minutes exercised per week.
Build an API with Django REST Framework. If you want to learn about building APIs, try installing Django REST Framework (DRF) and creating API endpoints for your workouts. This would let you build a mobile app or a separate front end that communicates with your Django back end.

Each of these improvements will teach you something new about Django while building on the foundation you already have.

Conclusion

You've built a fully functional fitness tracker web app with Django and deployed it to the internet. That's no small achievement.

Along the way, you learned how Django projects and apps are structured, how models define the shape of your data, how migrations translate those models into database tables, how views handle the logic of your application, how templates render dynamic HTML, and how URLs tie everything together. You also went through the entire deployment process on PythonAnywhere.

These are the core building blocks of Django development. The patterns you practiced here – defining a model, creating a form, writing a view, building a template, and connecting a URL – are the same patterns you will use in every Django project, no matter how complex.

The best way to solidify what you have learned is to keep building. Try one of the improvements mentioned above, or start a completely new project. A calorie tracker, a habit tracker, an expense tracker, or a personal journal would all use the same Django concepts with slightly different models and views.

How to Self-Host AFFiNE on Windows with WSL and Docker

Abdul Talha — Thu, 12 Mar 2026 16:00:05 +0000

Depending on cloud apps means that you don't truly own your notes. If your internet goes down or if the company changes its rules, you could lose access.

In this article, you'll learn how to build your own private workspace using AFFiNE. You'll use Docker Compose to link three separate pieces of software together:

The AFFiNE Core application.
A PostgreSQL database to store your notes and pages.
A Redis cache to make the app run fast and smooth.

By the end of this article, you'll have a fully functional web app running on your own computer that works just like the cloud version of Notion.

What is AFFiNE?
Prerequisites
Step 1: Preparing Your Workspace
Step 2: Getting the Official Setup Files
Step 3: Configuring Your Environment (.env)
Step 4: Launching the System
Step 5: Accessing the Admin Panel
Step 6: Configuration (Making It Yours)
Step 7: Connecting the Desktop App (Optional)
Step 8: Stopping the Server and Safe Backups
Step 9: How to Upgrade Later
Common Installation Errors and Troubleshooting
Conclusion

What is AFFiNE?

AFFiNE is an "all-in-one" workspace that combines the powers of writing, drawing, and planning.

While tools like Notion focus on documents and Miro focus on whiteboards, AFFiNE lets you do both in a single space. You can turn your written notes into a visual canvas with one click. This makes it perfect for brainstorming, tracking tasks, and managing your personal knowledge.

The Power of Self-Hosting

While AFFiNE offers a cloud version, hosting it yourself gives you three major benefits:

Total data ownership: Your notes never leave your machine. You own the database.
Privacy in the AI age: No big tech company can scan your private ideas or use them for AI training.
Real DevOps skills: Learning how to manage Docker inside WSL is a high-value skill for any modern developer.

Prerequisites

To follow this article, make sure you have these tools ready on your machine:

WSL 2 Installation: You must have WSL installed if you are using Windows (I am using Ubuntu for this guide).
Docker and Docker Compose: These must be installed and running on your machine.
Linux Terminal Commands: You should be familiar with basic commands like mkdir, cd, and wget.

Step 1: Preparing Your Workspace

To start, create a folder for your AFFiNE files. This keeps your data in one organised place.

Then open your WSL terminal and run these commands:

mkdir affine
cd affine

Step 2: Getting the Official Setup Files

You will download the official configuration files directly from the AFFiNE. In your WSL terminal, run these two commands:

Download the Docker Compose file:

wget -O docker-compose.yml https://github.com/toeverything/affine/releases/latest/download/docker-compose.yml

Download the Environment template:

wget -O .env https://github.com/toeverything/affine/releases/latest/download/default.env.example

Step 3: Configuring Your Environment (.env)

The .env file is like a hidden settings sheet. It keeps your passwords and setup details private.

To edit this file, you can use Nano, which is a simple text editor built into your Linux terminal. Follow these steps to update your settings:

Open the file with Nano:
```
nano .env
```
Update the settings: Use your arrow keys to move around the file. Update these specific lines to match the locations below. This keeps your data safely inside your new affine folder:
```
DB_DATA_LOCATION=./postgres
UPLOAD_LOCATION=./storage
CONFIG_LOCATION=./config

DB_USERNAME=affine
DB_PASSWORD=
DB_DATABASE=affine
```
Save and Exit: Press Ctrl + O to save.
- Press Enter to confirm the filename.
- Press Ctrl + X to exit the editor.

Step 4: Launching the System

Run this Docker command to build your workspace:

docker compose up -d

Docker will download the AFFiNE app and a Postgres database. The -d flag means it will run quietly in the background.

Step 5: Accessing the Admin Panel

Once the terminal says "Started," your private server is live!

Open your web browser and go to:

http://localhost:3010/

The first time you visit this page, you must create an admin account. This is the master key to your server.

Step 6: Configuration (Making It Yours)

There are two ways to configure your server.

The Easy Way: Admin Panel

In your browser, go to http://localhost:3010/admin/settings. You can change your server name or set up emails here.

The Developer Way: Config File

You can also create a config.json file inside your ./config folder.

{
  "$schema": "https://github.com/toeverything/affine/releases/latest/download/config.schema.json",
  "server": {
    "name": "My Private Workspace"
  }
}

Step 7: Connecting the Desktop App (Optional)

You don't have to use the browser. You can connect the official AFFiNE desktop app.

Download the AFFiNE desktop app.
Click the workspace list panel in the top left corner.
Click "Add Server" and enter http://localhost:3010.
Log in with your account.

Step 8: Stopping the Server and Safe Backups

You must turn your server off safely before you back up your notes.

To do that, run this command:

docker compose down

Once it stops, you can safely copy your entire affine folder to a safe place.

Step 9: How to Upgrade Later

When AFFiNE releases a new version, run these commands inside your affine folder:

Download the newest blueprint:

wget -O docker-compose.yml https://github.com/toeverything/affine/releases/latest/download/docker-compose.yml

Pull the new images and restart:

docker compose pull
docker compose up -d

Common Installation Errors and Troubleshooting

1. Docker is Not Running

The Error: Terminal says docker: command not found.
The Fix: Open the Docker Desktop app on Windows and wait for it to start.

2. Docker is Not Connected to WSL

The Fix: In Docker Desktop, go to Settings > Resources > WSL Integration and turn it ON for your distro.

3. The Port is Already in Use

The Fix: Open docker-compose.yml. Change "3010:3010" to "4000:3010". You will now visit localhost:4000.

4. Permission Denied

The Fix: If you cannot delete a folder, use the sudo command: sudo rm -rf affine/.

Conclusion

In this tutorial, you've successfully built a self-hosted, private workspace. You practised using WSL, Docker Compose, and Postgres. These are valuable skills for any developer.

Your next steps:

Create a note in AFFiNE documenting what you learned.
Turn off your server (docker compose down) and copy your folder to a backup drive.
Explore Cloudflare Tunnels if you want to access your server from your phone!

Self-hosting takes a little work, but the privacy is worth it.

Let’s connect! You can find my latest work on my Technical Writing Portfolio or reach out to me on LinkedIn.

How to Deploy AI-Generated Code on a PaaS Platform

Manish Shivanandhan — Fri, 06 Mar 2026 06:10:53 +0000

Vibe coding is about momentum. You open your editor, prompt an AI, stitch pieces together, and suddenly you have something that works.

Maybe it’s messy. Maybe the architecture is not perfect. But it’s live and working, and that’s the point.

Then comes deployment. This is where the vibe usually dies. Suddenly, you’re reading about containers, load balancers, CI/CD pipelines, infrastructure diagrams, and networking concepts you never asked for. You wanted to ship a thing. Instead, you’re learning accidental DevOps.

The truth is simple. Most vibe-coded apps don’t need complex infrastructure. They just need a clean path from code → live URL.

That’s where a Platform-as-a-Service fits in. It removes the infrastructure ceremony and lets deployment feel like a natural extension of building.

This guide is not about perfect production architecture. It’s about shipping fast without losing momentum. In this article, we will look at how to deploy a simple vibe-coded app using Sevalla. There are other options like Railway, render, and so on, with similar features, and you can pick one from this list.

What “Vibe Deployment” Actually Means

Traditional deployment advice assumes you’re building a long-term, heavily engineered system.

Vibe coders operate differently. The goal is speed, feedback, and iteration. A vibe-friendly deployment workflow has a few core characteristics:

Minimal configuration: You shouldn’t spend hours setting up environments before seeing your app live.
Fast feedback loops: Every push should quickly show you the result.
Safe defaults: You shouldn’t need deep infra knowledge to avoid obvious mistakes.

In other words, deployment shouldn’t be a “phase.” It should be part of the normal development loop. You build. You push. It updates. You keep going.

The Typical Vibe-Coded App

Most vibe-coded projects look similar under the hood. There’s usually a frontend generated or accelerated by AI using React, Next.js, Vue, or something equally modern. The backend might be a small API, sometimes written quickly without strict structure.

Data lives in a managed database. Authentication might be glued together from a few libraries.

The code evolves rapidly. Patterns change weekly. Files get renamed, rewritten, or deleted without ceremony. And that’s fine.

The problem is that traditional deployment workflows assume stability and planning. They expect clean separation between environments, carefully defined build pipelines, and long-term operational thinking.

Vibe-coded apps need the opposite: something that tolerates change and rewards experimentation.

The PaaS Mental Model

The biggest shift with a PaaS is how you think about deployment. Instead of asking:

Which server should I use?
How do I configure networking?
What container setup do I need?
How do I maintain and run my server 24/7?

You think in terms of:

Connect your repository.
Configure the app once.
Deploy automatically.

A PaaS treats your project as a service that can be built and run. You don’t manage infrastructure, you define the minimum information needed to run your code.

There are only a few concepts you really need to understand:

Services: Each deployable unit of your app. A frontend or backend typically becomes a service.
Environment variables: Secrets and configuration that differ between local and production.
Auto builds: Every code push triggers a build and deployment.

That’s it. The system handles the rest. The result is important: deployment stops being a separate discipline and becomes just another part of coding.

How to Ship Your First App on Sevalla

Sevalla is a developer-friendly PaaS provider. It offers application hosting, database, object storage, and static site hosting for your projects.

Let’s walk through what deployment actually looks like in practice. I have already written a few tutorials on both Python and Node.js projects, building an app from scratch and deploying it on Sevalla.

Step 1: Connect Your Repository

The starting point is your Git repository. Log in to Sevalla using your GitHub account, or you can connect it after logging in with your email.

You connect your project to Sevalla and select the branch you want to deploy. This creates a direct link between your code and the live app.

You can also enable “Automatic deployments”. Once you create an app, deployment becomes automatic. You push code, and Sevalla takes care of building and publishing.

No manual uploads. No SSH sessions. No server setup.

Step 2: Configure the Runtime

Next, you define how your app runs. Most modern frameworks are detected automatically. If you’ve built something common, you usually won’t need to tweak much.

This is where you add environment variables. API keys, database URLs, authentication secrets, and anything that shouldn’t live inside your codebase.

A simple rule for vibe coders: If it changes between local and production, make it an environment variable. Once set, you rarely need to touch this again.

Step 3: Deploy

Now you deploy. Sevalla builds the application, installs dependencies, and launches it. After a short wait, you get a live URL.

This is the moment that matters. Your app is no longer a local experiment, it’s something real people can use. And importantly, you didn’t need to make infrastructure decisions to get there.

Step 4: Iterate Like a Vibe Coder

Now your workflow shines! You make a change locally. Commit. Push. Sevalla rebuilds and redeploys automatically. Your deployment process becomes invisible, just part of your normal coding rhythm.

This matters more than most people realize. When deployment is effortless, you ship more often. When you ship more often, you learn faster. And fast learning is the real advantage of vibe coding.

Things Vibe Coders Usually Break (and How PaaS Helps)

Even simple deployment workflows can go wrong. Some patterns show up repeatedly.

Missing environment variables: The app works locally but crashes in production. A PaaS surfaces configuration clearly, making it easier to spot.
Localhost assumptions. Hardcoded URLs or local file paths break once deployed. Using environment configuration fixes this early.
File storage confusion. Local files disappear between deployments. Treat storage as external from day one.
Ignoring logs. Many developers only look at logs after panic sets in. Sevalla’s centralized logs make debugging faster when something inevitably fails.

The important point: these aren’t advanced problems. They’re beginner deployment mistakes, and the platform’s defaults help you avoid most of them.

The Minimal Production Checklist

Before you call something “live,” run through a quick checklist:

Environment variables are set correctly.
The database is external, not local.
Logs are enabled and readable.
Custom domain is connected if needed.
You know how to roll back to a previous version.

That’s enough for most early-stage projects. You don’t need complex monitoring stacks or multi-region infrastructure to start learning from real users.

Why This Workflow Works for Vibe Builders

Indie builders and vibe coders succeed by maintaining velocity. The highest hidden cost in software isn’t infrastructure, it’s context switching.

Every time you stop building to become a part-time DevOps engineer, momentum drops.

A PaaS system’s biggest advantage isn’t technical sophistication. It’s psychological. You stay in the builder mindset. You focus on product decisions instead of infrastructure decisions.

And because deployment feels safe, you ship more frequently. Small releases reduce risk, reduce anxiety, and make experimentation normal. This is exactly the environment where small projects grow into real products.

Conclusion

The best deployment system is one you barely think about. For vibe coders, deployment shouldn’t be a scary milestone or a weekend project. It should feel like pressing save, just another step in the creative loop.

Build something. Push it live. Learn from users. Repeat. That’s the real goal. And when deployment stops being a bottleneck, the vibe stays alive.

Top Heroku Alternatives for Deployment in 2026

Manish Shivanandhan — Wed, 11 Feb 2026 22:04:22 +0000

For more than a decade, Heroku defined what “developer-friendly deployment” meant. Push code, forget servers, and focus on shipping features.

That promise shaped an entire generation of platform-as-a-service products. In 2026, that landscape is changing.

Heroku has clearly stated that it’s moving into a sustaining engineering model. The platform remains stable, secure, and supported, but active innovation is no longer the focus.

For many teams, this is acceptable. For others, especially startups and product teams planning three to five years ahead, it raises an important question: where should new applications live?

In this article, we’ll look at five strong Heroku alternatives that are well-positioned for 2026. Each platform approaches deployment differently, but all aim to preserve what developers loved about Heroku while improving on cost, flexibility, or modern workflows.

What We’ll Cover

Why Teams Are Looking Beyond Heroku
Sevalla: The Closest Successor to Classic Heroku
Render: A Broad Platform for Growing Teams
Fly.io : Global-First Deployment for Latency-Sensitive Apps
Upsun: Enterprise-Grade Control Without Losing Structure
Vercel: The Frontend-Native Deployment Platform
Choosing the Right Heroku Alternative in 2026
Conclusion

Why Teams Are Looking Beyond Heroku

Heroku’s shift toward maintenance over expansion signals maturity, not failure. But modern teams expect faster iteration, deeper infrastructure control, and tighter integration with cloud-native tooling.

AI workloads, edge computing, and global latency expectations are also reshaping deployment needs.

As a result, teams may want platforms that feel simple on day one but don’t become limiting as scale and complexity grow.

The alternatives discussed here are not identical replacements. Each represents a different philosophy about how applications should be built and operated in 2026.

Sevalla: The Closest Successor to Classic Heroku

Sevalla has quietly positioned itself as one of the most Heroku-like platforms available today. The core idea is familiar. You deploy applications without managing servers, environments are predictable, and the platform stays out of your way.

What makes Sevalla compelling in 2026 is its balance between simplicity and control. It keeps the developer experience tight while avoiding the opaque pricing and rigid abstractions that frustrated many Heroku users over time. Deployments are fast, logs are easy to access, and scaling feels intuitive rather than magical.

Sevalla is particularly attractive for mid-sized teams as well as enterprises that want a clean path from prototype to production. It supports modern application stacks without forcing you into complex infrastructure decisions too early. For teams migrating directly from Heroku, Sevalla often feels like the least disruptive transition.

The platform’s biggest strength is restraint. It doesn’t try to be everything at once. Instead, it focuses on being a reliable home for long-running services, APIs, and background workers. In 2026, that clarity is refreshing.

Built for the enterprise, Sevalla meets the highest standards of security. They are fully compliant with SOC2, ISO 27017, and ISO 27001:2022, ensuring your data stays protected and your requirements are met.

Render: A Broad Platform for Growing Teams

Render takes a more expansive approach. While it’s often compared to Heroku, Render aims to cover a wider range of use cases, from simple web services to complex microservice architectures.

Render stands out because it blends platform simplicity with infrastructure transparency. You still get managed databases, background jobs, and zero-downtime deploys, but you also gain more visibility into how resources are allocated. This makes it easier to reason about cost and performance as systems grow.

For teams that expect to scale steadily, Render offers a comfortable middle ground. It removes much of the operational burden while allowing deeper configuration when needed. Many engineering teams appreciate that Render feels less restrictive than Heroku without pushing them into full DevOps territory.

In 2026, Render is especially popular with SaaS companies that have outgrown entry-level platforms but are not ready to manage Kubernetes clusters themselves. It supports modern CI/CD workflows and integrates well with common developer tools.

Fly.io: Global-First Deployment for Latency-Sensitive Apps

Fly.io represents a different philosophy entirely. Instead of abstracting infrastructure away, Fly.io embraces it, but makes it programmable and developer-friendly.

Fly.io allows applications to run close to users by deploying workloads across multiple regions by default. This makes it ideal for applications where latency matters, such as real-time collaboration tools, gaming backends, or global APIs.

Unlike Heroku, Fly.io expects developers to understand a bit more about how their application runs. You interact with virtual machines rather than dynos, and configuration is more explicit. However, this added complexity comes with real power.

In 2026, Fly.io appeals strongly to experienced teams that want performance and control without adopting heavy orchestration systems. It’s not always the easiest option, but it is one of the most flexible. For teams willing to invest in understanding the platform, Fly.io can outperform traditional PaaS solutions in both speed and cost efficiency.

Upsun: Enterprise-Grade Control Without Losing Structure

Upsun, previously known as Platform.sh, brings a more opinionated, enterprise-oriented model to application deployment. It’s designed for teams that care deeply about environment parity, reproducibility, and long-term maintainability.

Upsun treats infrastructure as part of the application. Environments are versioned alongside code, and deployments are deterministic. This approach reduces surprises and makes complex systems easier to reason about over time.

For organizations with compliance requirements or multi-environment workflows, Upsun offers a level of rigor that Heroku never aimed to provide. At the same time, it abstracts away much of the operational burden that typically comes with such control.

In 2026, Upsun is particularly well-suited for regulated industries, large content platforms, and teams with multiple long-lived environments. It’s less about rapid experimentation and more about predictable, repeatable delivery at scale.

Vercel: The Frontend-Native Deployment Platform

Vercel is often discussed in a different category, but it deserves inclusion in any modern deployment conversation. Vercel is optimized for frontend applications, serverless functions, and edge workloads.

If Heroku excelled at hosting monolithic web apps, Vercel excels at composable, frontend-driven architectures. It integrates deeply with modern frameworks and makes global deployment nearly effortless.

In 2026, many applications are frontend-heavy, with APIs split into smaller services or serverless functions. For these use cases, Vercel offers a developer experience that feels faster and more modern than traditional PaaS platforms.

However, Vercel is not a full replacement for Heroku in every scenario. Long-running background jobs and stateful services often live elsewhere. Still, for teams building modern web products, Vercel frequently becomes the centerpiece of their deployment strategy.

Choosing the Right Heroku Alternative in 2026

There is no single “best” Heroku replacement. The right choice depends on how your application behaves, how your team works, and how much control you want over infrastructure.

Sevalla is ideal for teams that want familiarity and minimal friction. Render suits growing teams that need flexibility without chaos. Fly.io is powerful for global, performance-sensitive systems. Upsun excels in structured, enterprise environments. Vercel dominates frontend-centric architectures.

The common thread is that deployment in 2026 is no longer one-size-fits-all. Heroku set the standard, but the ecosystem has evolved. Today’s platforms offer sharper trade-offs, clearer philosophies, and better alignment with modern development patterns.

For teams starting new projects, the opportunity is clear. You can choose a platform that matches your future, not just your present.

Conclusion

Heroku is not disappearing, and for many existing workloads, it will continue to run reliably for years. However, its shift toward a sustaining engineering model makes one thing clear: teams building new products in 2026 should think carefully about where they place their long-term bets.

Deployment platforms are no longer just hosting choices. They shape how fast teams move, how systems scale, and how painful future migrations become.

In 2026, the strongest deployment strategy is intentional, not inherited. Heroku showed the industry what was possible. Its successors are now defining what comes next.

Hope you enjoyed this article. Learn more about me by visiting my website.

How to Dockerize Your Application and Deploy It

Manish Shivanandhan — Thu, 05 Feb 2026 22:49:05 +0000

Modern applications rarely live in isolation. They move between laptops, staging servers, and production environments.

Each environment has its own quirks, missing libraries, or slightly different configurations. This is where many “works on my machine” problems begin.

Docker was created to solve this exact issue, and it has become a core skill for anyone building and deploying software today.

In this article, you’ll learn how to Dockerize a LogAnalyzer Agent project and prepare it for deployment.

We’ll first understand what Docker is and why it matters. Then we’ll walk through converting this FastAPI-based project into a Dockerized application. Finally, we’ll cover how to build and upload the Docker image so it can be deployed to a cloud platform like Sevalla.

You only need a basic understanding of Python for this project. If you want to learn Docker in detail, go through this detailed tutorial.

What is Docker?

Docker is a tool that packages your application together with everything it needs to run. This includes the operating system libraries, system dependencies, Python version, and Python packages. The result is called a Docker image. When this image runs, it becomes a container.

A container behaves the same way everywhere. If it runs on your laptop, it will run the same way on a cloud server. This consistency is the main reason Docker is so widely used.

For the LogAnalyzer Agent, this means that FastAPI, LangChain, and all Python dependencies will always be available, regardless of where the app is deployed.

Why Docker Matters

Without Docker, deployment usually involves manually installing dependencies on a server. This process is slow and error prone. A missing system package or a wrong Python version can break the app.

Docker removes this uncertainty. You define the environment once, using a Dockerfile, and reuse it everywhere. This makes onboarding new developers easier, simplifies CI pipelines, and reduces production bugs.

For AI-powered services like the LogAnalyzer Agent, Docker is even more important. These services often rely on specific library versions and environment variables, such as API keys. Docker ensures that these details are controlled and repeatable.

Understanding the Project

Before containerizing the application, it’s important to understand its structure. The LogAnalyzer Agent consists of a FastAPI backend that serves an HTML frontend and exposes an API endpoint for log analysis.

The backend depends on Python packages like FastAPI, LangChain, and the OpenAI client. It also relies on an environment variable for the OpenAI API key.

From Docker’s point of view, this is a typical Python web service. That makes it an ideal candidate for containerization.

At this stage, you should clone the project repository to your local machine. You can run the app using the command python app.py

Writing the Dockerfile

The Dockerfile is the recipe that tells Docker how to build your image. It starts with a base image, installs dependencies, copies your code, and defines how the application should start.

For this project, a lightweight Python image is a good choice. The Dockerfile might look like this:

FROM python:3.11-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Each line has a purpose: the base image provides Python and the working directory keeps files organized.

Dependencies are installed before copying the full code to improve build caching. The expose instruction documents the port used by the app. The command starts the FastAPI server.

This file alone turns your project into something Docker understands.

Handling Environment Variables in Docker

The LogAnalyzer Agent relies on an OpenAI API key. This key should never be hardcoded into the image. Instead, Docker allows environment variables to be passed at runtime.

During local testing, you can still use a .env file. When running the container, you can pass the variable using Docker’s environment flags or your deployment platform’s settings.

This separation keeps secrets secure and allows the same image to be used in multiple environments.

Building the Docker Image

Once the Dockerfile is ready, building the image is straightforward. From the root of the project, you run a Docker build command:

docker build -t loganalyzer:latest .

Docker reads the Dockerfile, executes each step, and produces an image.

This image contains your FastAPI app, the HTML UI, and all dependencies. At this point, you can run it locally to verify that everything works exactly as before.

Running the container locally is an important validation step. If the app works inside Docker on your machine, it’s very likely to work in production as well.

Testing the Container Locally

After building the image, you can start a container and map its port to your local machine. When the container starts, Uvicorn runs inside it, just like it did outside Docker.

docker run -d -p 8000:8000 -e OPENAI_API_KEY=your_api_key_here loganalyzer:latest

You should be able to open a browser, upload a log file, and receive analysis results. If something fails, the container logs will usually point you to missing files or incorrect paths.

This feedback loop is fast and helps you fix issues before deployment.

Preparing the Image for Deployment

At this stage, the Docker image is ready to be uploaded to a container registry. A registry is a place where Docker images are stored and shared. Your deployment platform will later pull the image from this registry.

We’ll use DockerHub to push our image. Create an account and run docker login command to authenticate it with your terminal.

Now let’s tag and push your image to the repository:

docker tag loganalyzer:latest your-dockerhub-username/loganalyzer:latest
docker push your-dockerhub-username/loganalyzer:latest

Adding the Docker Image to Sevalla

The final step is to upload the Docker image for deployment.

You can choose any cloud provider, like AWS, DigitalOcean, or others, to run your application. I’ll be using Sevalla for this example.

Sevalla is a developer-friendly PaaS provider. It offers application hosting, database, object storage, and static site hosting for your projects.

Every platform will charge you for creating a cloud resource. Sevalla comes with a $20 credit for us to use, so we won’t incur any costs for this example.

You can see the option to link your container repository. Use the default settings. Click “Create application”.

Now we have to add our OpenAI API key to the environment variables. Click on the “Environment variables” section once the application is created, and save the OPENAI_API_KEY value as an environment variable.

We’re now ready to deploy our application. Click on “Deployments” and click “Deploy now”. It will take 2–3 minutes for the deployment to complete.

Once done, click on “Visit app”. You will see the application served via a URL ending with sevalla.app.

Congrats! Your log analyser service is now Dockerized and live.

From this point on, deployment becomes simple. A new version of the app is just a new Docker image. You can push an image to the repository and Sevalla will pull it automatically.

Final Thoughts

Docker turns your application into a portable, predictable unit. For the LogAnalyzer Agent, this means the AI logic, the FastAPI server, and the frontend all move together as one artifact.

By cloning the project, adding a Dockerfile, and building an image, you convert a local prototype into a deployable service. Uploading that image to Sevalla completes the journey from code to production.

Once you’re comfortable with this workflow, you’ll find that Docker isn’t just a deployment tool. It becomes a core part of how you design, test, and ship applications with confidence.

Hope you enjoyed this article. Learn more about me by visiting my website.

How to Deploy a MERN Stack Notes App on AWS

Umair Mirza — Sat, 17 Jan 2026 02:25:39 +0000

Platforms like Vercel, Netlify, and Render simplify deployment by handling infrastructure for you. In this tutorial, we’ll step one layer deeper and work directly with AWS to understand the building blocks behind these platforms.

You'll take a small React and Express notes app and ship it straight to AWS. We'll use EC2 for the API, RDS Postgres for the database, and S3 (optionally CloudFront) for the frontend. If you're new to AWS, you can turn on the Free Tier first: https://aws.amazon.com/free.

If you’ve mostly used one-click deployments before, this guide will help you understand what’s happening behind the scenes. You’ll work directly with the core AWS services involved, focusing only on the pieces that matter so you can see how everything fits together. This will also enable you to have more control over cost, security, and scaling.

If you just want to grab the finished code, it's all in this public repo: umair-mirza/mern-notes-aws. You can clone or fork it and follow along without creating a new project from scratch.

What You’ll Build
Prerequisites
Mental Map
Free Tier Basics
Environment Variables
Step #1 - Run It Locally First
Step #2 - Push to GitHub (So EC2 Can Pull)
Step #3 - Create AWS Resources (Quick Path)
Step #4 - Configure the EC2 Box
Step #5 - Build and Upload the Frontend
Step #6 - Quick Troubleshooting
Step #7 - Secure and Save
Step #8 - Verify End-to-End
Next Steps

What You’ll Build

Before touching any buttons in AWS, it's helpful to know the exact pieces you're trying to build. At the end of this guide, you'll have a classic three-tier web app: a browser-based frontend, a backend API, and a database, all talking to each other over a network.

API (Express/Node) on EC2
Postgres on RDS (Free Tier eligible)
React/Vite frontend on S3 (CloudFront optional for CDN/HTTPS)
Health check at /api/health and CRUD at /api/notes

Prerequisites

You don't need to be a DevOps expert to follow along, but you should be comfortable running basic commands in a terminal and editing some config files. If you've ever used npm install before, then you're in the right place.

AWS account + AWS CLI configured (aws configure) – see AWS account setup and AWS CLI install.
Node.js 18+ and npm – get it from nodejs.org .
Git + GitHub repo – see GitHub getting started.
(Optional) Route 53 domain for a clean URL – Route 53 domains.

Mental Map

AWS throws a lot of jargon at you (VPCs, security groups, subnets). This section is the story version of what happens when someone opens your app in the browser, without any buzzwords. If you can picture this flow, the later AWS screens will feel less scary.

Browser loads the built React app from S3 (or CloudFront -> S3)
Browser calls the API on EC2 over HTTP/HTTPS
EC2 talks to RDS Postgres on port 5432 inside your VPC
Security groups: allow 80/443 to EC2; allow 5432 only from the EC2 SG to RDS

Free Tier Basics

AWS can be cheap if you use the free tier, but it can also surprise you with bills if you accidentally orprovision or leave things running. Here are the main knobs that affect cost for this tutorial and what to watch out for.

EC2: t2.micro or t3.micro ~750 hours/month
RDS: db.t3.micro Postgres/MySQL with ~20 GB storage
S3/CloudFront: Small sites cost pennies - free tier includes some egress
Save money: Stop EC2 when idle. Delete unused buckets/DBs

Environment Variables

Environment variables are just configuration values that live outside your code: ports, database URLs, and allowed origins. They keep secrets (like DB passwords) out of your Git repo and let the same code run in different places (local, staging, production) with different settings.

Backend: PORT, DATABASE_URL (your RDS endpoint), DATABASE_SSL (true on RDS), CORS_ORIGIN
Frontend: VITE_API_URL (API base, for example, https://api.example.com/api)

Step #1 - Run It Locally First

Before touching AWS, you want to prove the app actually works on your own machine. This removes a whole category of "Is it AWS or my code?" debugging later. In this step you just install dependencies and run both backend and frontend in dev mode.

cd mern-notes-aws

# Backend
cd backend
npm install
cp .env.example .env   # set DATABASE_URL to RDS (or local Postgres), DATABASE_SSL=true for RDS
npm run dev            # API on http://localhost:4000

# Frontend (new terminal)
cd frontend
npm install
cp .env.example .env   # keep API URL at http://localhost:4000/api for local dev
npm run dev            # SPA on http://localhost:5173

Open http://localhost:5173, add a note, and check if it persists. /api/health should return { status: 'ok' }. If something is broken here, pause and fix it before moving on. AWS will only make debugging harder.

Step #2 - Push to GitHub (So EC2 Can Pull)

Your EC2 server in AWS needs a place to pull your code from. Using GitHub is the simplest option: you push your code once, then the EC2 instance clones that repo. You can also reuse this repo later with CI/CD if you decide to automate deployments.

cd mern-notes-aws
git init
git add .
git commit -m "feat: mern notes app"
git branch -M main
git remote add origin https://github.com//mern-notes-aws.git
git push -u origin main

If you're following along with my example repo instead of creating your own, you can simply fork umair-mirza/mern-notes-aws and use that as your remote.

Before pushing, make sure your .env file is not committed to GitHub. Add it to your .gitignore so secrets like database passwords never end up in version control:

echo ".env" >> .gitignore

If you’ve already created a .env file locally, double-check it doesn’t appear in git status before committing.

Step #3 - Create AWS Resources (Quick Path)

RDS (Postgres, Free Tier template)

RDS (Relational Database Service) is AWS's way of running managed databases for you. Instead of installing Postgres manually on a VM, you click a few options and AWS handles backups, patching, and high availability. For this app we only need a small, free tier–eligible Postgres instance.

For more background, you can skim the official Amazon RDS for PostgreSQL docs.

We’ll start by creating the database layer. The settings below are the minimum you need for a small, production-style Postgres setup that stays within the AWS Free Tier while still following basic best practices.

RDS Create database Postgres Free Tier.
Class db.t3.micro, storage 20 GB gp2/gp3.
Set master user/pass. You'll need them for DATABASE_URL.
Public access: No.
Security group: allow 5432 only from the EC2 security group.
Enable backups and Require SSL. Download the RDS CA if you want strict cert validation.

S3 Bucket for the Frontend

S3 is AWS's "infinite hard drive" for files. A React/Vite app builds down to plain HTML, CSS, and JavaScript files, which are perfect to host from S3. Think of S3 as a very simple web server that just serves static files.

If you want to see more options, check the Hosting a static website on Amazon S3 guide.

Now, we’ll create an S3 bucket to host the React frontend. These options configure the bucket for static website hosting while keeping it simple and inexpensive.

Create bucket mern-notes-aws-frontend-.
For simple hosting, enable static website hosting and allow public reads, or keep private and use CloudFront + OAC.
Turn on versioning if you want rollback safety.

EC2 for the API

EC2 is "a computer in the cloud" that you control. You'll install Node.js on it, pull your code, and run server.js so that your backend API is always on. The security group attached to this instance works like a firewall.

If you've never launched an instance before, the Getting started with Amazon EC2 guide walks through the console screens you'll see.

Finally, we’ll provision a small EC2 instance to run the Express API. The configuration below focuses on a free tier–eligible setup that’s secure enough for learning and easy to extend later.

Launch Amazon Linux 2023, size t3.micro.
Inbound SG: 22 (your IP), 80 (world), 443 if you add HTTPS on the instance/ALB.
Attach this SG as the allowed source to RDS.

Optional: CloudFront + Route 53

CloudFront is AWS's CDN (content delivery network), and Route 53 is their DNS service. You don't strictly need them to get your app working, but they make it faster and nicer: your app loads from edge locations close to users and can live behind a friendly domain like app.example.com.

For more details, see Getting started with Amazon CloudFront and the Route 53 DNS developer guide.

Origin: the S3 bucket. Default root index.html. Add OAC if bucket is private.
Request an ACM cert in us-east-1, then create a Route 53 A/AAAA alias to the distribution.

Step #4 - Configure the EC2 Box

Once your EC2 instance is running, you treat it like a clean Linux machine. The commands below install the tools your API needs, pull your code from GitHub, configure environment variables, and run the server in a production-safe way.

Install basics:

sudo dnf update -y

This command updates all system packages to the latest versions. It's a good first step on any new Linux server.

sudo dnf install -y git

Installs Git so the EC2 instance can clone your repository from GitHub.

curl -fsSL https://rpm.nodesource.com/setup_20.x | sudo bash -

Adds the official NodeSource repository so you can install a modern version of Node.js (v20). Amazon Linux doesn’t ship with recent Node versions by default.

sudo dnf install -y nodejs

Installs Node.js and npm, which are required to run your Express API.

sudo npm install -g pm2

Installs PM2, a lightweight process manager that keeps your Node app running in the background and restarts it if it crashes or the server reboots.

Pull code and set environment variables:

git clone https://github.com//mern-notes-aws.git
cd mern-notes-aws/backend
npm install

cat <<'EOF' > .env
PORT=80
DATABASE_URL=postgres://:@:5432/
DATABASE_SSL=true
CORS_ORIGIN=https://
EOF

Start the API with PM2:

pm2 start server.js --name mern-notes-api
pm2 save
pm2 startup systemd -u ec2-user --hp /home/ec2-user

PM2 is a small process manager that makes sure your Node server keeps running if the machine reboots or the process crashes. Test on the box: curl http://localhost/api/health. From your laptop: http:///api/health (make sure SG allows 80/443).

Step #5 - Build and Upload the Frontend

In development, Vite serves your React app from memory, but in production you want a set of static files that any web server (or S3) can host. npm run build creates an optimized dist/ folder that you sync to S3 so the browser can load it.

cd frontend
setx VITE_API_URL "https:///api"
npm run build

This sets an environment variable called VITE_API_URL on your local machine. Vite only exposes environment variables to the frontend if they start with the VITE_ prefix.

Upload:

aws s3 sync dist/ s3://mern-notes-aws-frontend-/ --delete

This uploads your compiled frontend (dist/) to S3 and removes old files that no longer exist locally, ensuring the bucket reflects the current version of the app

Open the S3 website URL or your CloudFront URL.

Step #6 - Quick Troubleshooting

If something doesn't work the first time, that's normal, especially with networking and AWS permissions. This section gives you a few quick places to look before you start randomly changing settings in the console.

API 500s: pm2 logs mern-notes-api. This is often a bad DATABASE_URL or SSL flag.
DB connect issues: RDS SG must allow the EC2 SG - use the RDS endpoint.
CORS errors: CORS_ORIGIN must match your frontend origin exactly.
403 from S3: If you’re using static website hosting, allow public reads. With CloudFront, keep bucket private and use OAC.
Blank page: Confirm that you’ve uploaded dist/ to the right bucket.

Step #7 - Secure and Save

Once everything works, you don't want to accidentally expose your database to the internet or burn through free tier hours. These are simple, beginner-friendly hardening steps that make your setup safer and cheaper without turning you into a full-time security engineer.

Turn off SSH after setup or switch to SSM Session Manager.
Use HTTPS (CloudFront + ACM or ALB + ACM).
Keep RDS private and use SSM port forwarding if needed.
Ship PM2 logs with CloudWatch Agent and add alarms for CPU/status checks.
Snapshot RDS daily and stop EC2 when idle to save hours.

Step #8 - Verify End-to-End

Before you celebrate, run through the app like a real user: open it in the browser, create notes, refresh, and make sure everything behaves as expected. This confirms your frontend, API, and database are all wired together correctly.

Load the frontend (S3 or CloudFront).
Create and delete notes. They should persist in RDS.
Hit /api/health for a quick liveness check.

Next Steps

Once you're comfortable with this manual setup, you can start layering on more advanced tools. The ideas are the same: frontend, API and database but you get more automation, safety, and scalability.

Add Prisma + migrations for stronger schemas.
Add auth (Cognito/Auth0) and per-user notes.
Containerize and run on ECS/Fargate or add an ALB in front of EC2.
Use Terraform/CDK to recreate this stack with one command.

How to Manage Blue-Green Deployments on AWS ECS with Database Migrations: Complete Implementation Guide

Destiny Erhabor — Thu, 15 Jan 2026 18:25:13 +0000

Blue-green deployments are celebrated for enabling zero-downtime releases and instant rollbacks. You deploy your new version (green) alongside the current one (blue), switch traffic over, and if something goes wrong, you switch back. Simple, right?

Not quite. While blue-green deployments work beautifully for stateless applications, they become significantly more complex when you introduce databases and stateful services into the equation. The moment your blue and green environments need to share a database, you're facing a fundamental challenge: how do you evolve your schema and data without breaking either version?

In this article, we'll tackle the real-world complexities of implementing blue-green deployments on Amazon ECS when your application depends on shared state. You'll learn practical strategies for handling database migrations, managing sessions, and maintaining data consistency across application versions.

💡 Complete Working Example: All code examples in this article are available in the bluegreen-deployment-ecs repository on GitHub. You can clone it and deploy the entire infrastructure to your AWS account.

The Problem with State in Blue-Green Deployments
Database Migration Strategies for Blue-Green
Handling Stateful Services in ECS
Complete Implementation: End-to-End Example
Rollback Strategies
Monitoring During Deployments
Best Practices
When NOT to Use Blue-Green
Alternative Deployment Strategies
Cleanup
Conclusion
Further Resources

The Problem with State in Blue-Green Deployments

The elegance of blue-green deployments starts to crumble when you consider databases. Here's why: your blue environment runs application version 1, your green environment runs version 2, but they both connect to the same RDS instance.

Consider this scenario: you're adding a new feature that requires a new database column. Version 2 of your application expects this column to exist. You deploy green, run your migration to add the column, and switch traffic.

Everything works great until you need to rollback. Now version 1 is receiving traffic, but it doesn't know what to do with that new column. Worse, if your migration removed or renamed a column that version 1 depends on, your rollback will fail catastrophically.

Here are the specific challenges you'll face:

Schema versioning conflicts: Your blue environment expects schema version N, while green expects version N+1. Any breaking schema change will cause one environment to fail.
Data inconsistencies: If version 2 writes data in a new format that version 1 can't read, switching back to blue will result in errors or data corruption.
Irreversible migrations: Some database changes are inherently destructive. Dropping a column, changing data types, or restructuring tables can't be easily undone.
Failed rollbacks: The promise of instant rollback becomes hollow when your database has evolved beyond what the blue environment can handle.

Let's explore the strategies that solve these problems.

Database Migration Strategies for Blue-Green

Strategy 1: The Expand-Contract Pattern (Recommended)

The expand-contract pattern is the most practical approach for blue-green deployments with shared databases. It works by breaking schema changes into three phases, ensuring backwards compatibility throughout.

Phase 1: Expand

In this phase, you add new schema elements while keeping old ones intact. If you're renaming a column, add the new column without removing the old one. If you're changing table structure, create new tables alongside existing ones.

-- Example: Renaming 'user_name' to 'username'
-- Phase 1: Expand - Add new column
ALTER TABLE users ADD COLUMN username VARCHAR(255);

-- Populate new column from old column
UPDATE users SET username = user_name WHERE username IS NULL;

At this point, your database supports both the old schema (used by blue) and the new schema (used by green). Your application code needs to handle both as well.

Phase 2: Deploy

Now, deploy your green environment with code that uses the new schema. But this code should still write to both old and new columns to maintain compatibility.

# Version 2 code - writes to both columns
def update_user(user_id, username):
    db.execute(
        "UPDATE users SET username = %s, user_name = %s WHERE id = %s",
        (username, username, user_id)
    )

Traffic shifts from blue to green. Both environments work because the database supports both schemas. If you need to rollback, blue still functions perfectly because the old columns are intact.

Phase 3: Contract

After you're confident green is stable and you've decommissioned blue, remove the old schema elements in a separate deployment.

-- Phase 3: Contract - Remove old column
ALTER TABLE users DROP COLUMN user_name;

Update your application code to stop writing to the old columns. This is now version 3, deployed as a standard release.

When to use: This should be your default approach for most schema changes including adding/removing columns, renaming fields, changing constraints, and restructuring tables.

Strategy 2: Parallel Schemas or Databases

For major breaking changes where backwards compatibility is impractical, you might maintain entirely separate database versions. Version 1 connects to database A, version 2 connects to database B. This approach requires data synchronization between databases. AWS Database Migration Service (DMS) can replicate data in near real-time, or you can build custom replication logic using change data capture.

# Configuration for version-specific database connections
DATABASE_CONFIG = {
    'v1': {
        'host': 'blue-db.cluster-xxxxx.us-east-1.rds.amazonaws.com',
        'database': 'app_v1'
    },
    'v2': {
        'host': 'green-db.cluster-yyyyy.us-east-1.rds.amazonaws.com',
        'database': 'app_v2'
    }
}

During the transition period, you run DMS to keep both databases synchronized, with the understanding that writes go to the active version's database.

The challenge is that you're now managing data synchronization, dealing with replication lag, and paying for two databases. Eventually, you need to consolidate back to one database, which requires another migration. This is expensive and complex, which is why it's the "nuclear option."

When to use: Only for major architectural changes, complete data model redesigns, or when migrating between database types (for example, MySQL to PostgreSQL). If expand-contract can possibly work, use that instead.

Strategy 3: Feature Flags for Gradual Rollout

Feature flags allow you to decouple deployment from release. Both blue and green run the same codebase, but features are toggled on or off via configuration. This shifts the problem from schema compatibility to code-level compatibility.

def create_user(user_data):
    config = get_feature_config()
    if config['use_new_user_schema']:
        return create_user_v2(user_data)
    else:
        return create_user_v1(user_data)

Instead of having two separate deployments (blue and green), you have ONE deployment with conditional logic. The "switch" from old to new behavior happens via configuration change, not infrastructure change. This is technically not pure blue-green, but it's a powerful hybrid approach.

How it works

Your application checks AWS AppConfig (or similar service) for feature flags before executing code paths. When a flag is off, it uses the old schema/logic. When on, it uses the new schema/logic. You can even enable features for a percentage of users (5% get new behavior, 95% get old behavior) for gradual rollout.

The tradeoff is that your codebase temporarily contains both old and new logic with conditional branches everywhere. This increases complexity and requires disciplined cleanup after the feature is fully released. However, you gain fine-grained control and can toggle features on/off instantly without deploying new infrastructure.

When to use: For large features with uncertain stability, gradual rollouts to monitor impact, or when you want instant rollback capability without touching infrastructure. Also useful when combined with expand-contract for extra safety.

Handling Stateful Services in ECS

Beyond databases, several other stateful components require careful consideration during blue-green deployments.

Session Management

It’s a good idea to store sessions in ElastiCache or DynamoDB rather than application memory:

app.config['SESSION_TYPE'] = 'dynamodb'
app.config['SESSION_DYNAMODB'] = boto3.client('dynamodb')

Shared Resources

Beyond database sessions, your application likely depends on other stateful components that need coordination during blue-green deployments:

1. S3 buckets

If your application stores files or data in S3, schema changes to object metadata or file formats can cause compatibility issues between versions. To address this, you can enable S3 versioning to maintain multiple format versions simultaneously.

For example, if version 2 writes JSON files with a new structure, version 1 should still be able to read the old format. You can include a version prefix in object keys (like v1/user-data.json and v2/user-data.json) or embed version metadata in the objects themselves.

Message queues (SQS/SNS)

Messages sent by one version must be readable by the other during the transition. You can use versioned message schemas with a schema_version field in your message payload. Both blue and green should be able to parse messages from either version, even if they only produce messages in their preferred format. Consider using a schema registry or validation library to ensure compatibility.

Cache layers (ElastiCache/Redis)

Cached data structure changes can cause deserialization errors when switching between versions. Try versioning your cache keys by including the schema version: CACHE_VERSION = 'v2' and then cache_key = f"user:{CACHE_VERSION}:{user_id}". This ensures blue and green maintain separate cache namespaces, preventing cross-contamination. When you fully migrate to green, you can flush the old cache keys or let them expire naturally.

CACHE_VERSION = 'v2'
cache_key = f"user:{CACHE_VERSION}:{user_id}"

Implementation: End-to-End Example

Let's walk through a complete blue-green deployment with ECS, handling a database schema change using the expand-contract pattern. We'll migrate from a single address text field to structured street_address, city, state, and zip_code fields.

Here’s the scenario: You're running an e-commerce application on ECS. The current version (blue) stores customer addresses in a single address text field. Version 2 (green) splits this into structured fields: street_address, city, state, and zip_code.

Architecture Setup

Your infrastructure includes:

ECS cluster running Fargate tasks
Application Load Balancer with two target groups (blue and green)
RDS PostgreSQL database (shared between environments)
CodeDeploy for managing traffic shifts
Parameter Store for database connection strings

💡 Implementation Note: The complete Terraform code for this architecture is available in the companion GitHub repository.

Prerequisites

Before starting, make sure that you have the following tools installed and your AWS credentials properly configured:

# Required tools
aws --version      # AWS CLI
terraform --version # Terraform >= 1.0
docker --version   # Docker
psql --version     # PostgreSQL client

# Configure AWS credentials
aws configure
aws sts get-caller-identity  # Verify your identity

Step 1: Deploy Infrastructure and Blue Environment

We’ll start by setting up the entire AWS infrastructure from scratch using Terraform, then deploying the initial version of our application (blue environment).

First, clone the repository and set up your environment:

# Clone the repository
git clone https://github.com/Caesarsage/bluegreen-deployment-ecs.git
cd bluegreen-deployment-ecs

# Create terraform variables
cd terraform
cat > terraform.tfvars <"us-east-1"
project_name       = "ecommerce-bluegreen"
environment        = "production"
vpc_cidr           = "10.0.0.0/16"

# Database credentials (CHANGE THESE!)
db_username = "dbadmin"
db_password = "ChangeThisPassword123!"

# Container configuration
container_image = "PLACEHOLDER"  # Will update after building image
container_port  = 8080

# Scaling configuration
desired_count = 2
cpu           = "256"
memory        = "512"

# Notifications
notification_email = "your-email@example.com"
EOF

Security Note: Never commit terraform.tfvars to Git. It's already in .gitignore.

Next, initialize Terraform and create the ECR repository:

# Initialize Terraform
terraform init
terraform validate

# Create ECR repository
terraform apply -target=aws_ecr_repository.app

# Get ECR repository URL
export ECR_REPO=$(terraform output -raw ecr_repository_url)
echo "ECR Repository: $ECR_REPO"

We create the ECR repository first because we need somewhere to push our Docker image. Then we'll build the image, push it, and finally deploy the rest of the infrastructure that depends on that image existing.

Build and push the initial application like this:


cd ..  # Back to project root

# Set variables
export AWS_REGION=us-east-1
export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
export ECR_REPOSITORY=ecommerce-bluegreen
export IMAGE_TAG=v1.0.0

# Login to ECR
aws ecr get-login-password --region $AWS_REGION | \
    docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com

# Build the image
docker build --platform linux/amd64 -t $ECR_REPOSITORY:$IMAGE_TAG -f docker/Dockerfile .

# Tag and push to ECR
docker tag $ECR_REPOSITORY:$IMAGE_TAG \
    $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$ECR_REPOSITORY:$IMAGE_TAG

docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$ECR_REPOSITORY:$IMAGE_TAG

# Update terraform.tfvars with the image URL
echo "container_image = \"$AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$ECR_REPOSITORY:$IMAGE_TAG\"" >> terraform/terraform.tfvars

The application code is a Flask application that handles both old and new schema formats based on the APP_VERSION environment variable.

Now deploy the complete infrastructure:

cd terraform
terraform apply  # Takes ~15-20 minutes

# Get outputs
export ALB_URL=$(terraform output -raw alb_url)
export TEST_URL=$(terraform output -raw test_url)
export DB_ENDPOINT=$(terraform output -raw db_endpoint)
export ECR_URL=$(terraform output -raw ecr_repository_url)
export BASTION_IP=$(terraform output -raw bastion_public_ip)

echo "Application URL: $ALB_URL"
echo "Test URL: $TEST_URL"
echo "Database Endpoint: $DB_ENDPOINT"

The production listener (port 80) is what your users hit. The test listener (port 8080) lets you test the green environment before shifting production traffic to it. This is crucial for validation.

You can see the complete Terraform configuration in terraform.

Step 2: Initialize Database Schema

Now you’ll need to initialize the database with the schema for version 1 (blue). We'll use Bastion for secure access:

# Copy the migration files to the bastion host from your local machine

scp -i ~/.ssh/id_rsa docker/init.sql ec2-user@$BASTION_IP:/tmp/
scp -i ~/.ssh/id_rsa migrations/*.sql ec2-user@$BASTION_IP:/tmp/

# Then SSH into it and run migrations
ssh -i ~/.ssh ec2-user@$BASTION_IP

# Inside the bastion:
psql -h $DB_ENDPOINT -U dbadmin -d ecommerce -f /tmp/init.sql

# Verify
psql -h $DB_HOST -U $DB_USER -d $DB_NAME -c "\d customers"

# Exit the container
exit

Step 3: Verify Blue Environment

We’ll want to test that everything works before we start the migration. This is your baseline: you want to confirm that the current system is healthy before introducing changes.

# Check health
curl $ALB_URL/health | jq

# Expected response:
# {
#   "status": "healthy",
#   "version": "blue",
#   "environment": "production",
#   "database": "connected",
#   "schema": "compatible"
# }

# Create a customer with the old schema (single address field)
curl -X POST $ALB_URL/api/customers \
    -H "Content-Type: application/json" \
    -d '{
      "name": "John Doe",
      "email": "john@example.com",
      "address": "123 Main St, New York, NY, 10001"
    }' | jq

# List customers
curl $ALB_URL/api/customers | jq

Step 4: Expand Phase – Add New Columns

This is the first phase of expand-contract. We're adding the new columns WITHOUT removing the old one, creating a database schema that supports both blue and green simultaneously.

Run the expand migration (migrations/001_expand_address.sql):

-- Migration: 001_expand_address_fields.sql
BEGIN;

ALTER TABLE customers 
  ADD COLUMN street_address VARCHAR(255),
  ADD COLUMN city VARCHAR(100),
  ADD COLUMN state VARCHAR(2),
  ADD COLUMN zip_code VARCHAR(10);

-- Populate new columns from existing data
-- This uses a simple parsing strategy; yours might be more sophisticated

UPDATE customers 
SET 
  street_address = SPLIT_PART(address, ',', 1),
  city = TRIM(SPLIT_PART(address, ',', 2)),
  state = TRIM(SPLIT_PART(address, ',', 3)),
  zip_code = TRIM(SPLIT_PART(address, ',', 4))
WHERE address IS NOT NULL;

COMMIT;

Critical observation: We're NOT dropping the address column. It's still there. Blue continues reading and writing to it, completely unaware that new columns exist. This is what makes the migration safe – nothing breaks.

# Then SSH into it and run migrations
ssh -i ~/.ssh ec2-user@$BASTION_IP

# Inside the bastion:
export DB_ENDPOINT = "" # from terraform output

psql -h $DB_ENDPOINT -U dbadmin -d ecommerce -f /tmp/001_expand_address.sql

# Verify new columns exist
psql -h $DB_ENDPOINT -U dbadmin -d ecommerce -c "\d customers"

exit

Verification: The \d customers command shows the table structure. You should see BOTH the old address column AND the new street_address, city, state, zip_code columns. This confirms the expand phase worked.

The database now supports both old (blue) and new (green) schemas. Blue is still running and working perfectly, and nothing has changed from its perspective.

Step 5: Build and Deploy Green Environment

Now we’ll build version 2 of our application that knows how to work with the new structured address fields, while maintaining backwards compatibility with the old schema.

Start by building version 2 with structured address support:

cd ..  # Back to project root

# Build new version
export IMAGE_TAG=v2.0.0

docker build --platform linux/amd64 -t $ECR_REPOSITORY:$IMAGE_TAG -f docker/Dockerfile .

docker tag $ECR_REPOSITORY:$IMAGE_TAG \
    $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$ECR_REPOSITORY:$IMAGE_TAG

docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$ECR_REPOSITORY:$IMAGE_TAG

What’s different is that the v2 application code now has logic that:

Reads from the new structured columns (street_address, city, and so on)
Writes to BOTH new columns AND the old address column
Accepts API requests with structured address format

Why write to both: This is crucial. Even though green prefers the new format, it maintains the old format, too. If you need to rollback to blue, all the data blue needs is there and up-to-date. Without this, rollback would be impossible: blue would see empty or stale address fields.

Now create and register green task definition:

cd terraform

# Get necessary ARNs
EXECUTION_ROLE_ARN=$(terraform output -raw ecs_task_execution_role_arn)
TASK_ROLE_ARN=$(terraform output -raw ecs_task_role_arn)
DB_SECRET_ARN=$(terraform output -raw db_secret_arn)

# Create task definition
cat > task-def-green.json <"family": "ecommerce-bluegreen",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "executionRoleArn": "${EXECUTION_ROLE_ARN}",
  "taskRoleArn": "${TASK_ROLE_ARN}",
  "containerDefinitions": [{
    "name": "app",
    "image": "${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/${ECR_REPOSITORY}:${IMAGE_TAG}",
    "essential": true,
    "portMappings": [{
      "containerPort": 8080,
      "protocol": "tcp"
    }],
    "environment": [
      {"name": "APP_VERSION", "value": "green"},
      {"name": "ENVIRONMENT", "value": "production"},
      {"name": "AWS_REGION", "value": "${AWS_REGION}"},
      {"name": "DB_HOST", "value": "${DB_ENDPOINT}"},
      {"name": "DB_PORT", "value": "5432"},
      {"name": "DB_NAME", "value": "ecommerce"}
    ],
    "secrets": [
      {
        "name": "DB_USER",
        "valueFrom": "${DB_SECRET_ARN}:username::"
      },
      {
        "name": "DB_PASSWORD",
        "valueFrom": "${DB_SECRET_ARN}:password::"
      }
    ],
    "logConfiguration": {
      "logDriver": "awslogs",
      "options": {
        "awslogs-group": "/ecs/ecommerce-bluegreen",
        "awslogs-region": "${AWS_REGION}",
        "awslogs-stream-prefix": "ecs"
      }
    },
    "healthCheck": {
      "command": ["CMD-SHELL", "curl -f http://localhost:8080/health || exit 1"],
      "interval": 30,
      "timeout": 5,
      "retries": 3,
      "startPeriod": 60
    }
  }]
}
EOF

# Register the task definition
aws ecs register-task-definition --cli-input-json file://task-def-green.json

This JSON tells ECS everything about how to run your container:

Which Docker image to use (the v2.0.0 we just built)
How much CPU/memory to allocate (256 CPU units = 0.25 vCPU)
Environment variables (notice APP_VERSION is set to "green")
Secrets (database credentials pulled from AWS Secrets Manager)
Health check configuration (curl the /health endpoint every 30 seconds)
Logging configuration (send logs to CloudWatch)

Key detail: The APP_VERSION environment variable is how the application knows whether to behave as blue or green. Same codebase, different behavior based on configuration.

Step 6: Execute Blue-Green Deployment

Alright, now it’s time to create AppSpec and trigger the deployment:

TASK_DEF_ARN=$(aws ecs describe-task-definition \
  --task-definition ecommerce-bluegreen \
  --query 'taskDefinition.taskDefinitionArn' \
  --output text)

cat > appspec.json <"version": 0.0,
  "Resources": [{
    "TargetService": {
      "Type": "AWS::ECS::Service",
      "Properties": {
        "TaskDefinition": "${TASK_DEF_ARN}",
        "LoadBalancerInfo": {
          "ContainerName": "app",
          "ContainerPort": 8080
        }
      }
    }
  }]
}
EOF

# Deploy
APPSPEC=$(cat appspec.json | jq -c .)
aws deploy create-deployment \
  --application-name ecommerce-bluegreen \
  --deployment-group-name ecommerce-bluegreen-deployment-group \
  --deployment-config-name CodeDeployDefault.ECSLinear10PercentEvery3Minutes \
  --description "Blue-green deployment to structured address schema" \
  --cli-input-json "{
    \"revision\": {
      \"revisionType\": \"AppSpecContent\",
      \"appSpecContent\": {
        \"content\": $(echo \"$APPSPEC\" | jq -Rs .)
      }
    }
  }"

DEPLOYMENT_ID=$(aws deploy list-deployments \
    --application-name ecommerce-bluegreen \
    --deployment-group-name ecommerce-bluegreen-deployment-group \
    --query 'deployments[0]' --output text)

Monitor the deployment:

# Watch status
watch -n 10 "aws deploy get-deployment --deployment-id $DEPLOYMENT_ID \
    --query 'deploymentInfo.status' --output text"

# Monitor traffic distribution
while true; do
    echo "Production: $(curl -s $ALB_URL/health | jq -r '.version')"
    echo "Test: $(curl -s $TEST_URL/health | jq -r '.version')"
    sleep 30
done

The deployment shifts 10% of traffic every 3 minutes, completing in 30 minutes.

Step 7: Validate Green Environment

After the deployment begins, you need to validate that the green environment is functioning correctly with the new structured address format before allowing production traffic to reach it.

The CodeBuild dashboard below shows the Traffic migration and Deployment status:

We can also test through the test listener (port 8080), which provides isolated access to green tasks:

# Test new structured address API
curl -X POST $TEST_URL/api/customers \
    -H "Content-Type: application/json" \
    -d '{
      "name": "Jane Smith",
      "email": "jane@example.com",
      "address": {
        "street": "456 Oak Ave",
        "city": "Los Angeles",
        "state": "CA",
        "zip": "90001"
      }
    }' | jq

curl $ALB_URL/api/customers | jq

What you're validating:

The green environment accepts the new structured address format
Data is correctly written to both new columns (street_address, city, state, zip_code) and the old address column for backwards compatibility
The API response matches expectations for the new schema
Existing data from blue environment is still accessible and readable

If any of these tests fail, you can stop the deployment before production traffic reaches green, preventing customer impact.

Step 8: Post-Deployment Validation

Once CodeDeploy completes the traffic shift, all production requests route to green. This is your opportunity to verify that the deployment was successful and that the new version is handling real production traffic correctly.

# Verify all production traffic goes to green
# Running this multiple times confirms consistent routing
for i in {1..10}; do
    curl -s $ALB_URL/health | jq -r '.version'
done
# Expected output: "green" for all 10 requests

# Test complete CRUD operations with the new API
# Create a customer with structured address
CUSTOMER_ID=$(curl -s -X POST $ALB_URL/api/customers \
    -H "Content-Type: application/json" \
    -d '{"name": "Test User", "email": "test@example.com",
         "address": {"street": "789 Test St", "city": "Test City", 
         "state": "TX", "zip": "75001"}}' | jq -r '.id')

# Read the customer back to verify data persistence
curl $ALB_URL/api/customers/$CUSTOMER_ID | jq

# Update the customer to test modification
curl -X PUT $ALB_URL/api/customers/$CUSTOMER_ID \
    -H "Content-Type: application/json" \
    -d '{"address": {"street": "999 Updated Ave", "city": "Test City", 
         "state": "TX", "zip": "75001"}}' | jq

# Delete the test customer for cleanup
curl -X DELETE $ALB_URL/api/customers/$CUSTOMER_ID

What you're validating:

Traffic routing is 100% to green with no requests reaching blue
Create operations work with the new structured address format
Read operations return correct data with proper address structure
Update operations successfully modify existing records
Delete operations work without errors
The application correctly writes to both new columns and old address column (enabling potential rollback)

Check your CloudWatch logs and metrics during this validation period for any unexpected errors, increased latency, or database connection issues.

Step 9: Contract Phase (After 24-72 Hours)

This is the final phase of expand-contract. We're removing the old address column now that we're confident green is stable. This is the point of no return.

CRITICAL: Only proceed after green has been stable for your confidence period!

# Backup database first
aws rds create-db-snapshot \
    --db-instance-identifier ecommerce-bluegreen-db \
    --db-snapshot-identifier pre-contract-$(date +%Y%m%d-%H%M%S)

# Wait for snapshot
aws rds wait db-snapshot-completed \
    --db-snapshot-identifier pre-contract-$(date +%Y%m%d-%H%M%S)

# Run contract migration
psql -h $DB_ENDPOINT -U dbadmin -d ecommerce -f /tmp/002_contract_address.sql

# Verify old column is gone
psql -h $DB_ENDPOINT -U dbadmin -d ecommerce -c "\d customers"

The contract migration (migrations/002_contract_address.sql) removes the old address column.

Why wait 24-72 hours: You want to be absolutely certain green is stable before making irreversible changes. During this waiting period:

All your monitoring should show green performing normally
You've seen the system handle multiple daily traffic patterns (morning peak, evening peak, overnight)
Weekly batch jobs have run successfully
You've verified third-party integrations work
No unusual errors or performance degradation

It’s important to snapshot first because once you drop that column, there's no undo button. The snapshot is your safety net. If you discover a critical issue after contracting, you can restore this snapshot and get back to a state where rollback is possible. Without it, you're gambling.

What the contract migration does:

-- migrations/002_contract_address.sql
BEGIN;
ALTER TABLE customers DROP COLUMN address;
COMMIT;

It's simple but permanent. The old address column is gone. The Blue environment will no longer work with this database, as it expects that column to exist. This is fine because blue has been decommissioned (no traffic, tasks terminated).

What to update: You should also deploy version 3 of your application that removes the dual-write logic. Version 2 (green) is still writing to both the new columns and the old address column. Version 3 can stop wasting cycles writing to a column that no longer exists.

The contract migration (migrations/002_contract_address.sql) removes the old address column. Your migration is now complete!

Rollback Strategies

During Deployment (Safe Window)

Use this strategy when you detect issues during the traffic shift, before all traffic has moved to green. CodeDeploy is still managing the deployment, which means it can automatically revert traffic distribution to the previous state.

# Immediate rollback
aws deploy stop-deployment \
    --deployment-id $DEPLOYMENT_ID \
    --auto-rollback-enabled

You should use this strategy when you notice increased error rates, degraded performance, or functional issues during the canary or linear traffic shift. CodeDeploy automatically shifts all traffic back to blue, and green tasks are terminated. This is the safest and fastest rollback option.

This works because the database still contains the old address column (expand phase), so blue can function normally. No data has been lost or made incompatible.

After Deployment (Before Contract)

Use this when the deployment completed successfully, but you discover issues hours or days later during the monitoring period, before you've run the contract migration. Both blue and green environments still exist, and the database supports both schemas.

# Manual listener update
aws elbv2 modify-listener \
    --listener-arn $(terraform output -raw alb_listener_arn) \
    --default-actions Type=forward,TargetGroupArn=$(terraform output -raw blue_target_group_arn)

Or use the provided script:

cd scripts
./rollback.sh

Use this when you discover bugs in green that weren't caught during initial testing, business metrics show unexpected changes (conversion rates drop, customer complaints increase), or third-party integration issues emerge.

This works because the database still has both old and new schema elements. Blue tasks still exist and can serve traffic immediately. Because green was writing to both old and new columns, blue sees all the latest data.

With this, the traffic immediately shifts from green back to blue. Green continues running for observability, but serves no traffic. You can debug green in place without customer impact.

After Contract Phase

Use this as a last resort when you've already removed the old address column, and blue can no longer function with the current database schema. This is significantly more complex and time-consuming than the previous two strategies.

# Restore from snapshot
aws rds restore-db-instance-from-db-snapshot \
    --db-instance-identifier ecommerce-bluegreen-db-restored \
    --db-snapshot-identifier pre-contract-YYYYMMDD-HHMMSS

Only use this strategy when you discover a critical, production-breaking issue after the contract phase, and you have no other option but to return to the previous version.

Why it's painful:

Database restore takes 10-30 minutes depending on size
You lose all data written after the snapshot was taken
Requires updating connection strings to point to the restored instance
Need to re-deploy blue environment
Must communicate downtime to users

This is why you wait 24-72 hours before contracting, and take a snapshot immediately before the contract migration. The lengthy waiting period allows you to catch most issues while the safer rollback strategies are still available.

Monitoring During Deployments

Essential Metrics

During a blue-green deployment, you need to monitor both environments simultaneously to detect issues early and make informed decisions about proceeding or rolling back.For each target group (blue and green), track these CloudWatch metrics:

1. TargetResponseTime

Measures latency from when the load balancer sends a request to when it receives a response. You're looking for sudden spikes or gradual degradation. Green should have similar response times to blue (within 10-20%). If green's latency is significantly higher, you may have performance regressions, inefficient queries with the new schema, or resource constraints.

2. RequestCount

Shows traffic volume hitting each target group. During the deployment, you should see blue's count decreasing while green's increases proportionally. If the numbers don't add up (total requests drop significantly), users might be experiencing errors and not retrying. If green receives traffic but shows zero requests, health checks might be failing.

3. HTTPCode_Target_5XX_Count

Server errors indicate application problems. Even a single 5XX error during deployment warrants investigation. Green should have zero 5XX errors during the initial traffic shift. Any errors could indicate incompatibility issues with the new schema, missing environment variables, or database connection problems.

4. DatabaseConnections (from RDS metrics):

Shows active database connections from both environments. Watch for connection pool exhaustion, which manifests as a sudden spike or plateau at your max connections limit. If green uses more connections than blue did, you might have connection leaks or inefficient connection handling in the new code.

5. CPUUtilization

Monitor both ECS task CPU and RDS CPU. Green tasks should use similar CPU to blue tasks for the same request volume. Higher CPU might indicate less efficient code or more complex queries. RDS CPU spikes during deployment often indicate poorly optimized new queries or missing indexes for the new schema.

What to expect:

First 5-10 minutes: Green receives 10% traffic, metrics should closely match blue's baseline
15-20 minutes: Green at 30-50% traffic, both environments should show stable metrics
25-30 minutes: Green at 100% traffic, metrics should stabilize at historical levels
Any divergence from these patterns warrants stopping the deployment and investigating

Custom application metrics: Beyond infrastructure metrics, monitor business-critical metrics like checkout completion rates, API success rates, and user sign-up flows. Sometimes technical metrics look fine but user-facing functionality is broken.

Best Practices

Test Migrations in Staging

Always run your database migrations against a staging environment that mirrors production scale and complexity before touching production. Copy a recent production snapshot to staging and execute your expand migration there first.

Why this matters: Migrations that work fine on small datasets can timeout or lock tables on production-scale data. You might discover that adding an index to a 50-million-row table takes 2 hours, or that your column population query needs optimization.

What to test:

Migration execution time (should complete in seconds/minutes, not hours)
Table locks and their impact (can reads/writes continue during migration?)
Query performance with new schema (are your indexes still effective?)
Rollback procedures (can you undo the migration if needed?)

Use Migration Tools

Don't write raw SQL migrations manually. Use Flyway, Liquibase, Alembic (for Python), or your framework's built-in migration tools (Rails migrations, Django migrations, Entity Framework migrations).

Why this matters: Migration tools provide version tracking, rollback capabilities, checksums to prevent tampering, and a standardized way to manage schema changes across environments.

Configure Health Checks Properly

Your health check endpoint should verify that the application can actually function, not just that the process is running. A comprehensive health check validates database connectivity, schema compatibility, and dependent service availability.

@app.route('/health')
def health_check():
    checks = {
        'database': check_database(),
        'schema': check_schema_compatibility(),
        'cache': check_cache_connection()
    }

    if all(checks.values()):
        return jsonify(checks), 200
    else:
        return jsonify(checks), 503

def check_schema_compatibility():
    """Verify expected schema elements exist"""
    try:
        result = db.query("""
            SELECT column_name 
            FROM information_schema.columns 
            WHERE table_name = 'customers'
            AND column_name IN ('street_address', 'city', 'state', 'zip_code')
        """)
        return len(result) == 4
    except:
        return False

For ALB health checks specifically, make sure you configure appropriate thresholds in your target group settings. A healthy threshold of 2 means the target must pass 2 consecutive health checks before receiving traffic. An unhealthy threshold of 3 means it must fail 3 consecutive checks before being removed. Set your interval to 30 seconds and timeout to 5 seconds to balance responsiveness with stability.

# Terraform configuration for ALB health checks
resource "aws_lb_target_group" "green" {
  health_check {
    enabled             = true
    healthy_threshold   = 2
    unhealthy_threshold = 3
    timeout             = 5
    interval            = 30
    path                = "/health"
    matcher             = "200"
  }
}

This configuration ensures that ECS tasks aren't marked healthy prematurely (preventing traffic to broken tasks) while also not being overly sensitive to transient issues (preventing unnecessary task replacements).

Plan the Contract Phase

The contract phase is irreversible, so treat it with appropriate caution. Wait a minimum of 24-72 hours after green deployment before removing old schema elements. This waiting period isn't arbitrary: it ensures you've observed the system under various conditions.

What to verify before contracting:

Green has handled multiple daily traffic patterns (morning rush, evening peak, overnight batch jobs)
All scheduled jobs and cron tasks have run successfully with the new schema
Weekly reports or analytics pipelines have completed
Third-party integrations (payment processors, shipping APIs, analytics tools) are working
No unusual error patterns in logs
Business metrics (conversions, sign-ups, purchases) remain stable
Customer support hasn't reported related issues

The pre-contract checklist:

# 1. Create a final snapshot
aws rds create-db-snapshot \
    --db-instance-identifier ecommerce-bluegreen-db \
    --db-snapshot-identifier pre-contract-$(date +%Y%m%d-%H%M%S)

# 2. Document current state
echo "Green tasks: $(aws ecs describe-services --cluster ecommerce --services ecommerce-green | jq '.services[0].runningCount')"
echo "Error rate: $(aws cloudwatch get-metric-statistics --namespace AWS/ApplicationELB --metric-name HTTPCode_Target_5XX_Count --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%S) --end-time $(date -u +%Y-%m-%dT%H:%M:%S) --period 3600 --statistics Sum)"

# 3. Notify team
echo "Running contract migration at $(date)"

# 4. Run migration
psql -h $DB_ENDPOINT -U dbadmin -d ecommerce -f migrations/002_contract_address.sql

# 5. Verify
psql -h $DB_ENDPOINT -U dbadmin -d ecommerce -c "\d customers"

Version Your APIs

When changing data formats, maintain backward compatibility by supporting both old and new API versions simultaneously. This allows API consumers (mobile apps, third-party integrations, other services) to migrate at their own pace without coordinating releases.

# Support both API versions during transition
@app.route('/api/v1/customers/')
def get_customer_v1(id):
    customer = Customer.find(id)
    return jsonify({
        'id': customer.id,
        'name': customer.name,
        'address': customer.address  # Old format
    })

@app.route('/api/v2/customers/')
def get_customer_v2(id):
    customer = Customer.find(id)
    return jsonify({
        'id': customer.id,
        'name': customer.name,
        'address': {  # New structured format
            'street': customer.street_address,
            'city': customer.city,
            'state': customer.state,
            'zip': customer.zip_code
        }
    })

To implement this, you can initially deploy both endpoints with blue-green. Then monitor usage of v1 endpoint over time. Once v1 traffic drops below 1% (meaning clients have migrated), deprecate it formally. Remove v1 endpoint in a subsequent release, not during the blue-green deployment itself.

Announce the new API version to consumers with a migration timeline. Give them 2-3 months to update their integrations. Send reminder emails at the halfway point and 2 weeks before v1 shutdown.

Monitor Both Environments

During the transition period, both blue and green are production environments serving real traffic. Monitor them separately to detect version-specific issues.

Set up separate CloudWatch dashboards for blue and green target groups with the same metrics arranged identically. This makes it easy to spot differences at a glance. If green's response time is 200ms while blue's is 50ms, that's a red flag.

Alert on metric divergence

Create alarms that trigger when green's metrics deviate significantly from blue's baseline. For example, if green's error rate is more than 2x blue's historical average, trigger an alert. If green's database query time is 50% higher, investigate before shifting more traffic.

Log aggregation

Ensure logs from both environments are tagged with their version (environment: blue or environment: green) so you can filter and compare them. Use CloudWatch Insights queries to spot patterns.

When NOT to Use Blue-Green

Blue-green isn't always the right choice. Avoid it when you have:

Very large database migrations: If your migration takes hours or requires significant locks, use a traditional maintenance window.
Highly stateful applications: Real-time collaboration tools or WebSocket applications with complex in-memory state may need rolling deployments instead.
Cost constraints: Running two environments doubles costs. Consider canary deployments for cost-sensitive applications.
Complex data model redesigns: Use the strangler fig pattern to gradually migrate functionality to a new service.

Alternative Deployment Strategies

Canary Deployments

Route a small percentage (5-10%) to the new version:

{
  "trafficRouting": {
    "type": "TimeBasedCanary",
    "timeBasedCanary": {
      "canaryPercentage": 10,
      "canaryInterval": 5
    }
  }
}

Rolling Deployments

Gradually replace old tasks with new ones:

{
  "deploymentConfiguration": {
    "maximumPercent": 200,
    "minimumHealthyPercent": 100
  }
}

Cleanup

After you've successfully completed your blue-green deployment, validated the green environment, and run the contract phase, you need to clean up the AWS resources to avoid unnecessary costs and resource sprawl.

What you're removing:

The entire infrastructure stack (VPC, subnets, NAT gateways, load balancer, ECS cluster, RDS database, and all associated resources)
This is appropriate for a tutorial/testing scenario where you deployed everything from scratch

Important considerations before cleanup:

Ensure you have backups if you need to reference any data later
Export any logs or metrics you want to retain
Document lessons learned from the deployment
Verify no production traffic is still using these resources

cd terraform

# Terraform will prompt you to confirm with "yes"
# Review the destruction plan carefully before confirming
terraform destroy  # Takes ~10-15 minutes

Partial cleanup: If you want to keep certain resources (like RDS snapshots for reference), you can remove them from Terraform state before destroying:

# Remove RDS from Terraform management before destroying
terraform state rm aws_db_instance.main
terraform destroy  # Now destroys everything except RDS

For production environments, you would NOT destroy everything. Instead, you'd decommission the blue environment specifically after confirming green is stable:

# Production scenario - remove only blue environment
terraform destroy -target=aws_ecs_service.blue
terraform destroy -target=aws_lb_target_group.blue

Conclusion

Blue-green deployments with databases require careful planning, but the expand-contract pattern makes it manageable.

Here are some key takeaways:

Use expand-contract as default – Maintains backwards compatibility and safe rollbacks.
Externalize state – Sessions, caches, and storage should use external services.
Plan for three phases – Don't rush to the contract phase.
Test everything in staging – Mirror production scale and complexity.
Monitor aggressively – Track technical and business metrics for both environments.
Know when to use alternatives – Blue-green isn't always the answer.
Document rollback procedures – Everyone should know the rollback process before deployment.

The expand-contract pattern requires more work upfront, but this investment pays dividends in reduced risk and maintained uptime. With the strategies and complete implementation provided here, you can successfully deploy even complex, stateful applications with confidence.

As always, I hope you enjoyed this guide and learned something. If you want to stay connected or see more hands-on DevOps content, you can follow me on LinkedIn.

For more practical hands-on Cloud/DevOps projects like this one, follow and star this repository: Learn-DevOps-by-building.

Further Resources

Complete Code: github.com/Caesarsage/bluegreen-deployment-ecs
Learn DevOps by Building: GitHub repo
AWS ECS Blue/Green Documentation: AWS Docs
AWS CodeDeploy for ECS: AWS Docs

How to Build Your AI Demos with Gradio

Manish Shivanandhan — Thu, 28 Aug 2025 00:17:49 +0000

The world of artificial intelligence moves fast. Every week, new models appear, older ones get better, and the tools to use them become easier.

But if you are building a machine learning project, you may face one big problem: how to share your work quickly so that others can try it.

A notebook full of code is not always enough. People want to interact with your model. They want to see inputs, click buttons, and watch results appear instantly.

This is where Gradio comes in. With just a few lines of Python, you can turn your AI model into a simple web app. You don’t need to know HTML, CSS, or JavaScript, Gradio takes care of the interface so you can focus on your model.

In this tutorial, you will learn how to build AI demos in minutes using Gradio. By the end, you will have a live demo ready for anyone to test.

What is Gradio?
Why Use Gradio?
Your First Gradio App
How to Add Machine Learning Models
How to Customize the Interface
How to Share Your App
Conclusion

What is Gradio?

Gradio is an open-source Python library that makes it easy to create interactive web interfaces for machine learning models.

Imagine that you trained a text summarizer or an image classifier. Without Gradio, you would have to build a frontend, write backend code, host it somewhere, and then connect it all together. That takes time and effort.

With Gradio, you write a few lines of Python, and it gives you a shareable link with a complete UI. The interface works on any device with a browser. You can even embed it in websites or share it with teammates for feedback.

Gradio supports text, images, audio, video, and many other data types. This makes it perfect for computer vision, natural language processing, speech recognition, or any other AI application.

Why Use Gradio?

Speed is a major reason for choosing Gradio. Building a web app for your model can take hours or even days if you do it from scratch. Gradio reduces that to minutes. You focus on your AI model while Gradio handles the user interface.

It is also easy to use. Even beginners with basic Python knowledge can create functional demos. It works well with popular libraries like TensorFlow, PyTorch, and Hugging Face Transformers.

Another advantage is sharing. When you launch a Gradio app, you get a public link that anyone can open. You don’t need to deploy it manually or set up servers. This makes it perfect for hackathons, quick prototypes, or sending demos to clients and friends.

How to Install Gradio

Before building your first app, you need to install Gradio. Open your terminal or command prompt and type:

pip install gradio

That’s it. The installation is quick and usually takes less than a minute. Once done, you are ready to build your first demo.

Your First Gradio App

Let’s start simple. Imagine you want to build a text reversal app. The user types a sentence, and the app shows the reversed version. It may not be a real AI model, but it helps you learn the basics.

Here’s the code:

# Import the Gradio library
import gradio as gr

# Define a function that reverses any input text
def reverse_text(text):
    # The [::-1] slice notation reverses the string
    return text[::-1]

# Create a Gradio interface to connect the function with a simple web UI
demo = gr.Interface(
    fn=reverse_text,       # Function to call when the user submits input
    inputs="text",         # Type of input (a text box for user input)
    outputs="text",        # Type of output (a text box to display reversed text)
    title="Text Reversal App",          # Title displayed on the app
    description="Type any text and see it reversed instantly."  # Short description for users
)

# Launch the web app in the browser
demo.launch()

gr.Interface() links your Python function to a web-based user interface. fn=reverse_text tells Gradio to call this function whenever the user provides input.

inputs="text" specifies that the input field should be a text box. outputs="text" makes the output display as text.

title and description improve the look of the app with a heading and explanation.

Save this in a Python file and run it. A browser window will open with a text box. Type something, hit submit, and you will see the reversed text appear.

Congratulations! You just built your first interactive app with Gradio in under five minutes.

How to Add Machine Learning Models

Now let’s build something more exciting. Suppose you have a sentiment analysis model that takes text and predicts whether it is positive, negative, or neutral. You can connect it to Gradio easily.

Here is an example using Hugging Face Transformers:

# Import the Gradio library
import gradio as gr

# Import the 'pipeline' function from Hugging Face's Transformers library
# 'pipeline' lets you load pre-trained AI models with a single line of code
from transformers import pipeline

# Load a pre-trained sentiment analysis model from Hugging Face
# This model can classify text as POSITIVE, NEGATIVE, or NEUTRAL along with a confidence score
sentiment_model = pipeline("sentiment-analysis")

# Define a function that uses the model to analyze text sentiment
def analyze_sentiment(text):
    # Pass the user-provided text to the model
    # The model returns a list of predictions; we take the first one using [0]
    result = sentiment_model(text)[0]

    # Return the label (e.g., POSITIVE) and the confidence score formatted to 2 decimal places
    return f"Label: {result['label']}, Score: {result['score']:.2f}"

# Create a Gradio interface to turn the function into a web app
demo = gr.Interface(
    fn=analyze_sentiment,         # The function to call when user inputs text
    inputs="text",                # The input type (a single-line text box)
    outputs="text",               # The output type (display as text)
    title="Sentiment Analysis App",    # Title shown at the top of the web app
    description="Type a sentence to check its sentiment."  # Short explanation for the app
)

# Launch the web app so users can interact with it in a browser
demo.launch()

Run this code, type “I love this product!” and watch the model return “Label: POSITIVE” with a confidence score.

How to Customize the Interface

Gradio gives you control over titles, descriptions, themes, and even examples. For example, you can add example inputs like this:

demo = gr.Interface(fn=analyze_sentiment, 
                    inputs="text", 
                    outputs="text",
                    title="Sentiment Analysis App",
                    description="Type a sentence to check its sentiment.",
                    examples=[["I love AI"], ["I hate waiting"]])

Now the app shows example sentences that users can click to test instantly.

When you run demo.launch(), Gradio starts a local server and gives you a local link. To get a sharable link, use demo.launch(share=True) and you will get a public link that you can share with others.

The public link works for 72 hours by default. If you want a permanent link, you can deploy on Hugging Face Spaces for free or use platforms like AWS.

Conclusion

Gradio changes how developers share machine learning models. What once took hours of coding now takes minutes. You write the model code, connect it to Gradio, and instantly get a working demo with a shareable link.

Whether you are a student learning AI, a researcher sharing results, or a developer building prototypes, Gradio saves you time and effort. It removes the complexity of web development so you can focus on what matters: building your AI model.

I Hope you enjoyed this article. Signup for my free AI newsletter TuringTalks.ai for more hands-on tutorials on AI. You can also find me on Linkedin.

How to Deploy a Kubernetes App on AWS EKS

Ijeoma Igboagu — Fri, 22 Aug 2025 11:55:41 +0000

AWS makes it much easier to deploy containerized applications, and running Kubernetes in the cloud is a powerful way to scale and manage these applications.

Among the many managed Kubernetes services AWS offers, Amazon EKS (Elastic Kubernetes Service) stands out for its seamless integration with the AWS ecosystem, strong reliability, and excellent support.

If you’re ready to move beyond local setups and want to deploy a real-world Kubernetes app on AWS EKS, this guide will walk you through the entire process. Whether you’re working on a microservice, a full-stack app, or just experimenting with Kubernetes in an environment that mimics production, you’ll find this walkthrough useful.

In this article, I’ll guide you through the process of creating your EKS cluster, deploying your application, and making it accessible over the internet, step by step.

What We’ll Cover:

Prerequisites
What is a Kubernetes Cluster?
What is Amazon Elastic Kubernetes Service?
Why Use Amazon EKS for Kubernetes?
How to Create a Kubernetes Cluster Using AWS
Conclusion
Resources

Prerequisites

To get started, make sure you have the following installed on your local machine:

Have a basic understanding of cloud services.
Have a basic understanding of the Linux command line.
Have an AWS account.
Install eksctl, a simple CLI tool to create and manage EKS clusters.
Install kubectl, the standard Kubernetes command-line tool.
Install Docker to build and package your app into a container.

Before setting up a Kubernetes cluster for our application, it’s essential to understand a few basic concepts.

What is a Kubernetes Cluster?

A Kubernetes (also called K8S) cluster consists of machines (called nodes) that run containerized applications. It works alongside container engines like CRI-O or containerd to help you deploy and manage your apps more efficiently.

Kubernetes nodes come in two main types:

Master nodes (control plane): These handle the brainwork, such as scheduling, scaling, and managing the cluster’s overall state.
Worker nodes (data plane): They run the actual applications inside the containers.

If you're new to Kubernetes or want to brush up, check out the free course Introduction to Kubernetes (LFS158) from the Linux Foundation.

What is Amazon Elastic Kubernetes Service?

Amazon Elastic Kubernetes Service (EKS) is a managed service that enables easy Kubernetes deployment on AWS, eliminating the need to set up and maintain your own Kubernetes control plane node.

AWS EKS takes care of the heavy lifting by managing the control plane, handling upgrades, and installing core components, such as the container runtime and essential Kubernetes processes. It also offers built-in tools for scaling, high availability, and backup.

With EKS, you or your team can focus on building and running applications, while AWS handles the underlying infrastructure.

Why Use Amazon EKS for Kubernetes?

Here are some key benefits of using AWS EKS:

EKS handles upgrades, patching, and high availability for you, giving you a fully managed control plane with minimal manual effort.
You can easily scale your applications, and the infrastructure grows as your needs evolve.
It has built-in support for IAM roles, private networking, and encryption.
AWS EKS runs on highly available infrastructure across multiple AWS Availability Zones, making your application available globally.
With Amazon EKS, you get the power of Kubernetes without managing the underlying setup. So you can stay focused on building and running your apps.

How to Create a Kubernetes Cluster Using AWS

Now let’s walk through the process of getting a Kubernetes cluster up and running.

Step 1: How to Install the Tools Needed to Create a Cluster

The easiest and most developer-friendly way to spin up an Elastic Kubernetes Service that you can use at the production level is by using eksctl. It takes care of the manual setup and automatically provisions the necessary AWS resources.

Before we begin, we need to install two essential tools:

eksctl – This is used to create and manage your EKS cluster.
kubectl – This allows you to interact with your cluster, deploy apps, and manage Kubernetes resources.

These tools will make it easy to set up your Kubernetes cluster and work with it directly from your terminal.

How to Install eksctl

Open your browser and go to the official eksctl documentation. Scroll down to the Installation section.

Scroll to the Unix instructions if you're using Ubuntu or a similar system. Then copy the installation command and paste it into your terminal.

Once it’s done, run eksctl version to confirm that the installation was successful.

How to Install kubectl

The next step is to install kubectl. You can find the installation instructions in the official Kubernetes documentation, which provides steps based on your operating system.

Step 2: How to Create the Elastic Kubernetes Service (EKS) Cluster

Now that you've installed the tools needed to create and interact with a Kubernetes cluster on AWS, it's time to launch the cluster.

To get started, open your terminal and run the following command:

# Create an EKS cluster named "k8s-example" in eu-west-2 (London)
eksctl create cluster --name k8s-example --region eu-west-2

One great thing about using AWS EKS is that once your Kubernetes cluster is created, it automatically updates your ~/.kube/config file. This means you can start interacting with your cluster right away, using kubectl – no extra setup needed.

After running the command (as shown in the GIF above), your Kubernetes cluster is successfully created.

Head over to the AWS console, and you’ll see your new cluster listed with a status of Active.

With your cluster up and running, it’s time to test the connection. You can do this by running a few kubectl commands in your terminal to list the nodes, pods and namespaces in your cluster.

To test the connection:

kubectl get nodes

This command lists all the nodes in your cluster.

kubectl get pods

This command lists all the pods currently running.

kubectl get namespaces

This command lists all the namespaces currently running.

If each command returns a list of resources, congratulations! Your connection to the Kubernetes cluster is successful.

Step 3: How to Create Kubernetes Manifests

Let’s define the application using a YAML file. In this file, you’ll create two key resources: a Deployment and a Service.

The Deployment ensures your application runs reliably by specifying how many replicas to run, which container image to use, and how to manage updates.
The Service makes your application accessible — both within the Kubernetes cluster and, if needed, from the internet, even if the underlying pods change or restart.

Together, these resources orchestrate your application so it can run consistently in different environments and be accessed by others.

#deployment-example.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: amazon-deployment
  namespace: default
  labels:
    app: amazon-app
spec:
  replicas: 5
  selector:
    matchLabels:
      app: amazon-app
      tier: frontend
      version: 1.0.0
  template:
    metadata:
      labels:
        app: amazon-app
        tier: frontend
        version: 1.0.0
    spec:
      containers:
        - name: amazon-container
          image: ooghenekaro/amazon:2
          ports:
            - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: amazon-service
  labels:
    app: amazon-app
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 3000
  selector:
    app: amazon-app

The service uses a LoadBalancer type, which tells AWS to provision an Elastic Load Balancer (ELB) and route traffic to the pods.

Step 4: How to Deploy the App to EKS

Now that your YAML file is defined and the Kubernetes cluster on AWS EKS is ready, it’s time to deploy your application.

To do this, run the following command in your terminal to apply the configuration defined in your manifest file:

kubectl apply -f deployment-example.yaml

This command tells Kubernetes to create the necessary pods and services based on what’s specified in the manifest file.

Next, you can check the status of your pods and services:

kubectl get pods
kubectl get svc or service
kubectl get all

Step 5: How to Access Your Application

To view your application in the browser, run the following command to list your services:

kubectl get svc

Look for the EXTERNAL-IP of your service.

Copy the IP address and paste it into your browser. Your app should now be live!

Conclusion

Deploying a Kubernetes app on AWS EKS may seem complex at first, but with tools like eksctl and kubectl, the process is surprisingly approachable.

Whether you're a developer experimenting with Kubernetes or a team looking to scale production workloads, EKS provides a strong, scalable foundation that supports your applications as they grow.

Resources

Thanks for reading!

How to Deploy a Next.js API to Production using Sevalla

Manish Shivanandhan — Fri, 01 Aug 2025 23:14:57 +0000

When people hear about Next.js, they often think of server-side rendering, React-powered frontends, or SEO-optimised static websites. But there's more to this powerful framework than just front-end development.

Next.js also allows developers to build robust, scalable backend APIs directly inside the same codebase. This is especially valuable for small to mid-sized applications where having a tightly coupled frontend and backend speeds up development and deployment.

In this article, you’ll learn how to build an API using Next.js and deploy it to production using Sevalla. It’s relatively easy to learn how to build something using a tutorial – but the real challenge is to get it into the hands of users. Doing so transforms your project from a local prototype into something real and usable.

What is Next.js?
Installation & Setup
How to Build a REST API
How to Test the API
How to Deploy to Sevalla
Conclusion

What is Next.js?

Next.js is an open-source React framework built by Vercel. It enables developers to build server-rendered and statically generated web applications.

It essentially abstracts the configuration and boilerplate needed to run a full-stack React application, making it easier for developers to focus on building features rather than setting up infrastructure.

While it started as a solution for frontend challenges in React, it has evolved into a full-stack framework that lets you handle backend logic, interact with databases, and build APIs. This unified codebase is what makes Next.js particularly compelling for modern web development.

Installation & Setup

Let’s install Next.js. Make sure you have Node.js and NPM installed on your system, and that they’re the latest version.

$ node --version
v22.16.0

$ npm --version
10.9.2

Now let’s create a Next.js project. The command to do so is:

$ npx create-next-app@latest

The result of the above command will ask you a series of questions to setup your app:

What is your project named? my-app
Would you like to use TypeScript? No / Yes
Would you like to use ESLint? No / Yes
Would you like to use Tailwind CSS? No / Yes
Would you like your code inside a `src/` directory? No / Yes
Would you like to use App Router? (recommended) No / Yes
Would you like to use Turbopack for `next dev`?  No / Yes
Would you like to customize the import alias (`@/*` by default)? No / Yes
What import alias would you like configured? @/*

But for this tutorial, we aren’t interested in a full stack app – just an API. So let’s re-create the app using the — - api flag.

$ npx create-next-app@latest --api

It will still ask you a few questions. Use the default settings and finish creating the app.

Once the setup is done, you can see the folder with your app name. Let’s go into the folder and run the app.

$ npm run dev

Your API template should be running at port 3000. Go to http://localhost:3000 and you should see the following message:

{
"message": "Hello world!"
}

How to Build a REST API

Now that we’ve set up our API template, let's write a basic REST API. A basic REST API is simply four endpoints: Create, Read, Update, Delete (also called as CRUD).

Usually, we’d use a database, but for simplicity’s sake, we’ll use a JSON file in our API. Our goal is to build a REST API that can read and write to this JSON file.

The API code will reside under /app within the project directory. Next.js uses file-based routing for building URL paths.

For example, if you want a URL path /users, you should have a directory called “users” with a route.ts file to handle all the CRUD operations for /users. For /users/:id, you should have a directory called [id] under “users” directory with a route.ts file. The square brackets are to tell Next.js that you expect dynamic values for the /users/:id route.

You should also have the users.json inside the /app/users directory for your routes to read and write data.

Here is a screenshot of the setup. Delete the [slug] directory that comes with the project since it won’t be relevant for us:

The route.ts file at the bottom handles CRUD operations for /
The route.ts file under/users handles CRUD operations for /users
The route.ts file under /users/[id]/ handles CRUD operations under /users/:id where the ‘id’ will be a dynamic value.
The users.json under /users will be our data store.

While this setup can seem complicated for a simple project, it provides a clear structure for large-scale web applications. If you want to go deeper into building complex APIs with Next.js, here is a tutorial you can follow.

The code under /app/route.ts is the default file for our API. You can see it serving the GET request and responding with “Hello World!”:

import { NextResponse } from "next/server";

export async function GET() {
  return NextResponse.json({ message: "Hello world!" });
}

Now we need five routes:

GET /users → List all users
GET /users/:id → List a single user
POST /users → Create a new user
PUT /users/:id → Update an existing user
DELETE /users/:id → Delete an existing user

Here is the code for the route.ts file under /app/users:

import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";
import { promises as fs } from "fs"; // Importing promise-based filesystem methods
import path from "path"; // For handling file paths

// Define the structure of a User object
interface User {
  id: string;
  name: string;
  email: string;
  age: number;
}

// Define the path to the users.json file
const usersFile = path.join(process.cwd(), "app/users/users.json");

// Read users from the JSON file and return them as an array
async function readUsers(): Promise<User[]> {
  try {
    const data = await fs.readFile(usersFile, "utf-8");
    return JSON.parse(data) as User[];
  } catch {
    // If file doesn't exist or fails to read, return empty array
    return [];
  }
}

// Write updated users array to the JSON file
async function writeUsers(users: User[]) {
  await fs.writeFile(usersFile, JSON.stringify(users, null, 2), "utf-8");
}

// Handle GET request: return list of users
export async function GET() {
  const users = await readUsers();
  return NextResponse.json(users);
}

// Handle POST request: add a new user
export async function POST(request: NextRequest) {
  const body = await request.json();

  // Destructure and validate input fields
  const { name, email, age } = body as {
    name?: string;
    email?: string;
    age?: number;
  };

  // Return 400 if any required field is missing
  if (!name || !email || age === undefined) {
    return NextResponse.json(
      { error: "Missing name, email, or age" },
      { status: 400 }
    );
  }

  // Read existing users
  const users = await readUsers();

  // Create new user object with unique ID based on timestamp
  const newUser: User = {
    id: Date.now().toString(),
    name,
    email,
    age,
  };

  // Add new user to the list and save to file
  users.push(newUser);
  await writeUsers(users);

  // Return the newly created user with 201 Created status
  return NextResponse.json(newUser, { status: 201 });
}

Now the code for the /app/users/[id]/route.ts file:

import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";
import { promises as fs } from "fs";
import path from "path";

// Define the User interface
interface User {
  id: string;
  name: string;
  email: string;
  age: number;
}

// Path to the users.json file
const usersFile = path.join(process.cwd(), "app/users/users.json");

// Function to read users from the JSON file
async function readUsers(): Promise<User[]> {
  try {
    const data = await fs.readFile(usersFile, "utf-8");
    return JSON.parse(data) as User[];
  } catch {
    // If file doesn't exist or is unreadable, return an empty array
    return [];
  }
}

// Function to write updated users to the JSON file
async function writeUsers(users: User[]) {
  await fs.writeFile(usersFile, JSON.stringify(users, null, 2), "utf-8");
}

// GET /users/:id - Fetch a user by ID
export async function GET(
  request: NextRequest,
  { params }: { params: Promise<{ id: string }> },
) {
  const id = (await params).id;
  const users = await readUsers();

  // Find the user by ID
  const user = users.find((u) => u.id === id);

  // Return 404 if user is not found
  if (!user) {
    return NextResponse.json({ error: "User not found" }, { status: 404 });
  }

  // Return the found user
  return NextResponse.json(user);
}

// PUT /users/:id - Update a user by ID
export async function PUT(
  request: NextRequest,
  { params }: { params: Promise<{ id: string }> },
) {
  const id = (await params).id;
  const body = await request.json();

  // Extract optional fields from request body
  const { name, email, age } = body as {
    name?: string;
    email?: string;
    age?: number;
  };

  const users = await readUsers();

  // Find the index of the user to update
  const index = users.findIndex((u) => u.id === id);

  // Return 404 if user not found
  if (index === -1) {
    return NextResponse.json({ error: "User not found" }, { status: 404 });
  }

  // Update the user only with provided fields
  users[index] = {
    ...users[index],
    ...(name !== undefined ? { name } : {}),
    ...(email !== undefined ? { email } : {}),
    ...(age !== undefined ? { age } : {}),
  };

  await writeUsers(users);

  // Return the updated user
  return NextResponse.json(users[index]);
}

// DELETE /users/:id - Delete a user by ID
export async function DELETE(
  request: NextRequest,
  { params }: { params: Promise<{ id: string }> },
) {
  const id = (await params).id;
  const users = await readUsers();

  // Find the index of the user to delete
  const index = users.findIndex((u) => u.id === id);

  // Return 404 if user not found
  if (index === -1) {
    return NextResponse.json({ error: "User not found" }, { status: 404 });
  }

  // Remove user from the array and save updated list
  const [deleted] = users.splice(index, 1);
  await writeUsers(users);

  // Return the deleted user
  return NextResponse.json(deleted);
}

We will have an empty array inside the /app/users.json. You can find all the code here in this repository.

How to Test the API

Now let’s test the API endpoints.

First, lets run the API:

$ npm run dev

You can go to http://localhost:3000/users and can see an empty array since we have not pushed any user information.

From the code, we can see that a user object needs name, email, and age since the id is automatically generated in the POST endpoint.

We will use Postman to simulate requests to the API and ensure that the API behaves as expected.

GET /users: it will be empty on our first try since we haven’t pushed any data yet.

POST /users: create a new user. Under “body”, choose “raw” and select “JSON”. This is the data we will be sending the api. The JSON body would be

{"name":"Manish","age":30, "email":"manish@example.com"}

I’ll create one more record named “Larry”. Here is the JSON:

{"name":"Larry","age":25, "email":"larrry@example.com"}

Now let’s look at the users. You should see two entries for our GET request to /users:

Now let’s look at a single user using /users/:id.

Now let’s update Larry’s age to 35. We’ll pass just the age in request body using the PUT request to /users/:id.

Now let’s delete Larry’s record.

If you check /users, you should see only one record:

So we have built and tested our api. Now let’s get this live.

How to Deploy to Sevalla

Sevalla is a modern, usage-based Platform-as-a-service provider and an alternative to sites like Heroku or to your self-managed setup on AWS. It combines powerful features with a smooth developer experience.

Sevalls offers application hosting, database, object storage, and static site hosting for your projects. It comes with a generous free tier, so let’s see how to deploy our API to the cloud using Sevalla.

Make sure you have the code committed to GitHub or fork my repository for this project. If you are new to Sevalla, you can sign up using your GitHub account to enable direct deploys from your GitHub account. Every time you push code to your project, Sevalla will auto-pull and deploy your app to the cloud.

Once you login to Sevalla, click on “Applications”. Now let’s create an app.

If you have authenticated with GitHub, the application creation interface will display a list of repositories. Choose the one you pushed your code into or the nextjs-api project if you forked it from my repository.

Check the box “auto deploy on commit”. This will ensure your latest code is auto-deployed to Sevalla. Now, let’s choose the instance to which we can deploy the application. Each one comes with its own pricing, based on the server's capacity.

Let’s choose the hobby server that costs $5/mo. Sevalla gives us a $50 free tier, so we don’t have to pay for anything unless we exceed this usage tier.

Now, click “Create and Deploy”. This should pull our code from our repository, run the build process, setup a Docker container and then deploy the app. Usually the work of a sysadmin, fully automated by Sevalla.

Wait for a few minutes for all the above to happen. You can watch the logs in the “Deployments” interface.

Now, click on “Visit App” and you will get the live URL (ending with sevalla.app) of your API. You can replace “http://localhost:3000” with the new URL and run the same tests using Postman.

Congratulations – your app is now live. You can do more with your app using the admin interface, like:

Monitor the performance of your app
Watch real-time logs
Add custom domains
Update network settings (open/close ports for security, and so on)
Add more storage

Sevalla also provides resources like Object storage, database, cache, and so on, which are out of scope for this tutorial. But it lets you monitor, manage, and scale your application without the need for a system administrator. That’s the beauty of PaaS systems. Here is a detailed comparison of VPS vs PaaS systems for application hosting.

Conclusion

In this article, we went beyond the typical frontend use case of Next.js and explored its capabilities as a full-stack framework. We built a complete REST API using the App Router and file-based routing, with data stored in a JSON file. Then, we took it a step further and deployed the API to production using Sevalla, a modern PaaS that automates deployment, scaling, and monitoring.

This setup demonstrates how developers can build and ship full-stack applications like frontend, backend, and deployment, all within a single Next.js project. Whether you're prototyping or building for scale, this workflow sets you up with everything you need to get your apps into users’ hands quickly and efficiently.

Hope you enjoyed this article. I ll see you soon with another one. Connect with me on LinkedIn or visit my website.

How To Deploy a Next.js App To Vercel With GitHub Actions

Chidiadi Anyanwu — Tue, 10 Jun 2025 17:56:01 +0000

Vercel is a cloud platform or Platform-as-a-Service (PaaS) designed to help frontend developers create, preview, and deploy web applications swiftly and efficiently. In this tutorial, we’ll focus on deploying a Next.js application to Vercel using GitHub Actions.

In a previous article, we built a Next.js portfolio blog. Here, you’ll learn how to deploy it on Vercel with GitHub Actions.

Prerequisites

To be able to deploy your project, you should have a GitHub repository of the project (you can still follow along if you already have a Next.js project), and a Vercel account. Here is the GitHub repository that we’ll be working with. You can clone it to follow along.

How to Deploy Your Next App

Create Vercel Token and Add it to Your Secrets in GitHub

In your Vercel account, go to Settings, then go to Tokens.

In the Create Token section, enter a name for your token, select an expiration date and click “create”.

You should see a success message with your token. Next, go to your GitHub repository, and click on the “Settings“ tab.

In the Settings tab, go to Secrets and Variables on the sidebar, then click on Actions.

You’ll see a section for adding secrets. Add a secret named VERCEL_TOKEN, and paste the token there.

The Vercel token is a token used to authenticate the GitHub runner. The Vercel CLI installed on the GitHub runner is going to execute the commands with your account. So, instead of it having to login, it uses the access token to verify that it was actually authorized by you to take the actions.

The Organization ID is used to tell Vercel which organization or team account the project should be created under.

The Project ID then tells Vercel the specific project you want to deploy. Just like the Organization ID, it is a unique identifier.

Use the command below to install vercel CLI globally on your computer:

npm install -g vercel

Then log into the CLI with the following command:

vercel login

Use one of the options to login.

I used GitHub. Select one with your arrow keys, and click enter.

Create a Vercel Project from Your Local Directory

Navigate to your project directory if you’re not already in it. If you have already created a project on Vercel through the web interfce, use the vercel link command to link your current directory to the Vercel project. If you don’t already have a Vercel project, just type vercel in the CLI and follow the prompts to setup the project.

With that, Vercel will create a .vercel folder in the project. Open it, and go to the project.json file.

In the file, you should see your project ID and organization ID. Copy them and create secrets in your GitHub repository for each one.

Create your GitHub Workflow File

At the root of your project folder, create the .github/workflow folder. Then create a workflow file called vercel_deploy.yml.

In the file, write this:

name: Vercel Production Deployment
env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
on:
  push:
    branches:
      - main
    paths:
      - '01-simple-blog/**'  

jobs:
  Deploy-Production:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: 01-simple-blog
    steps:
      - uses: actions/checkout@v2

      - name: Install Vercel CLI
        run: npm install --global vercel@latest

      - name: Pull Vercel Environment Information
        run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}

      - name: Build Project Artifacts
        run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
        continue-on-error: true

      - name: Deploy Project Artifacts to Vercel
        run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}

This is the workflow file for my simple-writer-portfolio project.

First, we have the environment variables:

env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
# Other code

Then we have the trigger. This triggers when I push to the main branch, affecting files in the 01-simple-blog subdirectory.

# Previous code
on:
  push:
    branches:
      - main
    paths:
      - '01-simple-blog/**'  
# Other code

Then we have the job definition. Here, I defined a job “Deploy-Production” that runs on Ubuntu. By default, all commands there will run in the 01-simple-blog directory, which is equivalent to running cd 01-simple-blog from the root before running commands on the shell. I did this because the Next.js project is in that directory, where the package.json is located.

# Previous code
jobs:
  Deploy-Production:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: 01-simple-blog
# Other code

Then the steps involved:

# Previous code
 steps:
      - uses: actions/checkout@v2

      - name: Install Vercel CLI
        run: npm install --global vercel@latest

      - name: Pull Vercel Environment Information
        run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}

      - name: Build Project Artifacts
        run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
        continue-on-error: true

      - name: Deploy Project Artifacts to Vercel
        run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}

With these steps, Vercel is first installed on the GitHub runner. Then the vercel environment information is pulled. The project is built with vercel build, and the pre-built artifacts are then pushed to Vercel.

Push to GitHub and watch your code deploy

Stage your changes, if any:

git add .

Commit the changes:

git commit -m "Added GitHub Actions workflow"

And push:

git push origin

Now, go to your repository online, and check the deployment.

Conclusion

With your basic GitHub workflow in place, you can now make changes to your code, push to GitHub, and have it deploy automatically. Though Vercel allows you to connect your repository directly, this method provides you with more flexibility and customizability. If you enjoyed this article, share it with others. You can also reach me on LinkedIn or X.

The Best AWS Services to Deploy Front-End Applications in 2025

Ijeoma Igboagu — Tue, 27 May 2025 22:32:08 +0000

As front-end development evolves, finding the right deployment service is more important than ever. Amazon Web Services (AWS), a cloud-based service, offers a number of helpful tools and platforms for hosting modern front-end applications. Although it may present challenges for beginners, AWS can help give companies an edge with its global reach.

In this article, I’ll break down the best AWS services for frontend deployment in 2025, covering their use cases and their pros and cons. Whether you’re launching a static website, a React/Vue application, or a complex web application, this article will help you find the most effective AWS solution for your needs.

Why Choose AWS for Frontend Hosting?
AWS Services for Frontend Hosting
Conclusion
Related Articles

Why Choose AWS for Frontend Hosting?

Before we explore the specific AWS services for frontend hosting, let’s first look at why developers and companies often choose AWS over more familiar platforms like Netlify or Vercel.

AWS has data centers worldwide, reducing latency and ensuring high availability. This means that apps deployed using their services can be easily and quickly accessed anywhere in the world (as long as that region has a nearby data center).
Any provisioned AWS service has security features like encryption, IAM, and DDoS protection.
AWS automatically scales to handle high traffic spikes without downtime.
AWS is flexible – it supports frameworks like React, Vue, Angular, and Next.js.
AWS easily integrates with other AWS services like databases (DynamoDB, RDS), APIs (API Gateway), and authentication (Cognito).

AWS Services for Frontend Hosting

Amazon S3 (Simple Storage Service)

Amazon S3 is a storage service from AWS mainly used to store files like HTML, CSS, JavaScript, Images, and Videos. These files make up static websites – that is, websites that don’t change based on user actions.

Many developers use S3 to host their static websites because it’s reliable, it works well, and it doesn’t cost much. You just upload your files to an S3 bucket, make them public, and your website is live. You can also connect a custom domain and add extra features like faster loading through a CDN (like CloudFront).

Use Case:
AWS S3 is perfect for hosting static websites and storing media files, such as portfolio sites, blogs, documentation pages, or any site that doesn't require a server to run backend code.

Pros:

Easy to use and affordable for most projects.
Keeps your files available almost all the time.
Your data is stored safely and can be backed up automatically.

Cons:

It doesn’t support backend features like running code, handling forms, or connecting to databases.

To help you get started using S3 for hosting, here’s an article that explains how to host a static website using AWS S3 and Cloudfront.

AWS Elastic Beanstalk

AWS Elastic Beanstalk is a service that helps you quickly deploy and manage web applications without needing to handle the underlying infrastructure. While it’s often used for backend services, it also works well for frontend apps that need server-side features.

Use Case:
AWS Elastic Beanstalk is ideal for hosting full-stack applications, especially those built with server-side frameworks like Next.js or Nuxt.js. It handles both the frontend and backend in one environment.

Pros:

Automatically scales your app based on traffic
Includes load balancing to manage high traffic smoothly
Works well with other AWS tools like RDS for databases and CloudWatch for monitoring

Cons:

More complex to set up compared to simpler services like Amplify or S3
Not the best choice for static websites that don’t require server-side logic

To better understand how it works, I used AWS Elastic Beanstalk to set up a CI/CD pipeline. You can read this article: How to Create a CI/CD Using AWS Elastic BeanStalk.

Amazon EC2 (Elastic Compute Cloud)

Amazon EC2 lets you run your virtual server in the cloud. You can install any software, upload a website, open or close ports, and have full control over how your application runs. It's similar to having your physical computer, but it's hosted online and it’s more flexible.

Use Case:
AWS EC2 is great for developers or teams who need full control over their hosting setup. It's useful for projects where the frontend and backend are closely connected, or where you need to run custom services, tools, or configurations that simpler platforms can’t handle.

Pros:

Full control over the server environment.
Supports custom setups, tools, and applications.
It is a flexible way to run any application on it.

Cons:

Takes time to learn and manage.
You’re responsible for handling updates, scaling, and security.

To help you understand how it works and how to connect it to your code editor (IDE), here's an article that walks you through the process: How to Connect Your AWS EC2 Instance to VS Code.

AWS Amplify

AWS Amplify is a platform that makes it easy to build and host frontend and mobile applications. It’s designed for developers working with frameworks like React, Vue, Angular, or Next.js.

Amplify handles things like hosting, authentication, APIs, and data storage. It supports Git-based CI/CD, which means your app can automatically update every time you push code. It comes with built-in support for popular tools like Cognito (for login systems), AppSync (for APIs), and DynamoDB (for databases). You can even create different environments based on your Git branches.

Use Case:
AWS Amplify is ideal for teams or solo developers building full-stack apps with modern frontend tools, especially when you want built-in features like user authentication, cloud APIs, and easy deployment.

Pros:

Simple full-stack hosting – frontend and backend in one place.
Fast setup with automatic scaling.
Comes with HTTPS, custom domain setup, and performance monitoring.

Cons:

More expensive than simpler solutions like S3 for basic static sites.
Less flexibility for developers who want full control over infrastructure.

Here is a simple guide for building with AWS Amplify. I hope it helps you understand it better: How Can AWS Amplify Improve Your Development Process?

And here’s an in-depth guide that walks you through building a full-stack app with AWS Amplify and React.

AWS LightSail

AWS LightSail is a beginner-friendly cloud hosting service that offers a quick and easy way to launch small applications. It works like a simpler version of EC2 and comes with pre-configured environments for Node.js, LAMP (Linux, Apache, Mysql, PHP), and WordPress. This means that you don’t have to spend time setting everything up from scratch.

Use Case:
It is perfect for freelancers, small businesses, or anyone who wants to host a simple website or app, such as a blog, a small web app, or an online portfolio.

Pros:

More affordable than EC2.
Easy to set up and manage.
Comes with ready-to-use application stacks.

Cons:

Not ideal for large or fast-growing projects.
Has fewer customisation and scaling options compared to EC2 or Amplify.

For a fun, project-based tutorial, check out this guide that teaches you how to use AWS LightSail to deploy Docker containers to the cloud.

AWS App Runner

AWS App Runner is a service that helps you run web applications without setting up or managing any servers. You just connect your source code or a container image, and App Runner handles everything. It's a quick way to get your frontend or backend app online, especially if your app needs server-side processing.

Use Case:
App Runner is a good choice for frontend applications built with server-side rendering (like Next.js), full-stack apps, or APIs. It’s also helpful if your app is containerised and you want it to scale automatically based on traffic.

Pros:

No server setup or management.
Automatically scales your app as needed.
Easy to connect with GitHub or Amazon ECR.
HTTPS and custom domain support included.

Cons:

It’s not the best choice for very simple websites that only show static content like HTML, CSS, and JavaScript files. Other services like S3 are easier and cheaper for that kind of site.
It doesn’t give you as much control as EC2 or ECS. For example, you can’t fully customise the server environment or how things run behind the scenes. So, it’s great for simple or standard setups, but not ideal if you need to fine-tune advanced settings.

If you want to learn more about deploying apps with AppRunner, here’s a tutorial about deploying a Kotlin microservice to AppRunner that you can check out.

Conclusion

AWS offers a variety of powerful tools for hosting frontend applications, from simple static site hosting on S3 to full-stack managed deployments with Amplify. Whether you’re a solo developer launching your portfolio or a team deploying a production web app, AWS has the flexibility and scalability to support your frontend needs.

By understanding each service’s purpose and use case, you can confidently pick the best fit for your project and scale as needed. Start small, experiment, and grow with AWS.

If you found this article helpful, please share it with others who may find it interesting.

Stay updated with my projects by following me on Twitter, LinkedIn and GitHub.

Thank you for reading.

How to Deploy a Restful Web Service on Microsoft Azure App Service

Alaran Ayobami — Fri, 28 Mar 2025 15:34:24 +0000

Hey there! 👋, How’s it going?

I hope you're doing well. Whether you're a seasoned coder, a curious learner, or just someone browsing through, welcome to my little corner of the internet.

In this tutorial, we’ll dive into how you can deploy a web service on Microsoft Azure app service. It’s a topic I’ve been excited to explore, and I hope you’ll find it insightful and helpful. So grab a coffee, sit back, and let’s get started.

Prerequisites

Basic understanding of RESTful web services
Programming knowledge
Docker basics
Docker Hub account
Command Line Interface (CLI) skills

What we’ll cover:

Key Terminologies
How to Install Docker and Docker Compose
How to Create a Simple Get Client Info Web Service
How to Build the App’s Docker Image
How to Run the App in the Container
How to Create an Azure Resource Group on Azure Portal.
How to Deploy to Azure App Service
Conclusion

Before we actually get started, I’d like to go over some key terminologies that I'll be using throughout this tutorial. Understanding these terms will make it easier to follow along and get the most out of what we're discussing. Let’s dive in!

Key Terminologies

1. Docker

Docker is an open-source platform that simplifies application development, shipping, and deployment by using containers. With Docker, there are three key things you can do:

build once and run anywhere
keep environment consistent, and
easily scale your application with container orchestration tools like Kubernetes.

2. Docker Hub

Docker Hub is a cloud-based repository where developers can store, share, and manage Docker images. You can think of it as the GitHub for Docker images 😉.

3. Docker Image

A Docker image is a lightweight, standalone, and executable package that includes everything needed to run a piece of software. You can also think of it as a blueprint for creating and running a container.

Once built, an image is immutable, meaning it cannot change after creation. Instead, you create a new version when updates are needed. This means that you’ll need to rebuild if you update the code that’s being run in the container.

4. Container

A container is a running instance of a Docker image. It provides an isolated environment where an application runs with all its dependencies, without interfering with the host system or other containers.

Wait, what?! 😕 Well, simply put, a container is like a tiny virtual machine that runs the built Docker image. But unlike traditional VMs, it has no init process (PID 1), meaning it always runs on a host system rather than being fully independent. By now, you should be getting the idea: no image, no container. A container depends on an image to exist. You have to cook before you serve, right? 🍽️

5. Azure Resource Group

An Azure resource group refers to a store or folder containing all related resources for an application you want to deploy to production using MS Azure Cloud. For example, if I want to deploy an eCommerce web app with MS Azure, I could create a resource group called EcommWebAppRG. I’d use this to create all the resources I needed for the web app to go live and be accessible – like VMs, DBs, caches, and other services.

Alrighty, now that all the terms are out of the way, lets get started with the tutorial so you can learn how to deploy a web service on Azure App Service.

Since we are deploying an app, let’s start by creating simple REST API app. I’ll be using Golang for the API development, but you can use any programming language/framework of your choice. If you’d like to follow along with the app for this tutorial, I’ve provided the source code here.

How to Install Docker and Docker Compose

To install Docker and Docker compose on your PC, for Mac and Windows you’ll need to download Docker desktop for your Operating System here.

For Linux, you can run the following command:

sudo apt update # update apt registry
sudo apt install docker.io # for docker engine
sudo apt install docker-compose-plugin

After downloading the Docker desktop for your application, open your terminal and enter the following command to verify that Docker and Docker Compose have been successfully installed on your machine:

docker-compose -v # this should show the version of docker compose cli you have on your PC

My Docker Compose version is:

Docker Compose version v2.31.0-desktop.2

docker -v

You should see something similar if Docker has successfully been installed on your machine:

Docker version 27.4.0, build bde2b89

How to Create a Simple Get Client Info Web Service

Alright, I’ll use this handy tool called sparky_generate to generate the app code template. sparky_generate is a command line tool used to generate boilerplate code for backend development using various backend languages and frameworks.

Use this command to install and setup the tool on your Mac or Linux machine. If you are on Windows, you can use WSL.

wget https://raw.githubusercontent.com/Ayobami6/sparky_generate/refs/heads/main/install.sh

chmod 711 install.sh
./install.sh # run the install command like so

sparky # run the sparky command like so

You should see something similar to the below. Select whatever framework you want to use for your backend service.

I will select Go, because I’m using Go for this tutorial. You should have your project template ready once you’ve selected your framework. I won’t go through how to code the web service since it’s out of scope for this tutorial. The goal here is to deploy on Azure using Azure App Service.

How to Build the App’s Docker Image

To build the Docker image for our app, we first need to create a Docker file that will include all the steps needed to build the image.

touch Dockerfile

We will be using a multistage Docker build to reduce the size of our Docker image. We need something as light as possible.

The multistage Docker build helps reduce size because we use different stages for different concerns. This helps ensure that only what’s needed runs the application in the final stage. For example, we might need certain artifacts to build the application, but we don’t need them to run the application. This is why we have the builder and runner stages in the Docker file below.

Our first stage (build) is concerned with building and bundling the application. The second stage (runner) is just used to run the executable we built in the first stage. So basically all files, modules, and so on used in the build process will be discarded in the runner since they’ve already served their purposes.

# using the first stage as build
FROM golang:1.23-alpine AS build # using alpine base image to reduce size

# install git on the machine
RUN apk add --no-cache git

# setting the current work directory on the vm to be /app
WORKDIR /app

# Copying all go dependency files to the working directory
COPY go.mod go.sum ./

# Install go dependencies
RUN go mod download

# copy all remaining files to the working directory
COPY . .
# build the execuatable

# build the go program
RUN go build -o api cmd/main.go

# stage 2 AKA the runner
FROM alpine:3.18

RUN  apk add --no-cache ca-certificates

# copy the go executable to the working directory
COPY --from=build /app/api .

# expose the service running port
EXPOSE 6080

This Dockerfile outlines all the steps for building a Docker image for our app. Lets go through all these steps line by line. Because we are using a multistage build here, our stages are build and runner.

The first stage build starts from the first FROM golang:1.23-alpine AS build. It initializes a stage with all the steps in the stage. It states that the base image to be used for all the steps in this stage should use a pre-existing golang:1.23 image using an Alpine Linux distro to run all the steps in the stage.
Next, we have RUN, which is used to run the command apk add git, followed by setting the working directory to the /app folder.
Then we have the COPY command that copies all the Go dependencies that will run the Go program.
Following that is RUN go mod download which is used to install all the dependencies.
We then have the command COPY . . to copy all the files to the working directory /app of the image
Then the last step in the build stage, RUN go build -o api cmd/main.go, builds the app code main.go to an executable API. The second stage “runner“ uses an alpine:3.18 base image, and also uses the RUN directive to add ca-certificates to the Alpine base image. The COPY is used here to copy just the built executable file from the builder image to the runner image.
We then expose port 6080 so our built container can accept an HTTP connection from port 6080.

Now, let’s write our docker-compose.yml file to define and run our containerized service::

services:

  client_info_app:
    build: 
      context: .
      dockerfile: Dockerfile
    container_name: info_app

    ports:
      - "6080:6080"

    command: "./api"

Understanding the YAML Structure

YAML follows a key-value structure similar to a dictionary or hashmap. In our file, the top-level key is services, which acts as the parent key. Within services, we define individual service configurations.

In this case, we have a single service named client_info_app, which contains the necessary properties for Docker to build and run it.

build: This specifies how to build the Docker image for the service. The context: . tells Docker to look for the Dockerfile in the same directory as the docker-compose.yml file.
container_name: This assigns a custom name (info_app) to the running container, making it easier to reference.
ports: Defines the port mappings between the host and the container. The - before "6080:6080" indicates that multiple mappings could be listed. Here, port 6080 on the host is mapped to port 6080 inside the container.
command: Specifies the command to execute inside the container once it starts. In this case, it runs ./api.

This structure allows us to define and configure multiple services within the services key if needed, but for now, we are only defining client_info_app.

How to Run the App in the Container

You can use this command to start the container:

docker-compose up client_info_app

The above command will first build the image if it doesn’t exist. Then it runs it, because remember: no image, no container.

If all looks good, you should have something similar to this, depending on your application framework:

You should also verify that your Docker image has been built as well. To do that, run the following:

docker images

Voilà! You now have your Docker image built and ready for deployment on Azure App Service.

Let’s go on to the Azure Portal to deploy the app.

Note: if you don’t have an active Azure Subscription, that’s fine – you can still follow along. If you want to get a trial account, you can get one here.

How to Create an Azure Resource Group on Azure Portal.

As a reminder, an Azure resource group refers to a store or folder containing all related resources for an application you want to deploy to production using MS Azure Cloud. Now let’s go about creating one.

When you login to the Azure portal, you should see some like this, the dashboard:

Search for Resource group using the search bar:

Click on Create to create a new resource group:

Give your resource group a name and select a region for it. Here I will use the default East US 2, but you can use any you want. Then click on Review + create.

You should see something like the above after creating the resource group.

How to Deploy to Azure App Service

Ok now that we’ve created the resource group, let’s go ahead and create the Azure App Service. To do this, navigate back to the dashboard and click on Create a resource.

You can search for Web App if you don’t see it in the list there. Then click on the Create Web App option:

Here, select the resource group you created earlier, give the app a name, then select Container for the Publish option.

Before you click on Create, go back to your dev workspace (VS Code or whatever IDE you are using) to push your Docker image to Docker Hub so you can add it there before proceeding to the next steps.

But why do you need to push to Docker Hub? Well, first of all, for accessibility – so we can easily share it with others or have other services access it (which is what we need here).

Remember how I compared Docker Hub with Github earlier? Docker Hub helps you host your Docker image on the internet and make it available for others or for various services on the internet to access if you make it public. Otherwise it’s limited to only authorized services.

To push the Docker image to Docker Hub, you first need to tag the Docker image with your Docker Hub username. Go to Docker Docker Hub to register and get your username if you don’t have one.

Run the following:

docker tag client_info_webservice-client_info_app:latest ayobami6/client_info_webservice-client_info_app:latest
# this adds the latest tag to your docker image

This shows that you successfully tagged your image with the latest tag.

Before you actually push the image to Docker Hub, go ahead and login to it with the Docker CLI.

docker login # this will prompt for browser authetication, for the prompt and login your account with your usernam and password

Push the image to Docker Hub like this:

docker push ayobami6/client_info_webservice-client_info_app:latest

You should see something like the below once you enter the push command on Docker Hub.

Alright, now that you have the Docker image on Docker Hub, you can go ahead and deploy it using Microsoft Azure App Service.

Click on the container on the top menu bar to configure the container settings.

Here, select Other container registries.

Select public, because your pushed image is public (meaning it’s publicly accessible over the internet).

Add your Docker image and tag. You can get this when you run the command docker images.

λ MACs-MacBook-Pro ~ → docker images
REPOSITORY                                        TAG         IMAGE ID       CREATED         SIZE
ayobami6/client_info_webservice-client_info_app   latest      a14f2a5b3bd4   2 weeks ago     30.8MB
postgres                                          13-alpine   236985828131   4 weeks ago     383MB
glint_pm_frontend-nextjs                          latest      424233ceaa4b   4 weeks ago     1.72GB
flask_app-flask_app                               latest      ff6ecfc4ba5a   5 weeks ago     203MB
nginx                                             latest      124b44bfc9cc   7 weeks ago     279MB
encoredotdev/postgres                             15          58b55b0e1fc7   10 months ago   878MB
λ MACs-MacBook-Pro ~ →

Copy the repository name and tag – in my case I have ayobami6/client_info_webservice-client_info_app and tag latest → ayobami6/client_info_webservice-client_info_app:latest.

Then add your startup command. If you are not using Go for the development like I am, your startup command will be different – so just use the command you added to your Docker compose command key, like so command: "./api". Copy just the value (mine is ./api) don’t add the double quotes, and add it to the startup command.

This start up command is the command that will start the application from the container and get the container running.

Click on review and create to create the service.

Once the deployment is complete you’ll be redirected here:

Congratulations! You’ve successfully deployed your web service to Azure App Service. You can visit your app using the default domain from the overview. Mine is here.

Conclusion

Deploying a RESTful web service on Microsoft Azure App Service is a powerful way to leverage cloud technology for scalable and efficient application hosting.

Understanding key terms like Docker, Docker Hub, and Azure Resource Groups will help you streamline the deployment process.

This guide walked you through creating a simple web service, building a Docker image, and deploying it on Azure. By following these steps, you can confidently deploy your applications, ensuring they are accessible and performant.

Thank you for following along, and I hope this tutorial has been insightful and helpful in your cloud deployment journey. If you found it useful, feel free to share it with others who might benefit from it. Happy coding and deploying!

Stay tuned for more insightful content, and let's continue learning and growing together. Cheers to building smarter, more efficient solutions with Azure.

How to Deploy Your Project On Vercel With A Custom Domain

Okoro Emmanuel Nzube — Fri, 25 Oct 2024 19:35:48 +0000

Have you ever built a project but found it difficult to make it live on the internet? Well, worry no more because this article will help you do that.

In this article, I will introduce you to one of the fastest and easiest deployment platforms for bringing your code/project to the web.

I will also show you how you can deploy a web application with your custom domain and why it’s important to do so.

Let's dive right in.

Overview of Vercel
What are Domains?
How to Set Up a Vercel Account
How to Configure a Custom Domain
Conclusion

Overview of Vercel

Vercel is a cloud hosting platform that provides tools that enable developers to build, deploy and scale their web applications. One important fact about this platform is that it is quick, easy to navigate/use, and it is very efficient.

Vercel supports and deploys many frameworks with minimal configuration, especially frameworks built with JavaScript. Here is a list of frameworks that can be deployed to Vercel: Angular, Astro, Brunch, React, Dojo, Gatsby.js, Next.js, Nuxt.js, Vite, Vue.js, Vuepress, and so on.

You may not know all these frameworks at this point, but it's important to know that Vercel supports these frameworks and many more.

See Vercel documentation to view more.

What are Domains?

Domains are ‘unique identifiers’ used to locate or find a specific website on the internet. For example, freecodeCamp.org. Whenever you see a domain name, you should have an idea of the website it belongs to.

It is important to note that a domain name can be created with a combination of letters (A-z), numbers (0-9), and dash characters.

Importance of Having a Domain Name

Here are some reasons why you should have a domain name:

Easy to find and locate you: Having a domain name makes the work of finding your business easy and also increases the possibility of making more sales from your web page. If you have a physical store, not everyone may want to visit it.
For Professionalism and Credibility: Imagine having a business but no website or domain. This will make you look unprofessional to customers because they may not take you seriously.
Increase your Online Presence: With a domain name, your online presence or your brand’s online presence is increased, which makes you more visible.

Now let's talk about setting up a Vercel account. This process is actually simple and easy to follow.

How to Set Up a Vercel Account

The first step is to visit Vercel.

On the Vercel home page, click on the sign-up button, located at the top right corner of the home page.

Choose your "Plan Type" and then input your name. Then click on Continue to proceed.

Next, connect the account where you will be importing your project from. You’ll be provided with three options: GitHub, GitLab, or BitBucket.

In my case, I clicked “Continue with GitHub”.

Note: If you don’t have a GitHub account, you can read see how to create one here.

Once you have linked your GitHub account with Vercel, the interface should look like this:

At this point, you’re done setting up your Vercel account. The next step is to deploy your project.

From the image description above, you can see an “import” button. Go to the particular project you want to deploy and click on the import button. In my case, I named my project repository “practice-purpose”.

Once you click the import button, it should lead you to the next page where you can input your project name and finally deploy it.

Wait for a few minutes for the deployment to be complete. After that, your interface should look like this:

Congratulations! At this point, you have deployed your first project.

How to Configure a Custom Domain

Before you continue with the process of configuring a custom domain, you must have gotten your domain ready. If not, I have added a quick video that will guide you.

For this article, I will be making use of Namecheap, because that is where I got the domain I am using. Feel free to use any domain provider of your choice.

At this point, your domain name should be available. If that is so, let’s continue.

In your deployment page on Vercel, click on “Domain” in the navigation bar, input your custom domain name (the one you bought) in the space provided and click on “Add”.

When you click on the “Add” button, a prompt should pops up – don’t change anything, use the recommended option and click on the ‘Add’ button.

For the next step, click on the “Nameservers” option, then click on “Enable vercel DNS”.

Lastly, copy the DNS and head to the website where you purchased your domain.

Here are detailed images that show the above steps.

At this point, all you have to do is link your custom domain with Vercel, using the DNS you just copied from Vercel.

Here is how you can go do that (I’ll use the Namecheap process to explain it):

Go to the website where you purchased your domain and log in to your dashboard.

Head to the domain list option and click on it. This should display a list of domains you have purchased with that account.

Next, head to the domain name you used for your Vercel project and click on the “manage” option. This should open a page where details of the domain is displayed.

Find where you have “nameservers” and choose the “custom DNS” option. Lastly, paste each of the DNS you copied from Vercel into the spaces provided and click on save.

After this, you should get a prompt stating that the custom domain will be live in the next 48 hours. In most cases, it doesn’t take up to a day for it to be active.

Here is a detailed image that shows the above steps.

Conclusion

In this article, you learned about the Vercel platform, what a domain name means and its importance.

You also learned how to set up your Vercel account, deploy your project, and add a custom domain.

If you’ve read up to this point, I want to say a very big congratulations, and I hope you got the value out of this article.

deployment - freeCodeCamp.org

Why Your “Simple Deploy” Turned Into a Week of Infrastructure Work

What We'll Cover:

The Promise You Were Sold

The Hidden Contract You Are Already Operating Under

You Are Already Acting Like a Platform Team

The Cost Is Not Complexity. It Is Time

Why “It Works on My Machine” Still Exists

Fragmentation Is the Root Problem

This Model Breaks as You Scale

The Shift Toward Platforms

What You Stop Paying For

From Infrastructure Work Back to Product Work

Collapsing the Stack

The Trade-Off You Are Actually Making

When This Becomes Urgent

When Managing Infra Still Makes Sense

What a “Simple Deploy” Actually Means

Closing Thought

How to Build and Deploy a Fitness Tracker Using Python Django and PythonAnywhere - A Beginner Friendly Guide

Table of Contents

Prerequisites

What You Are Going Build

Step 1: How to Set Up Your Django Project

1. 1 How to Create a Virtual Environment

1.2 How to Install Django

1.3 How to Create the Project

1.4 How to Run the Development Server

Step 2: How to Create a Django App

2.1 How to Generate the App

2.2 How to Register the App

Step 3: How to Create a Workout Model

3.1 How to Define the Model

Step 4: How to Apply Migrations

4.1 How to Generate the Migration

4.2 How to Apply the Migration

Step 5: How to Register the Model in the Admin Panel

5.1 How to Add Model to Admin

5.2 How to Create a Superuser

5.3 How to Access the Admin Panel

Step 6: How to Create Views for the App

6.1 How to Create a Form Class

6.2 How to Write Views

Step 7: How to Create Templates

7.1 How to Set Up the Template Directory

7.2 How to Create the Workout List Template

My Workouts

My Workouts

7.3 How to Create Add Workout Template

Log a Workout

Step 8: How to Connect URLs

8.1 How to Create App Level URLs

8.2 How to Link App URLs to project

Step 9: How to Test the Application Locally

Step 10: How to Prepare for Deployment

10.1 How to Update Settings for Production

Step 11: How to Deploy Your Django App on PythonAnywhere

11.1 How to Create a PythonAnywhere Account

11.2 How to Upload Your Project Files

Option A: Upload using Git

Option B: Upload files manually

11.3 How to Set Up a Virtual Environment in PythonAnywhere

11.4 How to Run Migrations and Create a SuperUser on PythonAnywhere

11.4 How to Configure the Web App in Pythonanywhere

11.5 How to Set the Virtual Environment Path

11.6 How to Configure the WSGI file

11.7 How to Set Up Static Files

11.8 How to View Your Live Application

Common Mistakes and How to Fix Them

How You Can Improve This Project

Conclusion

How to Self-Host AFFiNE on Windows with WSL and Docker

Table of Contents

What is AFFiNE?

The Power of Self-Hosting

Prerequisites

Step 1: Preparing Your Workspace

Step 2: Getting the Official Setup Files

Step 3: Configuring Your Environment (.env)

Step 4: Launching the System