DEV Community: Mayur Pawar

Stop Paying for Authentication: Migrate from Clerk & Google OAuth to Open Source

Mayur Pawar — Fri, 17 Jul 2026 13:38:50 +0000

Authentication is one of the first things developers add to an application. Today, many teams use services like Google OAuth, Clerk, Auth0, or Firebase Authentication because they are easy to integrate and handle most of the security for you.

But what happens if you want complete control over your authentication system? Maybe you want to avoid vendor lock-in, reduce costs, or host everything yourself.

The good news is that you don't need to build authentication from scratch. You can replace managed authentication platforms with open source identity providers that offer the same core features.

In this article, we'll understand how Google OAuth and Clerk work, and how we can replace them with open source implementations in simple words.

How Authentication Works Today

Let's imagine a user wants to log into your application.

Here's what happens behind the scenes:

The user clicks Sign in.
Google or Clerk displays the login page.
The user enters their credentials.
The authentication provider verifies them.
A JWT (JSON Web Token) is generated.
The frontend sends this token with every API request.
The backend verifies the token before allowing access.

Notice something important:

Your backend never checks the user's password.

Google or Clerk does that for you.

The Problem

Managed authentication services are great, but they come with trade-offs.

Monthly subscription costs
Vendor lock-in
Limited customization
Your authentication depends on a third-party service
Less control over user management

As your application grows, you might want to host authentication yourself.

The Idea Behind Replacing Them

Many developers think they need to rebuild OAuth.

You don't.

OAuth is a standard.

What you're actually replacing is the Identity Provider.

Instead of asking Google or Clerk to verify users, you'll run your own authentication server.

That's it.

The New Architecture

Instead of this:

You'll have:

The flow stays almost exactly the same.

Only the service performing authentication changes.

Which Open Source Tools Can Replace Clerk?

Some popular options are:

Keycloak
Authentik
Ory Kratos
Zitadel
SuperTokens Community Edition

Among these, Keycloak is one of the most mature and widely used solutions.

It already supports:

OAuth 2.0
OpenID Connect
JWT Tokens
User Management
Role-Based Access Control
Multi-Factor Authentication
Social Login
Single Sign-On (SSO)

Step 1: Deploy Your Authentication Server

Install an authentication server like Keycloak.

Instead of relying on Google, Keycloak becomes responsible for:

Managing users
Managing passwords
Creating sessions
Generating JWT tokens
Handling login and logout

Think of it as your own private version of Google Login.

Step 2: Store Users Yourself

Instead of Google storing user accounts, your authentication server stores them.

Passwords are never stored as plain text.

They are securely hashed using algorithms like bcrypt or Argon2.

Step 3: User Logs In

The user enters:

Email
Password

The frontend sends these credentials to Keycloak.

Keycloak checks the credentials.

If they're correct, it generates a JWT token.

Step 4: Return the JWT

Keycloak sends a JWT token back to the frontend.

The frontend stores it securely.

Now the user is authenticated.

Step 5: Call Protected APIs

Whenever the frontend calls your backend, it includes the JWT.

GET /profile

Authorization: Bearer <JWT_TOKEN>

Step 6: Verify the Token

The backend checks whether the JWT is valid.

If it is valid:

Allow the request.

If it is invalid:

Return 401 Unauthorized.

This is exactly how Google OAuth and Clerk work.

The only difference is that your own server issued the token.

Before vs After

Before

After

Nothing changes for your backend except who issues the token.

Migration Steps

If you're moving away from Clerk or Google OAuth, your migration looks like this:

Deploy Keycloak (or another open source identity provider).
Create your application (client) inside Keycloak.
Configure login, registration, and roles.
Update the frontend to authenticate with Keycloak.
Update the backend to verify JWTs issued by Keycloak.
Test login, logout, and protected routes.
Remove Clerk or Google OAuth from your application.

Benefits of Self-Hosted Authentication

No vendor lock-in
Lower long-term costs
Full control over user data
Custom authentication workflows
Support for OAuth 2.0 and OpenID Connect
Enterprise-ready features like SSO, MFA, and RBAC

Challenges

Self-hosting also comes with responsibilities.

You must maintain the authentication server.
You need to install security updates.
You are responsible for backups and monitoring.
Initial setup takes more effort than using a managed service.

For small projects, managed authentication may still be the better choice.

For larger applications or organizations that need complete control, open source identity providers can be an excellent solution.

Final Thoughts

Replacing Google OAuth or Clerk doesn't mean replacing OAuth itself.

You're simply replacing the service that proves a user's identity.

Instead of trusting a third-party provider, you run your own identity server while continuing to use industry standards like OAuth 2.0, OpenID Connect, and JWT.

The overall login flow remains almost identical, but you gain full ownership of your authentication infrastructure.

If you're building products that require flexibility, customization, or long-term control, open source authentication is definitely worth exploring.

I Was Tired of Broken Deployments, So I Built This CLI Tool

Mayur Pawar — Tue, 26 May 2026 16:43:22 +0000

I Built an npm CLI Tool That Checks If Your Project Is Deployment Ready

Deployments often fail for the smallest reasons.

A missing .env file.

A forgotten build script.

A missing Dockerfile.

An incomplete Vercel configuration.

Or accidentally exposing secrets inside the project.

Most developers discover these issues only after pushing to production.

After running into these problems repeatedly while building projects, I decided to build a tool that checks deployment readiness before deployment even happens.

So I built:

🚀 mayur-deploy-ready

A zero-config CLI tool that analyzes your project, detects deployment issues, scans for security risks, validates platform configurations, and even auto-generates missing deployment files.

📦 What is mayur-deploy-ready?

mayur-deploy-ready is a deployment readiness analyzer for Node.js projects.

It performs automated checks across multiple categories including:

package configuration
Docker setup
security validation
framework detection
platform deployment configs
CI/CD readiness

The goal is simple:

Catch deployment issues locally before they break production.

⚡ Installation

Global Install

npm install -g mayur-deploy-ready

Run the Tool

mayur-deploy-ready

🎯 Example Output

When you run the CLI:

mayur-deploy-ready

You get a deployment analysis report like this:

━━━━━━━━━━━━━━━━━━━━━━
🚀 DEPLOY READY
━━━━━━━━━━━━━━━━━━━━━━

✔ package.json found
⚠ Build script missing
⚠ Dockerfile missing
⚠ .env missing

━━━━━━━━━━━━━━━━━━━━━━
📊 Deployment Score: 75/100
━━━━━━━━━━━━━━━━━━━━━━

🟡 Needs Attention

The tool also provides:

suggestions
categorized scoring
warnings
deployment readiness status

🔥 Features

✅ Weighted Deployment Scoring

One of the most interesting parts of the project was designing the scoring architecture.

The tool calculates a deployment readiness score out of 100 using weighted categories like:

PACKAGE: 20/20
SCRIPTS: 10/20
SECURITY: 25/25
DOCKER: 5/10
FRAMEWORK: 0/10

Instead of only showing warnings, this gives developers a much clearer picture of how deployment-ready their project actually is.

The scoring system categorizes projects into:

Score	Status
85–100	🟢 Production Ready
60–84	🟡 Needs Attention
0–59	🔴 Unsafe Deployment

🔐 Advanced Security Scanning

I wanted the tool to do more than just check missing files.

So I implemented recursive security scanning that detects:

OpenAI API keys
MongoDB URIs
JWT secrets
AWS access keys

Example:

⚠ Potential OpenAI API Key detected in src/test-secret.js
⚠ Potential MongoDB URI detected in config/api.js

While building this feature, I learned that security scanning is much harder than it initially looks.

At first, the scanner even detected secrets inside the tool’s own internal files.

That forced me to redesign the scanner architecture with:

configurable ignore paths
recursive traversal
extension filtering
smarter regex matching
production-style exclusions

This ended up becoming one of the most educational parts of the project.

🛠 Auto Fix Mode

Another feature I really enjoyed building was automatic repair mode.

Run:

mayur-deploy-ready fix

The tool can automatically generate missing deployment files such as:

.gitignore
.dockerignore
Dockerfile
.env.example
vercel.json
railway.json

This helps developers bootstrap deployment configurations much faster.

🤖 JSON Mode for CI/CD

I also added structured JSON output.

mayur-deploy-ready --json

This makes the tool easy to integrate into:

GitHub Actions
Jenkins
GitLab CI
dashboards
automation scripts

Example:

{
  "score": 85,
  "stats": {
    "passed": 6,
    "warnings": 2,
    "errors": 0
  }
}

⚙️ CI/CD Support

The tool also supports CI mode:

mayur-deploy-ready --ci

Exit codes:

0 → deployment ready
1 → deployment unsafe

This allows deployments to fail automatically inside CI pipelines if critical deployment issues are detected.

I also added example integrations for:

GitHub Actions
GitLab CI
Jenkins

inside the README documentation.

🧠 What I Learned Building This

This project taught me much more than I expected.

1. CLI Development Is Different From Web Development

Building CLI tools requires thinking about:

terminal UX
output formatting
developer experience
command parsing
readable logs
automation compatibility

2. npm Publishing Has Real-World Edge Cases

While publishing the package, I ran into:

npm authentication issues
2FA requirements
package publishing permissions
README caching
Shields.io badge caching
npm session expiration

These are things you rarely encounter while building normal frontend projects.

3. Security Tooling Requires Careful Design

The security scanner taught me an important lesson:

Naive scanning creates too many false positives.

To make the tool useful, I had to redesign the scanner with:

ignore systems
configurable exclusions
smarter recursion
safer matching logic

That experience gave me a much better understanding of developer tooling architecture.

📁 Project Structure

The project is organized into:

checks/ → validation logic
fixes/ → auto-generated deployment fixes
utils/ → scoring, logging, stats
frameworks/ → framework-specific validations
bin/index.js → CLI orchestration

The architecture became much larger than I originally planned, but it also helped me understand how production-style CLI tools are structured.

🚀 Open Source

The project is fully open source.

GitHub:

https://github.com/mayurCoder2004/mayur-deploy-ready

npm:

https://www.npmjs.com/package/mayur-deploy-ready

Final Thoughts

This started as a small utility to help me avoid deployment mistakes.

But while building it, I learned:

CLI architecture
npm publishing workflows
deployment tooling
security scanning
scoring systems
CI/CD integration
developer experience design

Honestly, this became one of the most educational projects I’ve built so far.

If you try it out, I’d genuinely love feedback from other developers 🚀

How I Built ChefMate — An AI Recipe App for Hostel & PG Students

Mayur Pawar — Wed, 06 May 2026 15:59:53 +0000

Most recipe apps assume you already have a full kitchen.

But during college and hostel life, the reality is usually:
onion + potato + maggi + random masalas 😭

That simple problem became the idea behind ChefMate.

I wanted to build something where users could simply select the ingredients they already had available and instantly generate quick Indian-style recipes instead of endlessly searching YouTube or recipe blogs.

🚀 What is ChefMate?

ChefMate is a full-stack AI-powered recipe and meal planning platform built using the MERN stack.

Users can:

generate recipes using available ingredients
use a guided Cook Mode
save recipes
create meal plans
share recipes using public links
browse additional recipes using TheMealDB API

The focus was making the experience simple and practical for students, hostel residents, and bachelors living alone.

🛠️ Tech Stack

Frontend

React
Vite
Tailwind CSS
React Router
Axios
React Hot Toast
React GA4

Backend

Node.js
Express
MongoDB
Mongoose
JWT Authentication
Express Rate Limit
Zod Validation

AI & APIs

OpenRouter API
Gemini / Llama / Mistral models
TheMealDB API

✨ Features I Added

🤖 AI Recipe Generator

Users select ingredients and preferences like:

vegetarian/vegan
cooking time
dietary preferences

The app then generates structured recipes with:

ingredients
cooking steps
health benefits
estimated cooking time

🍳 Cook Mode

One feature I personally liked building was Cook Mode.

Instead of showing a giant recipe paragraph, the app guides users step-by-step while cooking.

I also added:

progress tracking
timers
step navigation

to make the cooking experience smoother.

📅 AI Meal Planner

Users can generate meal plans for multiple days based on:

calorie goals
diet preferences
number of days

🔗 Shareable Recipes

Users can generate public recipe links and share them directly through WhatsApp or browser sharing APIs.

Shared recipes can be opened without login.

⚡ Biggest Challenges

1. Making AI responses consistent

LLM outputs are unpredictable.

Sometimes responses came as:

JSON
markdown
incomplete text
broken formatting

So I had to build normalization and validation logic to structure responses properly.

2. UI/UX Problems

One thing I learned quickly:
good functionality alone is not enough.

Early feedback made me realize:

the UI felt too “AI-generated”
layouts were inconsistent
some flows were confusing

I spent a lot of time refining:

spacing
typography
visual hierarchy
loading states
mobile responsiveness

3. Public Feedback & Distribution

I recently started sharing the project publicly and learned that distribution is honestly harder than coding sometimes 😭

Posting on communities taught me:

how people perceive AI products
how important positioning is
how to communicate projects naturally instead of sounding overly promotional

That was a surprisingly valuable learning experience.

🔒 Security Improvements

One important issue I discovered after feedback:
the AI endpoints initially had no proper rate limiting.

Since LLM APIs cost credits, users could theoretically spam requests.

I fixed this using Express Rate Limit to protect expensive endpoints.

📈 What I Learned

Building ChefMate taught me much more than just coding:

shipping real products
handling user feedback
improving UX
API security
analytics integration
authentication flows
real-world deployment

It also made me realize:
building something usable is much harder than just making something functional.

🔮 Future Plans

Some things I’d like to improve:

recipe images/videos
grocery list generation
better onboarding
stronger personalization
social/community features

🌐 Live Demo

ChefMate:
https://chefmate-frontend.vercel.app

GitHub:
https://github.com/mayurCoder2004/chefmate

Would genuinely love feedback from other developers/builders on:

UI/UX
product direction
architecture
ideas for improvement 🙌

Still Feel Alone Online? We Built Something to Fix That

Mayur Pawar — Wed, 01 Apr 2026 20:00:21 +0000

We Spent Months Building a Virtual Home for Couples. Here's the Honest Story.

You can be online all day and still feel completely alone.

Texts. Calls. Notifications. A green dot next to someone's name.

None of it makes you feel like you're actually with them.

That gap — between being connected and feeling present — is what led us to build TogetherUs.

What Is It?

TogetherUs is a shared 2D pixel-art virtual world built specifically for couples in long-distance relationships.

Think of it as your own private digital apartment — a cozy space where you and your partner can hang out, watch movies, listen to music, study together, or simply sit in a garden and talk face to face.

No tasks. No agenda. No performance. Just presence.

You create a private room, share a code with your partner, and step into a charming pixel world together. As your customizable avatars explore the space, a Picture-in-Picture video call keeps you visually connected the whole time.

The Zones Inside

This isn't just a chat room. Every area of the world serves a different kind of togetherness:

🎥 Movie Zone — Watch YouTube videos in perfect sync. Shared play/pause, seek, speed control, and quality selection up to 4K. An elastic sync system with heartbeat keeps both of you on the exact same frame even across different network speeds.

🎵 Music Zone — A synchronized jukebox powered by YouTube Music. Search any song, get real-time autocomplete, browse recommendations, and like tracks. No account needed.

🎮 Game Zone — Play multiplayer games together via an integrated arcade. Smash Karts, Mini Golf, Chess, and more — no extra installs.

📚 Study Zone — A co-working space with a synchronized Pomodoro timer, a collaborative whiteboard (Excalidraw), and a shared PDF viewer. For the couples who grind together.

🌿 Garden Area — Step in here and the PiP video expands to full screen. Just you two, face to face. Built for the conversations that matter.

The Tech Behind It

Here's what's actually running under the hood:

Frontend: React 18 + Vite, Phaser 3 for the 2D pixel world, Zustand for state, Framer Motion for animations, Socket.IO client, WebRTC via Simple-Peer for video, Excalidraw for the whiteboard, TailwindCSS

Backend: Node.js + Express, Socket.IO for real-time events, PostgreSQL 16, Redis 7 for sessions and pub/sub, Firebase Admin for Google Sign-In, Cloudinary for media uploads

Infrastructure: Docker Compose for local dev, Vercel for frontend, Render/Railway for backend, npm Workspaces as a monorepo

One architectural detail we're proud of: end-to-end encrypted chat using ECDH P-256 key exchange. Your conversations are genuinely yours — including stickers, GIFs, and file attachments up to 10MB.

The Hard Parts (Honest Take)

Real-time sync is deceptively brutal.

Here's what actually went wrong:

Video sync drift — even 200ms of lag breaks the illusion of watching together. We had to build a heartbeat-based elastic sync system to keep both users on the same frame continuously.
State inconsistencies on reconnect — when a user drops and rejoins, the world needs to feel seamless. Getting that right took far more edge-case handling than we expected.
Proximity-based video activation — making the PiP video call trigger naturally based on avatar closeness sounds simple. It introduced a whole class of race conditions.
WebRTC in the wild — peer-to-peer connections behave very differently across network types. NAT traversal, STUN/TURN fallbacks, and mobile networks all needed specific handling.

The hardest bugs weren't technical. They were experiential. When does lag stop feeling like lag and start feeling like distance? That question shaped most of our debugging sessions.

What We Learned

1. "Simple" is the most expensive feature.
We cut a lot. Every removal felt like a loss. But every cut made the core experience sharper and more emotionally coherent.

2. Emotional UX is an underexplored field.
Most UI/UX writing focuses on task completion rates and conversion funnels. We were building for feeling. There's very little playbook for that. We had to figure a lot of it out from first principles.

3. Phaser 3 + React is a genuinely powerful combination — with real gotchas.
Keeping the game engine and the React UI in sync without stepping on each other required careful boundary design. Zustand as the shared state layer helped enormously.

4. Real-time is never truly real-time.
There's always latency. The question is whether your sync system hides it well enough to preserve the illusion. We spent a surprising amount of time on perception, not performance.

Why We Built This

We're at a strange moment. We've never been more digitally connected. Loneliness has never been more of an epidemic.

Every existing platform treats togetherness as a side effect of something else — productivity, gaming, entertainment. We wanted a space that existed just to make two people feel less apart.

TogetherUs won't fix long-distance. We know.

But maybe it makes one couple's Sunday feel a little less lonely. Maybe it gives someone the feeling of sharing a couch they're 5,000 miles away from.

That was worth building.

Try It / Star the Repo

👉 Live: https://www.togetherus.in
👉 GitHub: https://github.com/Deepak0yadav/TogetherUs

It's open source under GPL-3.0. Contributions welcome — whether that's code, pixel art, bug reports, or just feedback on what togetherness should feel like.

Drop a comment if you've built anything in the real-time or presence space — we'd love to compare notes.

💼 Also shared this on LinkedIn — check out the post here if you'd like to connect or follow along.

The Team

Six of us built this. The irony of building a togetherness app as a distributed team was not lost on us.

Distance means so little when someone means so much.

#buildinpublic #showdev #webdev #opensource #javascript #react #realtimeapps #webrtc #ux #indiedev

📱 Access Your Localhost Website on Mobile Without Hosting! 🚀

Mayur Pawar — Sun, 02 Mar 2025 19:15:54 +0000

Have you ever imagined how can you access the webpage on your mobile which is present on localhost. So today we are going to discuss on how can we view the same webpage on your phone without actually hosting it.

🛠 Step 1: Open Visual Studio Code

Launch VS Code and make sure your project is ready to run.

🚀 Step 2: Start Your Local Server

Run your web project on localhost (e.g., npm start, live-server, etc.).

💻 Step 3: Open the Terminal in VS Code

Navigate to Terminal in the top menu or use Ctrl + ` (backtick) to open it.

🌐 Step 4: Enable Port Forwarding

Click on the Port section in VS Code and select Forward Port.

🔢 Step 5: Enter Your Port Number

Type in the port number your project is running on (e.g., 3000, 5500, etc.) and press Enter.

🔗 Step 6: Get Your Temporary Link

Once the port is forwarded, a temporary link will be generated. Copy this link! 📋

📲 Step 7: Access It on Your Phone!

📌 Open the link in your mobile browser, and voilà! 🎉 The same webpage running on your PC will now be visible on your phone.

⚠️ Important Note:

This link will only work as long as your project is running on localhost on your PC. So, make sure VS Code stays open and the project is active. ✅

That’s it! You’re now browsing your localhost project on mobile like a pro. 😎 Let me know in the comments if this worked for you! 🚀✨

🔥 Did you find this helpful? Don’t forget to ❤️ & 📝 leave a comment! 🚀