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:

1. 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.
2. Pick a source. A GitHub repository and one of its real branches (the list is fetched, not guessed), or a folder on your computer.
3. 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.
4. 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.
5. 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.

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:

1. 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.
2. Pick a source. A GitHub repository and one of its real branches (the list is fetched, not guessed), or a folder on your computer.
3. 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.
4. 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.
5. 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.

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

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

1. User logs in → server returns JWT.
2. React stores JWT and opens a Socket.io connection with auth: { token }.
3. Server verifies JWT before accepting the socket.
4. Client joins room general.
5. Client loads last 50 messages via REST (so refresh is not empty).
6. On send, server saves MongoDB document, then io.to(room).emit('new_message').
7. 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)

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)

1. MongoDB Atlas free cluster → copy URI into server env.
2. Deploy server to Railway / Render / a VPS (needs sticky sessions or Redis adapter for multi-instance).
3. Deploy client to Vercel/Netlify with VITE_API_URL pointing to your API.
4. 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

• All blog posts
• Website cost in Jaipur
• Contact Vishvajeet

Originally published at vishvajeetshukla.in