That's not NPM, that's Nginx proxy manager. They are very much not the same thing.
Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
I've seen others calm this npm, so went along and did the same 🙃
It’s even abbreviated that way in the official documentation: https://nginxproxymanager.com/advanced-config/
Two wrongs don't make a right. I was scratching my head for a few seconds looking at the thumbnail and the title. And even the post body didn't clarify things. 🤷🏻
Is it wrong to abbreviate your own product in your documentation?
Their own doc, sure why not.
Any other context where there's a giant with the same name. No, please at least write it out expanded once.
Multiple things have the same abbreviation, it's really all about the context it's used it imo. Considering Ngninx Proxy Manager being a very well known tool in the selfhosters toolbelt, I figured it would be familiar enough to use.
You also have a screenshot from proxy manager so any confusion should have been short lived
Since others have answered this already I just wanted to take a moment to appreciate someone posting about npm. It works so great and helps make selfhosting quite easy. Have a good one.
Well thank you! And 2Y2 🌻
I usually just turn on WebSocket support and turn off Block Common Exploits and Cache Assets for everything.
I don’t use NPM but if “Cache Assets” means what it means in the traditional sense, it wouldn’t affect most home deployments.
Historically, resources are limited and getting Apache to load images/javascript/CSS files from disk each time they’re requested, even if the OS kernel eventually caches them to RAM, was a resources intensive process. Reverse proxies stepped up and identifies assets (images, JS and CSS), and stores them in memory for subsequent requests. This reduces the load on the Apache web server and reduces the hops required to serve the request. Thereby making everything faster.
For homelabs, and single user systems, this is essentially irrelevant, as you’re not going to be putting so much load on the back end system to notice the difference. May be good to still turn it on, but if you’re noticing odd behaviors (ie updates to CSS or images not taking), it may be a good idea to turn it off to see if that’s the culprit.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
Fewer Letters | More Letters |
---|---|
HTTP | Hypertext Transfer Protocol, the Web |
VPN | Virtual Private Network |
nginx | Popular HTTP server |
2 acronyms in this thread; the most compressed thread commented on today has 8 acronyms.
[Thread #667 for this sub, first seen 9th Apr 2024, 13:15] [FAQ] [Full list] [Contact] [Source code]
As others said, "Websocket Support" enables support for them and is required for some applications. "Cache Assets" caches (likely static) assets in the proxy so they don't have to be loaded from the backend service - I'd leave this disabled unless the backend service is hosted on another network entirely, and even then only enable it if you know the implications. "Block Common Exploits" is a very primitive filter against SQL injection (and similar) attacks. It also blocks some user agents. I wouldn't enable it as it won't do much to block a dedicated attacker and some filters may falsely trigger in edge cases, causing errors.
Thanks for this, I guess it would matter much for me to have the BCE on or not, as my services are only hosted over my own VPN and not exposed at all.
Then yeah, that option is worthless to you. For me, having networked solutions over a domain I have that enabled. But if its just internally I'd also disable it
Probably not best practice, but I automatically check Block Common Exploits and Web Sockets every time because I'm lazy. Works every time.
Not sure what Cache Asset does, but I can guess from the name. I leave this one off because my NPM runs on a VM with not much storage
I don't use nginx proxy manager but websocket has to be enabled for apps that use websockets (duh) - you would have to dive into docs or example infra configs to check if the service uses it.
Rule of thumb here would be to enable it for everything. Optionally you could check if the service works with/without it.
E: Websockets are used when a website needs to talk in "real-time" with the servers - live views and graphs will usually use it also notifications, generally if the website does not reload/redraw fully but data seems to change then there is a high chance it uses websockets under the hood (but there are ways to do it without ws, ex. SSE).
Example: Grafana uses websockets but qbittorrent web ui uses other means (SSE) and does not require ws.
I see, thanks for the clarification!