DEV Community: Shams Ali Shaikh

Rhea.js 1.0: a security-first backend framework for Node.js and Express 5

Shams Ali Shaikh — Tue, 13 Oct 2026 11:21:22 +0000

I just released Rhea.js 1.0, an open-source backend framework for Node.js. It sits on top of Express 5 and adds the parts every API ends up needing: a project layout, security defaults, validation, logging, authentication and a CLI that generates code for you.

npx create-rhea my-api

This post explains what it is, why I built it, what you get, and, just as important, what it does not do yet.

The problem

Every Express project I started began the same way. Install Express. Add Helmet. Add CORS. Remember the body size limit. Add a rate limiter. Add a logger and then notice it prints passwords. Write an error handler. Decide on a folder layout. Copy the auth code from the last project.

Two things bothered me about that routine:

Security is opt-in. If you forget a step, nothing warns you. A fresh express() app has no security headers, no limits, and no opinion.
Every team invents its own structure. Nobody can open a new project and know where the validation lives.

Rhea.js is my answer: keep Express as the HTTP engine, and put the architecture and the safe defaults around it.

What Rhea.js is

A runtime package, @rheajs/core, with a createApp() function.
An auth package, @rheajs/auth (passwords, JWT, refresh tokens, guards).
A CLI, @rheajs/cli, and the scaffolder create-rhea.
Express 5 underneath. Your routes are normal Express routes. If you know Express, you already know most of Rhea.js.

It is MIT licensed, written in TypeScript, and works with TypeScript or JavaScript, ES Modules or CommonJS.

Get started in one minute

npx create-rhea my-api
cd my-api
npm run dev

The scaffolder asks four things: TypeScript or JavaScript, ES Modules or CommonJS, a database (MongoDB, MySQL or none) and, if you picked a database, whether to add authentication. Then it installs dependencies, runs git init, makes the first commit, and, if you have the GitHub CLI, can create the GitHub repository for you.

Open http://localhost:5000/api/rhea and you have a running API. Add a resource:

npx rhea generate module users

That creates the controller, service, repository, routes, Zod schema, types and an integration test, and registers the module.

What you get by default

Everything below is on from the first request, with no setup:

Request IDs on every request and every error response, so you can find a log line from a bug report.
Helmet security headers, plus a Permissions-Policy header.
CORS denied by default. You list the origins you trust. A wildcard is refused in production.
Rate limiting, with an option to share counters through Redis when you run more than one instance.
Body size limit, request timeout and JSON-only bodies (a form-encoded body gets a clean 415).
Prototype-pollution guard, and an optional guard against MongoDB operator keys such as {"$ne": null} in a login body (on in generated MongoDB projects).
One error shape. Throw NotFoundError or ConflictError from anywhere and the client always gets the same JSON. Stack traces never leave the server in production.
Structured logs with pino: JSON in production, readable in development, and passwords, tokens and cookies are redacted. In development you also get a short morgan line per request.
Validation with Zod for body, query and params, and environment validation that stops startup when your config is wrong.
Graceful shutdown and process error handlers.

A route looks like this:

import { Router, sendSuccess, validate, z } from "@rheajs/core";

const createUser = z.object({ name: z.string().min(1).max(100) });

export const users = Router();

users.post("/", validate(createUser), (req, res) =>
  sendSuccess(res, { name: req.body.name }, "Created", 201),
);

Invalid input returns 422 with a list of exactly which field failed, and the keys Zod strips never reach your handler.

Authentication that is not a tutorial snippet

Pick a database and say yes to authentication, and the generated project gets a complete flow:

POST /api/auth/register, login, refresh, logout, logout-all and GET /api/auth/me.
Short-lived access token (a JWT, 15 minutes) and a rotating refresh token. The refresh token is random, stored only as a SHA-256 hash, and replaced every time you use it.
Reuse detection. If an old refresh token is used again (a sign of theft), the whole session family is revoked. A short grace window handles honest double requests such as a flaky network.
Cookie mode for browser apps. Set AUTH_REFRESH_COOKIE=true and the refresh token lives in an HttpOnly, SameSite=Strict cookie, with an Origin check against CSRF. No token in localStorage.
Account lockout after five wrong passwords, and a common-password blocklist.
scrypt password hashing with OWASP-level parameters.

Protecting your own route is one line:

import { authenticate, requireRole } from "@rheajs/auth";

router.delete("/:id", authenticate(jwt), requireRole("admin"), handler);

I tested this flow against real MongoDB 7 and MySQL 8.4 over HTTP, including ten parallel refreshes with the same token (exactly one wins), and with a Next.js todo app in a real browser.

The CLI

Command	What it does
`rhea create`	scaffold a project
`rhea dev`	run with auto restart and graceful shutdown
`rhea generate module users`	controller, service, repository, routes, schema, test
`rhea doctor`	check your setup
`rhea security`	static scan for common config mistakes (`--audit` adds npm audit)
`rhea docker`	write a multi-stage, non-root Dockerfile
`rhea build` / `rhea start`	production build and run

Why not NestJS, Fastify or plain Express?

Honest answer: they are all good, and the right choice depends on you.

Plain Express is the fastest to start and the slowest to make safe. Rhea.js is Express plus the checklist.
NestJS is a large, decorator-based framework with dependency injection. Rhea.js is much smaller and has no decorators. It is plain functions and modules.
Fastify is faster and has its own ecosystem. If raw throughput is your top need, use Fastify.

Choose Rhea.js if you want Express and a safe starting point, with a layout your whole team can predict.

The honest part

Performance. On a trivial route Rhea.js reaches about 60% of the throughput of bare Express on my machine, because it does real work on every request (IDs, logging, headers, limits, checks). The numbers and the method are in BENCHMARKS.md. If you need raw speed and none of the checks, use bare Express.
Security review. Rhea.js is used in production by me. It has not had an independent security review. I wrote a self-audit that lists what was tested, what was fixed, and what is still open. If you can review it, I would love that.
Not included yet: server-side sessions, OAuth/OIDC, MFA, password reset, and an ORM. The rate limit is per process unless you pass a shared store.
Stability. From 1.0 it follows semantic versioning, and the docs say exactly what the public API is.

Try it and tell me what breaks

npx create-rhea my-api

Docs: https://rhea.devcodehub.cloud
GitHub: https://github.com/dev-shamsali/Rhea.js-framework
npm: https://www.npmjs.com/org/rheajs

If you try it, I would like to hear what was confusing or broken. Bug reports, questions and pull requests are all welcome. If you find a vulnerability, please follow SECURITY.md and report it privately.

Thanks for reading.

Building Settla: An AI-Powered Payment & Settlement Automation Platform

Shams Ali Shaikh — Tue, 06 Oct 2026 09:03:22 +0000

This is a submission for the MLH x DEV Writing Challenge

What I Built

For the Paytm AI Hackathon, I built Settla, an AI-powered payment and settlement automation platform designed to simplify payment operations, refunds, vendor management, and workflow automation.

The idea came from a simple observation: payment operations can become complicated when you have to deal with multiple transactions, vendors, refunds, and settlement processes manually.

I wanted to build something where AI wasn't just used as a chatbot, but could actually become part of the workflow.

That's where Settla came in.

The goal was to create a platform where users could interact with payment operations through an intelligent interface while the underlying system handled the actual business logic, integrations, and automation.

The Architecture

I built Settla as a full-stack application with an architecture focused on automation and extensibility.

The overall workflow looks like this:

User
  ↓
Settla Frontend
  ↓
Backend API
  ↓
AI / MCP Layer
  ↓
Payment Services
  ↓
n8n Automation
  ↓
Settlement / Refund Workflow

The backend handles the core application logic, while the automation layer is designed to connect different services and execute workflows.

I also focused heavily on testing during development.

The project currently includes:

135 backend tests
9 frontend unit tests
13 browser E2E tests

This was important because payment-related workflows need predictable behavior. A small mistake in a payment or refund workflow can have much bigger consequences than a normal application bug.

What I Learned

One of my biggest takeaways from building Settla was that AI is only one part of an AI-powered product.

The difficult part is building everything around it.

You need:

Reliable APIs
Authentication and authorization
Proper business logic
Tool permissions
Error handling
Testing
Workflow automation
External service integrations
Observability and maintainability

The AI becomes much more useful when it can safely interact with these systems.

That changed the way I think about AI applications.

Instead of:

"Let's add an AI chatbot."

I started thinking:

"What can the AI actually do inside the system?"

That's a much more interesting engineering problem.

Demo

I built Settla as a working full-stack application during the hackathon.

Project Links

GitHub: https://github.com/dev-shamsali/settla-frontend , https://github.com/dev-shamsali/settla-backend

Live Demo: https://settla.devcodehub.cloud/

Demo Flow

The intended Settla workflow is:

User Request
     ↓
AI Agent
     ↓
Tool / MCP
     ↓
Payment Operation
     ↓
Automation Workflow
     ↓
Settla Backend
     ↓
Result

The goal is to make complex payment operations easier to understand and automate instead of requiring users to manually perform every individual step.

Partner Technologies

One of the most interesting parts of building Settla was working with n8n and exploring Model Context Protocol (MCP).

n8n

I used n8n as the foundation for the automation layer.

Instead of putting every automation directly into the backend, n8n allows workflows to be composed visually and connected to different services.

For Settla, this opens up possibilities such as:

Payment Created
      ↓
Validate Transaction
      ↓
Process Workflow
      ↓
Update Settla
      ↓
Trigger Settlement
      ↓
Notify User

This makes the system easier to extend as more integrations are added.

MCP

I also explored Model Context Protocol to connect AI systems with external tools.

This was one of the most interesting technical parts of the project.

Instead of having an AI model simply generate text, MCP allows the AI layer to interact with tools that expose real application functionality.

Conceptually:

User
 ↓
AI
 ↓
MCP
 ↓
Tool
 ↓
External Service
 ↓
Result
 ↓
AI
 ↓
User

This approach made me think about AI agents differently.

The model doesn't need to know everything.

It needs access to the right tools, with the right permissions, and the application needs to enforce the business rules.

That separation between intelligence, tools, and business logic is something I found particularly valuable while building Settla.

Hackathon Experience

I participated in the Paytm AI Hackathon with Settla.

We didn't win this time.

Honestly, we weren't as prepared as we should have been.

But the experience was still extremely valuable.

The hackathon brought together developers, AI enthusiasts, builders, and people experimenting with completely different ideas.

I got the opportunity to discuss AI agents, payment systems, automation, MCP, architecture, and product ideas with other developers.

What I enjoyed most was the environment.

Everyone was trying to build something under a limited amount of time.

That creates a completely different development experience.

You have to constantly ask:

What should we build first?

What can we realistically finish?

What needs to be tested?

What should we leave for later?

And most importantly:

Can we actually demonstrate what we built?

That last question is something I learned the hard way.

Building the product is one thing.

Building it, testing it, preparing the demo, and presenting it effectively are completely different challenges.

What I'll Remember

I didn't leave the hackathon with a trophy.

I left with something else:

experience.

I learned more about building AI-powered systems, explored MCP and workflow automation, met developers and AI enthusiasts, discussed ideas with other builders, and understood where we need to improve for the next hackathon.

Most importantly, Settla gave me an opportunity to experiment with an idea that combines:

AI + Payments + MCP + Automation + Full-Stack Engineering

And that's something I'm proud of building.

Final Thoughts

Settla started as a hackathon project.

But while building it, it became much more than just an idea.

It became an experiment in how AI can interact with real systems instead of simply generating responses.

I didn't win the hackathon.

But I built something.

I tested it.

I learned from it.

I met great developers.

And I know exactly what I need to improve for the next one.

Sometimes the most valuable outcome of a hackathon isn't the prize.

It's knowing what you're capable of building next.

Built by Shams Ali Shaikh.

Your Code Isn't Done When It Works

Shams Ali Shaikh — Fri, 02 Oct 2026 06:13:21 +0000

Your Code Isn't Done When It Works

One of the biggest lessons I've learned as a developer is this:

Getting an application to work is only the beginning.

During development, we usually focus on one question:

"Does it work?"

But production asks much harder questions.

Can it handle traffic?

What happens when the server restarts?

What happens when the database goes down?

What happens when an API starts receiving unexpected requests?

Can we deploy a new version without breaking the existing one?

Can we find out what went wrong at 2 AM?

That's where software engineering becomes more than just writing code.

Localhost Is a Very Friendly Environment

On localhost, everything feels perfect.

npm run dev

The application starts.

The database is nearby.

Environment variables are available.

You have full access to the machine.

And if something breaks, you simply restart it.

Production doesn't care about any of that.

Production has:

Users
Traffic
DNS
SSL
Nginx
Firewalls
Processes
Databases
Logs
Backups
Monitoring
CI/CD
Security
Failures

And occasionally:

"Why is this server using 100% CPU?"

That's when the fun begins.

Writing Code vs Engineering Software

Writing code:

const user = await getUser(id);

Engineering the system around that code:

How is the request authenticated?
        ↓
How is the API protected?
        ↓
What happens if the database fails?
        ↓
How is the error logged?
        ↓
How is the application monitored?
        ↓
How is the new version deployed?
        ↓
How do we roll it back?

The code might be only a few lines.

The engineering around it can involve an entire architecture.

Production Changes Your Definition of "Done"

For me, a feature isn't really finished when:

Feature works

A better definition is:

Feature works
     +
Feature is tested
     +
Feature is secure
     +
Feature is observable
     +
Feature is deployable
     +
Feature is maintainable

That's a very different mindset.

The Deployment Lesson

I've spent a lot of time working with:

Next.js
Node.js
MongoDB
Docker
Nginx
PM2
GitHub Actions
Linux servers
CI/CD
VPS infrastructure

And one thing becomes obvious very quickly:

The application is only one part of the system.

A typical production flow might look like:

Developer
    |
    v
GitHub
    |
    v
CI/CD
    |
    v
Production Server
    |
    +---- Nginx
    |
    +---- Application
    |
    +---- Database
    |
    +---- Monitoring
    |
    +---- Logs
    |
    v
Users

Every layer can fail.

And every layer needs to be understood.

The Mindset Shift

Instead of asking:

"Does my code work?"

Start asking:

"What happens when my code doesn't work?"

That's where better engineering decisions start.

Build for failure.

Log for debugging.

Monitor for visibility.

Automate deployments.

Secure your infrastructure.

Keep backups.

Document your systems.

And most importantly:

Don't make production the place where you discover how your application works.

I'm Shams Ali Shaikh, and I'm documenting what I learn while building, deploying, and maintaining real-world applications.

Because writing code is satisfying.

But making that code survive production?

That's where the real engineering begins.

When Your Next.js App Works on Port 3000 but Production Says Nope

Shams Ali Shaikh — Thu, 10 Sep 2026 17:57:01 +0000

When Your Next.js App Works on Port 3000 but Production Says Nope

If you've ever deployed a Next.js application, you've probably experienced this:

Localhost: Works perfectly. Production: 502 Bad Gateway.

Your application is running.

Your process manager says it's online.

The server looks healthy.

And somehow, the browser still says:

"Nope."

This is where understanding Nginx reverse proxying becomes extremely useful.

I'm Shams Ali Shaikh, and in this post, I'll walk through one of the most common patterns I use when deploying Next.js and Node.js applications to a production server.

The Basic Problem

When running a Next.js application locally, you might use:

npm run dev

and access it through:

http://localhost:3000

In production, you might instead run:

npm run build npm run start

Your application is now listening on a port such as:

127.0.0.1:3000

But your users aren't going to visit:

http://your-server-ip:3000

They expect:

https://example.com

That's where Nginx comes in.

What Is Nginx Doing Here?

Think of Nginx as the receptionist sitting in front of your application.

The user talks to Nginx.

Nginx talks to your application.

The application doesn't need to be directly exposed to the internet.

The architecture looks like this:

This simple architecture solves a lot of deployment problems.

Basic Nginx Configuration

A basic configuration can look like this:

server { listen 80; server_name example.com www.example.com; location / { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; 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; } }

The important part is:

proxy_pass http://127.0.0.1:3000;

This tells Nginx:

"When someone requests this domain, forward the request to the application running on port 3000."

Testing the Configuration

After changing the Nginx configuration, don't immediately restart everything.

First test the configuration:

sudo nginx -t

If the configuration is valid, reload Nginx:

sudo systemctl reload nginx

This is a small habit that can save you from turning a configuration change into a production incident.

What If You Get a 502?

This is where things become interesting.

If Nginx returns:

502 Bad Gateway

don't immediately start changing random Nginx settings.

First check whether your application is actually running.

For example:

pm2 status

Then test the application directly:

curl http://127.0.0.1:3000

If this doesn't respond, the problem probably isn't Nginx.

Your application might have:

Crashed Failed to start Started on another port Failed because of environment variables Failed during the production build Been stopped by PM2 or another process manager

If curl works but the domain doesn't, then investigate the Nginx configuration, DNS, SSL, firewall, or networking.

Checking Nginx Logs

When things still aren't clear, logs become your best friend.

Check the Nginx error log:

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

You can also inspect the access log:

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

Logs usually give you a much better answer than repeatedly refreshing the browser and hoping for a miracle.

One Server, Multiple Applications

One of the reasons I like this architecture is that you can run multiple applications on the same server.

For example:

Nginx becomes the traffic controller.

Different domains can point to different applications and ports.

Adding HTTPS

In a real production environment, you generally don't want users accessing your application through plain HTTP.

The production flow becomes:

Nginx can terminate the TLS connection while your application continues running internally.

This also means your application doesn't necessarily need to manage the public SSL connection itself.

My Production Debugging Checklist

When a deployed Next.js application isn't working, I usually go layer by layer:

Is the application running? pm2 status 2. Is the application responding? curl http://127.0.0.1:3000 3. Is Nginx running? sudo systemctl status nginx 4. Is the configuration valid? sudo nginx -t 5. What does Nginx say? sudo tail -f /var/log/nginx/error.log 6. Is DNS pointing to the correct server?

Check the domain's DNS records.

Is HTTPS configured correctly?

Check the certificate and TLS configuration.

Is the required port accessible?

Check your firewall and server networking rules.

The important part is not to troubleshoot everything at once.

Start from the application and move outward.

Application ↓ Port ↓ Process ↓ Nginx ↓ HTTPS ↓ DNS ↓ Internet The Bigger Lesson

Deployment is not simply:

git push → website

A production application is a collection of interconnected layers.

Developer ↓ GitHub ↓ CI/CD ↓ Production Server ↓ Docker / PM2 ↓ Next.js / Node.js ↓ Nginx ↓ HTTPS ↓ Domain ↓ Users

When you understand each layer, debugging becomes much easier.

You stop asking:

"Why isn't my website working?"

And start asking:

"Which layer is failing?"

That change in thinking is one of the most useful things I've learned while working with production deployments.

Because "it works on my machine" might be a perfectly valid development statement.

It just isn't a very convincing production strategy.

I'm documenting what I learn while building and deploying real applications, from localhost to production.

More deployment and DevOps guides coming soon.

— Shams Ali Shaikh

From “It Works on My Machine” to Production: My DevOps Journey

Shams Ali Shaikh — Tue, 01 Sep 2026 13:13:00 +0000

From “It Works on My Machine” to “Why Is Production Down?”

Hi, I’m Shams Ali Shaikh, a Software Engineer passionate about building applications and figuring out how to make them actually work in production.

Writing code is one thing.

Deploying it without breaking the server is a completely different adventure.

Over the past few projects, I’ve been exploring application deployment, servers, DevOps, infrastructure automation, and production architecture.

Here are some of the topics I’ll be sharing:

How I Deploy Next.js Applications Using Nginx
Complete Docker Deployment Guide for Node.js
CI/CD Pipeline Using GitHub Actions
Terraform for Beginners: Infrastructure Automation
How I Configure Production Servers
MERN Application Deployment Architecture

Because building an application is only half the job.

The real challenge starts when you hear:

"It works perfectly on my local machine."

Then production introduces you to:

Nginx configuration issues
Docker containers that suddenly stop
Missing environment variables
SSL certificate problems
Firewall rules
Port conflicts
PM2 processes
CI/CD pipeline failures
And, of course, the legendary 502 Bad Gateway

My goal is to document everything I learn while building, deploying, breaking, fixing, and optimizing modern web applications.

I’ll be sharing practical experiences around:

MERN Stack Development
Next.js
Node.js
Docker
Nginx
GitHub Actions
CI/CD
VPS Deployment
Terraform
DevOps
Production Infrastructure

No unnecessary theory. No overcomplicated tutorials.

Just practical development, real deployment problems, infrastructure challenges, and solutions discovered along the way.

If you're interested in building applications and taking them from localhost to production, follow along.

Because writing the code is easy.

Finding out why it works locally but not in production is where the real character development begins.

— Shams Ali Shaikh
Software Engineer | MERN Stack | DevOps | Deployment