The "Day One" NestJS Fatigue
Every time I start a new NestJS project, I get a brief moment of excitement... followed by the realization that I have to build Auth again.
We’ve all been there. You spend 3 days setting up:
- JWT strategies and refresh token rotation.
- Password hashing with Bcrypt or Argon2.
- Passport strategies for Google/GitHub.
- Database schemas for Users and Roles.
- Docker Compose for Redis and Postgres.
- Swagger docs so the frontend team stops asking for endpoints.
It’s the same 80% of code every time. So, I decided to automate it.
Introducing @mehdijony/nestjs-user-service
I built a CLI tool that doesn't just scaffold a new project—it installs a complete, high-performance user management engine into your existing project.
⚡️ The 5-Minute Setup
In your terminal, just run:
npx @mehdijony/nestjs-user-service init
The CLI kicks off an interactive session. It’s smart enough to detect your stack:
- Package Manager: npm, yarn, pnpm, or bun.
- ORM: Prisma, TypeORM, Mongoose, or Drizzle.
-
Environment: It reads your
.envanddocker-compose.ymlto ensure zero conflicts.
🛠 What's under the hood?
I didn't want this to be "just another boilerplate." It’s built for senior-level requirements:
1. The Modular Architecture
It generates a src/user-service/ directory with a clean separation of concerns. It even injects the UserServiceModule into your AppModule automatically.
2. Multi-Driver Support
Whether you are a Prisma fan or a TypeORM veteran, the CLI generates the correct entities and repositories for your chosen database (Postgres, MySQL, MongoDB, etc.).
3. Safety First (The Rollback Engine)
This is my favorite feature. Modifying source code is scary.
Before the CLI touches a single line, it creates a Restore Point.
If you don't like the result, or something goes wrong:
npx @mehdijony/nestjs-user-service rollback
It uninstalls the packages, deletes the generated files, and restores your app.module.ts and .env to their exact original state. Zero footprint.
📦 Feature Checklist
| Category | Features |
|---|---|
| Auth | JWT, Refresh Tokens, Magic Links, OTP, Social OAuth |
| Security | 2FA (TOTP), RBAC, Rate Limiting, Account Lockout |
| Infra | Redis Caching, BullMQ/Kafka, S3 File Uploads |
| DevOps | Auto-Swagger, Health Checks, Docker Compose Merge |
🚀 Why I built this
As a Backend Engineer, I want to spend my time on unique business logic, not re-writing the same AuthService for the 10th time. This tool is for the solo dev who needs to ship fast and the agency team that wants a standardized auth foundation across all projects.
Give it a spin
I'd love to get the community's feedback on this. If it saves you a few days of work, drop a star on GitHub!
NPM: [https://www.npmjs.com/package/@mehdijony/nestjs-user-service]
GitHub: [https://www.github.com/mehdijony/nestjs-user-service]
What feature should I add next? LDAP support? SAML? Let me know in the comments! 👇
Top comments (2)
The "Day One NestJS fatigue" framing is dead on. We hit the same wall around service 3 or 4 — every new microservice was a 2-day yak shave on auth, env config, and folder layout before any product code got written. We solved it on the platform side rather than CLI side: a base service template + a shared schema package every service inherits. CLI is the better DX for solo devs and small teams though — lower cognitive load. One thing I'd love to see: can the CLI also wire role + permission guards out of the box, or is that v2? That's usually the second wave of "Day One fatigue."
This is exactly the kind of feedback I was hoping to hear —
the platform template approach makes total sense at scale,
and honestly it's the enterprise version of the same problem.
Shared schema packages work great when you have a dedicated
platform team to maintain them. The CLI targets the gap
below that: solo devs and small teams who don't have that
infrastructure layer yet.
On your RBAC question — good news, it is already in v1,
not v2.
When you select RBAC + Permissions during setup, the CLI
generates:
✅ RolesGuard (checks required roles against user.roles)
✅ @Roles() decorator (set metadata on any route)
✅ PermissionsGuard (fine-grained resource/action checks)
✅ Role and Permission models in your Prisma schema
✅ UserRole join table with cascade delete
✅ RolePermission join table
So a protected route looks like this immediately after install:
@UseGuards(JwtAuthGuard, RolesGuard)
@Roles('admin')
@Delete('users/:id')
remove(@param('id') id: number) { ... }
The "second wave of Day One fatigue" was very much
on my mind when building this. Auth without RBAC
is only half the job done.
What is on the roadmap for v2 is a dedicated
Role and Permission CRUD API (so you can manage
roles at runtime without touching code),
and a permission matrix UI for Swagger.
Would love to know what your base service template
handles that the CLI doesn't — that kind of
platform-side thinking would genuinely help
shape what gets built next.