DEV Community: Ajith Kumar P M

Atomic commits and git bisect

Ajith Kumar P M — Tue, 11 Nov 2025 17:32:14 +0000

So today, something happened at work.

Suddenly, the typecheck that used to take roughly 60 seconds started taking more than 8 minutes. Since typechecking is in our pre-commit hook, all the devs were complaining, everyone was making commits by force-skipping the git hooks, and I was tasked with finding the root cause.
I was pretty sure the command was working fine the last time I worked on the project, so something must have happened in the last week that caused this. This was a perfect time to use git bisect.
The command essentially lets you find a bad commit between a known "good" commit and a "bad" commit. But one thing that is crucial for using this effectively is having a clean commit history with atomic commits.

Working with atomic git commits just means your commits are of the smallest possible size. Each commit does one, and only one, simple thing that can be summed up in a simple sentence.

Btw, if you feel you need to add an "and" to your commit message, that should be two commits.
Also, if a commit is too large, if it breaks something, you know the commit is at fault, but you don't know which part of it.

Luckily, my teammates are pretty good at following basic git practices, so all our commits were properly described and atomic. The history looked something like this (not the real one, just an example):

fix(api): correct pagination offset                     (a12f3c9)
docs(readme): update setup instructions                 (b9d41ef)
feat(admin): add search bar to user table               (c7aa92d)
refactor(utils): simplify date formatting function      (f04bb12)

... (around 100 more commits) ...

fix(types): resolve inference issue in useQuery       (e3c91af)
chore: bump typescript to 4.9                         (9b7d2cc)

So, I knew the following:

The current commit (HEAD) was the bad one.
A commit from last week (let's call it 9b7d2cc) was the good one. I knew this 'cause I could check it out, run the typecheck, and see it only taking ~60 seconds.

With those two pieces of info, I started the process.

First, you tell Git you want to start the bisect process:

git bisect start

Then, you tell it the bad commit (the one I'm on) and the good commit (the one from last week):

$ git bisect bad HEAD
$ git bisect good 9b7d2cc

It automatically checked out a commit right in the middle of my good and bad ones. My job was just to run the typecheck:

pnpm run typecheck

If it was fast (60 seconds), the bug must have come after this commit. I'd tell Git:

git bisect good

If it was slow , the bug was introduced before or at this commit. I'd tell Git:

git bisect bad

Every time I did that, Git would cut the number of possible commits in half and check out a new one for me to test.

After just 6 or 7 tests, Git printed out the answer:

a9c3e1a is the first bad commit Commit: a9c3e1a Author: ... Date: ...
...
...

The actual issue was incorrect update of an internal package :). What could have been a full day of manually checking out commits and re-running tests was over in like 10 minutes.

Mock Client-side & Server-side API Requests Using Next.js and MSW.js

Ajith Kumar P M — Mon, 14 Jul 2025 17:45:43 +0000

Read from source
There are a bunch of situations where mocking API requests can really come in handy. Maybe you’re building out features without a backend yet, trying to avoid hitting a third-party API too often, or just want things to work offline.
Mocking used to be pretty straightforward when everything was happening on the client side. But things changed with modern React. With support for data fetching on the server, API requests can now come from both the server and the client.
So how do you mock both client-side and server-side API calls without writing two completely different sets of mocks?
That’s where MSW (Mock Service Worker) comes in. It’s honestly one of the best tools out there for this job.
MSW lets you mock API requests at the network level:

On the client, using a Service Worker (msw/browser)
On the server, using an intercepting server (msw/node) that works well for SSR and API routes

Let’s walk through how to set it all up.

Setting Up MSW in a Next.js App

You can find the full working example here:

👉 github.com/ajth-in/nextjs-mswjs

Install MSW

Install MSW as a dev dependency:

npm install msw --save-dev

Set Up the Folder Structure

Next, create a mocks directory at the root of your project. This will hold everything related to MSW, including handlers and setup files for both the browser and Node.js environments.

Here’s the structure:

.
├── app
│   └── page.tsx               # Example route that makes an API call
├── mocks
│   ├── browser.js             # Client-side MSW setup (Service Worker)
│   ├── node.js                # Server-side MSW setup (for SSR/API routes)
│   ├── handlers.js            # Main list of request handlers
│   └── data
│       └── github-user.json   # Mock json
├── components
│   └── MswWorker.tsx          # Component to load the worker script
├── instrumentation.ts         # To integrate msw node server

Let’s look at a simple example that fetches user information from the GitHub API. This will demonstrate both server-side and client-side fetching, which we’ll later mock using MSW.

`app/page.tsx`

This is a React Server Component that fetches user data during server-side rendering. It then renders a client component (GithubUserName) and also displays the user’s GitHub login directly.

import GithubUserName from "@/components/UserName";
import { Fragment } from "react";

export default async function Home() {
  const res = await fetch("https://api.github.com/users/ajth-in");
  const userData = await res.json();

  return (
    <Fragment>
      <GithubUserName />
      <p className="login">@{userData.login}</p>
    </Fragment>
  );
}

`components/UserName.tsx`

This is a Client Component that also fetches the same user data from GitHub, but on the client side using useEffect. Instead of showing the login, it displays the user’s full name.

"use client";

import { useEffect, useState } from "react";

export default function GithubUserName() {
  const [userData, setUserData] = useState<{ name: string } | null>(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    async function fetchUserData() {
      try {
        const res = await fetch("https://api.github.com/users/ajth-in");
        const data = await res.json();
        setUserData(data);
      } catch (error) {
        console.error("Failed to fetch user data:", error);
      } finally {
        setLoading(false);
      }
    }

    fetchUserData();
  }, []);

  if (loading) return <p>Loading...</p>;
  if (!userData) return <p>Failed to load user data.</p>;

  return <p>{userData.name}</p>;
}

💡 Note:

The client-side fetching here is redundant. Since the same user data is already available on the server, it could be passed as a prop to the client component. We're doing it this way purely to demonstrate both client-side and server-side mocking with MSW.

If you start the development server at this point, you'll see something like this:

The user information is being fetched live from the GitHub API, both on the server and the client.

`mocks/data/github-user.json`

Now let’s mock the GitHub API call we used earlier. We’ll return a static user response from a local JSON file.

Start by creating a file at:

mocks/data/github-user.json

And add the following mock response:

{
  "login": "ajth-in (cached)",
  "name": "Ajith Kumar P M (cached)"
}

The "(cached)" part is just there to help us verify that the mock is being used when the app runs.

`mocks/handlers.js`

Now we’ll create an MSW handler to intercept the GitHub API request and respond with our mock data.

import { http, HttpResponse } from "msw";
import user from "./data/github-user.json";

export const handlers = [
  http.get("https://api.github.com/users/*", ({}) => HttpResponse.json(user)),
];

In this example, we’re intercepting all requests that match the pattern https://api.github.com/users/*. If you want to target a specific user or URL, you can provide the exact match instead.

`mocks/node.js`

This sets up the mock server for handling requests in the Node.js environment (used during SSR or in API routes):

import { setupServer } from "msw/node";
import { handlers } from "./handlers";

export const server = setupServer(...handlers);

`mocks/browser.js`

This sets up the Service Worker that intercepts requests on the client side:

import { setupWorker } from "msw/browser";
import { handlers } from "./handlers";

export const worker = setupWorker(...handlers);

To hook MSW into our Next.js app, we’ll use Next.js instrumentation hooks. These allow you to run setup code during the server's startup lifecycle.

🛠️ From the Next.js documentation:

"Instrumentation is the process of using code to integrate monitoring and logging tools into your application. This allows you to track the performance and behavior of your application, and to debug issues in production."

We’re going to use this hook to spin up our mock server.

`instrumentation.ts`

Create a file at the root of your app directory named instrumentation.ts and add the following:

export async function register() {
  if (
    process.env.NEXT_PUBLIC_MSW_ENV === 'test' &&
    process.env.NEXT_RUNTIME === 'nodejs'
  ) {
    const { server } = await import('./mocks/node');
    server.listen();
  }
}

Here’s what this does:

NEXT_RUNTIME === 'nodejs' ensures we only run this in the Node.js runtime (not in the Edge runtime).
NEXT_PUBLIC_MSW_ENV === 'test' lets us control when to enable MSW. This way, mocks are only active in testing or development environments.

⚠️ Note:

This example uses Next.js version 15.3.5.

Depending on your version, you might need to enable the instrumentation hook explicitly in your config:

// next.config.ts
export const nextConfig = {
  experimental: {
    instrumentationHook: true,
 },
};

For client-side mocking, MSW uses a Service Worker to intercept requests in the browser. First, we need to generate the mockServiceWorker.js file that gets served from the public/ folder.

Generate the Service Worker File

Run the following command:

npx msw init public/ --save

This will generate a public/mockServiceWorker.js file that MSW uses under the hood.

`components/MswWorker.tsx`

This component is what we'll use to load the Mock Service Worker (MSW) into our app during development or testing.

"use client";

import { PropsWithChildren, useEffect, useState } from "react";

export function MswWorker({ children }: PropsWithChildren) {
  const [isMswReady, setIsMswReady] = useState(false);

  useEffect(() => {
    if (process.env.NEXT_PUBLIC_MSW_ENV !== "test") return;

    const enableMocking = async () => {
      const { worker } = await import("@/mocks/browser");
      await worker.start({
        onUnhandledRequest: "bypass",
      });
      setIsMswReady(true);
    };

    // @ts-expect-error msw not found
    if (!window.msw) {
      enableMocking();
    } else {
      setIsMswReady(true);
    }
  }, []);

  if (process.env.NEXT_PUBLIC_MSW_ENV !== "test") return children;

  if (!isMswReady) {
    return "loading msw worker...";
  }

  return <>{children}</>;
}

Basically, this waits until the mock worker is fully set up before rendering anything. That way, your app won't accidentally fire off real network requests before the mocks are ready.

To make this work across your entire app, just wrap your layout with it.

`layout.tsx`

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="en">
      <body className={`${geistSans.variable} ${geistMono.variable}`}>
        <MswWorker>{children}</MswWorker>
      </body>
    </html>
  );
}

Now if you restart the dev server, you should see your app serving mocked responses right away.

So that’s it — we’ve successfully mocked API calls from both the server and the client side. 🎉

Since both environments share the same set of handlers, we don’t need to worry about where a particular request is coming from. Whether it runs on the server during SSR or from the browser after hydration, our mocks stay consistent.

A Note on `instrumentation-client.ts`

One more thing worth mentioning: just like we used instrumentation.ts for server-side setup, there's also an instrumentation-client.ts file in Next.js that runs on the client before hydration starts.

In theory, we could load the MSW worker from there. Which sounds ideal, but after testing it out, I ran into some race conditions. Some API calls were firing before the worker was fully initialized, which kinda defeats the whole purpose of mocking.

At the time of writing this, clientInstrumentationHook is still an experimental feature. So until it's more stable (or there's a solid workaround), it’s safer to stick with loading the worker manually in a client-side component like MswWorker.tsx.

instrumentation-client.ts

Create this file at the root of your app directory:

if (process.env.NEXT_PUBLIC_MSW_ENV === 'test') {
  import('./mocks/browser')
    .then(async mod => {
      if (mod?.worker?.start) {
        mod.worker.start();
      }
    })
    .catch(async () => {
      console.error("Failed to load the browser module");
    });
}

⚠️ Important:

This file (instrumentation-client.ts) is executed before hydration, so avoid doing anything here that may block rendering or impact performance in production environments.

⚙️ Config Note:

Depending on your next js version, you might need to add the following to next.config.ts to enable this:

// next.config.ts
export const nextConfig = {
  experimental: {
    instrumentationHook: true,
    clientInstrumentationHook: true,
  },
};

How to Add Pre/post-Commit Hooks to Your Node.js Project

Ajith Kumar P M — Thu, 11 Apr 2024 18:51:24 +0000

As the project grows larger it's critical for the whole team to follow certain code quality and security standards. One way to ensure that is by using "git hooks".

Git hooks are scripts that run automatically every time a particular event occurs in a Git repository.

Numerous git hook managers are available for Node.js. Husky, pre-commit, and Lefthook are a few examples of such tools. We opted for Lefthook for this tutorial due to its capability to execute scripts concurrently and its simplicity.

So let's start!

Before each commit(pre-commit) we need to ensure the following.

No credentials leak: To ensure no secrets are accidentally exposed in the source.
No lint errors: The committed code does not contain any lint errors (eslint).
No formatting inconsistencies: The committed code should follow the organization's code formatting standards(prettier or pretty-quick).
No type errors: There shouldn't be any typescript errors.

And on each pre-push we need to ensure the following

No vulnerable packages: npm audit or pnpm audit --audit-level high
Standardized branch-names: we can usevalidate-branch-name

Apart from these we also need to enforce standards for all our commit messages(commit-lint).

GitLeaks

install gitleaks in your machine gitleaks

add the following changes to your package.json

{
   "scripts":{
+      "gitleaks": "gitleaks detect -v"
    }

}

Eslint

install and configure eslint with

npm init @eslint/config

add the following changes to your package.json

{
   "scripts":{
+      "lint": "eslint --ignore-path .gitignore \"{src,tests}/**/*.+(ts|js|tsx)\"",
    }

}

Typecheck

{
   "scripts":{
+      "typecheck": "tsc --noEmit",
    }

}

Prettier for code formatting

npm install --save-dev --save-exact prettier

Package.json

{
   "scripts":{
+      "format": "prettier --ignore-path .prettierignore --write \"**/*.+(js|ts|json|tsx|mdx)\" --log-level silent",
    }

}

Branch name validations

npm i validate-branch-name -D

Package.json

{
   "validate-branch-name": {
        "pattern": "^(feat|fix|hotfix|release|test|experimental)/.+$",
        "errorMsg": "Branch name validation failed"
    },

}

Commit lint for standardized commit messages

npm i @commitlint/cli -D
npm i @commitlint/config-conventional -D

create the file commitlint.config.js at the root

module.exports = {
    extends: ['@commitlint/config-conventional'], // => @commitlint/config-conventional
};

create the file .lefthook/commit-msg/commitlint.sh

echo $(head -n1 $1) | npx commitlint --color

Lefthook as githooks manager

// install lefthook
npm install lefthook --save-dev

# create a lefthook.yml file in the root
pre-commit:
  parallel: true
  commands:
    lint:
      glob: '*.{js,ts,jsx,tsx}' # glob filter for list of files
      run: npm run lint
    format:
      run: npm run format 
    types:
      glob: '*.{js,ts, jsx, tsx}'
      run: npm run typecheck
    gitLeaks:
      run: npm run gitleaks
pre-push:
  parallel: true
  commands:
    branchName:
      run: npx validate-branch-name
    packages-audit:
      tags: frontend security
      run: npm audit
commit-msg:
  parallel: true
  scripts:
    "commitlint.sh":
      runner: bash

package.json

{
   "scripts":{
+     "prepare": "lefthook install",
    }
}

Run lefthook install and try making your first commit.

Semantic DOS Attacks and Detection

Ajith Kumar P M — Tue, 25 Oct 2022 20:34:48 +0000

The global community now relies heavily on the Internet, making reliable Internet access a prerequisite for societal and economic development. When it comes to potential threats to online infrastructure, distributed denial-of-service (DDoS) attacks are among the most concerning.

Since DOS attackers employ a broad variety of techniques to achieve their goals, categorising these attacks accurately is a challenging task. Classification according to 1 is shown below.

We're especially curious about categorization. “EW: Exploited Weakness to Deny Service”
According to this a DOS can be categorized into following types.

EW-2: Brute-Force

Brute-force attacks are performed by initiating a vast amount of seemingly legitimate transactions. Since an intermediate network can usually deliver higher traffic volume than the victim network can handle, a high number of attack packets exhausts the victim’s resources.

EW-1: Semantic

Semantic attacks exploit a specific feature or implementation bug of some protocol or application installed at the victim in order to consume excess amounts of its resources.

The most common and classical practice for ddos is to flood the target application with numerous requests(EW-2), but These attacks may usually already be detected by sophisticated network-layer defence mechanisms. Most recently, DoS attacks have grown in complexity. Rather than relying on volume, attackers now use highly targeted and application-specific payloads to overwhelm their targets(EW-1). This article will be focusing on the second category since detection of such attacks are almost impossible with the traditional systems. TCP SYN attacks and ReDOS attacks are the most common in this category.
It is possible for us to find solutions for any one of such attacks for a specific environment. For instance we can detect ReDOS attacks to a python application from the application layer itself. But building a general purpose solution is difficult and almost impossible to achieve in the application layer. These days, most servers use Linux's containerization technologies, thus it's important that our solution is compatible with containers.

CODA 2 is an effort that aims to achieve these goals. And it ensures to

Works with applications written in any language
Supports monitoring containers while remaining invisible to them
Does not require familiarity with the app's source code.

CODA Models the CPU time consumed by legitimate connections within the application. When a new connection is established, CODA monitors the CPU time consumed by this connection and detects attacks through statistical methods. For Tracing it uses eBPF, A general-purpose execution engine in Linux kernel that can run sandboxed programs in an operating system kernel. The performance overhead introduced by CODA compared to the baseline performance of the tested servers is not high, adding about 0.7-5 milliseconds of latency. CODA is capable of detecting semantic DOS attacks with astonishing accuracy and impressively minimal performance overhead. Since it follows a context independent approach for detection, it can detect a wide variety of CPU-Exhaustion DOS attacks. The framework is far from perfect, as pointed out by the authors, since it measures the cpu-time based on the accept and close system calls, it cannot find cpu-time of UDP requests. Also the framework is using eBPF for implementation and hence it’s not possible for the system to work in other operating systems.

References

M. Zhan, Y. Li, H. Yang, G. Yu, B. Li and W. Wang, "Coda: Runtime Detection of Application-Layer CPU-Exhaustion DoS Attacks in Containers," in IEEE Transactions on Services Computing, 2022, doi: 10.1109/TSC.2022.3194266.
Jelena Mirkovic and Peter Reiher. 2004. A taxonomy of DDoS attack and DDoS defense mechanisms. SIGCOMM Comput. Commun. Rev. 34, 2 (April 2004), 39–53. https://doi.org/10.1145/997150.9971

How to set up and deploy a Django application on a Linux server

Ajith Kumar P M — Wed, 28 Jul 2021 14:16:47 +0000

Deploying a web application can seem daunting, but it's a manageable process with a structured approach. This guide walks you through setting up a secure Linux server and deploying your Django application using two popular stacks: Apache with mod_wsgi or Nginx with Gunicorn.

Note: The core principles in this guide remain best practices for modern Django deployments.

🔐 Step 1: Server Initialization & Security

A secure, well-configured server is the foundation of any deployment.

1.1. System Update

First, log into your new Linux server (e.g., Ubuntu, Debian) and ensure all system packages are up-to-date.

# On Debian/Ubuntu-based systems
sudo apt update && sudo apt upgrade -y

1.2. Create a Non-Root User

Running commands as root is a major security risk. Create a new user with administrative privileges instead.

# Create a new user (you'll be prompted for a password)
adduser your_username

# Add the new user to the 'sudo' group
usermod -aG sudo your_username

# Log out of root and log back in as your new user
exit

1.3. Harden SSH Access with Keys

Disable password-based logins in favor of more secure SSH keys.

On your local machine, generate a new SSH key pair.

ssh-keygen -t rsa -b 4096

Follow the prompts. Adding a passphrase is a good extra layer of security.

Next, copy your public key to the server. The easiest method is using ssh-copy-id.

ssh-copy-id your_username@your_server_ip

1.4. Disable Password & Root Login

On your server, edit the SSH daemon configuration.

sudo nano /etc/ssh/sshd_config

Find and modify these lines to enhance security:

PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Restart the SSH service to apply the changes.

sudo systemctl restart ssh

🚨 Critical: Before you close your current terminal, open a new one and confirm you can log in with your SSH key. If you can't, you'll be locked out! Revert the changes if it fails.

🔥 Step 2: Configure the Firewall with UFW

UFW (Uncomplicated Firewall) is an easy way to manage your server's network rules.

# Deny all incoming traffic and allow all outgoing by default
sudo ufw default deny incoming
sudo ufw default allow outgoing

# CRITICAL: Allow SSH access before enabling the firewall
sudo ufw allow ssh

# Allow HTTP and HTTPS traffic for your web app
sudo ufw allow http
sudo ufw allow https

# Enable the firewall
sudo ufw enable

You can check the status at any time with sudo ufw status.

📦 Step 3: Prepare Your Django Project

Get your project code and dependencies ready for the server.

3.1. Create `requirements.txt`

On your local machine, inside your project's virtual environment, generate a list of its Python dependencies.

pip freeze > requirements.txt

3.2. Transfer Project to Server

You can use scp for a simple copy or git for version-controlled projects.

Using scp (Secure Copy):

scp -r /path/to/local/project your_username@your_server_ip:~/

Using git (Recommended):

git clone your_repository_url

🐍 Step 4: Set Up a Python Virtual Environment

Isolate your project's dependencies from the system's Python packages on the server.

sudo apt install python3-pip python3-venv -y

# Navigate to your project directory
cd your_project_name

# Create a virtual environment named 'venv'
python3 -m venv venv

# Activate it
source venv/bin/activate

Your shell prompt will now be prefixed with (venv).

⚙️ Step 5: Install Dependencies & Configure Django

With the virtual environment active, install your packages and adjust your settings for production.

5.1. Install Packages

pip install -r requirements.txt

5.2. Adjust `settings.py`

Edit your project's settings.py file for production.

# your_project/settings.py

import os

# ... other settings ...

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = False

ALLOWED_HOSTS = ['your_server_ip', 'your_domain.com']

# Define the location for all static files
STATIC_ROOT = os.path.join(BASE_DIR, 'static_root')

5.3. Collect Static Files

Run Django's collectstatic command to gather all static assets (CSS, JS, images) into the STATIC_ROOT directory you just defined.

python manage.py collectstatic

🐘 Step 6: Set Up PostgreSQL Database

A robust database like PostgreSQL is essential for production.

6.1. Install PostgreSQL

sudo apt install postgresql postgresql-contrib -y

6.2. Create Database & User

Switch to the postgres user to create your database and a dedicated user for your app.

sudo -u postgres psql

Inside the psql shell, run these commands:

CREATE DATABASE myprojectdb;
CREATE USER myprojectuser WITH PASSWORD 'a_very_strong_password';

ALTER ROLE myprojectuser SET client_encoding TO 'utf8';
ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed';
ALTER ROLE myprojectuser SET timezone TO 'UTC';

GRANT ALL PRIVILEGES ON DATABASE myprojectdb TO myprojectuser;

-- Exit the psql shell
\q

6.3. Update `settings.py`

Update the DATABASES setting in settings.py with your new credentials.

# your_project/settings.py

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'myprojectdb',
        'USER': 'myprojectuser',
        'PASSWORD': 'a_very_strong_password',
        'HOST': 'localhost',
        'PORT': '', # Default is 5432
    }
}

Important: Don't hardcode passwords! We'll secure these credentials in Step 8. You'll also need to install the database adapter: pip install psycopg2-binary.

6.4. Run Migrations

Apply your project's database schema.

python manage.py migrate

🚀 Step 7: Configure a Production Web Server

Django's development server isn't for production. Choose one of the following setups.

Option A: Apache & `mod_wsgi`

A classic and powerful combination.

Install Packages:

sudo apt install apache2 libapache2-mod-wsgi-py3 -y
sudo a2enmod wsgi

Configure Apache Virtual Host: Create a new configuration file for your site.

sudo nano /etc/apache2/sites-available/your_project.conf

Paste and edit the following configuration.

<VirtualHost *:80>
    ServerName your_domain.com
    ServerAlias www.your_domain.com

    Alias /static /home/your_username/your_project_name/static_root
    <Directory /home/your_username/your_project_name/static_root>
        Require all granted
    </Directory>

    <Directory /home/your_username/your_project_name/your_project/ >
        <Files wsgi.py>
            Require all granted
        </Files>
    </Directory>

    WSGIDaemonProcess your_project python-home=/home/your_username/your_project_name/venv python-path=/home/your_username/your_project_name
    WSGIProcessGroup your_project
    WSGIScriptAlias / /home/your_username/your_project_name/your_project/wsgi.py
</VirtualHost>

Enable Site & Reload:

sudo a2ensite your_project.conf
sudo a2dissite 000-default.conf # Disable the default page
sudo systemctl restart apache2

Option B: Nginx & Gunicorn (Recommended)

A modern, high-performance stack. Nginx acts as a reverse proxy, passing requests to the Gunicorn application server.

Install Packages:

sudo apt install nginx -y
pip install gunicorn # Install inside your venv

Configure Nginx Server Block: Create a new Nginx configuration file.

sudo nano /etc/nginx/sites-available/your_project

Paste and edit the following. This tells Nginx to serve static files directly and proxy other requests to Gunicorn.

server {
    listen 80;
    server_name your_domain.com www.your_domain.com;

    location = /favicon.ico { access_log off; log_not_found off; }

    location /static/ {
        root /home/your_username/your_project_name;
    }

    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://unix:/run/gunicorn.sock;
    }
}

Enable Site & Reload:

sudo ln -s /etc/nginx/sites-available/your_project /etc/nginx/sites-enabled
sudo nginx -t # Test configuration for errors
sudo systemctl restart nginx

Create a systemd Service for Gunicorn: To ensure Gunicorn runs reliably and starts on boot, create a service file.

sudo nano /etc/systemd/system/gunicorn.service

Paste and edit the following.

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=your_username
Group=www-data
WorkingDirectory=/home/your_username/your_project_name
ExecStart=/home/your_username/your_project_name/venv/bin/gunicorn \
          --access-logfile - \
          --workers 3 \
          --bind unix:/run/gunicorn.sock \
          your_project.wsgi:application

[Install]
WantedBy=multi-user.target

Create a systemd Socket File:

sudo nano /etc/systemd/system/gunicorn.socket

```
[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target
```

Start and Enable Gunicorn:

sudo systemctl start gunicorn.socket
sudo systemctl enable gunicorn.socket

🤫 Step 8: Secure Environment Variables

Never store sensitive keys, passwords, or secrets directly in settings.py. Use environment variables. A clean way to manage this is with a .env file.

Install python-decouple:
```
pip install python-decouple
```

Create a .env file in your project's root directory (next to manage.py). Add this file to your .gitignore immediately!

# .env file
SECRET_KEY='your-django-secret-key-goes-here'
DEBUG=False
DATABASE_URL='postgres://myprojectuser:a_very_strong_password@localhost:5432/myprojectdb'
ALLOWED_HOSTS='.your_domain.com,your_server_ip'

Update settings.py to use decouple:

# your_project/settings.py
from decouple import config, Csv
import dj_database_url

# ...

SECRET_KEY = config('SECRET_KEY')
DEBUG = config('DEBUG', default=False, cast=bool)
ALLOWED_HOSTS = config('ALLOWED_HOSTS', cast=Csv())

# Database
DATABASES = {
    'default': dj_database_url.config(default=config('DATABASE_URL'))
}

✅ Final Step: Verification

Navigate to your server's IP address or domain name in your web browser. You should now see your live Django application!

Next Steps

HTTPS: Use Let's Encrypt to get a free SSL/TLS certificate. It's essential.
Backups: Set up a regular backup strategy for your database and user-uploaded files.
Logging & Monitoring: Configure logging to monitor application health and track errors.

Happy deploying!