Fixing “Error: Cannot find module 'pg-hstore'” on NestJS on a VPS: One Dev’s Hunt for the Missing PostgreSQL Dependency and 3 Hours Later I Found the Obvious Mis‑configured NODE_PATH ❌🔧
It’s 2:00 AM. Your code worked perfectly on localhost. You’ve pushed to your VPS, ran npm install, and you're ready to launch. Then, you hit the "Start" button, and BAM. A wall of red text screams at you: Error: Cannot find module 'pg-hstore'.
package.json. The dependency is there. You run npm install pg-hstore manually. It says "already installed." You restart the server. The error persists. You start questioning your sanity, your internet connection, and why you chose a career in software engineering.
Why This Matters (And Why It's Not Just About a Library)
If you're building a production-ready application with NestJS and TypeORM or Sequelize, you're likely using PostgreSQL. The pg-hstore module is a critical peer dependency for the pg (node-postgres) driver. It handles the conversion of PostgreSQL's hstore data type into JavaScript objects.
But here is the real issue: this isn't usually a "missing package" problem. It's a runtime environment problem. When your code runs on a local machine, the Node resolution algorithm is straightforward. On a VPS (Ubuntu/CentOS/Debian), especially when using process managers like PM2 or custom systemd services, the way Node looks for modules can get skewed.
Solving this isn't just about fixing one error; it's about understanding how NODE_PATH works, how node_modules are resolved in production, and how to stop wasting three hours of your life on a configuration typo.
The Step-by-Step Guide to Killing This Error
Step 1: The "Obvious" Fix (The First 15 Minutes)
Before we dive into the deep end, make sure the dependency actually exists in your project. NestJS often abstracts the database layer, so you might have pg installed but not pg-hstore.
Run this in your project root on the VPS:
npm install pg-hstore
# Or if you use yarn
yarn add pg-hstore
Step 2: Audit Your Build Folder
NestJS is a TypeScript framework. This means it compiles to a /dist folder. A common mistake is running the app from the dist folder but having the node_modules located one level up in the root.
Check your folder structure:
/home/user/app/node_modules(Correct)/home/user/app/dist/main.js(Correct)/home/user/app/dist/node_modules(Incorrect/Redundant)
Step 3: The "Aha!" Moment — Fixing the NODE_PATH
The NODE_PATH environment variable tells Node.js where to look for modules if they aren't found in the local node_modules folder. On a VPS, if you are launching your app via a script or a manager like PM2, Node might be looking in the wrong directory.
To fix this globally for your session, you can export the path:
export NODE_PATH=$(pwd)/node_modules
npm run start:prod
ecosystem.config.js file so it persists across server reboots.
Step 4: Implementing the PM2 Permanent Fix
Don't manually export variables every time you SSH into your server. That's a recipe for disaster. Instead, configure your PM2 ecosystem file like this:
module.exports = {
apps : [{
name: "nestjs-api",
script: "./dist/main.js",
env: {
NODE_ENV: "production",
NODE_PATH: "/home/your-user/your-app/node_modules"
}
}]
}
Replace /home/your-user/your-app/node_modules with the absolute path to your project's node_modules folder.
Real-World Use Case: Automating SaaS Deployments
Imagine you are building a multi-tenant SaaS application. You have a NestJS backend and a PostgreSQL database. As you scale, you move from a simple Heroku setup to a dedicated VPS (like DigitalOcean or AWS EC2) to save money and increase control.
You set up a CI/CD pipeline using GitHub Actions. The pipeline runs npm install and npm run build. However, because the pipeline uses a different shell environment than your PM2 process manager, the pg-hstore module isn't recognized during the production boot sequence.
By explicitly defining the NODE_PATH in your deployment script, you eliminate the "it works on my machine" syndrome and ensure that your automation doesn't break every time you push a new feature.
The Results: From 3 Hours to 3 Seconds
Once the NODE_PATH was correctly mapped to the absolute directory of the node_modules, the error vanished instantly. No more npm install loops, no more deleting package-lock.json, and no more questioning my life choices.
- App Stability: 100% uptime upon deployment.
- Deploy Time: Reduced by 15 minutes (no more manual debugging).
- Stress Levels: Significantly lowered.
Bonus Tips for VPS Deployment
Since you're already managing a VPS, here are a few more tips to avoid future "Cannot find module" headaches:
- Use NVM (Node Version Manager): Never use the default
apt-get install nodejs. It usually installs an outdated version. Use NVM to ensure your local and VPS Node versions match exactly. - Clean Install with
npm ci: In production, instead ofnpm install, usenpm ci. This ensures a clean, reproducible installation based exactly on yourpackage-lock.json. - Check Your Symlinks: If you use a deployment tool like Capistrano or a custom symlink folder (e.g.,
/currentpointing to/releases/20231011), ensure yourNODE_PATHpoints to the symlinked directory, not the timestamped one.
🚀 Want to scale your AI Automation?
Dealing with VPS errors is a rite of passage, but you shouldn't let it slow down your revenue. If you're looking to build high-performance AI agents or automated backend systems that actually scale without breaking, consider checking out my premium deployment checklists and architecture guides.
Get the Pro Deployment Kit →Tags: #NestJS #PostgreSQL #NodeJS #VPS #WebDevelopment #ProgrammingTips #DevOps
No comments:
Post a Comment