Why My NestJS API Keeps Crashing on a Cheap VPS: 7 Hard‑Hit Error Fixes and Performance Hacks You Can’t Afford to Miss

You’ve built a sleek, modular API with NestJS. It runs perfectly on your MacBook Pro with 16GB of RAM. You deploy it to a $5/month VPS, and suddenly—boom. The server freezes, the logs scream Out of Memory (OOM), and your app crashes every time more than three people hit your endpoint.

It’s a frustrating rite of passage for every developer. You start wondering if NestJS is "too heavy" or if you need to upgrade to a $40/month plan. Stop. Before you throw money at the problem, you need to realize that Node.js and NestJS are hungry by default. If you don't tune them for a low-resource environment, they will eat your VPS alive.

Why This Matters

Running professional-grade software on "budget" hardware is an art. If your API crashes, you lose users, you lose SEO rankings, and you lose money. Learning to optimize NestJS for a cheap VPS allows you to scale your MVP (Minimum Viable Product) without bleeding cash on cloud infrastructure.

The Root Cause: Why NestJS Struggles on Small VPS

NestJS is built on top of Express (or Fastify) and utilizes TypeScript. While powerful, the compilation process, the dependency injection system, and the default Node.js memory heap settings are designed for servers with plenty of breathing room.

On a 1GB RAM VPS, the operating system takes some, your database (PostgreSQL/MongoDB) takes some, and suddenly Node.js tries to claim 1.5GB for its heap. The Linux OOM Killer steps in and terminates your process instantly.

The 7 Hard-Hit Fixes and Performance Hacks

1. Limit the Node.js Heap Memory

By default, Node.js doesn't know it's on a tiny VPS. It may try to allocate more memory than the physical RAM available. You must explicitly tell Node.js where the ceiling is.

Warning: Setting this too low will cause your app to crash during heavy requests. Setting it too high will trigger the OS OOM Killer.

For a 1GB VPS, limit your heap to roughly 512MB to 768MB to leave room for the OS and DB.

# In your package.json or PM2 config
node --max-old-space-size=512 dist/main.js

2. Switch from Express to Fastify

NestJS uses Express by default. Express is reliable, but Fastify is significantly faster and uses less memory. Switching can reduce your memory overhead by up to 20-30% in high-throughput scenarios.

First, install the platform adapter:

npm i @nestjs/platform-fastify

Then, update your main.ts:

import { NestFactory } from '@nestjs/core';
import { FastifyAdapter, NestFastifyApplication } from '@nestjs/platform-fastify';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create<NestFastifyApplication>(
    AppModule,
    new FastifyAdapter()
  );
  await app.listen(3000);
}
bootstrap();

3. Implement a Swap File (The Life-Saver)

If you are on a cheap VPS, you likely have no swap space. When RAM fills up, the app dies. A swap file uses a portion of your SSD as "emergency RAM." It's slower, but it prevents the crash.

Pro Tip: A 2GB swap file is usually enough to stop 90% of "random" VPS crashes for small NestJS apps.

1. Create a 2GB file: sudo fallocate -l 2G /swapfile
2. Set permissions: sudo chmod 600 /swapfile
3. Set up swap area: sudo mkswap /swapfile
4. Enable it: sudo swapon /swapfile
5. Make it permanent: Add /swapfile swap swap defaults 0 0 to /etc/fstab.

4. Optimize your Build Process (Don't Run TS Directly)

Running your app via ts-node or nest start in production is a cardinal sin. It consumes massive amounts of RAM because it compiles TypeScript on the fly.

Always build to plain JavaScript and run the dist folder:

# Build the project
npm run build

# Run the compiled JS
node dist/main.js

5. Use PM2 with Cluster Mode (Carefully)

PM2 keeps your app alive, but "Cluster Mode" can actually crash a cheap VPS if you start too many instances. If you have 1 CPU core, don't start 4 instances.

Use a ecosystem.config.js file to manage resources:

module.exports = {
  apps : [{
    name: "nestjs-api",
    script: "./dist/main.js",
    instances: 1, // Keep this at 1 for 1GB RAM VPS
    exec_mode: "fork", 
    max_memory_restart: "600M", // Restart if it leaks memory
    env: {
      NODE_ENV: "production",
    }
  }]
}

6. Avoid Memory Leaks in Observables and Intervals

NestJS developers often use setInterval or RxJS Observables for background tasks. If you don't clear these, they accumulate in memory.

Always implement OnModuleDestroy to clean up your timers:

import { Injectable, OnModuleDestroy } from '@nestjs/common';

@Injectable()
export class TaskService implements OnModuleDestroy {
  private timer: NodeJS.Timeout;

  startPolling() {
    this.timer = setInterval(() => {
      console.log('Polling data...');
    }, 60000);
  }

  onModuleDestroy() {
    clearInterval(this.timer); // Prevent memory leak
  }
}

7. Database Connection Pooling

Your API might not be crashing; your database might be rejecting connections, causing the NestJS app to hang and eventually crash due to request backlog.

If you use TypeORM or Prisma, limit your connection pool. A cheap VPS cannot handle 100 open connections.

// Example TypeORM config
TypeOrmModule.forRoot({
  type: 'postgres',
  host: 'localhost',
  port: 5432,
  extra: {
    max: 10, // Limit pool size to 10 connections
    idleTimeoutMillis: 30000,
  },
})

Real-World Use Case: Scaling a SaaS MVP

I recently helped a developer running a small AI-automation tool. They were using a DigitalOcean droplet with 1GB RAM. Their NestJS API was crashing every 4 hours.

The Problem: They were running npm run start:prod (which is slower) and had no swap file. They also had 3 PM2 instances running on a 1-core CPU.

The Fix: We switched them to Fastify, added a 2GB Swap file, and limited the Node heap to 512MB.

The Result: The API uptime went from 70% to 99.9%. They didn't have to upgrade their server, saving them $15/month, and the response time dropped by 40ms.

Bonus Tips for Maximum Performance

• Compression: Use the compression middleware to reduce the size of the response bodies.
• Logging: In production, stop using console.log. Use a lightweight logger like pino. Standard output is surprisingly resource-heavy.
• Zipping: If you're deploying via CI/CD, ensure you aren't uploading node_modules. Run npm install --production on the server to avoid installing devDependencies.

🚀 Ready to Scale Your App?

If you're tired of managing servers, consider moving your optimized NestJS app to a PaaS or using Docker to ensure environment consistency. But for now, these 7 fixes will keep your cheap VPS running like a powerhouse!