DEV Community: Ramananda Panda

I put my API collection in a folder of curl scripts, and it finally behaved

Ramananda Panda — Mon, 05 Oct 2026 07:59:46 +0000

Chapter 1: The JSON file that ate Friday

It was a Friday evening. The kind where you push one last fix and promise yourself you'll close the laptop in five minutes.

Then a teammate pinged me:

"Hey, can you review my change to the API collection?"

I opened the pull request. It was a single file, Petstore.postman_collection.json. The diff was 1,400 lines. Somewhere in that wall of "id", "_postman_id" and re-ordered keys, one header had changed. Probably. I approved it the way you accept cookie banners: quickly, and with mild guilt.

Later the CI job failed, because the CI runner needed a different tool, a different login and a different copy of the environment. My "five minutes" turned into an evening of archaeology.

That night I asked a dangerous question:

What if an API request was just... a curl command in a file?

Chapter 2: The humble `.sh` file

Every backend developer already speaks curl. We paste it into Slack, into bug reports and into README files. It is the lingua franca of HTTP.

So I wrote one:

curl -sS "$BASE_URL/pets" \
  -H "Authorization: Bearer $TOKEN"

It worked. It was readable. It diffed beautifully. But it couldn't answer the questions a test suite needs to answer:

Did it return the status I expected?
Is the body actually right?
How do I pass the token from the login call to the next one?

I didn't want a new language for that. Comments, however, are free. Every shell already ignores them.

Chapter 3: Comments that do real work

Here is the same request, with a few annotations on top. This is the actual login file from the Sankh petstore example:

#!/usr/bin/env bash
# @name Log in
# @tags smoke
# @expect status 200
# @expect json .token exists
# @capture TOKEN=.token
curl -sS "$BASE_URL/login" \
  -H 'Content-Type: application/json' \
  -d "{\"username\":\"$PET_USER\",\"password\":\"$PET_PASSWORD\"}"

Read it like a sentence:

@name gives the request a human name.
@tags smoke puts it in the smoke suite.
@expect status 200 means anything else is a failure.
@expect json .token exists checks the body with a jq expression.
@capture TOKEN=.token saves the token for every request that comes after.

And here is the best part: to the shell, all of that is just comments. The file still runs on its own, with or without Sankh:

set -a; . environments/dev.env; set +a
sh auth/01-login.sh

No lock-in, no export button, no proprietary format. If Sankh vanished tomorrow, you'd still own a folder of perfectly good curl commands. That's my favourite feature, and I didn't even have to write code for it.

Chapter 4: A collection is just a folder

Put a few of those files together and you have a collection:

petstore/
  sankh.toml            # optional: name, default env, timeout
  .env.example          # what secrets you need (no values)
  .env.local            # your actual secrets (gitignored)
  environments/
    dev.env
    ci.env
  auth/
    01-login.sh
  pets/
    01-list.sh
    02-create.sh
    03-get.sh
    04-delete.sh
    05-get-deleted.sh

The numeric prefixes set the run order. environments/dev.env holds the boring, shareable values:

BASE_URL=http://localhost:4010
PET_USER=demo

And the password? It goes in .env.local, which is gitignored. Secrets in git are like glitter: you never fully get rid of them.

Chapter 5: Chaining, or "the token relay race"

APIs are rarely one call. You log in, create something, fetch it, delete it, then check it's really gone. Each step hands something to the next, like runners passing a baton.

The create step catches two batons at once, the new pet's id from the body and a request id from a response header:

#!/usr/bin/env bash
# @name Create pet
# @description Creates a pet and stores its id for the next steps.
# @tags smoke
# @expect status 201
# @expect json .name == "Rex"
# @expect json .tags contains "good-boy"
# @capture PET_ID=.id
# @capture REQUEST_ID=header X-Request-Id
curl -sS "$BASE_URL/pets" \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"name":"Rex","tags":["good-boy"]}'

The next request just uses $PET_ID like any shell variable:

#!/usr/bin/env bash
# @name Get pet
# @expect status 200
# @expect json .id | tostring == "$PET_ID"
# @expect json .status matches "^(available|pending|sold)$"
curl -sS "$BASE_URL/pets/$PET_ID" \
  -H "Authorization: Bearer $TOKEN"

And because a good test suite also checks the sad paths, the last step expects a 404:

#!/usr/bin/env bash
# @name Deleted pet is gone
# @tags negative
# @expect status 404
# @expect json .error == "not found"
curl -sS "$BASE_URL/pets/$PET_ID" \
  -H "Authorization: Bearer $TOKEN"

Without any @expect status, a request passes on any 2xx. Once you write @expect status 404, a 404 is a success and a 200 is a failure. Finally, a tool that celebrates things going missing.

Chapter 6: Blow the conch

Sankh (शंख, "shankh") is the conch shell blown to announce a beginning. Here's what blowing it looks like:

$ sankh trust examples/petstore
$ sankh run examples/petstore
sankh · petstore · env dev (6 requests)
✓ Log in  200  12ms  auth/01-login.sh
    captured TOKEN=***
✓ List pets  200  4ms  pets/01-list.sh
✓ Create pet  201  5ms  pets/02-create.sh
    captured PET_ID=1
    captured REQUEST_ID=req-1
✓ Get pet  200  3ms  pets/03-get.sh
✓ Delete pet  204  3ms  pets/04-delete.sh
✓ Deleted pet is gone  404  3ms  pets/05-get-deleted.sh

6 passed  41ms

Notice TOKEN=***. Any variable whose name contains TOKEN, SECRET, KEY, PASSWORD, AUTH or COOKIE is masked everywhere: terminal output, reports and the UI. Screenshots of your terminal are now safe to post on the internet, and so is your pride.

Now let's break something on purpose. Say someone renames the dog and changes the assertion to @expect json .name == "Fluffy":

✗ Create pet  201  5ms  pets/02-create.sh
    json .name == "Fluffy": expected .name == "Fluffy", got "Rex"
    │ {"id":1,"name":"Rex","status":"available","tags":["good-boy"]}

It tells you which assertion failed, what it expected, what it got, and shows the body. Captures only run when every assertion passes, so a broken step never passes a bad PET_ID down the line. The run exits with code 1, which is exactly what CI wants to hear.

Chapter 7: CI, the part where Friday is saved

Remember the CI job that needed a different tool, login and environment? Here's the whole thing now:

- run: curl -fsSL https://sankh.dev/install.sh | sh
- run: sankh run . --env ci --tag smoke --trust --report junit
  env:
    PET_PASSWORD: ${{ secrets.PET_PASSWORD }}

One binary. Secrets come from CI, because the process environment beats the env files. --tag smoke runs just the smoke suite. --report junit gives your CI a test report it already knows how to display.

The exit codes mean something, too:

Exit code	Meaning
0	Everything passed
1	An assertion, a capture or a request failed
2	Usage or configuration error
3	The collection isn't trusted

And that pull request with the 1,400-line JSON diff? Now it looks like this:

 # @expect status 201
 # @expect json .name == "Rex"
+# @expect json .status == "available"

You can review that. You can even review it on your phone, in a queue, while pretending to listen to someone.

Chapter 8: "Wait, it runs shell scripts from a git repo?"

Yes. And that should make you a little nervous, so Sankh is nervous on your behalf.

Trust first. A freshly cloned collection refuses to run until you sankh trust it. In a git repository the trust is tied to the HEAD commit, so after a git pull you review and trust again. Nobody sneaks a rm -rf into 03-get.sh.
The local UI is locked down. sankh serve binds to 127.0.0.1, rejects foreign Host headers (so no DNS rebinding tricks) and blocks cross-origin calls. Any other address needs a token.
No telemetry. The only network requests Sankh makes are the ones in your files.

Chapter 9: For people who like buttons

Not everyone wants to live in the terminal, and that's fine:

sankh serve examples/petstore    # http://localhost:4747

You get a small web UI with a file tree, a form editor and a raw editor, an environment picker (with a Manage button to edit env files) and live results. The server runs the requests, not the browser, so there's no CORS drama.

There's also a desktop app for macOS, Windows and Linux, which is the same UI in a native window. And a Scratch collection for "let me just try this one call" moments, with Copy to… for when that one call turns out to be important.

Chapter 10: Bringing the old collection along

That Postman collection from Chapter 1? It doesn't have to be left behind:

sankh import postman Petstore.postman_collection.json --env dev.postman_environment.json

Folders become directories and requests become numbered .sh files. {{baseUrl}} becomes ${BASE_URL}. Common test scripts translate directly:

Postman	Sankh
`pm.response.to.have.status(201)`	`# @expect status 201`
`pm.environment.set("token", pm.response.json().token)`	`# @capture TOKEN=.token`

Anything Sankh can't translate is kept as comments and listed in an import report, because Sankh doesn't run JavaScript. Secrets are never written to disk; they're listed in .env.example, and .env.local is created with placeholder values for you to fill in.

Epilogue: How it works (it's almost embarrassing)

Sankh is written in Rust, and the trick at its core is small. It never modifies your file. It defines a curl shell function that adds -o, -D and -w '%{json}' to record the body, headers and timing, then sources your file. When curl finishes, Sankh checks your annotations against what it recorded.

That's why every curl flag you already know just works. Sankh didn't reinvent HTTP. It just started taking notes.

Try it

curl -fsSL https://sankh.dev/install.sh | sh
sankh init my-api
sankh trust my-api
sankh run my-api

Docs: sankh.dev
Code: github.com/sankh-dev/sankh
License: MIT or Apache-2.0

The annotation format is young, and @expect header, @expect time, @retry and @depends are next on the list. If you try it, tell me what's missing, and what made you smile. I'll take both.

Now go close that laptop. It's Friday. 🐚

I wanted GraphQL's superpower without GraphQL's personality disorder

Ramananda Panda — Tue, 07 Jul 2026 04:57:23 +0000

So I built MeshQL.

It's a small TypeScript library that lets clients say "give me these fields, nested like this" - over normal REST - while you keep writing SQL (or Prisma, or Drizzle, or Kysely) like a person who still enjoys weekends.

Tagline on the tin: Shape your API, not your codebase.

The problem nobody admits at standup

REST is fine until every frontend wants a different ?include= and you accidentally ship half the database in JSON because someone asked for user.posts.comments.author.avatar.url.

GraphQL fixes that - and then invoices you for:

47 resolvers
N+1 archaeology
Codegen that eats your types and burps Maybe<T> at 2am

What I actually wanted was the middle:

Normal URLs. Query in headers. One handler per entity. SQL I already know how to write.

That's MeshQL.

What it does (without the enterprise keynote voice)

Client sends a field selection - JSON or a little QL syntax - in X-Mesh-Query.
MeshQL parses it and builds a JoinPlan: exactly the fields and joins the client asked for. No over-fetching guilt trip.
Your resolver runs one query (SQL, Prisma findMany, whatever).
MeshQL shapes flat SQL rows into nested JSON.

No resolver per field. No dataloader yoga. No "quick sync, I just need to regenerate the schema real quick" (famous last words).

A tiny example

Schema:

const schema = {
  entities: {
    user: { fields: ["id", "name"], table: "users" },
    token: {
      fields: ["accessToken"],
      table: "tokens",
      columns: { accessToken: "access_token" },
    },
  },
  joins: {
    "user.tokens": {
      entity: "token",
      on: "tokens.user_id = users.id",
      type: "many",
    },
  },
};

Client query (conceptually):

{
  "user": {
    "id": true,
    "name": true,
    "tokens": { "accessToken": true }
  }
}

Your resolver gets a plan that says only fetch those fields. Return flat rows:

{ user_id: 1, user_name: "Ada", tokens_accessToken: "tok_ada" }

MeshQL hands the client:

{
  "id": 1,
  "name": "Ada",
  "tokens": [{ "accessToken": "tok_ada" }]
}

Still REST. Still one GET /mesh/user/1. Still your Express/Fastify/Hono app. The client just stops bullying your backend into bespoke DTOs.

"But I use Prisma and I'm emotionally attached"

Same. We just shipped v0.6.0 with ORM adapters:

You	One line
Prisma	`withPrisma(mesh, prisma, { schema })`
Drizzle	`withDrizzle(mesh, db, { schema })`
Kysely	`withKysely(mesh, db, { schema, dialect: "postgres" })`
Raw SQL enjoyers	`buildSelectSql(plan, schema)` + your pool

Catch-all resolver pattern:

mesh.resolve("*", async (plan) => {
  // plan.fields and plan.joins = only what the client asked for
});

Prisma example app in the repo: express-prisma.

Hot take: MeshQL does NOT want your database password

This confused me at first, so I'll save you the trip:

MeshQL doesn't create or pool connections.

You create PrismaClient / pg.Pool / DatabaseSync once at startup. You pass it into the resolver. MeshQL plans queries and shapes JSON. Connection lifecycle stays your problem - which is actually what you want in production anyway.

Docs: Database connections

What's in the box

Published on JSR (@meshql/*) and npm (meshql-*):

@meshql/core - parser, planner, shaper
@meshql/postgres / @meshql/sqlite - parameterized SQL builders
@meshql/prisma / @meshql/drizzle / @meshql/kysely - ORM adapters (new in 0.6.0)
@meshql/http - Express, Fastify, Hono
@meshql/client - typed client for Node + browser
@meshql/integrity + @meshql/access - signing & field/row access (optional, for when paranoia is a feature)

Install the core stack:

# JSR
npx jsr add @meshql/core @meshql/http @meshql/client

# npm
npm install meshql-core meshql-http meshql-client

Prisma path:

npx jsr add @meshql/core @meshql/prisma @meshql/http

Who is this for?

Probably you if:

You like SQL (or your ORM) and dislike resolver mazes
Your mobile/web clients keep asking for different field shapes
You want GraphQL-style selection without standing up GraphQL

Probably not you if:

You need a full mutation/subscription graph with a federated supergraph and a committee
You want the framework to own your DB pool (try something else; we're not fighting for that job)

Try it in five minutes

Full walkthrough: docs.meshql.dev/guide/run-example

Or clone the showcase - React + SQLite, no Docker, actual signed requests in DevTools:

git clone https://github.com/meshql/meshql.git
cd meshql && pnpm install && pnpm build
pnpm --filter showcase start
# http://localhost:3010

Why I built it

Honestly? I got tired of choosing between:

Shipping bloated REST, and
Adopting GraphQL and suddenly my side project needed a platform team.

MeshQL is the "what if the client shaped the response, but I kept my stack boring" experiment. It's MIT, Node 22+, works on Bun/Deno, and I'm using it for real APIs - not as a thought experiment that dies in a packages/ folder (we've all been there).

If you try it and something feels off, open an issue. If you try it and it clicks, I'd love to hear what you built.

Links:

GitHub: meshql/meshql
Docs: docs.meshql.dev
Prisma demo: express-prisma

P.S. - Yes, the name is a pun. No, I won't apologize. Yes, post.comments.author.name works end-to-end now. We fixed that before the ORM release because nested reads that don't actually read are a special kind of betrayal.

🚀 I Built QNVS — A Node.js Version Manager That Doesn't Need Admin Rights (Yes, Even on Windows)

Ramananda Panda — Thu, 09 Apr 2026 13:27:13 +0000

No sudo. No IT ticket. No drama. Just qnvs and vibes.

Suggested hero image: Unsplash — Christopher Gower (Developer workstation)

The Problem That Made Me Build This

Picture this: Monday morning. You're a developer at a company where IT guards the admin password like it's nuclear launch codes. You need Node.js 22 for a new project, but your machine has Node 18. The options?

Submit an IT ticket. Estimated response: 3-7 business days. Maybe. If Mercury is in retrograde.
Use nvm. Great on macOS/Linux! On Windows? [laughs in Group Policy]
Use nvm-windows. Requires admin privileges to create symlinks. Back to step 1.
Download Node.js manually. Sure, if you enjoy living like it's 2009.

None of these worked for me. So instead of rage-quitting, I rage-coded.

Meet QNVS — Quick Node Version Switcher. A single binary, zero-dependency, cross-platform, no-admin-required Node.js version manager with a gorgeous interactive TUI. Built in Go. Ships in ~10MB. Works everywhere.

Suggested image: Unsplash — Florian Olivo (Terminal/Code)

Wait, What Does "No Admin Required" Actually Mean?

Let me be crystal clear because this is the entire reason QNVS exists:

❌ No sudo
❌ No Administrator PowerShell
❌ No Developer Mode toggle
❌ No Group Policy exceptions
❌ No IT tickets
❌ No "please sir, may I have write access to Program Files"

QNVS lives entirely in user space. On macOS/Linux, it chills in ~/.qnvs. On Windows, it sits in %LOCALAPPDATA%\qnvs. That's it. Your home directory. The one place on the computer that's actually yours.

You download the binary. You run qnvs setup. You install Node.js versions. You switch between them. You feel powerful. All without elevating a single privilege.

The TUI That Made My Terminal Beautiful ✨

Look, I could've just built a boring CLI. But I had access to the Charm ecosystem — bubbletea, bubbles, lipgloss — and honestly, if you're going to build a terminal tool in 2025, you owe it to yourself to make it pretty.

Run qnvs with no arguments and you get this:

 ██████╗ ███╗   ██╗██╗   ██╗███████╗
██╔═══██╗████╗  ██║██║   ██║██╔════╝
██║   ██║██╔██╗ ██║██║   ██║███████╗
██║▄▄ ██║██║╚██╗██║╚██╗ ██╔╝╚════██║
╚██████╔╝██║ ╚████║ ╚████╔╝ ███████║
 ╚══▀▀═╝ ╚═╝  ╚═══╝  ╚═══╝  ╚══════╝
  Quick Node Version Switcher • No admin required

╭──────────────────────────────────────────────╮
│                                              │
│  ▸ 📦  Install Node.js                       │
│        Download and install a new version    │
│                                              │
│    📋  List/Switch                            │
│    🗑️   Uninstall                             │
│    🔧  Setup                                  │
│    🔓  Toggle TLS Skip                        │
│    ❓  Help                                   │
│    👋  Exit                                   │
│                                              │
│   2 installed   Active: v22.22.0             │
╰──────────────────────────────────────────────╯

  ↑↓ navigate │ ⏎ select │ q quit

Arrow keys to navigate. Enter to select. q to quit. That's the entire learning curve.

No flags to memorize. No --help to desperately consult. Just a menu. With emojis. Like civilized people.

Suggested image: Unsplash — Clay Banks (Colorful keyboard)

The Windows Problem (And How I Solved It)

Here's the dirty secret of Node.js version managers on Windows: they almost all rely on symlinks or junctions.

Symlinks need Developer Mode or admin rights
Directory junctions (mklink /J) usually work without admin... until your company's Group Policy says "nah"
Cue developer tears

QNVS takes a hybrid approach that I'm unreasonably proud of:

Step 1: Try to create a directory junction. This works on most Windows machines without admin rights and gives you fast, transparent version switching.

Step 2: If junctions fail (thanks, Group Policy), QNVS automatically falls back to shim mode — it creates tiny .cmd wrapper scripts in ~/.qnvs/bin/ that redirect to the active Node.js version:

@echo off
"C:\Users\you\AppData\Local\qnvs\versions\v22.22.0\node.exe" %*

That's it. A .cmd file. Group Policy can't block .cmd files because that would break literally everything else on Windows. It's not a hack — it's a feature.

The fallback is completely automatic and transparent. You don't configure anything. You don't even know it happened. QNVS just... works.

The CLI: For When You Know What You Want

The interactive TUI is great for exploring, but sometimes you just want to get in, switch versions, and get out. The CLI has your back:

# Install Node 22 (latest 22.x.x)
qnvs install 22

# Install the latest LTS
qnvs install lts

# Install a specific version
qnvs install 20.10.0

# Switch versions
qnvs use 22

# See what you've got
qnvs list

# What's active?
qnvs current

Version resolution is smart. Type 22 and QNVS fetches the latest 22.x.x from nodejs.org. Type lts and it finds the latest Long Term Support release. Type latest and... you get the latest. Revolutionary stuff.

Command	What It Does
`qnvs`	Launch the interactive TUI
`qnvs install <version>`	Download and install a version
`qnvs use <version>`	Switch to an installed version
`qnvs list`	List installed versions
`qnvs current`	Show the active version
`qnvs uninstall <version>`	Remove a version
`qnvs setup`	Initialize QNVS + configure PATH

Corporate VPN? No Problem.

Raise your hand if you've ever seen this error:

x509: certificate signed by unknown authority

If you're behind a corporate VPN like Cato, Zscaler, or Palo Alto, your company is probably doing TLS inspection — which means your HTTPS requests are getting re-signed by a corporate certificate that your tools don't trust.

Most tools: "Figure it out yourself. Here's a 47-step Stack Overflow thread."

QNVS: "Toggle a switch."

CLI:

qnvs install 22 --insecure

Interactive mode: Just select "🔓 Toggle TLS Skip" from the menu before installing.

Is it ideal? No. TLS verification exists for good reasons. But when you're on a locked-down corporate machine and the VPN is doing inspection, this beats "can't install Node.js at all" every single time.

Why Go? (Again)

I keep building things in Go and people keep asking why. So here's the elevator pitch:

Single binary. No runtime. No node_modules. No Python virtual environment. No Java classpath. Just one file. Copy it. Run it. Done.
Cross-compilation is stupid easy. One command gives me binaries for Windows/macOS/Linux across amd64 and arm64. Six platforms, zero hassle:

GOOS=windows GOARCH=amd64 go build -o qnvs-windows-amd64.exe .
GOOS=darwin  GOARCH=arm64  go build -o qnvs-macos-arm64 .
GOOS=linux   GOARCH=amd64  go build -o qnvs-linux-amd64 .

The Charm ecosystem. Bubbletea + Bubbles + Lipgloss = gorgeous terminal UIs with minimal effort. It's like React but for terminals and without the existential crisis of choosing a state management library.
~10MB binary. The entire tool — TUI, version resolution, download with progress bars, archive extraction, platform detection — fits in the space of about 3 JPEG photos from your phone.

Suggested image: Gopherize.me for a custom gopher, or Unsplash — Go-related imagery

How It Actually Works Under The Hood

For the curious (and the people who read source code for fun — I see you), here's the architecture:

The whole project is two files:

main.go — The core: version resolution, downloading, extraction, symlink/junction/shim management, CLI handling
interactive.go — The entire TUI, built on Bubbletea's Elm architecture

Version resolution hits https://nodejs.org/dist/index.json, parses the JSON, and fuzzy-matches your input. 22 → latest v22.x.x. lts → latest release where the lts field is a string (Node.js marks LTS versions with a codename like "Jod").

Downloading uses a custom progress bar (Charm's progress component) that shows real-time MB progress. It does a HEAD request first to get the content length, then streams the download with a 32KB buffer.

Extraction handles both .tar.gz (macOS/Linux) and .zip (Windows) natively — no tar or unzip binary needed. Pure Go. It even handles symlinks in tar archives (npm/npx are symlinks in the Node.js distribution).

Switching is where it gets spicy:

Unix: Swap a symlink. ~/.qnvs/current → ~/.qnvs/versions/v22.22.0. Done.
Windows (happy path): Create a directory junction. Same concept, Windows flavor.
Windows (corporate dystopia): Generate .cmd shims. Same result, different mechanism.

Installation: Pick Your Poison

macOS / Linux:

curl -L https://github.com/qnvs/qnvs/releases/latest/download/qnvs-linux-amd64 -o qnvs
chmod +x qnvs
./qnvs setup

Windows (PowerShell):

Invoke-WebRequest -Uri "https://github.com/qnvs/qnvs/releases/latest/download/qnvs-windows-amd64.exe" -OutFile "qnvs.exe"
.\qnvs.exe setup

Build from source:

git clone https://github.com/qnvs/qnvs.git
cd qnvs
go build -o qnvs .
./qnvs setup

setup creates the directory structure, copies the binary to ~/.qnvs/bin/, and even tries to auto-append the PATH export to your .bashrc or .zshrc. On Windows, it tells you exactly what to add to your PATH. No guessing.

Suggested image: Unsplash — Riccardo Annandale (Light bulb)

QNVS vs. The Competition

Let's be honest — there are other version managers out there. Here's where QNVS stands:

Feature	QNVS	nvm	nvm-windows	fnm	Volta
No admin required	✅	✅	❌	⚠️	⚠️
Windows support	✅	❌	✅	✅	✅
Works behind corporate VPN	✅ (built-in)	❌	❌	❌	❌
Interactive TUI	✅	❌	❌	❌	❌
Single binary	✅	❌	✅	✅	✅
Corporate Windows (no junctions)	✅ (auto shim)	N/A	❌	❌	❌
Zero dependencies	✅	❌ (bash)	✅	✅	✅

The corporate Windows row is the killer feature. If you've ever been stuck on a locked-down Windows machine where mklink is blocked and Developer Mode is disabled, you know the pain. QNVS is the first version manager I know of that handles this gracefully with its automatic shim fallback.

Who Is This For?

🏢 Corporate developers trapped behind Group Policy and VPN inspection
💻 Windows users who are tired of "requires admin" being the answer to everything
🎨 TUI enthusiasts who believe CLI tools should be beautiful
🏃 Developers who hate bloat — one binary, no runtime, no install scripts
🔄 Anyone juggling multiple Node.js projects with different version requirements
🆕 Beginners who find nvm confusing — just run qnvs and use the arrow keys

If you've ever Googled "how to install Node.js without admin rights" at 11 PM on a work laptop... I built this for you.

Suggested image: Unsplash — Jason Leung (Confetti)

What's Next?

QNVS is at v1.1.3 and I'm actively working on it. Things rattling around in my brain:

📌 Auto-detect .nvmrc / .node-version — walk into a project directory and QNVS switches automatically
🔄 Self-update — qnvs update to grab the latest QNVS binary
📦 Package manager support — install and manage pnpm/yarn alongside Node
🪟 Windows code signing — so you stop getting the "Unknown Publisher" warning
🌐 Mirror support — for environments that can't reach nodejs.org directly
📊 Disk usage display — see how much space each version is eating

Give It a Spin ⭐

QNVS is open-source (MIT licensed) and lives at github.com/qnvs/qnvs.

Three steps to happiness:

Download the binary for your platform from Releases
Run qnvs setup
Run qnvs and bask in the TUI glow

Star the repo if it saved you from filing an IT ticket. Open an issue if something's broken. Submit a PR if you want to make it better. Or just enjoy switching Node versions without asking anyone's permission for once in your corporate life.

Built with 🐹 Go, the ✨ Charm ecosystem, and a deep resentment for "Please contact your system administrator."

🚀 I Built PQPM — A Process Manager That Doesn't Care What Language You Speak

Ramananda Panda — Thu, 09 Apr 2026 06:13:49 +0000

And yes, your PHP queue workers, Go binaries, and Python bots can finally coexist in peace.**

Suggested hero image: Unsplash — Taylor Vick (Server Room)

The Itch I Couldn't Stop Scratching

If you've ever managed a VPS — especially with something like Virtualmin — you know the pain. You've got 14 users on a shared server. Dave is running a Laravel queue worker. Sarah has a Go API. And someone named admin3 (who no one remembers creating) is running a rogue Python Discord bot eating 90% of the RAM.

You SSH in. You nohup. You screen. You pray.

PM2? Great tool! ...if your entire universe is Node.js. But the moment you need to babysit a PHP artisan command or a compiled Go binary, PM2 looks at you like you just spoke Klingon.

I needed something that:

Let non-root users manage their own processes (without calling me at 2 AM)
Was language-agnostic — Go, PHP, Python, Rust, a bash script that plays elevator music — I don't judge
Had real resource limits so one bad actor doesn't nuke the whole server
Was dead simple to configure

So I built it. Meet PQPM — the Process Queue Process Manager.

Suggested image: Unsplash — Gabriel Heinzer (Terminal/Code)

What Even Is PQPM?

PQPM is a lightweight, system-level process manager written in Go. It runs as a daemon (pqpmd) on your Linux server and lets any user on the system manage their own long-running processes through a simple CLI (pqpm).

Think of it as a bouncer at a nightclub: the daemon has the master key (runs as root), but it immediately drops privileges to match the user who's requesting the action. User A can't touch User B's stuff. Period.

Here's the whole mental model:

The Daemon (pqpmd) — runs as root, listens on a Unix socket
The Config (~/.pqpm.toml) — each user defines their services in a dead-simple TOML file
The CLI (pqpm) — users run commands like pqpm start my-worker with zero sudo required
The Magic — the daemon verifies the caller's identity using kernel-level socket credentials (SO_PEERCRED), then spawns the process under that user's UID/GID

No sudo. No chmod 777 hacks. No "just run everything as root and hope for the best."

The Config File is Chef's Kiss 🤌

I'm a sucker for simple config files. XML can leave. YAML can take its "is this a string or a boolean" energy elsewhere. TOML just... makes sense.

Here's what a user's ~/.pqpm.toml looks like:

[service.my-worker]
command = "/usr/bin/php /home/user/public_html/artisan queue:work"
restart = "always"
max_memory = "512MB"
cpu_limit = "20%"

[service.api-server]
command = "/home/user/bin/api-server --port 8080"
restart = "on-failure"
max_memory = "1GB"
cpu_limit = "50%"
working_dir = "/home/user/api"
env = { NODE_ENV = "production", PORT = "8080" }

[service.python-bot]
command = "/usr/bin/python3 /home/user/bots/discord_bot.py"
restart = "always"
max_memory = "256MB"
cpu_limit = "10%"

Three services. Three languages. One config file. Zero drama.

Suggested image: Unsplash — Chinmay B (Gopher) or any Go mascot image from Gopherize.me

Why Go? Because Speed is Non-Negotiable

When your process manager is responsible for keeping other people's services alive, it better not be the thing that dies first.

Go gave me:

Goroutines & channels for async, non-blocking process monitoring (each managed process gets its own goroutine — beautiful)
Static binaries — pqpmd and pqpm are single-file executables. No runtime. No dependencies. Just curl, extract, and go
First-class syscall support — spawning processes, dropping privileges with setuid/setgid, reading SO_PEERCRED from Unix sockets — Go's golang.org/x/sys package is a dream
Cross-compilation — building for amd64 and arm64 in one make command

The entire dependency tree is laughably small: BurntSushi/toml for config parsing, spf13/cobra for the CLI, and golang.org/x/sys for syscalls. That's it. Three dependencies. In 2025. I'll wait while you pick your jaw up off the floor.

Security: The Part I Lost Sleep Over (So You Don't Have To)

This is a process manager that runs as root. Let me say that louder for the people in the back: it runs as root. If the security isn't airtight, you might as well email your SSH keys to a stranger.

Here's how PQPM stays paranoid (in a healthy way):

🔐 Identity via `SO_PEERCRED`

When the CLI connects to the daemon over a Unix Domain Socket, the daemon asks the kernel — not the user — "who is this?" The kernel responds with the UID, GID, and PID. No tokens. No passwords. No trust-me-bro headers. The kernel doesn't lie.

🪂 Immediate Privilege Drop

The daemon spawns the process as root but instantly drops to the target user's UID/GID. The spawned process never runs with elevated privileges. Not even for a millisecond... well, maybe a couple of nanoseconds. Go is fast.

🧱 Resource Limits via cgroups

Each process can have hard limits on memory and CPU using Linux cgroups (v2). If Dave's queue worker decides to allocate 16 GB of RAM, cgroups will politely (and firmly) say no.

📂 Path Restrictions

Processes are locked to running within the user's authorized directories. No sneaky ../../etc/shadow business.

Suggested image: Unsplash — FlyD (Neon Lock)

The CLI: Boring On Purpose

I didn't want a CLI that requires a PhD to operate. Six commands. That's your entire vocabulary:

Command	What It Does
`pqpm start <name>`	Fire up a service
`pqpm stop <name>`	Gracefully stop it
`pqpm restart <name>`	Stop + start (shocking, I know)
`pqpm status`	See what's running
`pqpm log <name>`	Tail logs for a service
`pqpm version`	Print the version

That's it. No pqpm init --template advanced --with-monitoring --enable-clustering --sacrifice-goat. Just start, stop, restart, status, log, version. Done.

Installation: The One-Liner™

curl -sSL https://raw.githubusercontent.com/pqpm/pqpm/main/install.sh | sudo bash

This detects your architecture, pulls the latest release from GitHub, drops the binaries into /usr/local/bin, creates runtime directories, and sets up the systemd service. The whole thing takes about 5 seconds.

Want to build from source? Also easy:

git clone https://github.com/pqpm/pqpm.git
cd pqpm
make build && sudo make install

Updating? Run the one-liner again. Your managed processes keep running and get "re-adopted" by the daemon once it restarts. Like a responsible parent coming home from the grocery store.

Suggested image: Unsplash — SpaceX (Rocket Launch)

Who Is This For?

VPS admins running shared hosting environments (especially Virtualmin/Webmin setups)
Small teams where multiple developers deploy services on the same box
Anyone tired of PM2 who runs more than just Node.js
The sysadmin who wants their users to stop asking for root access to run a queue worker
Solo devs running a $5 VPS with a Go API, a PHP backend, and a Python cron job — all at once

If you've ever typed nohup something & and then immediately regretted your life choices, PQPM is for you.

What's Next?

PQPM is at v0.2.3 and actively being developed. Here's what's on the roadmap (or at least, living rent-free in my head):

📊 Web dashboard — because sometimes you want to click buttons instead of typing commands
🔔 Notifications — get pinged when a process dies (and auto-restarts)
📈 Metrics export — Prometheus-compatible resource usage stats
🐳 Container-aware mode — playing nice with Docker environments
🧪 More tests — always more tests

Give It a Spin ⭐

PQPM is open-source (MIT licensed) and lives at github.com/pqpm/pqpm.

If it saves you even one sudo argument with a client, one 2 AM SSH session, or one "why is the server at 100% CPU" panic — I'll consider it a win.

Star the repo if you dig it. Open an issue if you find a bug. Submit a PR if you're feeling generous. Or just silently use it and never tell me — that's cool too. I'll never know. But my download counter will. 👀

Built with 🐹 Go, ☕ too much coffee, and a burning hatred for nohup.

Image Source Summary

Here's a quick reference for all the suggested images (all free to use via Unsplash):

Section	Image	Source
Hero / Banner	Server room / data center	Unsplash — Taylor Vick
"What Is PQPM"	Terminal with code	Unsplash — Gabriel Heinzer
"Why Go?"	Go gopher / mascot	Gopherize.me or Unsplash
Security section	Neon lock / cybersecurity	Unsplash — FlyD
Installation	Rocket launch	Unsplash — SpaceX
Community / CTA	Team collaboration	Unsplash — Annie Spratt

Fixing "No valid 'aps-environment' entitlement string found for application" in Flutter App

Ramananda Panda — Wed, 12 Feb 2025 16:56:53 +0000

Introduction

If you're developing a Flutter app with push notifications on iOS, you might encounter this frustrating error:

"No valid 'aps-environment' entitlement string found for application"

This issue prevents push notifications from working correctly and often appears when configuring Firebase Cloud Messaging (FCM) or APNs (Apple Push Notification Service). But don’t worry! In this blog, we’ll walk you through the exact steps to fix it.

Why Does This Happen?

The error occurs because iOS requires a valid `entitlement in your app’s provisioning profile. This entitlement determines whether your app supports push notifications in development (development) or production (production`). If it’s missing, iOS refuses to deliver push notifications.

Step-by-Step Fix

1. Enable Push Notifications in Xcode

Open your Flutter project’s iOS folder in Xcode.
Select your Runner project from the left panel.
Navigate to Signing & Capabilities.
Click the + Capability button and add Push Notifications.
Also, add Background Modes and check Remote notifications.

2. Ensure Your Provisioning Profile Supports Push Notifications

Go to Apple Developer Account.
Navigate to Certificates, Identifiers & Profiles > App IDs.
Find your app’s bundle ID and make sure Push Notifications is enabled.
If it's not enabled, edit the App ID and enable Push Notifications.
Now, head to Profiles and regenerate your Provisioning Profile.
Download and install the new profile in Xcode (Preferences > Accounts > Manage Certificates).

3. Check the `Entitlements.plist` File

Open Runner/Runner.entitlements in Xcode.
Ensure it contains the following key: `xml <key>aps-environment</key> <string>development</string>  `
If the file doesn’t exist, create a new one named Runner.entitlements and add the above content.
Go to Build Settings in Xcode, search for Code Signing Entitlements, and make sure it includes Runner.entitlements.

4. Make `Runner.entitlements` Available for Debug Mode

When a user enables push notifications, Xcode adds a RunnerProfile.entitlements file:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>aps-environment</key> <string>development</string> </dict> </plist>

However, this file may not be available when you try to build and run the app on a simulator or device. To resolve this, you need to explicitly specify the entitlement file for debug mode:

Go to Build Settings in Xcode.
Navigate to Signing > Code Signing Entitlements.
Set the entitlement file path (Runner.entitlements) for each build mode.
Users can set multiple entitlement files for debug and release modes.
- For debug, set aps-environment to development.
- For release, set aps-environment to production.

5. Rebuild and Deploy

Clean the project: sh flutter clean
Reinstall dependencies: sh flutter pub get
Run your app again: sh flutter run
If you are building for release, ensure you archive and upload the build to TestFlight or App Store.

Final Thoughts

This error can be annoying, but following these steps should resolve it quickly. If you still face issues, double-check your Apple Developer settings and Xcode configurations.

Now, go ahead and test your push notifications! 🚀

Have you faced this issue? Let me know in the comments how you fixed it or if you need any help! 🙌

DEV Community: Ramananda Panda

I put my API collection in a folder of curl scripts, and it finally behaved

Chapter 1: The JSON file that ate Friday

Chapter 2: The humble .sh file

Chapter 3: Comments that do real work

Chapter 4: A collection is just a folder

Chapter 5: Chaining, or "the token relay race"

Chapter 6: Blow the conch

Chapter 7: CI, the part where Friday is saved

Chapter 8: "Wait, it runs shell scripts from a git repo?"

Chapter 9: For people who like buttons

Chapter 10: Bringing the old collection along

Epilogue: How it works (it's almost embarrassing)

Try it

I wanted GraphQL's superpower without GraphQL's personality disorder

The problem nobody admits at standup

What it does (without the enterprise keynote voice)

A tiny example

"But I use Prisma and I'm emotionally attached"

Hot take: MeshQL does NOT want your database password

What's in the box

Who is this for?

Try it in five minutes

Why I built it

🚀 I Built QNVS — A Node.js Version Manager That Doesn't Need Admin Rights (Yes, Even on Windows)

The Problem That Made Me Build This

Wait, What Does "No Admin Required" Actually Mean?

The TUI That Made My Terminal Beautiful ✨

The Windows Problem (And How I Solved It)

The CLI: For When You Know What You Want

Corporate VPN? No Problem.

Why Go? (Again)

How It Actually Works Under The Hood

Installation: Pick Your Poison

QNVS vs. The Competition

Who Is This For?

What's Next?

Give It a Spin ⭐

🚀 I Built PQPM — A Process Manager That Doesn't Care What Language You Speak

The Itch I Couldn't Stop Scratching

What Even Is PQPM?

The Config File is Chef's Kiss 🤌

Why Go? Because Speed is Non-Negotiable

Security: The Part I Lost Sleep Over (So You Don't Have To)

🔐 Identity via SO_PEERCRED

🪂 Immediate Privilege Drop

🧱 Resource Limits via cgroups

📂 Path Restrictions

The CLI: Boring On Purpose

Installation: The One-Liner™

Who Is This For?

What's Next?

Give It a Spin ⭐

Image Source Summary

Fixing "No valid 'aps-environment' entitlement string found for application" in Flutter App

Introduction

Why Does This Happen?

Step-by-Step Fix

1. Enable Push Notifications in Xcode

2. Ensure Your Provisioning Profile Supports Push Notifications

3. Check the Entitlements.plist File

4. Make Runner.entitlements Available for Debug Mode

5. Rebuild and Deploy

Final Thoughts

Chapter 2: The humble `.sh` file

🔐 Identity via `SO_PEERCRED`

3. Check the `Entitlements.plist` File

4. Make `Runner.entitlements` Available for Debug Mode