DEV Community: karabo seeisa

Update: My Phone-Built Auth CLI Hit 270+ Runs in 48 Hours And Already Got Its First Contributor

karabo seeisa — Thu, 23 Apr 2026 06:27:37 +0000

Two days ago I published “I Built a CLI That Generates Production-Ready Auth Backends in 30 Seconds (While Working From My Phone)”.

At that point the project had 177 tracked runs.
Since then… things got interesting.

As of April 22 (just 48 hours later):

270+ tracked real runs (internal telemetry)
160 runs in a single day (April 21 launch day)
143 of those 160 runs came directly from the GitHub repo done by only 5 unique people

Yes, you read that right.
Five strangers landed on the repo, read the README, and between them ran npx create-authenik8-app 143 times in one day.

That kind of repeat usage from a tiny group of early visitors is the best validation I could ask for.
And yesterday something even better happened.

I created a few small “[Good First Issue]” labels, including one for adding a clean production-ready /health endpoint to the generated Express + TypeScript templates.
Within hours, snakefood3232
replied saying:

“I’d handle this by implementing a middleware… Can have a PR up in the next 24 hours. I’ve built similar endpoints for multiple production-level applications…”

That was my first external contributor.

I’m still pinching myself.
This whole project started over two years ago as a full auth app, evolved through an SDK and the Identity Engine, and finally became the CLI I built entirely on my Android phone after my laptop died and I quit retail to go full-time.

Every single run still gives me a little notification, and seeing real people actually using it (and now contributing to it) keeps me going.
What changed in the last 48 hours:

• Added full SECURITY.md + private vulnerability reporting
• Enabled GitHub Sponsors (the button is now live)

Created realistic good-first-issues so others can jump in
First community PR is coming in the next day

If you tried the CLI after my last post , thank you.
If you haven’t yet, here’s the one-command way:

npx create-authenik8-app my-app

Repo: https://github.com/COD434/create-authenik8-app

Example generated app: https://github.com/COD434/create-authenik8-app-example

Discussions (come say hi): https://github.com/COD434/create-authenik8-app/discussions

There are still open good-first-issues if you want to be the second contributor 😉

Would love to hear what you think , drop a comment below with any feedback, what’s missing, or what you built with it.

This phone-built project is just getting started.

— Karabo (COD434)

I Built a CLI That Generates Production-Ready Auth Backends in 30 Seconds (While Working From My Phone)

karabo seeisa — Tue, 21 Apr 2026 10:58:42 +0000

Introduction

Two months ago I quit my retail job to go full indie.
Then my laptop died.

Since then, I’ve been building create-authenik8-app entirely on my phone , and it just crossed 177 runs with a new daily record of 51 yesterday.

The idea was simple: I was tired of starting every new backend project by copy-pasting the same JWT + refresh token + Redis + RBAC code… and often getting parts of the security wrong.

So I built a CLI that does it correctly from day one.

npx create-authenik8-app my-app

30 seconds later you have a production-ready Express + TypeScript backend with secure authentication already solved.

The Problem Most Developers Face

Every backend needs authentication. Yet most of us waste days (sometimes weeks) on:

Setting up secure JWT access + refresh tokens with proper rotation
Implementing replay protection and secure token storage (usually in Redis)
Handling OAuth account linking without creating duplicate users
Adding RBAC middleware that actually works
Wiring up production concerns (rate limiting, Helmet, PM2, memory guards, etc.)

Even with Passport.js or Lucia, you still end up gluing everything together and hoping you didn’t introduce subtle security flaws.

I wanted something better.
The Solution:
create-authenik8-app

create-authenik8-app is not another auth library.
It’s a focused auth system generator that scaffolds a clean, opinionated, production-ready starter.

What you get instantly:
✅ JWT (access + refresh tokens) with secure rotation and JTI replay protection
✅ Redis-backed stateful sessions
✅ Built-in RBAC middleware (auth.requireAdmin, etc.)
✅ Google & GitHub OAuth handled intelligently
✅ Prisma support (optional)
✅ Clean scalable folder structure + TypeScript
✅ Auto-generated .env with secure defaults
✅ Production extras (PM2 cluster mode, Helmet, rate limiting, memory guards)

The Identity Engine: The Real Differentiator

At the core is the Authenik8 Identity Engine (inside authenik8-core).

Instead of treating auth as separate login flows, it treats authentication as an identity resolution problem.

It intelligently:

Unifies credentials (email/password) and OAuth providers
Prevents duplicate identities
Handles smart account linking
Normalizes provider profiles into your app’s schema
Applies consistent security rules across all methods
This design makes the whole system cleaner, more secure, and much easier to extend (MFA, WebAuthn, etc. are coming).

See Exactly What You Get

I published a real generated example so you can inspect the output without running anything:

create-authenik8-app-example

You’ll see clean code, proper middleware usage, and how the Identity Engine is integrated.

Security & Trust

I know the biggest concern many developers have: “It has a closed-source core , why should I trust it?”
Valid point. Auth is critical.

Here’s my stance:

The CLI is 100% open source ,you can see exactly how everything is wired.
The Identity Engine is closed-source by design (common in security tooling) to protect sensitive implementation details like exact replay protection and token lifecycle logic.

Everything generated is fully inspectable and uses battle-tested patterns.
I added full CI on every push/PR with a live status badge.

I’m actively working on more transparency: detailed threat model, SECURITY.md, and future third-party audit.

My goal is to give solo devs and small teams a much better starting point than copy-paste boilerplate ,while being honest about the trade-offs.

My Journey So Far

Building this on a phone has been chaotic but rewarding.
Every time someone runs the CLI, I get a little notification and it keeps me motivated. The growth has been surprising, from 0 to 177 runs in under two weeks, with strong spikes after sharing updates.

I’m iterating daily based on feedback (thank you to everyone who’s commented!).

Who Is This For?

Solo developers and indie hackers
Small teams that want to ship fast
Anyone tired of repeating the same auth setup on every project

If you’re building something real and want auth done correctly without the usual headache, give it a spin.

Try It Now
npx create-authenik8-app my-app
cd my-app
redis-server --daemonize yes
npm run dev

Repo: https://github.com/COD434/create-authenik8-app
Example output: https://github.com/COD434/create-authenik8-app-example
npm: create-authenik8-app

If it saves you time, a star would mean a lot to this phone-built project ⭐

I’d love your honest feedback ,what’s missing? What should I improve next?

Building a Secure Auth System in Express (JWT, Redis, Refresh Tokens, and RBAC) and Automating It with a CLI

karabo seeisa — Sat, 04 Apr 2026 07:46:19 +0000

Authentication in Express applications is often underestimated.

Most implementations stop at “generate a JWT and verify it,” but real-world systems require much more:

• Refresh token rotation

• Token invalidation

• Concurrency safety

• Role-based access control (RBAC)

• Stateful tracking (usually via Redis)

After building this stack multiple times, I decided to formalise it into a reusable system and eventually a CLI that scaffolds it in seconds.

This post breaks down the architecture behind it and how you can use it.

The Problem with Typical JWT Auth

A basic JWT setup usually looks like this:

TypeScript

const token = jwt.sign(user, secret, { expiresIn: "15m" });

This works for simple cases, but breaks down quickly:

No Token Revocation

Once issued, a JWT is valid until it expires.

You can’t easily invalidate it.

Stateless Refresh = Security Risk

If refresh tokens are not tracked, they can be reused indefinitely.

Concurrency Issues

If two refresh requests happen at the same time:

both can succeed

multiple valid tokens are created

This leads to token duplication and potential session abuse.

The Architecture I Settled On

To solve these issues
, the system uses:

Access Tokens (JWT)

• Short-lived (e.g. 15 minutes)

• Used for API authentication

• Stateless verification

Refresh Tokens (Stateful)

• Stored in Redis

• Rotated on every use

• Old tokens are invalidated

This gives you control over sessions.

Redis as a Token Store

Redis acts as the source of truth for refresh tokens:

• Track active sessions

• Invalidate tokens instantly

• Enforce single-use refresh tokens

Refresh Token Rotation

Every refresh request:

• Verifies the token

• Checks Redis for validity

• Deletes the old token

• Issues a new refresh token

This ensures:

A refresh token can only be used once.

Concurrency Safety

A key problem is handling simultaneous refresh requests.

Solution:

• Atomic operations in Redis

• Only one request can invalidate + rotate

• The second request fails with 401

This prevents replay attacks and token duplication.

RBAC (Role-Based Access Control)

Authentication is not enough , you also need authorization.

Example middleware:

TypeScript

app.get("/admin", auth.requireAdmin, (req, res) => {

res.json({ message: "Admin only" });

});

This ensures only users with the correct role can access protected routes.

Putting It Together
The system exposes a simple interface:

TypeScript:

const auth = await createAuthenik8({

jwtSecret: process.env.JWT_SECRET!,

refreshSecret: process.env.REFRESH_SECRET!,

});

From there:

signToken() → access tokens

generateRefreshToken() → refresh tokens

Refresh token() → rotation logic

requireAdmin → RBAC middleware

Automating the Setup
After building this repeatedly, I created a CLI to remove the setup step entirely:

Bash

npx create-authenik8-app my-app

This generates:

• Express + TypeScript project

• JWT + refresh token system

• Redis integration

•RBAC middleware

• Preconfigured routes

You can go from zero → running auth server in minutes.

Why Redis is Required
A common question is: “Why not keep everything stateless?”

Because:

• You can’t revoke tokens

• You can’t prevent reuse

• You can’t track sessions

Redis enables:

• Immediate invalidation

• Session tracking

• Single-use refresh tokens

Trade-offs

This approach introduces:

• External dependency (Redis)

• Slight complexity increase

• Network latency for token validation

But in exchange, you get:

• Proper session control

• Stronger security guarantees

• Predictable auth behavior

Final Thoughts

Authentication is one of those systems that seems simple until it isn’t.

The difference between a basic implementation and a production-ready one is:

• handling edge cases

• controlling state

• preventing abuse

This project started as a way to standardize those decisions and avoid rewriting the same logic repeatedly.

If you’ve built auth systems before, I’d be interested in how you approach:

refresh token handling
revocation strategies
concurrency edge cases

Links:
Authenik8 site:https://authenik8.vercel.app/

Gitlab: https://gitlab.com/COD434/create-authenik8-app

Tiktok: https://www.tiktok.com/@thesbd8?\_r=1&\_t=ZS-9577WVfucT4

Try It

Bash

npx create-authenik8-app my-app

Closing

If you’re working with Express and need a solid starting point for authentication, this should save you a significant amount of setup time.

Feedback is welcome.

RabbitMQ: The Superhero My API Didn’t Know It Needed

karabo seeisa — Mon, 28 Jul 2025 13:20:16 +0000

The Problem: Hanging Requests, Delivered Emails

In my Node.js API, users register and receive a verification email. Simple, right?

But something strange kept happening:

The email would be sent
But the HTTP request would hang
The client got no response
My logs showed timeouts
And eventually… crashed sockets

After digging, I realized:

The SMTP email-sending process was blocking the main thread just long enough to let the HTTP connection time out.

This was a race condition: my API was waiting for the SMTP server to respond, while the client’s connection was waiting for me.

The Insight: Decouple the Work

I realized I was making the email-sending part synchronous, tying the API response to something slow (SMTP).

That’s when I remembered the concept of queuing so I did some research and found that personally I liked RabbitMQ.

How I Fixed This Issue

Here’s what I did:

The /register route publishes a message to a RabbitMQ queue (emailQueue)
A separate email worker subscribes to the queue
The worker handles the SMTP email process asynchronously
Meanwhile, the API responds immediately to the client

Here's What Achieved:

No more hanging sockets
Emails still go out
Race condition avoided
Clean separation of concerns

Why I Chose RabbitMQ?

I could’ve tried background threads or retry logic. But RabbitMQ gave me:

Message durability
Retry control
A proper job queue
A decoupled architecture I can scale later

And now, I can apply this same technique for:

Password resets
Event logs
Audit trails
Even SMS messages or 2FA

Call me a nerd but I think that's cool.

Implementation:

This is the publisher - gets the request to send a verification email, drops it into a queue, and the worker handles the rest . simple, fast, and scalable.

export const publishToQueue = async (queue: string, message: any)=>{
if(!channel)
throw new Error("RabbitMQ channel not initialized");
channel.sendToQueue(queue,Buffer.from(JSON.stringify(message)),{persistent: true});
}

This is the worker - It consumes messages form the queue and sends the email asynchronously,without delaying the HTTP response to the client .

That means users don't wait around for an email to send = much better UX if you ask me

channel.consume("emailQueue",async (msg) =>{
if(msg !== null){
const {email,verifyToken} = JSON.parse(msg.content.toString())
await sendVerificationEmail(email,verifyToken);
channel.ack(msg)
}
})

Final Thoughts

If your API does more than just respond to users — like sending emails or talking to 3rd parties — don’t make it wait.

RabbitMQ helped me move that responsibility out of the request cycle and made my code faster, safer, and easier to maintain.

I also plan to use it in the near future.

Let’s Connect

Have you hit similar issues in your backend? let me know how you tackled async tasks or race conditons.

Here's how I implemented it might spark something in your project :Github

A Plug and Play Auth API

karabo seeisa — Sun, 13 Jul 2025 14:39:58 +0000

From "Simple Form" to Full Pure Backend Auth API—Here’s What I Learned

I thought building a form would be easy. Spoiler: I was wrong.

What started as a basic CRUD app quickly spiraled into a deep dive into:

✔️ Token-based authentication (JWT)

✔️ Password hashing & encryption

✔️ Role-based access control

✔️ Redis-rate-limiting
And some other cool features

Turns out, the "Login with Google" button I mindlessly click every day? Way more complex under the hood.

I built this Auth API to demystify the process with security, docs, and scalability in mind. Perfect for devs who:

🔹 Want to see auth workflows stripped bare

🔹 Need a reference for their next project

Check it out & roast my code: (https://github.com/COD434/Auth-System-API)

Question for you:
What’s the most "simple" feature that surprised you with its complexity?