I have a NestJS backend with Postgres DB (Neon) and BullMQ (Local redis on the same vps) running. The backend has an endpoint that accepts files and compresses them and then makes an API call to OpenRouter to extract the information from the file. The frontend doesn't use presigned urls to upload directly to S3 yet. The backend also runs some cron jobs.

I am currently running the whole setup (nest backend docker container + BullMQ Redis docker container on same vps) on a 2 core vCPU VPS from Hetzner. But I think the backend is only able to utilize 1 core. I may upgrade to a 4 core cpu soon but before that, I want the backend to be able to utilize all available cpu cores on the machine that its deployed on. How can we achieve that? The Redis BullMQ runs on the same machine as the backend, so I'm afraid a single job might get processed multiple times.

I've been working on a project called nest-sequelize-repository that aims to bring a TypeORM-like repository experience to NestJS + Sequelize, while still using Sequelize under the hood.

The goal isn't to replace Sequelize or build another ORM. It's simply to reduce boilerplate and provide a reusable, strongly typed abstract repository for common CRUD operations and patterns.

Current features

• Generic abstract repository
• Type-safe CRUD operations
• Pagination support
• Soft delete support
• Transaction support
• Custom repository extensions
• Better error handling

Planned roadmap

• Cursor pagination
• More repository helpers and developer experience improvements

I'd really appreciate feedback from people using NestJS + Sequelize.

• What repetitive code do you find yourself writing in every repository?
• What's the biggest pain point when working with Sequelize in NestJS?
• Are there any features you'd love to see in a library like this?

NPM: https://www.npmjs.com/package/@nestlize/repository

Repository: https://github.com/stbestichhh/nest-sequelize-repository

I'd love to hear your thoughts and ideas!

I am about to embark on a large multi application project, and am back to weighing the pros and cons of each framework.

In my opinion, Nest is the only Node backend worth running, due to its strictly typed, opinionated nature. It keeps things organized and maintainable. Native GraphQL support is super nice as well.
That said, Symfony is so good, predictable, and honestly relaxing to use and maintain due to it's debugging capabilities.

Here are my two cents for the pros and cons. I am curious to hear what you all have to say on the topic.

NestJS

Pros:

• Database connections remain open over multiple requests, managing connection limits.
• Background task processing without Supervisor.
• Written with Typescript.
• Native GraphQL support.
• Dynamic type definition with class inheritance, allowing for strictly typed dynamic inheritance.
• Elegant, Rails like event and request interception.
• Modules based approach feels organized, and easy to navigate.

Cons:

• Module import and exports are both confusing and tedious.
• Needs dedicated processor (Not a bad thing, just has a slightly increased cost).
• Confusing and/or incomplete documentation.
• Smaller community.
• Async processing can cause database lockups if not careful.
• Errors will take down the entire thread. One funny request and the process goes down for everyone potentially.
• Debugging and logging. While there, I find them to be not quite as nice as Symfony.

Symfony

Pros:

• Can be cheap as chips to host.
• Doctrine.
• Independent service definitions that can easily be injected.
• Auto-wiring & dependency injection is an absolute pleasure to work with.
• Well written, highly complete, and easy to understand documentation.
• Native third party bundles, and well defined ways to create your own bundles.
• Native "dump" feature.
• Logging and Debugging is super clear, controllable, and provides useful information without clutter.

Cons:

• PHP (While I love, Javascript is arguably much nicer to write)
• Higher memory requirements for a single instance
• Non-devs sticking their nose up at you because you use PHP. It's a real concern if you are trying to sell the service. Business folks like hiring a person that knows Javascript for both front and back.
• Event listeners and subscribers feel detached, and are non-intuitive.

Every time I started a new NestJS project, I'd lose the first hour to setup.

Configuring Prisma, wiring up authentication, setting up Swagger, creating boilerplate, fixing version mismatches... the same process over and over again.

Then Prisma 7 dropped.

More breaking changes, configuration updates, and errors that somehow only appeared when you were already tired at 2 a.m.

After fixing the same setup issues for what felt like the tenth time, I decided to automate everything.

So I built quick-nest.

A CLI that scaffolds a complete NestJS 11 + Prisma 7 + PostgreSQL backend with authentication, Swagger docs, and a sample TODO module in a single command:

bunx quick-nest

What you get out of the box

🏗️ NestJS 11 — Modern, scalable architecture

🗄️ Prisma 7 — Properly configured and ready to use

🐘 PostgreSQL — Production-ready database setup

🔐 JWT Authentication — Register, login, and protected routes

📚 Swagger — Interactive API documentation

⚡ Bun Runtime — Fast installs and execution

☁️ Deployment Ready — Works anywhere with minimal configuration

😪😪Everything is intentionally minimal so you can understand and extend it with confidence.

The goal was simple:

Stop spending time on setup. Start building features immediately.

I published it 3 days ago and it just crossed 2,000 downloads, which genuinely surprised me. I built it to solve my own frustration and didn't expect this much interest so quickly.

Package:

https://www.npmjs.com/package/quick-nest

If Prisma 7 (or NestJS setup in general) has caused you pain, I'd love to hear what issues you've run into. There are still plenty of improvements I want to make, and community feedback helps a lot.

Thanks to everyone who has tried it.

Hi everyone,

I've been working on a notification worker built with NestJS:

https://github.com/jayemscript/nestjs-notification-worker

The project is not fully finished yet, but the core functionality is already working.

Current goals:

• Process notification jobs asynchronously
• Support multiple notification channels
• Decouple notification processing from the main application
• Provide a scalable worker-based architecture

I'm sharing it early because I'd like feedback before I continue building additional features.

Areas where I'd appreciate feedback:

• Project structure and module organization
• Queue/worker architecture
• Error handling and retry strategy
• Scalability concerns
• Database design (if applicable)
• Testing approach
• Anything that feels over-engineered or under-engineered

I'm especially interested in hearing from developers who have built notification services or event-driven systems in production.

Any criticism is welcome. Thanks!

How do you handle duplicate JSON keys in production Node.js APIs?

I recently ran into this while testing APIs: JSON.parse silently accepts duplicate keys, and the last value wins.

It also accepts keys like proto, constructor, and prototype, which can become risky depending on how the parsed object is later merged, validated, cached, or passed between services.

The annoying part is that API/security testers catch this immediately, but many apps don’t handle it before the request reaches business logic.

I looked for a strict JSON parser/middleware that handles this efficiently, but most options I found were either too slow, too low-level, or didn’t cover the full set of cases I needed.

So I built one for NestJS, Express, and Fastify:
Repo: https://github.com/pas7-studio/nestjs-strict-json
npm: @pas7/nestjs-strict-json - npm

It checks duplicate keys, prototype pollution keys, depth limits, body size limits, and key whitelist / blacklist rules.

Are there other good libraries that solve this cleanly at the parser/body-parser level?

What are you using in production for this?

Hi everyone,

I'm a Full Stack Developer specializing in:

- React.js

- Next.js

- Node.js

- Express.js

- MongoDB

- REST API Development

- Dashboard/Admin Panel

- SaaS MVP Development

- Bug Fixing & Performance Optimization

What I can help with:

- Build responsive web applications

- Convert Figma to React/Next.js

- Create backend APIs

- Fix existing project bugs

- Build startup MVPs

- Integrate third-party APIs

Why work with me?

- Clean and scalable code

- Fast communication

- On-time delivery

- Long-term support

Portfolio GitHub Linkend

Feel free to DM me if you need help with your project.

Hey, we’re looking for a Nest.js developer to join us.

Nothing overly formal here. If you’ve got at least a year of experience building backend systems with Nest.js and you enjoy creating clean, scalable APIs, you’ll probably fit right in.

We care a lot about clean architecture, solid performance, maintainable code, and building systems that are reliable in production.

We’re flexible with tools, but most of the work revolves around Nest.js, TypeScript, APIs, databases, integrations, and backend infrastructure.

Pay is between $36–$46/hour depending on your experience. Fully remote, with flexible hours (part-time or full-time both fine).

Work mainly includes:

• Building and maintaining Nest.js backend services

• Designing APIs and integrations

• Improving scalability, performance, and security

• Working with databases, authentication, and cloud deployments

If you’re interested, send over:

• What you’ve worked on

• Your experience with Nest.js / TypeScript

• Your location 📍

As a Full-Stack Engineer, I love optimizing systems. So a few months ago, I decided to apply that exact mindset to a different kind of system: my own body. 💻🏋️‍♂️

I built a free-to-use web application using NestJS, React, and TypeScript. The goal? To completely automate my macro tracking and weekly grocery lists based on custom budgets.

To test the algorithm, I managed to generate a full weekly muscle-building meal prep with a grocery receipt of just $27!

I have officially deployed the web app and made it completely FREE for everyone to use and optimize their nutrition routine. No hidden fees, no manual Excel sheets, and zero subscription costs.

I’ve documented the entire architectural breakdown, from the database design to our Hybrid Localization strategy for global/local ingredients, in a detailed deep-dive article.

👇 Check out the full technical breakdown and web link in the comments below!

First of all - a huge thank you to everyone who left comments, opened issues, and submitted PRs. You are amazing!

Second, I've added a major new section: AI-assisted development. It covers how to work with AI effectively, how to maintain code quality when using it, and how to reduce costs. I also wrote an effective claude.md. Your feedback on this section is especially welcome.

For those unfamiliar with the project:

Prod Forge isn't another Todo list tutorial or a CRUD walkthrough. It's a step-by-step reference for building a real production system - the way professional engineering teams actually do it.

The project covers: AI-assisted workflows, quality gates, architecture, AWS infrastructure, fault tolerance, observability, migrations, rollback, and more.

PRs and feedback are always welcome - let's make this better together.

https://github.com/prod-forge/backend

I'm currently developing a nodejs app (nestjs) using node ver20. Instead of using local db studio such as pgadmin for postgresql, I use Neondb (neon.tech). At first it was going well, but for these few days, idk why I have this issue with etimedout so frequently. Sometimes it still works with no further action, however I don't want it to be so unstable like this. Do you have any suggestions?

This is the log content I got:

```bash

[Nest] 1142441 - 05/16/2026, 1:54:30 PM ERROR [TypeOrmModule] Unable to connect to the database. Retrying (7)...

AggregateError [ETIMEDOUT]:

at internalConnectMultiple (node:net:1134:18)

at internalConnectMultiple (node:net:1210:5)

at Timeout.internalConnectMultipleTimeout (node:net:1742:5)

at listOnTimeout (node:internal/timers:590:11)

at process.processTimers (node:internal/timers:523:7)

[Nest] 1142441 - 05/16/2026, 1:54:34 PM ERROR [TypeOrmModule] Unable to connect to the database. Retrying (8)...

AggregateError [ETIMEDOUT]:

at internalConnectMultiple (node:net:1134:18)

at internalConnectMultiple (node:net:1210:5)

at Timeout.internalConnectMultipleTimeout (node:net:1742:5)

at listOnTimeout (node:internal/timers:590:11)

at process.processTimers (node:internal/timers:523:7)

```

...

```bash

Error: connect ETIMEDOUT 34.196.24.162:5432

at createConnectionError (node:net:1678:14)

at Timeout.internalConnectMultipleTimeout (node:net:1737:38)

at listOnTimeout (node:internal/timers:590:11)

at process.processTimers (node:internal/timers:523:7) {

errno: -110,

code: 'ETIMEDOUT',

syscall: 'connect',

address: '34.196.24.162',

port: 5432

},

Error: connect ENETUNREACH 2600:1f18:240c:540d:f710:6e36:7f35:f468:5432 - Local (:::0)

at internalConnectMultiple (node:net:1206:16)

at Timeout.internalConnectMultipleTimeout (node:net:1742:5)

at listOnTimeout (node:internal/timers:590:11)

at process.processTimers (node:internal/timers:523:7) {

errno: -101,

code: 'ENETUNREACH',

syscall: 'connect',

address: '2600:1f18:240c:540d:f710:6e36:7f35:f468',

port: 5432

}

]

}

```

I am integrating MyFatoorah for a SaaS product with monthly/yearly subscription plans, and I’m trying to understand how people usually structure the billing side.

From the docs, it seems MyFatoorah supports recurring payments, but I’m not sure whether it behaves like Stripe Billing where subscriptions, invoices, amount changes, renewals, etc. are automatically managed.

Questions for people who already implemented it:

Do you manage subscription logic entirely in your backend? Does MyFatoorah automatically generate recurring invoices/payments correctly? How do you handle upgrades/downgrades or price changes? Did you store your own subscription + invoice tables? Any issues with webhooks or recurring payment reliability? How do you handle yearly plans?

Would really appreciate hearing real implementation experiences, architecture advice, or pitfalls before we finalize our billing system.

My theory is that if the framework has more rules, the AI will make fewer mistakes, allowing me to focus on the actual product

to those who have made the switch: did you find that a more structured framework improved your AI workflow and reduced technical debt?

"Swagger for Kafka"
I’ve been working a lot with Kafka consumers in NestJS, and testing always felt the same:
Open Kafka UI -> find topic -> build message -> send -> go back to VSCode -> check logs.
It works... but it’s not convenient.
So I asked myself:
why isn’t there something like Swagger - but for Kafka?
One place to see, send, and test events without jumping between tools.
I checked AsyncAPI - good idea, but didn’t fit my day-to-day needs.
So I built EventScribe.
In short:
a “Swagger for Kafka” (for now), built for NestJS, focused on being simple and easy to plug into any project.
Then i've realized its a solution to any event driven api so,
Today:

• Kafka support
• WebSockets support

If this sounds useful - feel free to try it and share feedback
#NestJS #Kafka #Swagger
Docs: https://nestjs-events-swagger.com/
Library: https://www.npmjs.com/package/nestjs-eventscribe

Hey guys,

I realized I was spending a lot of time doing the exact same configs every time I started a new NestJS project. Things like setting up auth, getting the logger right, and configuring basic security tools always felt like a chore.

So, I decided to put together a starter boilerplate for my own workflow, and I thought I'd share it here in case it saves anyone else some time.

It's not overly complicated, but it includes the stuff I usually need for a production-ready setup:

• Database & Auth: Wired up PostgreSQL with TypeORM, plus standard JWT authentication and Passport.
• Security Built-in: Added Helmet for secure headers and global rate limiting (Throttler) right out of the box.
• Better Logging: Replaced the default logger with Winston, and set it up to auto-rotate log files daily so they don't get out of hand.
• Health Checks: Added a /health endpoint using Terminus to keep an eye on database connections and memory usage.
• Docs & Error Handling: Swagger is pre-configured, along with global interceptors and exception filters so errors and responses look consistent.

It’s pretty much just a clean, structured starting point so you don't have to keep rebuilding the wheel.

Github: https://github.com/saaiilbasnet/nestjs-enterprise-starter

If you end up using it or taking a look, I'd genuinely love to know what you think. I'm always open to feedback on how to improve the structure or if I missed any obvious best practices!

Cheers!

hello guys,

I'm deploying a NestJS app to AWS Lambda and injecting environment. The issue is that some variables are still being picked up from the `.env` file instead of the OS environment. and those ones are empty.

what i want is unset some env variables in .env file, by replacing them with empty one in the os level, but instead it takes the .env value.