DEV Community: Vishvajeet Shukla

Stop Hand-Rolling VPS Deploys: Why I Built Shipown, an AI-Powered Deployment App

Vishvajeet Shukla — Tue, 20 Oct 2026 09:00:56 +0000

If you have ever deployed a Next.js or Node app to your own Linux server, you know the drill. It is not hard, exactly. It is just a lot of steps, every single time, and each one is a place where something can quietly go wrong.

I'm the builder of Shipown, and that list of steps is the reason it exists. This post is about why I'd choose Shipown over doing it all by hand, using only what Shipown actually does today.

The traditional way: DevOps by hand

Here is what a "simple" deploy to a VPS usually looks like when you do it yourself:

SSH into the server and check what's installed.
Install Node.js, a package manager, Git and PM2.
Clone the repo, pick the branch, install dependencies, and build.
Write a PM2 config: start command, port, restart policy.
Write an Nginx server block to proxy your domain to the app.
Test the Nginx config, reload, and hope you didn't break another site.
Run Certbot for HTTPS and remember the certificate will expire.
Invent your own release/rollback scheme (folders, symlinks, scripts).
Keep several terminal tabs open to watch CPU, RAM, disk and PM2.
When something breaks at night — a 502, a crashed process, a full disk — debug it command by command from memory and Stack Overflow.

None of these steps is exotic. Together, they are a part-time job.

The same deploy with Shipown

Shipown is an AI-powered desktop app for Windows and Linux. It connects to your Linux VPS or bare-metal server over plain SSH, with no Shipown deployment agent installed on the server, and walks the same path for you:

Connect a server: host, port, user, key or password. The connection is tested before anything is saved.
Pick a source: a GitHub repo and one of its real branches, or a local folder.
Review the plan: framework, commands, port, domain and target are detected and shown, and every value is editable. You approve it.
Watch it build: install and build output streams live, on the server or on your PC.
Operate it: live URL, history, health, logs, redeploy and rollback on one page.

Steps 2–9 of the manual list are now inside that flow.

Why choose Shipown

1. An AI operator that proposes, and you approve

This is the heart of it. Shipown's AI terminal works with your own Anthropic (Claude), OpenAI or DeepSeek API key. Describe the problem in plain language — a 502 from Nginx, a crashed PM2 process, a full disk — and the model inspects the server and proposes one shell command at a time, with its reason. You approve each command before it runs.

Destructive commands such as recursive deletes, reboots, firewall flushes or stopping SSH are always held for confirmation, and auto mode only runs commands that read. Requests go from your computer straight to the provider you chose, and your key is encrypted by the OS. That turns step 10 from "debug from memory" into a guided, reviewable conversation.

2. PM2 and Nginx set up for you

Next.js, Nuxt, Remix, SvelteKit, NestJS, Fastify and Express apps are installed, built and started under PM2, with the port, health check and restart policy set. Static sites (Vite, Astro, plain HTML) are published to a release directory and served straight from Nginx. Supported Dockerfile and Compose projects deploy too, with images labelled by commit.

3. Nginx and HTTPS without the 2 a.m. surprises

Point a domain at an app and Shipown writes the Nginx virtual host, tests the config before reloading, and asks Certbot for a certificate when you want HTTPS. If Nginx rejects a config, it is put back the way it was. Certificate expiry is surfaced in the app.

4. Rollback that's built in, not bolted on

Every deploy gets its own release directory. A Shipown-managed app can return to a retained release, and detected runtime failures trigger recovery attempts. For Docker, the previous container is kept until the health check passes.

5. Monitoring and a terminal in one window

CPU, RAM, disk, load average and PM2 processes are read from /proc and pm2 jlist, with no extra metric collectors, next to an embedded terminal. Heartbeats report an unreachable server once and report its recovery once.

6. You still own everything

Your servers, your keys, your data. Shipown connects over SSH and uses what is already on the box. Pricing is simple: a free 30-day trial with no card, then Pro at $5/month or $32/year with unlimited servers, and purchases don't auto-renew.

Honest limits

No deploy-on-push. Shipown shows when a branch is ahead, but a person presses deploy.
The desktop app must be running (and your PC awake) for health checks.
Scope: Node apps, static sites and supported Docker projects on Linux servers.
Release candidate: v0.1.0-rc.10. An end-to-end verification matrix across server OS versions hasn't been completed yet; check the supported environments page.
Platforms: Windows and Linux today; macOS (Apple Silicon and Intel) is coming in the next release.
Recovery isn't magic: database migrations and persistent data need their own plan.

Try it

If those ten manual steps feel familiar, try Shipown free for 30 days at shipown.com. Feedback from people running real servers is exactly what this stage needs.

I'm Vishvajeet Shukla, a full stack developer in Jaipur and the builder of Shipown. More of my work is at vishvajeetshukla.in.

Deploy Your Next.js or Node App to Your Own VPS Over SSH — Without a PaaS

Vishvajeet Shukla — Tue, 20 Oct 2026 08:56:29 +0000

I build websites and web apps for clients, and almost every project ends with the same question: where does this actually run?

The easy answer is a managed platform like Vercel or Netlify. The workflow is great: connect a repo, build, get a URL, roll back if something breaks. But your app runs on their runtime, under their account, and the bill and the rules are theirs too. The other answer is a cheap Linux VPS. You own it, but then you are back to SSH tabs, hand-written Nginx configs, PM2 commands, and Certbot, every single time.

I wanted the first workflow on the second kind of server. That is why I built Shipown. This post explains the problem, how Shipown approaches it, and where it honestly stands today.

The gap between PaaS and "just SSH in"

There are already good self-hosted platforms: Coolify, Dokploy, CapRover. They are real options and worth a look. But they share a design choice: they are platforms you install on the server. A web dashboard and its services run there, and apps are deployed as Docker containers.

That is fine for some setups. For a lot of my work it is more than I need. I often have a small VPS that should run one Next.js app under PM2 behind Nginx. I don't want a control plane living next to it, and I don't necessarily want Docker in the picture at all.

So the question I started from was: what if the "platform" lived on my desktop, and the server stayed a plain Linux box?

How Shipown works

Shipown is a desktop application (Windows and Linux today) that deploys and operates apps on a Linux VPS, cloud VM, or bare-metal server you control. It connects over plain SSH. No Shipown deployment agent is installed on the server; it uses what is already there.

The flow is five steps:

Connect a server. Host, port, user, and key or password. Shipown tests the connection before saving anything, so a bad credential fails at setup instead of halfway through a deploy.
Pick a source. A GitHub repository and one of its real branches (the list is fetched, not guessed), or a folder on your computer.
Review the plan. Framework, install/build/start commands, port, domain, and target are shown and every value is editable. Framework detection is a proposal, not a decision. You approve it, then it runs.
Watch it build. Choose a server build or a PC build. Output streams live over SSH. In PC mode the verified output is uploaded without rebuilding remotely.
Operate it. One page shows what is deployed, which commit it came from, how far behind its branch it is, health, logs, redeploy, rollback, or taking a site offline.

What it deploys

Node apps under PM2: Next.js, Nuxt, Remix, SvelteKit, NestJS, Fastify, and plain Express. Installed, built, and started on your server with the port, health check, and restart policy set.
Static sites on Nginx: Vite (React or Vue), Astro, or plain HTML, published to a release directory and served straight from Nginx. No process, no port.
Docker apps: supported Dockerfile and Compose projects, images labelled with the commit they came from, routed through Nginx to 127.0.0.1 when configured. The previous container is kept until the health check passes.

Docker is optional. Node apps run directly under PM2 and static sites from Nginx on a server with no Docker at all.

Domains, HTTPS, and rollback

When you point a domain at an app, Shipown writes the Nginx virtual host, tests the config before reloading, and asks Certbot for a certificate when you want HTTPS. If Nginx rejects a config, it is put back the way it was. Certificate expiry is surfaced in the app.

Every deploy goes into its own release directory. A Shipown-managed app can return to a retained release (or an earlier image for Docker) while its files are still available. Detected runtime failures trigger recovery attempts. I want to be clear about limits here: recovery can fail if the server is unreachable or prerequisites are missing, and database migrations and persistent data need their own recovery plan.

Monitoring without a metrics stack

The server view shows CPU, RAM, disk, load average, and PM2 processes, read directly from /proc and pm2 jlist, next to an embedded xterm terminal (a real PTY). So there are no extra collectors to install. Heartbeats keep running from the tray: two consecutive failures report one "unreachable" incident, and recovery is reported once. These checks need the app running and your PC awake.

The AI terminal: one command at a time

This is the part I care about most. When something breaks — a 502 from Nginx, a crashed PM2 process, a full disk — you can describe it in plain language. Using your own Anthropic, OpenAI, or DeepSeek API key, the model inspects the server and proposes one shell command at a time, with its reason. You approve each command before it runs.

Destructive commands such as recursive deletes, reboots, firewall flushes, or stopping SSH are always held for confirmation. The AI never runs on Shipown's servers: requests go from your computer to the provider you chose, and your key is encrypted by the OS. Prompts and command output do go to that provider, so review output for secrets before sharing.

What Shipown is not

A few honest boundaries, because they matter when you pick a tool:

No auto-deploy on push. Shipown tells you when a branch has moved ahead and how many commits are waiting, but a person presses deploy.
Not open source. It is a commercial desktop app. What runs on your server is plain SSH and shell.
Not fully offline. The desktop app uses a hosted licence service (with limited offline grace) and a hosted update service.
Windows and macOS are not server targets. The targets are Linux servers.

Pricing and trial

Every plan is the full product. There is a free 30-day trial (1 server, 1 seat, 1 device) with no card required. After that, Pro is $5/month or $32/year: 1 seat, 2 devices, unlimited servers. A purchase covers a fixed period and does not renew automatically, and an unused licence can be refunded within seven days.

Platforms and current status

The desktop app runs on Windows (.exe) and Linux (.deb for Debian/Ubuntu). macOS (Apple Silicon and Intel) is coming in the next release.

Shipown is currently a release candidate (v0.1.0-rc.10). The docs state plainly that an end-to-end verification matrix across server OS versions, architectures, and runtimes has not been completed for this release, so check the supported environments page before choosing a setup.

Try it

If you rent a VPS and want the deploy-and-rollback workflow without moving your app onto someone else's platform, give it a try at shipown.com. Feedback from people running real servers is exactly what this RC stage needs.

I'm Vishvajeet Shukla, a full stack developer in Jaipur and the builder of Shipown. More of my work is at vishvajeetshukla.in.

Next.js Server vs Client Components: 2026 Developer Tips

Vishvajeet Shukla — Tue, 20 Oct 2026 08:48:59 +0000

In 2026 the Next.js App Router still defaults layouts and pages to Server Components. That is not a slogan. It means you fetch close to the database, keep keys off the client, and ship less JavaScript. The teams that struggle are the ones who paste 'use client' at the top of every file “just in case.”

I am Vishvajeet Shukla. I ship production Next.js sites. These are the habits I wish juniors learned before they “optimise” a brochure site into a 400 kb client tree. If you are choosing a CMS rather than writing components, start with Next.js vs WordPress.

Related: Core Web Vitals · mobile-first checklist.

The 2026 default, in one sentence

Official Next.js docs (updated August 2026) still say: use Client Components when you need interactivity or browser APIs; use Server Components to fetch, to hide secrets, to cut JS, and to improve First Contentful Paint with streaming. That split is the golden rule this year. Vercel-facing write-ups keep repeating 30–40% smaller bundles when people actually follow it.

Tip 1: Server is the default. Mark client last

If a file only maps props to JSX, it is a Server Component. You do not need hooks to render a card. You need 'use client' for useState, useEffect, click handlers, and window. Push that leaf down. Keep the page and the data fetch above it.

A whole tree marked client throws away the App Router. I still open codebases where layout.tsx is client because someone put a theme toggle in it. Extract the toggle. Leave the layout on the server.

Tip 2: Fetch in the Server Component, not in useEffect

The old pattern — mount, spinner, fetch — is how you leak waterfalls and empty first paint. In the App Router an async Server Component can await the database and stream HTML. Secrets stay on the server. The official getting-started page is explicit: fetch near the source, do not expose tokens.

If a child needs interactivity, pass serialisable props down. Do not fetch the same list again in the client “for freshness” unless you have a real live requirement.

Tip 3: Know which cache you are fighting

Next.js has more than one cache: request memoisation, the data cache, the full route cache, the router cache. When a page “won’t update,” read which layer you set. unstable_cache plus ISR is how this site’s blog used to look stale until we busted a tag. Same class of bug as “I published and nothing changed.”

In local dev, Server Component edits re-fetch. For large apps the experimental serverComponentsHmrCache can cache those fetches across HMR so you do not burn a paid API on every save. That is a 2026 local-dev tip from the official local-development guide, not a Twitter myth.

Tip 4: Stream the slow part

Wrap the product grid in Suspense with a loading.js sibling. The hero can paint while the catalogue waits. Users on Jio 4G feel that more than they feel your folder structure. Pair it with real image work from the slow website guide.

Tip 5: Do not fetch in a Client Component just to use a hook

Need a like button? Server Component fetches the count. Client Component is a 20-line button that posts to a Route Handler. That is composition, not a rewrite.

A review checklist before you merge

How many files have 'use client'? If it is most of app/, stop.
Are env secrets only imported from server files?
Does the first HTML include the main heading without waiting for JS?
Did you add a loading UI for the slow query?

If the page works with JavaScript disabled for the main content, you probably used Server Components correctly.

How I split a real marketing page

Hero with a heading and a primary button: server. The button that opens a drawer: a tiny client child. The blog list: server fetch from Firestore. The search box: client. The footer: server. That is an entire SME homepage with two client files. I have seen the same homepage as one 800-line client component importing framer-motion, a map, and a form library “for later.” Later never comes. The JS always does.

When you add a third-party chat or analytics snippet, load it after idle. Do not wrap the whole layout in a provider that is a client component unless you must. Providers are how a single theme hook infects the tree. Read the import graph once a month. If page.tsx imports a file that imports a file that says 'use client', you just bought that graph for the route.

For data that changes per request (a draft preview, a personalised dashboard), opt out of caching on purpose and write it down in the PR. Silent no-store everywhere is how you pay for a serverless function on every asset request. Silent force-cache is how clients call you because yesterday’s price is still on the page. Choose, then document.

What this is not

This is not “never use client.” Forms, maps, drawers, and three.js scenes belong on the client. It is “do not pay the client tax for a paragraph.” For SME marketing sites that tax shows up as a bad LCP and a bounce. For dashboards it shows up as a 3G laptop fanspin.

A migration note if you are stuck on Pages Router

Do not port a file a day without a map. List routes that need SEO HTML first — home, services, blog — and move those to app/. Leave a messy dashboard on Pages Router for a sprint if you must. Mixing forever is how two data-fetch styles live in one head. Official stance in 2026 is still: new work belongs in App Router.

When you move a page, delete the client fetch that duplicated the server query. I have migrated sites that called the same API twice, once in getServerSideProps and once in useEffect, “because it flickered.” It flickered because the client refetch raced. One server await fixes it.

FAQ

Should every new Next.js app use the App Router in 2026?

Yes for new work. Pages Router is maintenance. Official examples and docs assume app/.

Can I mix App Router and Pages Router?

You can. You will confuse yourself. Don’t, unless you are migrating.

Do Server Components replace an API route?

They replace a lot of “GET for this page” routes. You still want Route Handlers for webhooks, webhooks, and browser mutations.

Why is my client bundle still huge?

A client parent pulls every import with it. Move the heavy chart into its own client file. Keep the page server.

Does this help SEO?

Yes, when the HTML arrives with the words Google should index. A client-only render can still work, but you are fighting the default. See ranking on Google.

Next step

If a Next.js site feels heavy, send the repo or the live URL. I will tell you which files should lose 'use client' before we talk about a new host.

Contact · vishvajeet4711@gmail.com · hello@vishvajeetshukla.in · More guides

Originally published at vishvajeetshukla.in

Building a Real-Time Chat App with MERN and Socket.io (Complete Guide)

Vishvajeet Shukla — Tue, 20 Oct 2026 08:46:29 +0000

When I started freelancing from Jaipur, one of the first “real” full-stack projects I built for learning and client demos was a real-time chat app. Not a toy alert box — a working MERN stack chat with login, rooms, live messages, and message history.

In this guide I walk through the same architecture I still use as a foundation: MongoDB + Express + React + Node.js, with Socket.io for real-time delivery. You will leave with a complete, runnable flow — not a half-finished intro.

Who this is for: developers who know basic JavaScript/React and want a production-minded chat skeleton they can extend for support widgets, community apps, or client MVPs.

What You Will Build

User signup / login with JWT
Persistent messages in MongoDB
Live message broadcast with Socket.io
A simple React chat UI (list + input)
Basic security: auth on HTTP + socket handshake

Stack choices (and why):

MongoDB — flexible documents for users and chat history
Express — clean REST for auth and history
React — component UI, easy socket lifecycle
Socket.io — rooms, reconnect, browser-friendly WebSockets

Prerequisites

Node.js 18+
MongoDB (local or Atlas free cluster)
Basic React hooks knowledge
A code editor and terminal

node -v
npm -v

Project Structure

chat-app/
├── server/
│   ├── package.json
│   ├── index.js
│   ├── models/
│   │   ├── User.js
│   │   └── Message.js
│   ├── middleware/
│   │   └── auth.js
│   └── routes/
│       └── auth.js
└── client/
    ├── package.json
    └── src/
        ├── App.jsx
        ├── api.js
        ├── socket.js
        └── components/
            ├── Login.jsx
            └── Chat.jsx

I keep backend and frontend separate so you can later host the API on Render/Railway and the React app on Vercel without rewriting everything.

Step 1 — Backend Setup

mkdir chat-app && cd chat-app
mkdir server && cd server
npm init -y
npm install express mongoose cors dotenv bcryptjs jsonwebtoken socket.io
npm install -D nodemon

server/.env:

PORT=5000
MONGO_URI=mongodb://127.0.0.1:27017/mern-chat
JWT_SECRET=replace_with_a_long_random_string
CLIENT_URL=http://localhost:5173

Tip: Never commit real secrets. For production, use environment variables on your host.

User and Message models

server/models/User.js:

const mongoose = require('mongoose');

const userSchema = new mongoose.Schema(
  {
    username: { type: String, required: true, unique: true, trim: true, minlength: 3 },
    passwordHash: { type: String, required: true },
  },
  { timestamps: true }
);

module.exports = mongoose.model('User', userSchema);

server/models/Message.js:

const mongoose = require('mongoose');

const messageSchema = new mongoose.Schema(
  {
    room: { type: String, required: true, default: 'general', index: true },
    sender: { type: mongoose.Schema.Types.ObjectId, ref: 'User', required: true },
    text: { type: String, required: true, trim: true, maxlength: 2000 },
  },
  { timestamps: true }
);

module.exports = mongoose.model('Message', messageSchema);

I index room because history queries always filter by room. That small detail matters once you have thousands of messages.

Auth middleware

server/middleware/auth.js:

const jwt = require('jsonwebtoken');

function auth(req, res, next) {
  const header = req.headers.authorization || '';
  const token = header.startsWith('Bearer ') ? header.slice(7) : null;
  if (!token) return res.status(401).json({ error: 'Missing token' });

  try {
    const payload = jwt.verify(token, process.env.JWT_SECRET);
    req.user = { id: payload.id, username: payload.username };
    next();
  } catch {
    return res.status(401).json({ error: 'Invalid token' });
  }
}

module.exports = auth;

Auth routes

server/routes/auth.js:

const express = require('express');
const bcrypt = require('bcryptjs');
const jwt = require('jsonwebtoken');
const User = require('../models/User');

const router = express.Router();

router.post('/signup', async (req, res) => {
  try {
    const username = String(req.body.username || '').trim().toLowerCase();
    const password = String(req.body.password || '');

    if (username.length < 3 || password.length < 6) {
      return res.status(400).json({ error: 'Username min 3 chars, password min 6' });
    }

    const exists = await User.findOne({ username });
    if (exists) return res.status(409).json({ error: 'Username already taken' });

    const passwordHash = await bcrypt.hash(password, 10);
    const user = await User.create({ username, passwordHash });

    const token = jwt.sign(
      { id: user._id.toString(), username: user.username },
      process.env.JWT_SECRET,
      { expiresIn: '7d' }
    );

    res.status(201).json({ token, user: { id: user._id, username: user.username } });
  } catch (err) {
    console.error(err);
    res.status(500).json({ error: 'Signup failed' });
  }
});

router.post('/login', async (req, res) => {
  try {
    const username = String(req.body.username || '').trim().toLowerCase();
    const password = String(req.body.password || '');

    const user = await User.findOne({ username });
    if (!user) return res.status(401).json({ error: 'Invalid credentials' });

    const ok = await bcrypt.compare(password, user.passwordHash);
    if (!ok) return res.status(401).json({ error: 'Invalid credentials' });

    const token = jwt.sign(
      { id: user._id.toString(), username: user.username },
      process.env.JWT_SECRET,
      { expiresIn: '7d' }
    );

    res.json({ token, user: { id: user._id, username: user.username } });
  } catch (err) {
    console.error(err);
    res.status(500).json({ error: 'Login failed' });
  }
});

module.exports = router;

Step 2 — Express + Socket.io Server

server/index.js is the heart of the app: one HTTP server shared by Express and Socket.io.

require('dotenv').config();
const http = require('http');
const express = require('express');
const cors = require('cors');
const mongoose = require('mongoose');
const jwt = require('jsonwebtoken');
const { Server } = require('socket.io');

const authRoutes = require('./routes/auth');
const auth = require('./middleware/auth');
const Message = require('./models/Message');

const app = express();
const server = http.createServer(app);

const io = new Server(server, {
  cors: {
    origin: process.env.CLIENT_URL,
    methods: ['GET', 'POST'],
  },
});

app.use(cors({ origin: process.env.CLIENT_URL }));
app.use(express.json({ limit: '16kb' }));

app.get('/health', (_req, res) => res.json({ ok: true }));
app.use('/api/auth', authRoutes);

// Load last 50 messages for a room (history after refresh)
app.get('/api/messages/:room', auth, async (req, res) => {
  try {
    const room = req.params.room || 'general';
    const messages = await Message.find({ room })
      .sort({ createdAt: -1 })
      .limit(50)
      .populate('sender', 'username')
      .lean();

    res.json(
      messages
        .reverse()
        .map((m) => ({
          id: m._id,
          room: m.room,
          text: m.text,
          username: m.sender?.username || 'unknown',
          createdAt: m.createdAt,
        }))
    );
  } catch (err) {
    console.error(err);
    res.status(500).json({ error: 'Could not load messages' });
  }
});

// Socket auth: same JWT as REST
io.use((socket, next) => {
  try {
    const token = socket.handshake.auth?.token;
    if (!token) return next(new Error('Unauthorized'));
    const payload = jwt.verify(token, process.env.JWT_SECRET);
    socket.user = { id: payload.id, username: payload.username };
    next();
  } catch {
    next(new Error('Unauthorized'));
  }
});

io.on('connection', (socket) => {
  console.log('connected:', socket.user.username);

  socket.on('join_room', (room = 'general') => {
    const safeRoom = String(room).slice(0, 40);
    socket.join(safeRoom);
    socket.data.room = safeRoom;
    socket.to(safeRoom).emit('system', {
      text: `${socket.user.username} joined`,
    });
  });

  socket.on('send_message', async ({ text, room }) => {
    try {
      const clean = String(text || '').trim().slice(0, 2000);
      const targetRoom = String(room || socket.data.room || 'general').slice(0, 40);
      if (!clean) return;

      const doc = await Message.create({
        room: targetRoom,
        sender: socket.user.id,
        text: clean,
      });

      const payload = {
        id: doc._id,
        room: targetRoom,
        text: clean,
        username: socket.user.username,
        createdAt: doc.createdAt,
      };

      // Emit to everyone in the room (including sender for consistency)
      io.to(targetRoom).emit('new_message', payload);
    } catch (err) {
      console.error(err);
      socket.emit('error_message', { error: 'Message not sent' });
    }
  });

  socket.on('disconnect', () => {
    console.log('disconnected:', socket.user.username);
  });
});

async function start() {
  await mongoose.connect(process.env.MONGO_URI);
  console.log('MongoDB connected');
  server.listen(process.env.PORT || 5000, () => {
    console.log(`API + Socket on :${process.env.PORT || 5000}`);
  });
}

start().catch((err) => {
  console.error(err);
  process.exit(1);
});

Why auth on the socket matters: If you only protect REST routes, anyone can open a socket and spam your room. Handshake JWT verification is non-negotiable for a serious demo.

Add to server/package.json:

"scripts": {
  "dev": "nodemon index.js",
  "start": "node index.js"
}

npm run dev

Step 3 — React Client

cd ..
npm create vite@latest client -- --template react
cd client
npm install
npm install socket.io-client
npm run dev

Set the API base in client/.env:

VITE_API_URL=http://localhost:5000

client/src/api.js:

const API = import.meta.env.VITE_API_URL;

export async function signup(username, password) {
  const res = await fetch(`${API}/api/auth/signup`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ username, password }),
  });
  const data = await res.json();
  if (!res.ok) throw new Error(data.error || 'Signup failed');
  return data;
}

export async function login(username, password) {
  const res = await fetch(`${API}/api/auth/login`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ username, password }),
  });
  const data = await res.json();
  if (!res.ok) throw new Error(data.error || 'Login failed');
  return data;
}

export async function fetchMessages(token, room = 'general') {
  const res = await fetch(`${API}/api/messages/${room}`, {
    headers: { Authorization: `Bearer ${token}` },
  });
  const data = await res.json();
  if (!res.ok) throw new Error(data.error || 'History failed');
  return data;
}

client/src/socket.js:

import { io } from 'socket.io-client';

const API = import.meta.env.VITE_API_URL;

export function createSocket(token) {
  return io(API, {
    auth: { token },
    autoConnect: true,
  });
}

client/src/components/Login.jsx:

import { useState } from 'react';
import { login, signup } from '../api';

export default function Login({ onAuth }) {
  const [username, setUsername] = useState('');
  const [password, setPassword] = useState('');
  const [mode, setMode] = useState('login');
  const [error, setError] = useState('');
  const [loading, setLoading] = useState(false);

  async function handleSubmit(e) {
    e.preventDefault();
    setError('');
    setLoading(true);
    try {
      const fn = mode === 'login' ? login : signup;
      const data = await fn(username, password);
      localStorage.setItem('chat_token', data.token);
      localStorage.setItem('chat_user', JSON.stringify(data.user));
      onAuth(data);
    } catch (err) {
      setError(err.message);
    } finally {
      setLoading(false);
    }
  }

  return (
    <form onSubmit={handleSubmit} style={{ maxWidth: 360, margin: '4rem auto' }}>
      <h1>{mode === 'login' ? 'Login' : 'Sign up'}</h1>
      {error && <p style={{ color: 'crimson' }}>{error}</p>}
      <input
        placeholder="Username"
        value={username}
        onChange={(e) => setUsername(e.target.value)}
        required
      />
      <input
        type="password"
        placeholder="Password"
        value={password}
        onChange={(e) => setPassword(e.target.value)}
        required
      />
      <button disabled={loading} type="submit">
        {loading ? 'Please wait…' : mode === 'login' ? 'Login' : 'Create account'}
      </button>
      <button type="button" onClick={() => setMode(mode === 'login' ? 'signup' : 'login')}>
        Switch to {mode === 'login' ? 'Sign up' : 'Login'}
      </button>
    </form>
  );
}

client/src/components/Chat.jsx:

import { useEffect, useRef, useState } from 'react';
import { fetchMessages } from '../api';
import { createSocket } from '../socket';

const ROOM = 'general';

export default function Chat({ auth, onLogout }) {
  const [messages, setMessages] = useState([]);
  const [text, setText] = useState('');
  const [status, setStatus] = useState('connecting');
  const bottomRef = useRef(null);
  const socketRef = useRef(null);

  useEffect(() => {
    let active = true;
    const socket = createSocket(auth.token);
    socketRef.current = socket;

    (async () => {
      try {
        const history = await fetchMessages(auth.token, ROOM);
        if (active) setMessages(history);
      } catch (err) {
        console.error(err);
      }
    })();

    socket.on('connect', () => {
      setStatus('online');
      socket.emit('join_room', ROOM);
    });
    socket.on('disconnect', () => setStatus('offline'));
    socket.on('connect_error', () => setStatus('auth error'));

    socket.on('new_message', (msg) => {
      setMessages((prev) => [...prev, msg]);
    });
    socket.on('system', (msg) => {
      setMessages((prev) => [
        ...prev,
        { id: crypto.randomUUID(), text: msg.text, username: 'system', createdAt: new Date().toISOString() },
      ]);
    });

    return () => {
      active = false;
      socket.disconnect();
    };
  }, [auth.token]);

  useEffect(() => {
    bottomRef.current?.scrollIntoView({ behavior: 'smooth' });
  }, [messages]);

  function send(e) {
    e.preventDefault();
    const clean = text.trim();
    if (!clean || !socketRef.current) return;
    socketRef.current.emit('send_message', { text: clean, room: ROOM });
    setText('');
  }

  return (
    <div style={{ maxWidth: 640, margin: '2rem auto' }}>
      <header style={{ display: 'flex', justifyContent: 'space-between' }}>
        <div>
          <strong>#{ROOM}</strong> · {auth.user.username} · {status}
        </div>
        <button onClick={onLogout}>Logout</button>
      </header>

      <div style={{ height: 420, overflowY: 'auto', border: '1px solid #ddd', padding: 12, marginTop: 12 }}>
        {messages.map((m) => (
          <div key={m.id} style={{ marginBottom: 8 }}>
            <strong>{m.username}</strong>:{' '}
            <span>{m.text}</span>
          </div>
        ))}
        <div ref={bottomRef} />
      </div>

      <form onSubmit={send} style={{ display: 'flex', gap: 8, marginTop: 12 }}>
        <input
          style={{ flex: 1 }}
          value={text}
          onChange={(e) => setText(e.target.value)}
          placeholder="Type a message…"
          maxLength={2000}
        />
        <button type="submit">Send</button>
      </form>
    </div>
  );
}

client/src/App.jsx:

import { useMemo, useState } from 'react';
import Login from './components/Login';
import Chat from './components/Chat';

export default function App() {
  const initial = useMemo(() => {
    const token = localStorage.getItem('chat_token');
    const userRaw = localStorage.getItem('chat_user');
    if (!token || !userRaw) return null;
    try {
      return { token, user: JSON.parse(userRaw) };
    } catch {
      return null;
    }
  }, []);

  const [auth, setAuth] = useState(initial);

  function handleLogout() {
    localStorage.removeItem('chat_token');
    localStorage.removeItem('chat_user');
    setAuth(null);
  }

  if (!auth) return <Login onAuth={setAuth} />;
  return <Chat auth={auth} onLogout={handleLogout} />;
}

Open two browsers (or one normal + one incognito), create two users, join general, and send messages. You should see live delivery without refresh — that is Socket.io doing its job.

How the Real-Time Flow Works

User logs in → server returns JWT.
React stores JWT and opens a Socket.io connection with auth: { token }.
Server verifies JWT before accepting the socket.
Client joins room general.
Client loads last 50 messages via REST (so refresh is not empty).
On send, server saves MongoDB document, then io.to(room).emit('new_message').
Every client in the room appends the message to UI state.

That split — REST for history, sockets for live events — is the pattern I recommend for client projects. Pure sockets-only apps get messy for pagination and SEO tooling; pure REST-only apps feel laggy.

Security Checklist (Do Not Skip)

Hash passwords with bcrypt (never store plain text).
Verify JWT on sockets, not only on HTTP routes.
Limit message length (we used 2000 chars) to stop abuse.
Sanitize room names so users cannot invent huge random rooms forever without control.
Rate-limit login and send events in production (express-rate-limit + socket throttling).
CORS locked to your real frontend origin.
For public apps, add report/block features and moderation later.

Common Mistakes I See (and How to Fix Them)

Problem	Likely cause	Fix
Messages vanish on refresh	Only using sockets, no DB history	Save to MongoDB + GET history endpoint
Socket connects then drops	JWT missing/expired in handshake	Pass token in `auth`, handle reconnect after re-login
CORS errors in browser	Client URL not allowed	Match `CLIENT_URL` and Vite origin exactly
Duplicate messages	Emitting to sender twice incorrectly	Use one room emit path; avoid optimistic double-append bugs
Works locally, fails online	Mixed HTTP/HTTPS or wrong API URL	HTTPS everywhere; env vars per environment

Optional Upgrades (When Clients Ask)

Private DMs: room id = sorted pair of user ids
Typing indicators: socket.emit('typing') with debounce
Read receipts: store last-read timestamps
File uploads: Cloudinary / S3 + message type image
Presence: Redis adapter when you scale past one server process
Next.js frontend: same socket client works; keep API on a long-lived Node server (Vercel serverless is a poor fit for Socket.io alone)

For multi-instance deploys, add the Socket.io Redis adapter so rooms sync across processes. One Node process is fine for demos and early MVPs.

Deploy Outline (Practical)

MongoDB Atlas free cluster → copy URI into server env.
Deploy server to Railway / Render / a VPS (needs sticky sessions or Redis adapter for multi-instance).
Deploy client to Vercel/Netlify with VITE_API_URL pointing to your API.
Update CLIENT_URL on the server to the live frontend origin.

If you want a single-domain setup later, put Nginx or Cloudflare in front and proxy /api + /socket.io to Node.

What This Project Teaches Employers / Clients

A complete chat app signals more than “I know React.” It shows you can:

Design data models
Handle auth correctly
Mix REST and real-time protocols
Think about security and edge cases
Ship something demoable in a portfolio

When I talk to local businesses in Jaipur about custom dashboards or support chat, this is the same backbone — just restyled and connected to their leads or orders.

Frequently Asked Questions

Is Socket.io better than raw WebSockets?

Raw WebSockets are lighter. Socket.io adds reconnect, rooms, fallbacks, and a nicer event API. For freelance MVPs and teaching projects, Socket.io is usually the faster path.

Can I use this with Next.js instead of Vite?

Yes for the UI. Keep Socket.io on a long-running Node server. Pairing Next.js (frontend) + Express socket server (API) is a common production pattern.

Do I need Redis on day one?

No. Start with one server process. Add Redis when you scale horizontally or need shared presence across instances.

How do I stop spam?

Auth + rate limits + max message length. For public communities, add moderation tools and ban lists next.

Is this production-ready as-is?

It is a solid foundation — not a full product. Production needs HTTPS, hardened rate limits, monitoring, backups, and UX polish (retries, offline state, accessibility).

Conclusion

You now have a full MERN + Socket.io chat path: models, JWT auth, message history, live rooms, and a React UI. Build it once, break it on purpose, then extend it — private rooms, typing indicators, or a client support widget.

If you want help turning this into a branded chat feature for your product or business site, I build full-stack apps with Node, React/Next.js, and real-time features for clients in India and abroad.

Next step: run both servers, open two browsers, send a message, and confirm it appears live. That single green path is your foundation for everything more advanced.

Related guides

Originally published at vishvajeetshukla.in