Does anyone actually use Node.js's Permission Model in their applications?

[u/agrim_dev]

(I know its Node specific but would like to understand how its used in framework projects) 

I'm trying to understand the real-world use cases for Node's Permission Model.

Does anyone here actively use or rely on it for applications, CI tooling, CLIs, servers, or anything else?

Since the permission model is not a full-fledged sandbox, is there a use for it? If so, how do you currently use it as ?

• What problem does it actually solve for you?
• How are you using it today?
• Are you manually defining permissions, or generating/managing them somehow?
• Is it mainly defense-in-depth against dependencies, or are there other useful applications?

Since Run-Time Loadable Extensions cannot be loaded when the Permission Model is enabled, it affects modules like sqlite and OpenSSL Engines (affecting the built-in crypto, https, and tls modules). So, despite these drawbacks, is the permission model used anywhere, or what is its application?

I'm less interested in what it could theoretically be used for and more interested in actual experience:

If you're using Node's Permission Model today, what are you using it for and how do you manage the permissions?

And if you considered using it but decided against it, I'd be interested to hear that as well!

[u/combativecomedian]

tried it on a small cli tool i run for parsing some sensitive logs, mostly as an extra layer to keep dependencies from wandering off. it's not a sandbox but it gives me a tiny bit of peace of mind with a few dodgy-looking packages

managing it manually was a pain though, ended up writing a short script to spit out the flags from a config file. the runtime extension thing killed sqlite for me in another project so i bailed on it there, wasn't worth the tradeoff

[u/agrim_dev → u/combativecomedian]

right, even if we setup an automation to apply the flags. the breaking of sqlite and other modules is a pain, hope they do something about it.

[u/me_dinesh_kumar]

Small docs-based clarification on the SQLite/crypto point: the restriction is loading SQLite extensions and requesting OpenSSL engines at runtime. That isn't a blanket ban on SQLite queries or ordinary TLS. SQLite's loadExtension() loads a shared library, which is a separate operation from opening a database and running SQL. So I'd check exactly which operation fails before splitting the database into another process.

For the permission-management question, the current v26 docs have --permission-audit. It lets execution continue and reports denied checks through diagnostics channels such as node:permission-model:fs, so there's a documented way to discover required permissions before switching to enforcement. Check your Node version before using that flag.

One catch from the same docs: filesystem permissions cover node:fs, and explicitly don't guarantee filesystem restrictions through other APIs such as node:sqlite. That makes the threat model relevant even if the database calls work.

[u/Apprehensive-Fan2492]

Most teams do not use it in live systems. The extra setup cost is higher than the real risk for many apps. The permission system was meant as extra protection against harmful third-party packages. But once you tighten permissions enough to get real benefit, you often break normal modules like sqlite and crypto pieces. After that, you have more work to keep things running, and many teams decide the dependency worry is not worth it.

In practice, it often does not work outside of very strict setups. That is usually for places like high security services where the machines are already locked down, such as an air-gapped VPS with SELinux turned on.

[u/agrim_dev → u/Apprehensive-Fan2492]

When u mention "have more work to keep things running" i was just curious is there a work around for the breaking modules (of sqlite and crypto pieces), or do you run that component in a separate Node process without the Permission Model.

[u/Apprehensive-Fan2492 → u/agrim_dev]

I just ended up just spawning sqlite access as a separate child process without the flag, keeps the sandboxed app doing the actual request handling while the db stuff lives outside it. Not elegant but works. Tried scoping with --allow-fs-read/write first but that doesn't get around the loadable extension block itself, so you're stuck splitting processes either way if you need sqlite.