I built a CLI that tells you exactly what's on your port before killing it

Abhishek Verma — Thu, 09 Apr 2026 11:30:21 +0000

We've all been here:

$ lsof -i :3000
COMMAND   PID  USER   FD   TYPE  ...
node     3877  dev   ...

Is that my Next.js dev server? A stale process? Something else entirely? You grep, you squint, you kill -9 and hope for the best.

I got tired of guessing. So I built portrm.

What it does

ptrm 3000

Output:

⚡ Port 3000 in use
→ Next.js (PID 3877)
→ running for 9s
→ memory 69.4 MB
→ next-server (v14.2.29) TERM_PROGRAM=vscode
→ user dev
→ cwd /home/dev/projects/my-app
→ detected Next.js (95% confidence)
→ 🛡️ safe to kill.

Before touching anything, it shows you:

What process is on that port
How long it's been running
Memory usage
Working directory — so you know which project it belongs to
Framework detection — Next.js, Vite, Express, and more
Safety verdict — whether it's safe to kill

Then it sends SIGTERM first (graceful shutdown), and only escalates to SIGKILL if the process doesn't exit in time. No blind force kills.

Works in CI and scripts too

ptrm 3000 && npm start

Clean exit codes, fully scriptable. Drop it in your Makefile or pre-start hooks.

Install

# Homebrew
brew install abhishekayu/tap/portrm

# Cargo
cargo install portrm

# npm
npm install -g portrm

Single static binary. No Node, no Python, no runtime deps required.

Why I built this

On shared dev machines and in CI environments, a blind kill -9 on a PID you're not sure about can take down the wrong service. The "show first, kill second" approach has saved me a few times already.

Built in Rust mostly for the single binary distribution and native signal handling.

Repo: github.com/abhishekayu/portrm
Site: portrm.dev

Would love feedback especially if there's a workflow this breaks or a feature you'd expect.

Stop managing RBAC and feature flags separately in React

Abhishek Verma — Fri, 27 Mar 2026 11:40:45 +0000

Access control gets messy faster than most people expect.

Most apps handle:

RBAC (roles & permissions)
Feature flags
Experiments
Plan-based access

…as separate systems.

That usually leads to:

duplicated logic across frontend and backend
inconsistent behavior over time
harder scaling as the product grows

The problem

At small scale, this works fine.

But as your app grows:

permissions live in one place
feature flags in another
experiments somewhere else

👉 Now your logic is fragmented.

You end up asking:

“Is this user allowed?”
“Is this feature enabled?”
“Is this experiment active?”

…in multiple places, with different rules.

A better approach

Instead of managing all of this separately, unify everything into a single access layer.

👉 Define access once
👉 Use it everywhere

Example

const canEdit = access.can("edit_post", user)

if (canEdit) {
  return <EditButton />
}

Same logic:

frontend
backend
APIs

What I’ve been building

I’ve been working on a small library called React Access Engine to solve this.

It combines:

RBAC
ABAC
Feature flags
A/B experiments
Plan-based access
Remote config

👉 Into one consistent system.

Why this matters

No duplicated logic
Consistent behavior across layers
Easier to scale
Cleaner mental model

Curious how others are solving this

Would love to hear how you're handling access control in production apps — especially at scale.

Links

GitHub: https://github.com/abhishekayu/react-access-engine

react-access-engine.dev

Forem: Abhishek Verma