At the end of this tutorial, you’ll have a web app that works and can be accessed through HTTP and HTTPS. It will have automatic restarts, proper database migrations, and a modern, responsive dashboard interface.

System Requirements and Prerequisites

Before starting, ensure you have:

• A Linux VPS (Ubuntu 24.04 LTS or RHEL 9/AlmaLinux 9)
• Root or sudo access
• At least 2GB RAM and 20GB storage
• SSH access configured
• A domain name or public IP address

Installing Node.js 20 LTS

Next.js 16 requires Node.js 20 or higher. Install using the NodeSource repository:

Ubuntu/Debian:

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt-get install -y nodejs

RHEL/CentOS/AlmaLinux:

curl -fsSL https://rpm.nodesource.com/setup_20.x | sudo bash -
sudo dnf install -y nodejs

Verify the installation:

node --version
npm --version

Expected output:

v20.11.1
10.2.4

Installing and Configuring PostgreSQL

Install PostgreSQL 14 or higher for your distribution:

Ubuntu/Debian:

sudo apt update
sudo apt install -y postgresql postgresql-contrib
sudo systemctl start postgresql
sudo systemctl enable postgresql

RHEL/CentOS/AlmaLinux:

sudo dnf install -y postgresql-server postgresql-contrib
sudo postgresql-setup --initdb
sudo systemctl start postgresql
sudo systemctl enable postgresql

Create the application database and user:

sudo -u postgres psql

Inside the PostgreSQL prompt:

CREATE DATABASE testapp_production;
CREATE USER appuser WITH PASSWORD 'AppPassword2024';
GRANT ALL PRIVILEGES ON DATABASE testapp_production TO appuser;
\q

Configure PostgreSQL to accept password authentication. Edit /var/lib/pgsql/data/pg_hba.conf (RHEL) or /etc/postgresql/14/main/pg_hba.conf (Ubuntu):

# Change peer to md5 for local connections
local   all             all                                     md5
host    all             all             127.0.0.1/32            md5

Restart PostgreSQL:

sudo systemctl restart postgresql

Test the connection:

PGPASSWORD=AppPassword2024 psql -U appuser -h localhost -d testapp_production -c "SELECT version();"

Expected output:

                                                version
--------------------------------------------------------------------------------------------------------
 PostgreSQL 14.10 (Ubuntu 14.10-0ubuntu0.22.04.1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit
(1 row)

Initializing the Next.js Project

Create a new Next.js project with TypeScript and Tailwind CSS:

npx create-next-app@latest nextjs-app --typescript --tailwind --app --no-src-dir
cd nextjs-app

Install core dependencies:

npm install @prisma/client@^5.22.0 next-auth@^4.24.13 bcrypt@^6.0.0 zod@^4.2.1 react-hook-form@^7.69.0
npm install -D prisma@^5.22.0 @types/bcrypt@^6.0.0

The package.json should include these versions:

{
  "dependencies": {
    "@prisma/client": "^5.22.0",
    "next-auth": "^4.24.13",
    "bcrypt": "^6.0.0",
    "next": "^16.1.1",
    "react": "^19.2.3",
    "tailwindcss": "^3.4.0"
  }
}

Setting Up Prisma ORM

Initialize Prisma with PostgreSQL:

npx prisma init

This creates prisma/schema.prisma. Configure the database schema:

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
}

model User {
  id            String    @id @default(cuid())
  email         String    @unique
  name          String?
  password      String
  createdAt     DateTime  @default(now())
  updatedAt     DateTime  @updatedAt
  posts         Post[]
}

model Post {
  id        String   @id @default(cuid())
  title     String
  content   String   @db.Text
  published Boolean  @default(false)
  authorId  String
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  author    User     @relation(fields: [authorId], references: [id], onDelete: Cascade)

  @@index([authorId])
}

Create the .env file with your database connection:

DATABASE_URL="postgresql://appuser:AppPassword2024@localhost:5432/testapp_production"
NEXTAUTH_SECRET="your-secret-key-here"
NEXTAUTH_URL="http://85.29.10.87"
NODE_ENV="production"

Generate a secure NextAuth secret:

openssl rand -base64 32

Output example:

NGFR39BFGxtN6018TnjC4RoyYC+FUnyaBRD+Ae6P79o=

Run the initial migration:

npx prisma migrate dev --name init

Expected output:

Environment variables loaded from .env
Prisma schema loaded from prisma/schema.prisma
Datasource "db": PostgreSQL database "testapp_production", schema "public" at "localhost:5432"

Applying migration `20240307103000_init`

The following migration(s) have been created and applied from new schema changes:

migrations/
  └─ 20240307103000_init/
    └─ migration.sql

Your database is now in sync with your schema.

✔ Generated Prisma Client (v5.22.0) to ./node_modules/@prisma/client in 169ms

Verify tables were created:

PGPASSWORD=AppPassword2024 psql -U appuser -h localhost -d testapp_production -c '\dt'

Output:

                List of relations
 Schema |        Name        | Type  |  Owner
--------+--------------------+-------+---------
 public | Post               | table | appuser
 public | User               | table | appuser
 public | _prisma_migrations | table | appuser
(3 rows)

Building the Application

Update package.json scripts for production:

"scripts": {
  "dev": "next dev",
  "build": "prisma generate && prisma migrate deploy && next build",
  "start": "next start -p 3000",
  "migrate:deploy": "prisma migrate deploy"
}

Build the application:

npm run build

Expected output excerpt:

▲ Next.js 16.1.1 (Turbopack)
- Environments: .env

  Creating an optimized production build ...
✓ Compiled successfully in 6.1s
  Running TypeScript ...
  Collecting page data using 3 workers ...
  Generating static pages using 3 workers (0/9) ...
✓ Generating static pages using 3 workers (9/9) in 292.3ms
  Finalizing page optimization ...

Route (app)
┌ ○ /
├ ƒ /api/auth/[...nextauth]
├ ƒ /dashboard
├ ○ /login
└ ○ /signup

ƒ  (Dynamic)  server-rendered on demand
○  (Static)   prerendered as static content

Installing and Configuring PM2

PM2 is a production process manager for Node.js applications with automatic restarts and monitoring.

Install PM2 globally:

sudo npm install -g pm2

Ubuntu/Debian:

sudo apt install -y pm2

RHEL/CentOS:

sudo npm install -g pm2

Create ecosystem.config.js in your project root:

module.exports = {
  apps: [{
    name: 'nextjs-app',
    script: 'npm',
    args: 'start',
    instances: 1,
    exec_mode: 'fork',
    env: {
      NODE_ENV: 'production',
      PORT: 3000
    }
  }]
};

Start the application with PM2:

pm2 start ecosystem.config.js

Output:

[PM2] Starting npm in fork mode (1 instance)
[PM2] Done.
┌────┬───────────────┬─────────────┬─────────┬─────────┬──────────┬────────┬──────┬───────────┬──────────┬──────────┐
│ id │ name          │ namespace   │ version │ mode    │ pid      │ uptime │ ↺    │ status    │ cpu      │ mem      │
├────┼───────────────┼─────────────┼─────────┼─────────┼──────────┼────────┼──────┼───────────┼──────────┼──────────┤
│ 0  │ nextjs-app    │ default     │ N/A     │ fork    │ 25018    │ 0s     │ 0    │ online    │ 0%       │ 56.3mb   │
└────┴───────────────┴─────────────┴─────────┴─────────┴──────────┴────────┴──────┴───────────┴──────────┴──────────┘

Save the PM2 process list and configure auto-start on system boot:

pm2 save
pm2 startup systemd -u yourusername --hp /home/yourusername

The output provides a command to run with sudo:

sudo env PATH=$PATH:/usr/bin pm2 startup systemd -u devopslinx --hp /home/devopslinx

Verify PM2 status:

pm2 list

View real-time logs:

pm2 logs nextjs-app --lines 50

Output example:

0|nextjs-a | ▲ Next.js 16.1.1
0|nextjs-a | - Local:         http://localhost:3000
0|nextjs-a | - Network:       http://85.29.10.87:3000
0|nextjs-a |
0|nextjs-a | ✓ Starting...
0|nextjs-a | ✓ Ready in 246ms

Configuring Nginx Reverse Proxy

Install Nginx:

Ubuntu/Debian:

sudo apt install -y nginx

RHEL/CentOS:

sudo dnf install -y nginx
sudo systemctl start nginx
sudo systemctl enable nginx

Create Nginx configuration at /etc/nginx/sites-available/nextjs-app:

server {
    listen 80;
    listen [::]:80;
    server_name 85.29.10.87;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $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_cache_bypass $http_upgrade;
    }
}

Enable the site (Ubuntu/Debian):

sudo ln -s /etc/nginx/sites-available/nextjs-app /etc/nginx/sites-enabled/
sudo rm /etc/nginx/sites-enabled/default

For RHEL/CentOS, place the config in /etc/nginx/conf.d/nextjs-app.conf.

Test Nginx configuration:

sudo nginx -t

Output:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Reload Nginx:

sudo systemctl reload nginx

Configuring the Firewall

Allow HTTP traffic through the firewall:

Ubuntu (UFW):

sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw status

Output:

Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                   # SSH
80/tcp                     ALLOW       Anywhere                   # HTTP
443/tcp                    ALLOW       Anywhere                   # HTTPS

RHEL/CentOS (firewalld):

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Test the application:

curl -I http://85.29.10.87

Expected response:

HTTP/1.1 200 OK
Server: nginx/1.24.0 (Ubuntu)
Content-Type: text/html; charset=utf-8
X-Powered-By: Next.js

Performance Monitoring

Monitor PM2 processes in real-time:

pm2 monit

This displays:

• CPU usage per process
• Memory consumption
• Process uptime
• Real-time logs

Check application metrics:

pm2 show nextjs-app

Output includes:

Describing process with id 0 - name nextjs-app
┌───────────────────┬─────────────────────────────────────────────────┐
│ status            │ online                                          │
│ name              │ nextjs-app                                      │
│ namespace         │ default                                         │
│ version           │ N/A                                             │
│ restarts          │ 4                                               │
│ uptime            │ 8h                                              │
│ entire log path   │ /home/devopslinx/nextjs-app/logs/combined-0.log │
│ script path       │ /usr/bin/npm                                    │
│ script args       │ start                                           │
│ error log path    │ /home/devopslinx/nextjs-app/logs/err-0.log      │
│ out log path      │ /home/devopslinx/nextjs-app/logs/out-0.log      │
│ pid path          │ /home/devopslinx/.pm2/pids/nextjs-app-0.pid     │
│ interpreter       │ /usr/bin/node                                   │
│ interpreter args  │ N/A                                             │
│ script id         │ 0                                               │
│ exec cwd          │ /home/devopslinx/nextjs-app                     │
│ exec mode         │ fork_mode                                       │
│ node.js version   │ 20.19.6                                         │
│ node env          │ production                                      │
│ watch & reload    │ ✘                                               │
│ unstable restarts │ 0                                               │
└───────────────────┴─────────────────────────────────────────────────┘

Conclusion

You now have a production-ready Next.js full-stack app running on a Linux VPS with a PostgreSQL database, NextAuth authentication, PM2 process management, and an Nginx reverse proxy. The app restarts on crashes, survives server reboots, and serves traffic on HTTP port 80.

Major achievements are correct database migrations, secure authentication flow, process monitoring with PM2, and professional reverse proxy setup. For production, add SSL/TLS certificates with Let’s Encrypt, database backups, and monitoring with Prometheus and Grafana.

I have been in charge of production deployments for years, and I have learned that the key is not just knowing the commands but also understanding the workflow. Today, I’m going to show you step by step how I update a working Node.js and React app without missing a single request. We will be using a functioning Todo app that runs on an operational VPS, and I’ll show you how to do it all.

This guide will help you sleep better at night, whether you’re fixing a bug quickly or adding a big new feature.

Understanding Your Production-like Environment

Before we do anything in production, let’s take a minute to get acquainted about what we’re working with. This is the stack we have to work with:

• Nginx on port 80 – and handles incoming traffic and serves our React files.
• Node.js Backend – on port 5000 is our Express API, which is kept running by PM2.
• React Frontend – is made up of static files built with Vite. PostgreSQL stores all of our data.
• PostgreSQL – stores all of our data.
• PM2 – the underrated hero that makes everything work.

Nginx is like your front door, and React is like your living room that guests see. Your kitchen is Node.js where the real work gets done, and PostgreSQL is your storage room. PM2? That’s your security system making sure the kitchen is always open.

Let’s Checkout What’s Running

First, connect to your server using SSH. I’m using my VPS at 85.29.10.87:

ssh devopslinx@85.29.10.87

Now, let’s check what processes are actually running:

ps aux | grep -E 'node|nginx|postgres' | grep -v grep

Here’s what I see on my server:

postgres 1620071  0.0  0.3 223252 31360 ?        Ss   Mar02   0:16 /usr/lib/postgresql/16/bin/postgres -D /var/lib/postgresql/16/main
devopsl+ 1621070  0.2  0.8 11786920 72380 ?      Ssl  Mar02   8:36 node /home/devopslinx/todo-app/backend/server.js
root     1621722  0.0  0.0  11160  1976 ?        Ss   Mar02   0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data 1621723  0.0  0.0  12880  4920 ?        S    Mar02   0:00 nginx: worker process

PostgreSQL is humming along (PID 1620071), my Node.js backend is running (PID 1621070), and Nginx has its master and worker processes ready to handle traffic.

Now let’s check PM2 – this is where the magic happens:

pm2 list

┌────┬─────────────┬─────────────┬─────────┬─────────┬──────────┬────────┬──────┬───────────┬──────────┬──────────┬──────────┬──────────┐
│ id │ name        │ namespace   │ version │ mode    │ pid      │ uptime │ ↺    │ status    │ cpu      │ mem      │ user     │ watching │
├────┼─────────────┼─────────────┼─────────┼─────────┼──────────┼────────┼──────┼───────────┼──────────┼──────────┼──────────┼──────────┤
│ 0  │ todo-api    │ default     │ 1.0.0   │ fork    │ 1621070  │ 2D     │ 0    │ online    │ 0%       │ 70.2mb   │ devopsl… │ disabled │
└────┴─────────────┴─────────────┴─────────┴─────────┴──────────┴────────┴──────┴───────────┴──────────┴──────────┴──────────┴──────────┘

Perfect! The app has been running for 2 days straight with zero restarts (see that ↺ column?). This is the baseline we want to maintain.

Quick sanity check on the app structure:

ls -la ~/todo-app/

total 16
drwxr-xr-x 4 devopslinx devopslinx 4096 Mar 02 02:27 .
drwxr-xr-x 9 devopslinx devopslinx 4096 Mar 02 02:30 ..
drwxr-xr-x 3 devopslinx devopslinx 4096 Mar 02 05:28 backend
drwxr-xr-x 3 devopslinx devopslinx 4096 Mar 02 05:26 frontend

Let’s verify the database is responding:

PGPASSWORD=todopass123 psql -h localhost -U todouser -d tododb -c 'SELECT COUNT(*) FROM todos;'

 count
-------
     3
(1 row)

And finally, let’s ping the API to make sure it’s responding:

curl -s http://localhost:5000/api/health

{"status":"OK","message":"Server is running"}

Alright, everything looks good. We’re ready to deploy some changes.

Deploying Backend Changes (The Safe Way)

Here’s where most people mess up. They SSH in, edit the file, restart the server, and hope for the best. Don’t do that. Let me show you the professional approach.

Step 1: Always Backup First

I cannot stress this enough – ALWAYS backup before you touch production code. I’ve been saved by backups more times than I care to admit:

cd ~/todo-app/backend
cp server.js server.js.backup.$(date +%Y%m%d-%H%M%S)

Let’s verify it worked:

ls -lh server.js*

-rwxr-xr-x 1 devopslinx devopslinx 3.3K Mar 02 02:30 server.js
-rwxr-xr-x 1 devopslinx devopslinx 3.3K Mar 02 10:45 server.js.backup.20240302-104523

Good. Now if something goes wrong, we have a timestamped backup we can quickly restore.

Step 2: Making the Code Change

For this example, I’m adding a statistics endpoint to the API. Let’s see what we’re working with first:

head -20 ~/todo-app/backend/server.js

const express = require('express');
const cors = require('cors');
const pool = require('./db');
require('dotenv').config();

const app = express();
const PORT = process.env.PORT || 5000;

app.use(cors());
app.use(express.json());

// Health check endpoint
app.get('/api/health', (req, res) => {
  res.json({ status: 'OK', message: 'Server is running' });
});

// Get all todos
app.get('/api/todos', async (req, res) => {
  try {

Now I’ll add my new endpoint. First, let me create the code snippet:

cat > /tmp/stats_endpoint.txt << 'EOF'

// Get todo statistics
app.get('/api/stats', async (req, res) => {
  try {
    const stats = await pool.query(
      'SELECT COUNT(*) as total, SUM(CASE WHEN completed = true THEN 1 ELSE 0 END) as completed, SUM(CASE WHEN completed = false THEN 1 ELSE 0 END) as pending FROM todos'
    );

    res.json({
      total: parseInt(stats.rows[0].total),
      completed: parseInt(stats.rows[0].completed),
      pending: parseInt(stats.rows[0].pending)
    });
  } catch (err) {
    console.error(err.message);
    res.status(500).json({ error: 'Server error' });
  }
});
EOF

Now I’ll insert it into the server file right after the health check:

head -15 server.js > /tmp/server_new.js && \
echo "" >> /tmp/server_new.js && \
cat /tmp/stats_endpoint.txt >> /tmp/server_new.js && \
echo "" >> /tmp/server_new.js && \
tail -n +16 server.js >> /tmp/server_new.js && \
mv /tmp/server_new.js server.js

Let’s double-check the new code is in there:

head -35 server.js

const express = require('express');
const cors = require('cors');
const pool = require('./db');
require('dotenv').config();

const app = express();
const PORT = process.env.PORT || 5000;

app.use(cors());
app.use(express.json());

// Health check endpoint
app.get('/api/health', (req, res) => {
  res.json({ status: 'OK', message: 'Server is running' });
});

// Get todo statistics
app.get('/api/stats', async (req, res) => {
  try {
    const stats = await pool.query(
      'SELECT COUNT(*) as total, SUM(CASE WHEN completed = true THEN 1 ELSE 0 END) as completed, SUM(CASE WHEN completed = false THEN 1 ELSE 0 END) as pending FROM todos'
    );

    res.json({
      total: parseInt(stats.rows[0].total),
      completed: parseInt(stats.rows[0].completed),
      pending: parseInt(stats.rows[0].pending)
    });
  } catch (err) {
    console.error(err.message);
    res.status(500).json({ error: 'Server error' });
  }
});

Perfect! The new endpoint is in place.

Step 3: The Zero-Downtime Reload

This is the part that used to scare me until I learned about PM2’s reload feature. Unlike restart, which just kills and restarts your app (causing downtime), reload is graceful. Here’s what happens:

1. PM2 starts a new instance of your app
2. Waits for it to be ready
3. Routes new traffic to the new instance
4. Gracefully shuts down the old instance
5. Your users never see an error

Watch this:

pm2 reload todo-api

Use --update-env to update environment variables
[PM2] Applying action reloadProcessId on app [todo-api](ids: [ 0 ])
[PM2] [todo-api](0) ✓

That checkmark is what you want to see. Now let’s verify:

pm2 status

┌────┬─────────────┬─────────────┬─────────┬─────────┬──────────┬────────┬──────┬───────────┬──────────┬──────────┬──────────┬──────────┐
│ id │ name        │ namespace   │ version │ mode    │ pid      │ uptime │ ↺    │ status    │ cpu      │ mem      │ user     │ watching │
├────┼─────────────┼─────────────┼─────────┼─────────┼──────────┼────────┼──────┼───────────┼──────────┼──────────┼──────────┼──────────┤
│ 0  │ todo-api    │ default     │ 1.0.0   │ fork    │ 1703070  │ 9s     │ 1    │ online    │ 0%       │ 58.5mb   │ devopsl… │ disabled │
└────┴─────────────┴─────────────┴─────────┴─────────┴──────────┴────────┴──────┴───────────┴──────────┴──────────┴──────────┴──────────┘

See what happened?
– PID changed from 1621070 to 1703070 (we got a fresh process)
– Uptime reset to 9 seconds (brand new instance)
– Restart counter went from 0 to 1
– Status stayed online the entire time

That’s zero-downtime deployment in action.

Step 4: Testing the Changes

Never assume the deployment worked. Always test:

curl -s http://localhost:5000/api/stats

{"total":3,"completed":0,"pending":3}

Excellent! The new endpoint works. But wait – that’s just the backend. Let’s make sure it’s accessible through Nginx:

curl -s http://85.29.10.87/api/stats

{"total":3,"completed":0,"pending":3}

Perfect! And let’s verify we didn’t break anything:

curl -s http://85.29.10.87/api/health

{"status":"OK","message":"Server is running"}

All good. Now check the logs to make sure there are no hidden errors:

pm2 logs todo-api --lines 20 --nostream

[TAILING] Tailing last 20 lines for [todo-api] process
/home/devopslinx/.pm2/logs/todo-api-error.log last 20 lines:
/home/devopslinx/.pm2/logs/todo-api-out.log last 20 lines:
0|todo-api | Server is running on port 5000
0|todo-api | Server is running on port 5000

Clean logs, no errors. This is a successful deployment.

Step 5: Monitor for a Bit

I like to keep an eye on the app for a few minutes after deployment. PM2 makes this easy:

pm2 monit

This opens a real-time dashboard showing CPU, memory, and logs. Press Ctrl+C when you’re satisfied everything is stable.

You can also check detailed process info:

pm2 show todo-api

Describing process with id 0 - name todo-api
┌───────────────────┬──────────────────────────────────────────────────┐
│ status            │ online                                           │
│ name              │ todo-api                                         │
│ restarts          │ 1                                                │
│ uptime            │ 5m                                               │
│ script path       │ /home/devopslinx/todo-app/backend/server.js      │
│ script args       │ N/A                                              │
│ error log path    │ /home/devopslinx/.pm2/logs/todo-api-error.log    │
│ out log path      │ /home/devopslinx/.pm2/logs/todo-api-out.log      │
│ pid path          │ /home/devopslinx/.pm2/pids/todo-api-0.pid        │
│ mode              │ fork_mode                                        │
└───────────────────┴──────────────────────────────────────────────────┘

Everything looks solid. Deployment complete!

Deploying Frontend Changes

Frontend deployments are actually simpler than backend because there’s no process to restart. Nginx serves static files, so we just need to upload new ones.

Step 1: Build on Your Local Machine

On your development machine, make your React changes and build:

cd /path/to/your/local/todo-frontend
npm run build

vite v4.5.0 building for production...
✓ 342 modules transformed.
dist/index.html                   0.45 kB │ gzip:  0.30 kB
dist/assets/index-DCTgUJ87.css    4.01 kB │ gzip:  1.24 kB
dist/assets/index-5F_pVDlP.js   196.25 kB │ gzip: 63.45 kB
✓ built in 3.42s

Your optimized production files are now in the dist/ folder.

Step 2: Backup Current Frontend

On the server, create a backup:

cd ~/todo-app
cp -r frontend frontend.backup.$(date +%Y%m%d-%H%M%S)

Verify:

ls -ld frontend*

drwxr-xr-x 3 devopslinx devopslinx 4096 Mar 02 05:26 frontend
drwxr-xr-x 3 devopslinx devopslinx 4096 Mar 02 11:15 frontend.backup.20240302-111530

Step 3: Upload the New Build

From your local machine, use scp to upload:

scp -r dist/* devopslinx@85.29.10.87:~/todo-app/frontend/

index.html                                    100%  455     8.2KB/s   00:00
index-DCTgUJ87.css                            100% 4013    72.1KB/s   00:00
index-5F_pVDlP.js                             100%  196KB   3.2MB/s   00:00
vite.svg                                      100% 1497    27.5KB/s   00:00

Or if you prefer rsync (I do, because it’s faster for updates):

rsync -avz --delete dist/ devopslinx@85.29.10.87:~/todo-app/frontend/

sending incremental file list
./
index.html
assets/
assets/index-DCTgUJ87.css
assets/index-5F_pVDlP.js

sent 201,245 bytes  received 92 bytes  134,224.67 bytes/sec
total size is 200,712  speedup is 1.00

Step 4: Verify the Upload

Back on the server, check the files:

ls -lah ~/todo-app/frontend/

total 20K
drwxr-xr-x 3 devopslinx devopslinx 4.0K Mar 02 11:18 .
drwxr-xr-x 4 devopslinx devopslinx 4.0K Mar 02 02:27 ..
drwxr-xr-x 2 devopslinx devopslinx 4.0K Mar 02 11:18 assets
-rw-r--r-- 1 devopslinx devopslinx  455 Mar 02 11:18 index.html
-rw-r--r-- 1 devopslinx devopslinx 1.5K Mar 02 11:18 vite.svg

Test that Nginx is serving the new files:

curl -I http://85.29.10.87/

HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Sat, 02 Mar 2024 11:20:15 GMT
Content-Type: text/html
Content-Length: 455
Last-Modified: Sat, 02 Mar 2024 11:18:42 GMT
Connection: keep-alive
ETag: "676d8b82-1c7"
Accept-Ranges: bytes

The Last-Modified timestamp matches our upload time – Nginx is serving the new files immediately. No restart needed!

Step 5: Clear Browser Cache

Here’s a gotcha that trips up a lot of people: browsers cache static files aggressively. Your users might not see the changes right away. To force a refresh:

• Chrome/Firefox: Ctrl+Shift+R (Windows/Linux) or Cmd+Shift+R (Mac)
• Or open in incognito/private mode

Pro tip: Vite automatically generates hashed filenames (like index-5F_pVDlP.js) which acts as cache-busting. When you change the code and rebuild, the filename changes, forcing browsers to download the new version.

Database Migrations (Proceed with Caution)

Database changes are where things can really go wrong if you’re not careful. Here’s my battle-tested approach:

Step 1: Backup, Backup, Backup

Did I mention you should backup? Because you should REALLY backup before touching the database:

pg_dump -h localhost -U todouser tododb > ~/backup_$(date +%Y%m%d_%H%M%S).sql

Verify it:

ls -lh ~/backup_*.sql | tail -1

-rw-rw-r-- 1 devopslinx devopslinx 99K Mar 02 11:25 backup_20240302_112530.sql

Step 2: Test in a Safe Environment First

Never test migrations directly in production. Create a test database:

PGPASSWORD=todopass123 psql -h localhost -U todouser -d tododb -c 'CREATE DATABASE tododb_test TEMPLATE tododb;'

Test your migration there first, make sure it works, then proceed.

Step 3: Run the Migration

Connect to the production database:

PGPASSWORD=todopass123 psql -h localhost -U todouser -d tododb

Let’s say we’re adding a priority field to todos:

ALTER TABLE todos ADD COLUMN priority VARCHAR(20) DEFAULT 'medium';

ALTER TABLE

Verify the change:

\d todos

                                        Table "public.todos"
   Column    |            Type             | Collation | Nullable |              Default
-------------+-----------------------------+-----------+----------+-----------------------------------
 id          | integer                     |           | not null | nextval('todos_id_seq'::regclass)
 title       | character varying(255)      |           | not null |
 description | text                        |           |          |
 completed   | boolean                     |           |          | false
 created_at  | timestamp without time zone |           |          | CURRENT_TIMESTAMP
 priority    | character varying(20)       |           |          | 'medium'::character varying

Exit PostgreSQL:

\q

Step 4: Update Code if Needed

If your schema change requires code updates, deploy those backend changes using the PM2 reload workflow we covered earlier.

The beauty of adding a column with a DEFAULT value is that it’s backward compatible – the existing code keeps working while the new code can start using the new field.

Step 5: Verify Everything Works

Query the updated table:

PGPASSWORD=todopass123 psql -h localhost -U todouser -d tododb -c 'SELECT id, title, priority FROM todos LIMIT 3;'

 id |        title        | priority
----+---------------------+----------
  1 | Welcome to Todo App | medium
  2 | Learn React         | medium
  3 | Learn Node.js       | medium
(3 rows)

All existing todos got the default value. Perfect!

When Things Go Wrong: Rollback Procedures

Let’s face it – sometimes deployments don’t go as planned. Here’s how to quickly recover.

Rolling Back Backend Code

Restore your backup:

cd ~/todo-app/backend
cp server.js.backup.20240302-104523 server.js
pm2 reload todo-api

Test to make sure the rollback worked:

curl -s http://localhost:5000/api/stats

If you get a 404 error, the rollback succeeded (assuming /api/stats was the new endpoint you added).

Rolling Back Frontend

Delete the new files and restore the backup:

cd ~/todo-app
rm -rf frontend/*
cp -r frontend.backup.20240302-111530/* frontend/

Force refresh your browser to see the old version.

Rolling Back Database Changes

Restore from your backup:

PGPASSWORD=todopass123 psql -h localhost -U todouser -d tododb < ~/backup_20240302_112530.sql

For simple schema changes, you can revert manually:

PGPASSWORD=todopass123 psql -h localhost -U todouser -d tododb -c 'ALTER TABLE todos DROP COLUMN priority;'

Essential PM2 Commands (Your Daily Toolkit)

Here are the PM2 commands I use most often:

Deployment Commands

Zero-downtime reload (my go-to for deployments):

pm2 reload todo-api

Quick restart with brief downtime:

pm2 restart todo-api

Restart and update environment variables:

pm2 restart todo-api --update-env

Stop the application:

pm2 stop todo-api

Start it back up:

pm2 start todo-api

Monitoring Commands

Watch logs in real-time:

pm2 logs todo-api

View last 50 log lines:

pm2 logs todo-api --lines 50 --nostream

Real-time CPU and memory monitoring:

pm2 monit

Detailed process information:

pm2 show todo-api

List all processes:

pm2 list

Log Management

View only errors:

pm2 logs todo-api --err

View only output:

pm2 logs todo-api --out

Clear all logs:

pm2 flush

Process Management

Save current process list:

pm2 save

Restore saved processes:

pm2 resurrect

Remove process from PM2:

pm2 delete todo-api

Troubleshooting Real Deployment Issues

Let me share three problems I’ve actually encountered and how I solved them.

Problem 1: PM2 Reload Fails Immediately

So you run pm2 reload todo-api and instead of seeing that beautiful checkmark, your app shows “errored”. Here’s what I do:

Check the status:

pm2 status

┌────┬─────────────┬─────────────┬─────────┬─────────┬──────────┬────────┬──────┬───────────┬──────────┬──────────┬──────────┬──────────┐
│ id │ name        │ namespace   │ version │ mode    │ pid      │ uptime │ ↺    │ status    │ cpu      │ mem      │ user     │ watching │
├────┼─────────────┼─────────────┼─────────┼─────────┼──────────┼────────┼──────┼───────────┼──────────┼──────────┼──────────┼──────────┤
│ 0  │ todo-api    │ default     │ 1.0.0   │ fork    │ 0        │ 0      │ 15   │ errored   │ 0%       │ 0b       │ devopsl… │ disabled │
└────┴─────────────┴─────────────┴─────────┴─────────┴──────────┴────────┴──────┴───────────┴──────────┴──────────┴──────────┴──────────┘

That restart counter at 15 tells me PM2 is repeatedly trying to start the app but it keeps crashing. Time to check the logs:

pm2 logs todo-api --lines 30 --nostream

0|todo-api | Error: Cannot find module 'express'
0|todo-api |     at Function.Module._resolveFilename (internal/modules/cjs/loader.js:815:15)

Ah! Missing dependencies. This usually happens when you pull code changes but forget to run npm install:

cd ~/todo-app/backend
npm install
pm2 restart todo-api

Problem solved.

Problem 2: New Endpoint Returns 502 Bad Gateway

You deployed the new code, PM2 shows online, but hitting the endpoint gives you a 502 error. Frustrating, right?

First, test the backend directly:

curl -v http://localhost:5000/api/stats

If this works but http://85.29.10.87/api/stats returns 502, the issue is with Nginx, not your code.

Check the Nginx error logs:

sudo tail -f /var/log/nginx/error.log

2024/03/02 11:45:23 [error] 1621723#1621723: *234 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.12.10, server: 85.29.10.87, request: "GET /api/stats HTTP/1.1", upstream: "http://127.0.0.1:5000/api/stats"

“Connection refused” means Nginx can’t connect to your backend. Let’s check if Node.js is actually listening:

pm2 status
sudo ss -tlnp | grep :5000

If port 5000 isn’t listening, your backend crashed. Restart it:

pm2 restart todo-api

Problem 3: Users Still See Old Frontend

You deployed new frontend files but users are complaining they don’t see the changes. I’ve been there!

Solution 1: Browser cache is the most common culprit. Have them hard refresh with Ctrl+Shift+R.

Solution 2: Verify the files actually uploaded. SSH into the server:

ls -lah ~/todo-app/frontend/index.html

Check the timestamp. If it’s old, your upload didn’t work. Try uploading again.

Solution 3: Make sure Nginx is pointing to the right directory:

sudo grep "root" /etc/nginx/sites-enabled/todo-app

Should show:

        root /home/devopslinx/todo-app/frontend;

If the path is wrong, fix the Nginx config and reload:

sudo systemctl reload nginx

Best Practices I’ve Learned the Hard Way

Use Version Control

Don’t edit files directly on the server and hope for the best. Use Git:

git add .
git commit -m "Add statistics endpoint"
git push origin main

On the server:

cd ~/todo-app/backend
git pull origin main
pm2 reload todo-api

This gives you a proper audit trail and makes rollbacks trivial.

Implement Health Checks

Before declaring victory, verify the deployment actually works. I use a simple script:

#!/bin/bash
# health-check.sh

if curl -s http://localhost:5000/api/health | grep -q "OK"; then
    echo "✓ Health check passed"
    exit 0
else
    echo "✗ Health check failed"
    exit 1
fi

Run it after deployment:

bash health-check.sh && echo "Deployment successful"

Monitor Resource Usage

After deploying, keep an eye on memory and CPU:

pm2 monit

Or watch status updates:

watch -n 2 'pm2 status'

Sometimes new code is less efficient than you thought.

Use Staged Deployments

For critical apps, deploy to staging first:

# Deploy to staging
pm2 start server.js --name todo-api-staging --env staging

# Test thoroughly
curl http://localhost:5001/api/stats

# If all good, deploy to production
pm2 reload todo-api

Automate Common Tasks

Create a deployment script to avoid mistakes:

#!/bin/bash
# deploy.sh

echo "Starting deployment..."

# Backup
cp server.js server.js.backup.$(date +%Y%m%d-%H%M%S)

# Pull latest code
git pull origin main

# Install dependencies
npm install --production

# Reload application
pm2 reload todo-api

# Health check
sleep 3
if curl -s http://localhost:5000/api/health | grep -q "OK"; then
    echo "✓ Deployment successful"
else
    echo "✗ Deployment failed, rolling back"
    cp server.js.backup.* server.js
    pm2 reload todo-api
    exit 1
fi

Make it executable:

chmod +x deploy.sh
./deploy.sh

Wrapping Up

Deployments don’t have to be scary, you know. The most important thing is to have a good workflow and stick to it:

1. Always backup before making any changes in production.
2. Use PM2 reload for backend updates with no downtime.
3. Test immediately after deployment, don’t assume it worked.
4. Monitor logs for at least a few minutes after deployment
5. Know how to rollback quickly to where you were when things go wrong.

You can update your Node.js backend without losing any requests with PM2’s reload feature. Nginx serves static files directly, so changes to the frontend happen right away. And if you have the right backups, your system will always be up and running in less than 30 seconds.

I’ve been using this process for years in dozens of production apps. It has saved me from a lot of sleepless nights and having to roll back things in a hurry. I hope it does the same for you.

Happy deployment!

What is systemd?

Systemctl is the main command for working with systemd. It controls the systemd system and service manager. Unit files with the .service extension define services in systemd. These files are usually found in /lib/systemd/system/ or /etc/systemd/system/.

systemd is an init system and system manager that is now the standard for most major Linux distributions, such as RHEL, CentOS, Ubuntu, and Debian. It took the place of older init systems like SysV init and Upstart. It has advanced dependency management, the ability to start services in parallel, and the ability to activate services on demand.

Installing and checking systemd

Most modern versions of Linux already have systemd installed. You can check the version and installation of systemd on your computer:

systemctl --version

Sample output:

systemd 249 (249.11-0ubuntu3.12)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

To check if systemd is running as PID 1 (the init process):

ps -p 1

Output:

PID TTY          TIME CMD
  1 ?        00:00:12 systemd

Basic systemd Commands

Starting and Stopping Services

To start a service immediately:

sudo systemctl start nginx

To stop a running service:

sudo systemctl stop nginx

To restart a service (stops and starts):

sudo systemctl restart apache2

To reload the configuration without stopping the service:

sudo systemctl reload nginx

If you’re not sure if a service supports reload, use this:

sudo systemctl reload-or-restart mysql

Turning Services On and Off

Enabling a service sets it up so that it starts up automatically when the computer boots up:

sudo systemctl enable nginx

Output:

Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /lib/systemd/system/nginx.service.

To disable automatic startup:

sudo systemctl disable apache2

You can enable and start a service in one command:

sudo systemctl enable --now mysql

Checking Service Status

The status command gives you a lot of information about a service:

systemctl status sshd

Sample output for a running service:

● sshd.service - OpenSSH server daemon
     Loaded: loaded (/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2024-12-16 09:23:14 UTC; 2 days ago
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 1842 (sshd)
      Tasks: 1 (limit: 4615)
     Memory: 5.2M
        CPU: 1.234s
     CGroup: /system.slice/sshd.service
             └─1842 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

Dec 16 09:23:14 webserver systemd[1]: Starting OpenSSH server daemon...
Dec 16 09:23:14 webserver sshd[1842]: Server listening on 0.0.0.0 port 22.
Dec 16 09:23:14 webserver sshd[1842]: Server listening on :: port 22.
Dec 16 09:23:14 webserver systemd[1]: Started OpenSSH server daemon.

Key fields explained:

• Loaded: Shows unit file location and whether service is enabled
• Active: Current running state with uptime
• Main PID: Process ID of the main service process
• Tasks: Number of running tasks/threads
• Memory/CPU: Resource usage
• CGroup: Control group hierarchy
• Log entries: Recent systemd journal entries

To check if a service is active:

systemctl is-active nginx

Output: active or inactive

To check if a service is enabled:

systemctl is-enabled nginx

Output: enabled, disabled, or static

List all running services:

systemctl list-units --type=service --state=running

List all services (running and stopped):

systemctl list-units --type=service --all

Structure of a Service Unit

Service Unit Structure

The three main parts of a basic service unit file are [Unit], [Service], and [Install]. For a custom web app, here’s an example:

cat /etc/systemd/system/myapp.service

[Unit]
Description=My Web Application
After=network.target mysql.service
Requires=mysql.service

[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/node /opt/myapp/server.js
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Key directives explained:

• After: Makes sure the service starts after the specified units
• Requires: Hard dependency—if the dependency fails, the service won’t start.
• Type: The type of service (simple, forking, oneshot, notify, or dbus)
• ExecStart: The command to start the service
• Restart: When to restart (never, always, when something goes wrong, or when something goes wrong)
• WantedBy: Target that should have this service

Generating Custom Services

Let’s make a custom service for a Python application:

sudo nano /etc/systemd/system/python-api.service

Content:

[Unit]
Description=Python REST API Service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=apiuser
WorkingDirectory=/opt/python-api
Environment="PATH=/opt/python-api/venv/bin"
ExecStart=/opt/python-api/venv/bin/python app.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

After creating the unit file, reload systemd and start the service:

sudo systemctl daemon-reload
sudo systemctl start python-api
sudo systemctl enable python-api

Verify the service is running:

systemctl status python-api

Advanced systemd Operations

Managing Dependencies

View service dependencies:

systemctl list-dependencies nginx

Output:

nginx.service
● ├─system.slice
● ├─network.target
● │ ├─network-online.target
● │ └─network-pre.target
● └─sysinit.target
●   ├─dev-hugepages.mount
●   ├─dev-mqueue.mount

Show reverse dependencies (what depends on this service):

systemctl list-dependencies nginx --reverse

Using journalctl to look at logs

For centralized logging, systemd works with journald. Check out the service logs:

journalctl -u nginx

Follow logs in real-time:

journalctl -u nginx -f

Show logs from the last hour:

journalctl -u mysql --since "1 hour ago"

Show logs between specific times:

journalctl -u sshd --since "2024-12-16 09:00:00" --until "2024-12-16 10:00:00"

Sample output:

Dec 16 09:23:45 webserver sshd[3421]: Accepted publickey for admin from 192.168.1.100 port 54332 ssh2: RSA SHA256:abc123...
Dec 16 09:24:12 webserver sshd[3456]: pam_unix(sshd:session): session opened for user admin(uid=1000) by (uid=0)
Dec 16 09:45:33 webserver sshd[3456]: pam_unix(sshd:session): session closed for user admin

Show only errors:

journalctl -u apache2 -p err

Display logs with full output (no truncation):

journalctl -u nginx --no-pager

Services for Masking

Masking stops a service from starting up on its own or by hand:

sudo systemctl mask apache2

Output:

Created symlink /etc/systemd/system/apache2.service → /dev/null.

If you have two services that want the same port (like Apache and Nginx both wanting port 80), this is helpful. Unmask to let you start over:

sudo systemctl unmask apache2

Troubleshooting in the Real World Scenarios

Scenario 1: Service Fails to Start After Update

Problem: After a system update, nginx fails to start.

Investigation steps:

systemctl status nginx

Output shows:

● nginx.service - A high performance web server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Wed 2024-12-18 14:22:10 UTC; 30s ago
    Process: 5234 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)
        CPU: 45ms

Check detailed logs:

journalctl -u nginx -n 50

Output reveals:

Dec 18 14:22:10 webserver nginx[5234]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Dec 18 14:22:10 webserver nginx[5234]: nginx: configuration file /etc/nginx/nginx.conf test failed
Dec 18 14:22:10 webserver systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE

Solution: Port 80 is already in use. Find the conflicting process:

sudo ss -tlnp | grep :80

Output:

LISTEN 0      511          0.0.0.0:80        0.0.0.0:*    users:(("apache2",pid=1234,fd=4))

Apache2 is using port 80. Stop it and start nginx:

sudo systemctl stop apache2
sudo systemctl disable apache2
sudo systemctl start nginx

Scenario 2: The Service Keeps Restarting

Problem: A custom application service keeps crashing and restarting.

Check status:

systemctl status myapp

Output:

● myapp.service - My Web Application
     Loaded: loaded (/etc/systemd/system/myapp.service; enabled; vendor preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since Wed 2024-12-18 15:10:45 UTC; 3s ago
    Process: 6789 ExecStart=/usr/bin/node /opt/myapp/server.js (code=exited, status=1/FAILURE)
   Main PID: 6789 (code=exited, status=1/FAILURE)
        CPU: 234ms

View recent restart attempts:

journalctl -u myapp -n 100

Output shows repeated failures:

Dec 18 15:10:42 webserver node[6789]: Error: Cannot find module 'express'
Dec 18 15:10:42 webserver systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE
Dec 18 15:10:42 webserver systemd[1]: myapp.service: Failed with result 'exit-code'.

Solution: Missing Node.js dependencies. Install them and restart:

cd /opt/myapp
npm install
sudo systemctl restart myapp

If you need to stop the restart loop temporarily:

sudo systemctl stop myapp

Scenario 3: Database Service Won’t Start After Crash

Problem: MySQL won’t start after an unexpected server reboot.

systemctl status mysql

Output:

● mysql.service - MySQL Community Server
     Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Wed 2024-12-18 16:05:12 UTC; 2min ago
    Process: 2341 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
    Process: 2349 ExecStart=/usr/sbin/mysqld (code=exited, status=1/FAILURE)
   Main PID: 2349 (code=exited, status=1/FAILURE)
     Status: "Server startup in progress"

Check MySQL error log:

journalctl -u mysql -n 200

Output:

Dec 18 16:05:12 dbserver mysqld[2349]: [ERROR] InnoDB: Unable to lock ./ibdata1 error: 11
Dec 18 16:05:12 dbserver mysqld[2349]: [ERROR] InnoDB: Check that you do not already have another mysqld process

Check for existing MySQL processes:

ps aux | grep mysqld

Solution: Stale PID file or lock. Remove it and restart:

sudo rm /var/run/mysqld/mysqld.pid
sudo rm /var/lib/mysql/*.pid
sudo systemctl start mysql

Verify it’s running:

systemctl status mysql

Conclusion

Systemd is now the standard for managing services on modern Linux distributions. It has powerful tools for controlling, monitoring, and fixing services. You can easily manage any Linux system if you learn how to use systemctl commands, understand how unit files are structured, and know how to use journalctl to find and fix common problems.

Important points:

• For immediate service control, use systemctl start, stop, or restart.
• Use systemctl enable to turn on services so that they start up automatically when the computer boots up.
• When you’re having problems, always use systemctl status and journalctl -u.
• Make your own unit files for your apps in /etc/systemd/system/.
• After changing unit files, run systemctl daemon-reload.
• Use journalctl to look at all of your logs in one place.

These basic systemd commands will help you keep Linux systems stable and reliable in production environments, whether you’re in charge of web servers, databases

Reasons for Deploying Without Containers

We all are aware of Docker’s popularity. However, it is important to recognise that direct deployment on Ubuntu offers several significant advantages that are often overlooked. The application starts faster, troubleshooting is way easier when you have direct file access, there’s less resource overhead (which matters when you’re on a budget), and logging integration with systemd is straightforward. If you’re working on a small to medium application or you’re just getting started with DevOps, this approach gives you a solid foundation before jumping into the containerised world.

Prerequisites Required Prior to Commencing

Things You Need to Do Before You Start

Make sure that these basic parts are taken care of:

• Ubuntu 24.04 LTS server with admin rights
• You need at least 2GB of RAM and 10GB of disc space
• SSH access set up. You can get root or sudo access.

For this example, I’m using a simple Todo List app that has a React frontend, an Express.js backend, and a PostgreSQL database. Perfect for getting the hang of things.

Setting Up Node.js the Right Way

Ubuntu’s default repositories have older Node.js versions, and trust me, you don’t want to deal with version mismatches. Here’s how I installed the latest LTS version from NodeSource:

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs

Quick verification to make sure everything’s working:

node --version
npm --version

You should see something like v20.19.6 and 10.8.2. Perfect!

Getting PostgreSQL Up and Running

PostgreSQL is my go-to database for production apps. Installation is straightforward:

sudo apt install -y postgresql postgresql-contrib

I always check if the service is actually running (can’t tell you how many times I’ve forgotten this step):

psql --version
sudo systemctl status postgresql

You’ll see PostgreSQL 16.11 running, which is solid and stable.

Nginx for Web Serving and Reverse Proxy

Nginx is going to serve your static React files and proxy API requests to the Node.js backend. It’s fast and reliable:

sudo apt install -y nginx
nginx -v

Should show nginx version 1.24.0.

PM2 – Your Application’s Guardian Angel

PM2 is seriously one of the best tools out there. It keeps your Node.js app running 24/7 and automatically restarts it if something goes wrong:

sudo npm install -g pm2
pm2 --version

Version 6.0.14 is what I’m running.

Configuring PostgreSQL (The Fun Part)

Now let’s set up the database. I like to create a dedicated database and user for each application – it’s just cleaner:

sudo -u postgres psql -c "CREATE DATABASE tododb;"
sudo -u postgres psql -c "CREATE USER todouser WITH PASSWORD 'todopass123';"
sudo -u postgres psql -c "GRANT ALL PRIVILEGES ON DATABASE tododb TO todouser;"
sudo -u postgres psql -d tododb -c "GRANT ALL ON SCHEMA public TO todouser;"

Creating the table structure:

sudo -u postgres psql -d tododb -c "CREATE TABLE todos (
  id SERIAL PRIMARY KEY,
  title VARCHAR(255) NOT NULL,
  description TEXT,
  completed BOOLEAN DEFAULT false,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);"

I always add some test data to make sure everything works:

sudo -u postgres psql -d tododb -c "INSERT INTO todos (title, description, completed) VALUES
  ('Welcome to Todo App', 'This is your first todo item', false),
  ('Learn React', 'Build amazing frontend applications', false),
  ('Learn Node.js', 'Create powerful backend APIs', true);"

Setting Up the Backend

Time to get the Node.js backend in place. I organize my projects like this:

mkdir -p ~/todo-app/backend
cd ~/todo-app/backend

Here’s my package.json – keeping dependencies minimal and focused:

{
  "name": "todo-backend",
  "version": "1.0.0",
  "description": "Todo app backend API",
  "main": "server.js",
  "scripts": {
    "start": "node server.js"
  },
  "dependencies": {
    "express": "^4.18.2",
    "pg": "^8.11.3",
    "cors": "^2.8.5",
    "dotenv": "^16.3.1"
  }
}

Installing dependencies:

npm install

Pro tip: Always use environment variables for sensitive data. Here’s my .env setup:

cat > .env << EOF
PORT=5000
DB_USER=todouser
DB_HOST=localhost
DB_NAME=tododb
DB_PASSWORD=todopass123
DB_PORT=5432
EOF

Important: In production, use stronger passwords! Consider tools like AWS Secrets Manager or dotenv-vault.

Launching with PM2

This is where the magic happens. PM2 will keep your app running forever:

pm2 start server.js --name todo-api

You’ll see a nice table showing your app is online. Beautiful!

Now, make sure it starts automatically on server reboots (I forgot this once and had a fun surprise after maintenance):

pm2 startup systemd
# Run the command it gives you
pm2 save

Some useful PM2 commands I use all the time:

pm2 list          # See all running apps
pm2 logs todo-api # View real-time logs
pm2 monit         # Monitor resources
pm2 restart todo-api # Restart the app

Building the React Frontend

Time to create the production build of your React app:

cd ~/todo-app/frontend
npm run build

Vite builds it super fast – usually done in under a second. The optimized files go into the dist directory.

Configuring Nginx (The Critical Part)

This is where a lot of people get stuck, so I’ll walk through it carefully. Create your Nginx config:

sudo nano /etc/nginx/sites-available/todo-app

Here’s the configuration I use:

server {
    listen 80;
    server_name your_server_ip;

    # Serve React frontend
    location / {
        root /home/yourusername/todo-app/frontend/dist;
        index index.html;
        try_files $uri $uri/ /index.html;
    }

    # Proxy API requests to backend
    location /api {
        proxy_pass http://localhost:5000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $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_cache_bypass $http_upgrade;
    }
}

Enable the site:

sudo ln -s /etc/nginx/sites-available/todo-app /etc/nginx/sites-enabled/
sudo rm /etc/nginx/sites-enabled/default

Always test the config before restarting (learned this lesson the hard way):

sudo nginx -t
sudo systemctl restart nginx

The Permission Headache (And How I Fixed It)

If you see a 500 error, it’s probably permissions. Check the Nginx error log:

sudo tail -20 /var/log/nginx/error.log

You’ll likely see “Permission denied” errors. Here’s the fix:

chmod 755 /home/yourusername
chmod -R 755 ~/todo-app

This gave me a headache for about 30 minutes before I figured it out!

Testing Everything

Let’s make sure everything works. Test the backend directly:

curl http://localhost:5000/api/health
curl http://localhost:5000/api/todos

Test through Nginx:

curl http://localhost/api/health

And from outside your server:

curl http://your_server_ip/api/health

Open your browser and visit your server IP – you should see your Todo app!

Troubleshooting Common Issues

App keeps crashing? Check PM2 logs:

pm2 logs todo-api --lines 50

Database connection errors? Test PostgreSQL:

psql -h localhost -U todouser -d tododb

502 Bad Gateway? Make sure your backend is running:

pm2 status
netstat -tulpn | grep 5000

Security Best Practices

Don’t skip this part! Set up a basic firewall:

sudo ufw allow 22/tcp    # SSH
sudo ufw allow 80/tcp    # HTTP
sudo ufw allow 443/tcp   # HTTPS
sudo ufw enable

Change your database password to something strong:

sudo -u postgres psql -c "ALTER USER todouser WITH PASSWORD 'YourStrongPasswordHere';"

Add security headers to Nginx (inside your server block):

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;

Performance Tips

Want better performance? Run PM2 in cluster mode:

pm2 delete todo-api
pm2 start server.js -i max --name todo-api

This runs one instance per CPU core – really helps with load handling.

Add Nginx caching for static files:

location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

Maintenance and Updates

When you need to deploy updates:

cd ~/todo-app/backend
npm install  # If dependencies changed
pm2 restart todo-api

For frontend updates:

cd ~/todo-app/frontend
npm run build

Regular database backups are crucial:

pg_dump -U todouser -h localhost tododb > backup_$(date +%Y%m%d).sql

To restore:

psql -U todouser -h localhost tododb < backup_20251224.sql

Conclusion

And at the last. We have successfully deployed full-stack Node.js app on Ubuntu 24.04 without Docker. You can do the same for production: PM2 keeps things alive, Nginx serves fast, and PostgreSQL keeps data safe.

Key takeaways from my experience:
PM2 is a must-have for keeping your application running 24/7. Nginx is high performance and efficient for static file serving and reverse proxying. PostgreSQL with proper user isolation is a solid database.
File permissions can be a problem, check them first.
Regular monitoring and backups avoid future problems

I recommend Let’s Encrypt for SSL certificates for production, automated backups, Grafana for monitoring, and log rotation. But this way you have control over your infrastructure, and it’s simple and easy to debug.
If you have any problems, let me know, I have probably been there before.

There are two versions:

• WSL 1: Faster and lighter file input/output between Linux and Windows.
• WSL 2: A full Linux kernel that is recommended for its improved performance, Docker compatibility, and authentic Linux behavior.

Why Use WSL for Testing?

WSL allows you to operate complete Linux distributions directly on your Windows computer without the need for a virtual machine or dual-boot configuration. Here is the rationale for why WSL represents a significant advancement in testing:

• Seamless Integration: Utilize Linux tools, scripts, and applications natively within the Windows environment.
• Resource Efficiency: Utilize fewer resources than conventional virtual machines, enabling quicker deployment and reduced memory consumption.
• Improved Productivity: Streamline cross-platform testing without departing from your primary operating system.
• DevOps Alignment: Replicate production environments to facilitate precise testing and effective troubleshooting.

Step-by-Step Installation Guide

1. Enable WSL on Windows

First, enable the Windows Subsystem for Linux feature:

Run PowerShell as Administrator and execute:

wsl --install

This installs:

• WSL 2 backend

• Latest Ubuntu LTS distro by default

After installation:

wsl --set-default-version 2

Optional: Install a Specific Linux Distro

To see available distros:

wsl --list --online
The following is a list of valid distributions that can be installed.
Install using 'wsl.exe --install <Distro>'.

NAME                            FRIENDLY NAME
AlmaLinux-8                     AlmaLinux OS 8
AlmaLinux-9                     AlmaLinux OS 9
AlmaLinux-Kitten-10             AlmaLinux OS Kitten 10
AlmaLinux-10                    AlmaLinux OS 10
Debian                          Debian GNU/Linux
FedoraLinux-43                  Fedora Linux 43
FedoraLinux-42                  Fedora Linux 42
SUSE-Linux-Enterprise-15-SP7    SUSE Linux Enterprise 15 SP7
SUSE-Linux-Enterprise-16.0      SUSE Linux Enterprise 16.0
Ubuntu                          Ubuntu
Ubuntu-24.04                    Ubuntu 24.04 LTS
archlinux                       Arch Linux
kali-linux                      Kali Linux Rolling
openSUSE-Tumbleweed             openSUSE Tumbleweed
openSUSE-Leap-16.0              openSUSE Leap 16.0
Ubuntu-20.04                    Ubuntu 20.04 LTS
Ubuntu-22.04                    Ubuntu 22.04 LTS
OracleLinux_7_9                 Oracle Linux 7.9
OracleLinux_8_10                Oracle Linux 8.10
OracleLinux_9_5                 Oracle Linux 9.5
openSUSE-Leap-15.6              openSUSE Leap 15.6
SUSE-Linux-Enterprise-15-SP6    SUSE Linux Enterprise 15 SP6

I have to install a different Linux distribution, specifically Oracle Linux 9, which is what I need to do. Let’s move forward with the installation in accordance with the instructions.

wsl --install --distribution OracleLinux_9_5
wsl: Using legacy distribution registration. Consider using a tar based distribution instead.
Downloading: Oracle Linux 9.5
Oracle Linux 9.5 has been downloaded.
Distribution successfully installed. It can be launched via 'wsl.exe -d Oracle Linux 9.5'
Launching Oracle Linux 9.5...
Installing, this may take a few minutes...
Please create a default UNIX user account. The username does not need to match your Windows username.
For more information visit: https://aka.ms/wslusers
Enter new UNIX username: asif
Changing password for user asif.
New password:
BAD PASSWORD: The password is shorter than 8 characters
Retype new password:
passwd: all authentication tokens updated successfully.
Installation successful!

Managing WSL Distros

List Installed Distros

wsl --list --verbose

or shorthand:

wsl -l -v

  NAME                STATE           VERSION
* Ubuntu-24.04        Stopped         2
  FedoraLinux-43      Stopped         2
  Ubuntu              Stopped         2
  OracleLinux_8_10    Stopped         2
  OracleLinux_9_5     Stopped         2
  Ubuntu-22.04        Stopped         2

Set Default Distro

wsl --setdefault OracleLinux_9_5
The operation completed successfully.

wsl --list --verbose
  NAME                STATE           VERSION
* OracleLinux_9_5     Stopped         2
  FedoraLinux-43      Stopped         2
  Ubuntu              Stopped         2
  Ubuntu-24.04        Stopped         2
  OracleLinux_8_10    Stopped         2
  Ubuntu-22.04        Stopped         2

Set WSL Version (1 or 2)

wsl --set-version <distro-name> 2

Launch a Specific Distro

wsl -d Ubuntu-24.04
user@DESKTOP:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04.1 LTS
Release:        24.04
Codename:       noble

Terminate the instance

wsl --terminate FedoraLinux-43

wsl --list --verbose
  NAME                STATE           VERSION
* OracleLinux_9_5     Stopped         2
  FedoraLinux-43      Running         2
  Ubuntu              Stopped         2
  Ubuntu-24.04        Stopped         2
  OracleLinux_8_10    Stopped         2
  Ubuntu-22.04        Stopped         2

wsl --terminate FedoraLinux-43
The operation completed successfully.

wsl --list --verbose
  NAME                STATE           VERSION
* OracleLinux_9_5     Stopped         2
  FedoraLinux-43      Stopped         2
  Ubuntu              Stopped         2
  Ubuntu-24.04        Stopped         2
  OracleLinux_8_10    Stopped         2
  Ubuntu-22.04        Stopped         2

Shut down all WSL instances

wsl --shutdown

Unregister (delete) the distribution

wsl --unregister Ubuntu-22.04
Unregistering.
The operation completed successfully.

wsl --list --verbose
  NAME                STATE           VERSION
* OracleLinux_9_5     Stopped         2
  FedoraLinux-43      Stopped         2
  Ubuntu              Stopped         2
  Ubuntu-24.04        Stopped         2
  OracleLinux_8_10    Stopped         2

Starting and Stopping WSL

Start WSL

wsl

Start a Specific Distro

wsl -d Ubuntu-24.04

Stop All Running Instances

wsl --shutdown

Export, Import, and Backup WSL

Export a Distro (for Backup)

wsl --export Ubuntu-24.04 "D:\01\WSL_Backups\Ubuntu24_Snapshot.tar"

Import a Distro (Restore)

wsl --import MyUbuntu D:\WSL\MyUbuntu D:\01\WSL_Backups\Ubuntu24_Snapshot.tar --version 2

Unregister (Delete) a Distro

wsl --unregister FedoraLinux-43
Unregistering.
The operation completed successfully.

wsl --list --verbose
  NAME                STATE           VERSION
* OracleLinux_9_5     Stopped         2
  Ubuntu              Stopped         2
  Ubuntu-24.04        Stopped         2
  OracleLinux_8_10    Stopped         2

Useful WSL Configuration Commands

View WSL Config

cat /etc/wsl.conf

Example configuration file:

[boot]
systemd=true

[network]
generateResolvConf=false

Enable systemd in WSL

If systemd services like systemctl don’t work:
Edit /etc/wsl.conf inside your distro:

sudo nano /etc/wsl.conf

Add:

[boot]
systemd=true

Then run:

wsl --shutdown

and restart the distro.

Accessing Windows Files from WSL

Your Windows drives are available under /mnt:

cd /mnt/c
cd /mnt/d

You can also open Windows apps from WSL:

Using WSL for DevOps or Cloud Tools

You can install:

• Docker Desktop (uses WSL2 backend)

• kubectl, minikube, or kind for Kubernetes

• Terraform, Ansible, AWS CLI, etc.

sudo apt update && sudo apt install -y docker.io kubectl ansible

Summary

Windows Subsystem for Linux (WSL) is an option to take into consideration if you want to create a development environment on Windows that is similar to that of Linux. Through the use of WSL, you are able to work with Windows apps while simultaneously running a full Linux distribution. You may start utilizing WSL by:

• You can activate Windows Subsystem for Linux (WSL) by going into the settings for Windows Features.
• Through the Microsoft Store, you can get your preferred Linux distribution up and running successfully.
• Your development environment should be configured in the same manner as it would be on Linux.

When creating across many platforms, this setup provides a more consistent experience for the user. You can find thorough information by checking the Microsoft’s official WSL documentation.

Nmap, short for Network Mapper, is a robust, open-source utility. Network Mapper is a sophisticated program for network discovery, security auditing, and service upgrade management. Network administrators and security professionals use it to scan systems, discover hosts, detect open ports, and locate networked services. Mastering nmap can help you diagnose network faults and improve network security.

This tutorial will walk you through the fundamentals, advanced capabilities, and best practices of using nmap on Linux.

Installation of Nmap

Most Linux distributions include nmap in their official repositories. To install it, use:

• Debian/Ubuntu: sudo apt update sudo apt install nmap
• CentOS/RHEL: sudo yum install nmap
• Fedora/OEL: sudo dnf install nmap

Basic Usage

a. Scanning a Single Host

nmap <target>

Example:

nmap 192.168.100.10
Starting Nmap 7.92 ( https://nmap.org )
Nmap scan report for 192.168.100.10
Host is up (0.000013s latency).
Not shown: 999 closed tcp ports (reset)
PORT   STATE SERVICE
22/tcp open  ssh
Nmap done: 1 IP address (1 host up) scanned in 0.23 seconds

nmap 8.8.8.8
Starting Nmap 7.92 ( https://nmap.org )
Nmap scan report for dns.google (8.8.8.8)
Host is up (0.040s latency).
Not shown: 997 filtered tcp ports (no-response), 1 filtered tcp ports (net-unreach)
PORT    STATE SERVICE
53/tcp  open  domain
443/tcp open  https
Nmap done: 1 IP address (1 host up) scanned in 4.98 seconds

This command scans the default 1,000 ports on the target.

b. Scanning Multiple Hosts

nmap 192.168.1.1 192.168.1.2
nmap 192.168.1.1-10
nmap 192.168.1.*

nmap 8.8.8.8 8.8.4.4
Starting Nmap 7.92 ( https://nmap.org )
Nmap scan report for dns.google (8.8.8.8)
Host is up (0.056s latency).
Not shown: 997 filtered tcp ports (no-response), 1 filtered tcp ports (net-unreach)
PORT    STATE SERVICE
53/tcp  open  domain
443/tcp open  https

Nmap scan report for dns.google (8.8.4.4)
Host is up (0.056s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT    STATE SERVICE
53/tcp  open  domain
443/tcp open  https
Nmap done: 2 IP addresses (2 hosts up) scanned in 18.76 seconds

c. Scanning a Range of IP Addresses

nmap 192.168.1.1-20

or

nmap 192.168.1.0/24

nmap 192.168.10.0/24
Starting Nmap 7.92 ( https://nmap.org )
Nmap scan report for 192.168.10.1
Host is up (0.014s latency).
Not shown: 995 closed tcp ports (reset)
PORT   STATE    SERVICE
21/tcp filtered ftp
22/tcp filtered ssh
23/tcp filtered telnet
53/tcp open     domain
80/tcp open     http
MAC Address: (New Technologies)

Nmap scan report for 192.168.10.50
Host is up (0.00070s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT     STATE SERVICE
135/tcp  open  msrpc
2179/tcp open  vmrdp
MAC Address:

Nmap scan report for 192.168.10.60
Host is up (0.00070s latency).
All 1000 scanned ports on 192.168.10.60 are in ignored states.
Not shown: 1000 closed tcp ports (reset)
MAC Address:

Nmap scan report for 192.168.10.70
Host is up (0.0000090s latency).
Not shown: 999 closed tcp ports (reset)
PORT   STATE SERVICE
22/tcp open  ssh

Nmap done: 256 IP addresses (4 hosts up) scanned in 22.36 seconds

Port Scanning Techniques

a. Scan Specific Ports

nmap -p 22,80,443 192.168.10.1

Starting Nmap 7.92 ( https://nmap.org )
Nmap scan report for 192.168.10.1
Host is up (0.0016s latency).

PORT    STATE    SERVICE
22/tcp  filtered ssh
80/tcp  open     http
443/tcp closed   https
MAC Address: (New Technologies)

Nmap done: 1 IP address (1 host up) scanned in 1.39 seconds

b. Full Port Scan (1-65535)

nmap -p- 192.168.10.1
Starting Nmap 7.92 ( https://nmap.org )
Nmap scan report for 192.168.10.1
Host is up (0.020s latency).
Not shown: 65527 closed tcp ports (reset)
PORT      STATE    SERVICE
21/tcp    filtered ftp
22/tcp    filtered ssh
23/tcp    filtered telnet
80/tcp    open     http
17998/tcp open     unknown
37443/tcp open     unknown
37444/tcp open     unknown
Nmap done: 1 IP address (1 host up) scanned in 13.07 seconds

c. Fast Scan

Scan only the top 100 common ports:

nmap -F 192.168.10.1

Service and Version Detection

To detect running services and their versions:

nmap -sV 192.168.10.1
Starting Nmap 7.92 ( https://nmap.org )
Nmap scan report for 192.168.10.1
Host is up (0.0097s latency).
Not shown: 995 closed tcp ports (reset)
PORT   STATE    SERVICE  VERSION
21/tcp filtered ftp
22/tcp filtered ssh
23/tcp filtered telnet
80/tcp open     ssl/http
SF-Port53-TCP:V=7.92%I=7%D=1
SF:(DNSVersionBindReqTCP,44vers
SF:ion\x04bind\0\0\x10\0
SF:0\x0c\0\x02\0\x03\0\0
Service detection performed.
Nmap done: 1 IP address (1 host up) scanned in 18.15 seconds

Operating System Detection

Try to identify the target’s operating system:

nmap -O 192.168.10.1
Starting Nmap 7.92 ( https://nmap.org )
Nmap scan report for 192.168.10.1
Host is up (0.0012s latency).
Not shown: 999 closed tcp ports (reset)
PORT   STATE SERVICE
22/tcp open  ssh
Device type: general purpose
Running: Linux 4.X|5.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
OS details: Linux 4.15 - 5.6
Network Distance: 1 hop
OS detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1.79 seconds

Combine service and OS detection:

nmap -A 192.168.10.1
Starting Nmap 7.92 ( https://nmap.org )
Nmap scan report for 192.168.10.1
Host is up (0.00056s latency).
Not shown: 999 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 9f:90:98:f:1f:87:96:b3:73:e3:f1:8a:ee (ECDSA)
|_  256 35:55:ef:e:af:32:b2:c1:51:69:e4:30:e5 (ED25519)
Device type: general purpose
Running: Linux 4.X|5.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
OS details: Linux 4.15 - 5.6
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE
HOP RTT     ADDRESS
1   0.56 ms 192.168.10.1
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 2.56 seconds

Advanced Scanning Options

a. Stealth Scan (SYN Scan)

sudo nmap -sS 192.168.1.1

b. UDP Scan

sudo nmap -sU 192.168.1.1
Starting Nmap 7.92 ( https://nmap.org )
Nmap scan report for 192.168.1.1
Host is up (0.000018s latency).
Not shown: 999 closed udp ports (port-unreach)
PORT     STATE         SERVICE
5353/udp open|filtered zeroconf
Nmap done: 1 IP address (1 host up) scanned in 1.34 seconds

c. Aggressive Scan

nmap -A 192.168.1.1
Starting Nmap 7.92 ( https://nmap.org )
Nmap scan report for 192.168.1.1
Host is up (0.000058s latency).
Not shown: 999 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.7 (protocol 2.0)
| ssh-hostkey:
|   256 5c:c4:66:2b:70:e3:11:8b:13:14:03:88 (ECDSA)
|_  256 a0:80:d6:53:32:6c:c3:a8:25:e3:be:40 (ED25519)
Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:linux_kernel:2.6.32
OS details: Linux 2.6.32
Network Distance: 0 hops
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 2.40 seconds

This enables OS detection, version detection, script scanning, and traceroute.

d. Using Nmap Scripts

Nmap has a powerful scripting engine (NSE):

nmap --script=default 192.168.1.1

Or use a specific script:

nmap --script=http-enum 192.168.1.1

Output Formats

• Normal Output: (default)
• Grepable Output: nmap -oG output.txt 192.168.1.1
• XML Output: nmap -oX output.xml 192.168.1.1
• All Formats: nmap -oA output 192.168.1.1
  List of files
  ls
  output.gnmap  output.nmap  output.txt  output.xml

Tips for Mastering Nmap

• Practice Regularly: Try different scan types and options on test networks.
• Read the Documentation: man nmap and the official Nmap documentation are invaluable.
• Explore NSE Scripts: There are hundreds of scripts for various tasks—enumeration, vulnerability detection, brute force, etc.
• Stay Legal: Only scan networks you own or have explicit permission to test.

Useful Nmap Examples

• Scan all devices on your subnet: nmap -sn 192.168.1.0/24
• Detect firewall rules: nmap -sA 192.168.1.1
• Scan for vulnerabilities: nmap –script vuln 192.168.1.1

Conclusion

When it comes to auditing network security and exploring networks, Nmap is a strong and flexible tool. Gaining expertise requires consistent effort and a thirst for knowledge. You may quickly and easily map out networks, identify weaknesses, and protect your infrastructure if you are familiar with its many features and possibilities.

Always use Nmap in a responsible and ethical manner.

Installing Java 17 on Linux

Easy way to install Java 17 is with your system’s package manager. For most distributions, OpenJDK is recommended.

For Ubuntu/Debian:

Update Your System

sudo apt update && sudo apt upgrade -y

Install OpenJDK 17

sudo apt install openjdk-17-jdk -y

For CentOS/RHEL/Fedora:

sudo dnf update -y

Enable EPEL Repository (if needed)

sudo dnf install epel-release -y
sudo dnf install java-17-openjdk-devel

Verifying Java Installation

After installation, verify your Java version by running:

java -version

openjdk version "17.0.17" LTS
OpenJDK Runtime Environment (Red_Hat-17.0.17.0.10-1.0.1) (build 17.0.17+10-LTS)
OpenJDK 64-Bit Server VM (Red_Hat-17.0.17.0.10-1.0.1) (build 17.0.17+10-LTS, mixed mode, sharing)

You should see an output indicating Java 17 is installed.

Creating a Java Program in Linux

Use any text editor to create a new Java source file. For example, using nano:

nano HelloWorld.java

Insert the following code:

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

Save and exit the editor (for nano: press Ctrl+O, then Enter, then Ctrl+X).

Compiling and Running a Java Program

To compile your Java program, run:

javac HelloWorld.java
ls
HelloWorld.class  HelloWorld.java

This generates a HelloWorld.class file. To execute the program:

java HelloWorld

You should see:

Hello, World!

Finding the Java Installation Path

To determine where Java is installed, run:

which java
/usr/bin/java

This shows the symbolic link. For the actual installation directory, use:

readlink -f $(which java)
/usr/lib/jvm/java-17-openjdk-17.0.17.0.10-1.0.1.el9.x86_64/bin/java

Or, to list all installed Java versions with their paths:

update-alternatives --config java
There is 1 program that provides 'java'.
  Selection    Command
-----------------------------------------------
*+ 1           java-17-openjdk.x86_64 (/usr/lib/jvm/java-17-openjdk-17.0.17.0.10-1.0.1.el9.x86_64/bin/java)
Enter to keep the current selection[+], or type selection number: 1

Creating a JAR File Using a Java Program

First, ensure your program is compiled (.class files exist). Then, use the jar command:

jar cvf HelloWorld.jar HelloWorld.class
added manifest
adding: HelloWorld.class(in = 427) (out= 290)(deflated 32%)

• c creates a new JAR file.
• v enables verbose output.
• f specifies the filename.

To create an executable JAR, include a manifest specifying the main class:

echo "Main-Class: HelloWorld" > manifest.txt
jar cfm HelloWorld.jar manifest.txt HelloWorld.class
ls
HelloWorld.class  HelloWorld.jar  HelloWorld.java  manifest.txt

Executing a JAR File in Linux

To run your JAR file:

java -jar HelloWorld.jar

You should again see:

Hello, World!

Setting JAVA_HOME in Linux

Setting JAVA_HOME ensures that development tools and scripts can locate your Java installation.

1. Find your Java installation directory:

   sudo update-alternatives --config java
   

   The path will look something like /usr/lib/jvm/java-17-openjdk-17

2. Open your shell profile (.bashrc, .bash_profile, or .profile) in a text editor:

   nano ~/.bashrc
   

3. Add the following line at the end:

   export JAVA_HOME="/usr/lib/jvm/java-17-openjdk-17.0.17.0.10-1.0.1.el9.x86_64"
   export PATH="$JAVA_HOME/bin:$PATH"
   

4. Apply the changes:

   source ~/.bashrc
   

5. Verify:

   echo $JAVA_HOME
   /usr/lib/jvm/java-17-openjdk-17.0.17.0.10-1.0.1.el9.x86_64
   

Conclusion

You may now efficiently create, compile, and package Java applications on your Linux machine with Java 17 installed. Having a solid grasp of these fundamental stages guarantees a seamless development experience, regardless of whether you’re working with basic apps or huge corporate solutions. More new setups and in-depth tutorials are coming soon!

In this article, we’ll talk about how to set up passwordless access with SSH key pairs and how this helps rsync and scp work.

Understanding Passwordless SSH Authentication

Passwordless SSH enables users to log in to remote Linux systems securely without entering a password each time. This is achieved using a pair of cryptographic keys:

• Private Key: Stays on your local machine and must be kept secure.
• Public Key: Shared with the remote server.

When properly configured, the SSH protocol uses these keys to authenticate the user, eliminating manual password entry.

Step 1: Generate SSH Key Pair

On your local machine, open a terminal and run:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
or
ssh-keygen -t rsa -b 4096

• Press Enter to accept the default file location.
• Optionally, set a passphrase for added security.

This creates two files in your ~/.ssh/ directory:

• id_rsa (private key)
• id_rsa.pub (public key)

Step 2: Copy the Public Key to the Remote Server

To enable passwordless login, copy your public key to the remote server’s authorized keys:

ssh-copy-id user@remote_host

• Replace user with your remote username and remote_host with the server’s IP or hostname.

Alternatively, if ssh-copy-id is unavailable:

cat ~/.ssh/id_rsa.pub | ssh user@remote_host 'cat >> ~/.ssh/authorized_keys'

Step 3: Test Passwordless SSH Login

Try logging into the remote server:

ssh user@remote_host

If everything is set up correctly, you should be granted access without being prompted for a password.

Using Passwordless SSH with rsync and scp

Now that passwordless SSH is enabled, you can leverage it with rsync and scp for seamless file transfers and backups.

Rsync Example

Synchronize a local directory to a remote server:

rsync -avz /local/dir/ user@remote_host:/remote/dir/

No password prompt will appear, enabling automated backups or deployments.

SCP Example

Copy a file to a remote server:

scp /path/to/local/file user@remote_host:/path/to/remote/

Copy a file from the remote server:

scp user@remote_host:/path/to/remote/file /path/to/local/

Security Best Practices

• Protect Your Private Key: Never share your private key and always use strong filesystem permissions (chmod 600 ~/.ssh/id_rsa).
• Consider a Passphrase: For additional security, set a passphrase when generating your SSH key.
• Limit SSH Access: Use firewalls and SSH configuration (/etc/ssh/sshd_config) to restrict who can log in.
• Use SSH Agent: If you use a passphrase, ssh-agent can cache your decrypted key during a session for convenience.

Conclusion

Setting up passwordless SSH authentication makes Linux environments much more productive, especially when using rsync and scp. You can safely and quickly automate file transfers, backups, and remote operations with these tools.
By doing the things above, you’ll make your Linux management tasks easier and faster than ever.

What is the ss Command?

The ss command is a tool that dumps socket statistics and shows information that is similar to what you would get with the older netstat tool. But “ss” is faster, gives more information, and is now the best way to look at network sockets on modern Linux distributions.

Why Choose ss Over netstat?

While netstat has been a staple for network diagnostics, it is now deprecated in many distributions in favor of ss. Here’s why:

• Speed: ss leverages /proc files directly, making it significantly faster.
• Detail: It provides more detailed information about sockets.
• Active Development: ss is actively maintained, ensuring compatibility with the latest Linux kernels and features.

Basic Syntax

The basic syntax for the ss command is:

ss [options]

You can combine options to tailor the output to your needs.

Common Use Cases and Examples

1. Display All Connections

To display all current TCP, UDP, and Unix socket connections:

ss -a

2. Show Listening Sockets

To list all listening sockets (commonly used by servers):

ss -l

3. Filter by Protocol

To view only TCP connections:

ss -t

For UDP connections:

ss -u

4. Show Process Information

To display the processes using each socket:

ss -p

5. Display Listening TCP Ports with Process Info

ss -ltp

6. Find Connections on a Specific Port

For example, to see connections on port 80:

ss -t state listening '( sport = :80 )'

7. Show All IPv4 and IPv6 Connections

ss -4   # IPv4 only
ss -6   # IPv6 only

Key Options and Flags

• a: Show all sockets (listening and non-listening)
• l: Display only listening sockets
• t: Show TCP sockets
• u: Show UDP sockets
• p: Show process using socket
• n: Don’t resolve service names

Conclusion

The “ss” command is an important tool for anyone who works with Linux systems or networks. It is the modern standard for investigating and fixing socket problems because it is fast, flexible, and has a lot of features. If you learn how to use “ss,” you can quickly see what’s going on with your system’s network and fix connection problems quickly. The ss command should be in your Linux toolkit if you want to debug a service, keep an eye on active connections, or make sure security.

Further Reading:

• To see the full documentation, type man ss in your terminal or go to the Linux man pages online.

What Is netstat?

The command-line tool “netstat” stands for “network statistics” and gives you information about network connections, routing tables, interface statistics, masquerade connections, and multicast memberships. Most Unix-like operating systems, like Linux, can use it.

In recent years, newer tools like ss have come out, but netstat is still a must-have for many administrators because it is simple to use and works with a wide range of systems.

Why Use netstat?

Network issues can be elusive, and troubleshooting them often requires insight into which ports are open, which services are listening, and where connections are being made. The netstat command gives you a real-time snapshot of this information, making it invaluable for:

• Diagnosing connectivity problems
• Identifying open ports and active services
• Monitoring network performance
• Investigating security concerns

Basic Usage

To get started, open your terminal and type:

netstat

By default, this displays a list of active connections, but the real power of netstat comes from its various options. Let’s look at some of the most useful ones.

1. Display All Connections and Listening Ports

netstat -a

This command shows all active connections and the ports on which the computer is listening.

2. Show Listening Ports Only

netstat -l

If you’re interested in services waiting for incoming connections, this option filters out only the listening ports.

3. Display Numerical Addresses

netstat -n

By default, netstat tries to resolve hostnames and service names, which can slow things down. The -n flag keeps things fast and simple by showing raw IP addresses and port numbers.

4. Show Process IDs

netstat -p

This option adds the PID and name of the program to the output, which is especially useful for tracking down which application is using a specific port.

5. Combine Options for Detailed Output

A common combination is:

netstat -tulnp

Here’s what these flags mean:

• t: TCP connections
• u: UDP connections
• l: Listening ports
• n: Numerical addresses
• p: Show process information

This command gives a concise, detailed overview of all active listening TCP and UDP ports with numerical addresses and associated processes.

Example Output

Here’s what a sample output might look like:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1023/sshd
tcp6       0      0 :::80                   :::*                    LISTEN      1204/apache2

This tells you which protocols are being used, which addresses and ports are in play, and which processes are responsible.

Modern Alternatives

It’s important to note that even though netstat is still widely used, some newer distributions recommend using the ss command instead because it is faster and has more features. netstat is still a good backup, though, especially on older systems.

Conclusion

Anyone who works with Linux systems needs the netstat command. It is easy to find network problems, keep an eye on activity, and keep a safe environment with its simple output and flexible options. If you want to know what’s going on behind the scenes or if you’re having problems, you should learn how to use netstat.