Your own link says that a proper package manager (e.g. pnpm) supports this out of the box.
If there are other use cases that really need post-install scripts, you can whitelist just those in pnpm. In projects I'm working with, there are often zero post-install scripts that must be enabled for everything to work properly, and it's usually from poorly cobbled packages that use them to download prebuilt binaries (well written packages, like biome or tsgo, use per-architecture subpackages).
You enable just one or two of those, and block everything else.
Given that has an impact over the whole industry, I will for sure tell you that patching on install SHOULD NOT be a thing. Up to you to run your own post install script yourself
Or maybe just add a script in package.json to run whatever patch-package does (eg, "install:patch": "npm install && patch-package") instead of whitelisting every package to have that power.
How would getting rid of postinstall break patch-package? If people use a package, and that package needs some kind of step to get working, user of that package should decide when that step happens. He can very well just call patch before building on his own. There's zero issues with that approach and the upside is he actually has control.
I work in a monorepo where running install calls dozens of deeply nested postinstalls of some elaborate NextJs or React Native dependencies other projects use. It's borderline insane. Unless you regularly screen everything, it's impossible to know whether one of those is compromised, especially in the world of Node where is-even is being used and the sheer amount of crypto scams around.
This thing also helps capture images from stupid crap apps that prohibit screenshots. On my rooted phone with a disable-flag-secure module installed, adb screenshots are still black.
Recording a video via scrcpy works on the other hand. Amazing, agreed.
Yes, it's absolutely the frameworks. That each weigh <100KB. Definitely frameworks :D
Edit:
I don't even know where you lot get these numbers from nowadays, smh.
Just checked, in Slovakia, google.com is 1MB (compressed) total with cache disabled. 400kib of those is my own extension that I installed which is counted among the 'loaded scripts'. Loads in 400ms, blink of an eye.
Framework rants are completely detached from reality, as always.
It's simple to use only for toy use cases, that's why nobody uses it. The article everyone in this thread seems to like only goes as far as 'I pushed to git so it must be ok' which is laughable and I'm not even DevOps.
What happens if it errored on deployment or after that? you wanna write custom (bash? :D) hooks for that? What about upgrading your 'very vertically scalable' box? What if it doesn't come up after the upgrade? your downtime is suddenly hours, oops.
The k8s denial is strong and now rivals frontend frameworks denial. Never fails to amuse.
Fair points, and yes, failed deploys need to be handled explicitly.
In our case, the answer is not "hope and bash". We deploy versioned images, use health checks, monitor the result, and keep rollback simple: redeploy the previous known-good image/config. Host upgrades are also treated as maintenance events, with backups and a recovery path, not as something Compose magically solves.
But I think there is an opposite mistake too: assuming every production system should be operated like a high-scale tech company.
Many production workloads are boring, predictable, and business-critical. They do not need aggressive autoscaling, multi-node orchestration, or constant traffic-spike handling. They need reliable deploys, backups, monitoring, health checks, and a clear rollback path.
That is where Compose can be a good fit: simple operational model, understood failure modes, low moving parts.
Kubernetes becomes much more compelling when you actually need automated failover, rolling deploys, autoscaling, multi-node scheduling, and stronger deployment primitives.
Not needing Kubernetes is not necessarily denial, it is just choosing the complexity budget that matches the problem.
Definitely not a one-size-fits-all choice, but Kubernetes can be so easy and there are so many benefits that get you from one small app to a medium sized business that it seems like a no-brainer for someone starting out. Spinning up k3s is pretty minimal overhead, but right away you can handle storage and backups very easily, automatic certs for all your apps with cert-manager is pretty much a one-and-done, traffic management for external and internal tools is easy, and even logins for websites is just an annotation in a yaml file. You can spin up and try out any software you want without spending time configuring it or setting up additional servers- and when you do need more hardware, it's one command on a virtual server, and just about as easy with physical hardware.
2-3 miniPCs, cloudflare, tailscale, and k3s can save (possibly tens of) thousands on SaaS products, and would probably scale you to a company of dozens AND host your product.
>2-3 miniPCs, cloudflare, tailscale, and k3s can save (possibly tens of) thousands on SaaS products, and would probably scale you to a company of dozens AND host your product.
Get a few Beelink SER5 or SER9's, install Nextcloud to cover the files, document editing, communications (to save on Microsoft 365). Then you can have Gitea (and gitea actions) for your source code and building (skipping github enterprise), Harbor to host and scan your containers, frappe for HR, etc. Pretty much anything you pay enterprise rates for, you can self-host a version that will get your company from 1 to 100s with minimal extra work. If it's not on https://github.com/awesome-selfhosted/awesome-selfhosted, you can probably vibe code it in a couple hours.
I just started to run a k3s cluster with an almost enterprise grade software factory and a few (light) production workloads on a single cheap minipc.
The concept totally works but I would worry about using a beelink in a business context where I had to support it.
For up to low hundreds of users I think you're better off just with 1 vertically scalable box for all the officey / web server workloads.
You mitigate the hardware failure stuff with a vendor contract where you can get someone on-site and overnight you parts, and by keeping things super boring. Volume replication is not boring, avoid at all costs. NAS or SAN if you have to but all disks in the main box for as long as you can.
For 20 person SME maybe a 2-bay Synology or similar, for a heavier company a low end 2U with hardware support. Proxmox under the OS for reduced worry snapshots, rollback, backup etc. Proxmox is there for operational flexibility, resist the temptation to create a network of VMs, you just need 1 CT or VM with all the workload inside it.
For container workloads on 1 host Portainer works as well as k8s IMHO, it gives you the key property you want - you can IaC everything declaratively with terraform + compose over an API.
Caveat that if CI gets heavy you might need to scale that out but you can keep it stateless.
I checked your page. Wanted to ask, are you using longhorn with k3s for replicated volumes? How beefy a box do you need for that (CPU/MEM/Disk speed)?
I have several VMs in clouds with similar k3s architecture as yours and am wondering if there are any benefits to installing longhorn vs sticking to logical (postgres, mimir, whateveritis) replication instead.
I think people are using different meanings of “production environment.”
I agree with gear54us and upvoted their comment, but I also understand what the author of the root comment is saying.
I have also delivered systems using Docker Compose that are actually running in production. The point I want to make is that people may define “production” differently depending on the number of active users, operational requirements, and risk level.
To me, this debate feels similar to the broader monolith vs. microservices debate.
Not necessarily. When you get to those numbers you're seeing dozens of teams with their own silos and deployment methods. So they might be responsible for the core business that's running 30 nodes and serving 100MM users a day, or they might be working on some internal portal or a WordPress site.
When I mentioned that, it was for a company that got acquired by a bigger company. I can't give specifics with revenue / profits but it is a 10+ year old online SAAS business and all of their web apps are being served by Docker Compose with a non-trivial amount of direct customer facing traffic.
Lots of data, caching, web apps, background workers and lots of various API integrations. No fancy React front-end, no fancy crazy system architectures. Just a typical LAMP stack but running in Docker Compose, cranking away serving value to customers with very good uptime and a very low cloud cost relative to revenue. With that said, a managed database was involved but all of the web traffic was served by apps running through Docker Compose with a simple git push model of deployment that handled thousands of deployments over the years without much fuss.
That as well as different definitions of scale. I've done small bits of consulting work for a research company for the past four years, deploying and managing Kubernetes clusters for them as well as helping get some of the main applications up on it. This is all internal tooling, though. Their customer-facing sites are just Drupal instances running on bare EC2.
Internally, though, they wanted to self-host a chat server, Apache airflow, Overleaf for collaborative editing of research proposals, three separate Git servers, a container registry, many other things, all with extremely strict multi-tenancy isolation requirements for storage and networking because they're handling customer data and their own customers audit them for it. That was a hell of a lot easier to do with Kubernetes than trying to figure out some giant universe of barely related technologies with vastly different APIs, having to buy specialized appliances for network and storage that probably also need their own control plane software hosted somewhere else.
But if you just look at "scale" as number of http requests a particular URL gets per some unit of time, the customer-facing sites have far greater scale. If you're trying to attribute revenue, beats me. They wouldn't sell anything without the customer-facing sites, but they wouldn't have anything to sell without the internal tooling. Solo web devs get into this tunnel vision view of ops because, to them, often the web site is the product. That's not the case for most businesses.
And, of course, they'd probably just use someone else's SaaS for tooling. But if you're in a heavily regulated space where that isn't possible and you have to self-host most of your business systems, then what?
The post receive hook provides you real-time feedback as it runs in the terminal where you did the git push. If something broke during the deployment you'd get notified by looking at the output. If it's running in CI, you'd see a CI failure and get notified using whatever existing mechanisms you have in place to get notified of deployment pipeline failures.
Zero downtime server upgrades are easy. You could make a new server, ensure it's working in private and then adjust DNS or your floating IP address to point to the new server when you're happy. I've done this pattern hundreds of times over the years for doing system upgrades without interruption and safely. The only requirement is your servers are stateless but that's a good pattern in general.
Define production. Docker compose is fine for running a small internal service in production for dozens of users (i.e. not for developing said service, but for using it). I would assume it isn't fine to run a hyperscaler (but I wouldn't know). Those are extremes, and there are going to be a ton of situations in between.
I can't personally speak to what the limit of docker compose is, as I have only worked on the lower end of this: self hosting for personal use and for small internal services serving maybe 20 users.
From my personal experience if deployment strategy is thought through then Docker running through Compose can handle few hundreds of thousand of users per day without an issue and probably could handle more with proper hardware upgrades.
Most people/apps only need the toy cases... If you're writing an internalized tool for a company that will only have a handful of users, then doing much more than compose for deployments is a violation of KISS and YAGNI.
Are you really going to try to get 4+ 9's of uptime for a small, one-off app? Do you really need to use a cloud distributed data store that only slows things down for no real gains in practice? Do you really think the cloud services are never down, and you're willing to spend a f*ck-ton of money to create a distributed app when historically an Access DB or VB6 app would have done the job?
I've moved applications deployed via compose pretty easily... compose down -t 30 then literally sftp the application to a backup location then to the new server which only needs the Docker Engine community stack installed.. then compose up -d ... tada! In terms of deployment, you can use github action runners if you want, or anything else... you can even do it by hand pretty easily.
Then you learn podman can't even list containers for all users properly and it kind of starts smelling like the whole ip4 vs ip6 debacle: bunch of vocal proponents wanting you to subject yourself to endless torture for no discernible reason.
A transaction fee of what? To take a fee from a transaction there has to be a transaction to take a fee from, which needs some sort of "coin" that came from somewhere. Somebody has to create a money supply and distribute it somehow. When the network first comes into existence, nobody has any money, so where does it come into being from?
Mining is what generates the coins. And you need mining because otherwise you need some other issuing organism. Without decentralized mining you get a central issuer, and that's untrustworthy and possible to shut down.
It is subtle, but PoW mining itself doesn't generate coins. It isn't like someone is digging a hole in the ground and extracting gold.
PoW miners are rewarded for correctly validating transactions, with newly minted coins.
The whole proof of work thing is that you proved that you validated a transaction by expending energy, and the network pays you for that security service.
Miners then need to sell those coins on the open market in order to pay for their capex/opex, which creates the market.
The open question is that if you have a fixed supply of coins that eventually runs out, what will carry the miners?
It'll be increased fees or the network will switch to another solution.
I believe transactions are quite optional though? A miner could choose to mine empty blocks if they truly wanted, which transactions to include if any is up to them.
Correct, one can mine empty blocks, but in practice, dumb idea. Most people mine with a pool. The pool decides what goes into a block. Even at scale. The point is that it smoothes out the reward cycle. For ETH, we mined with a pool that dual mined ETH+ZIL, which increased our overall rewards.
Proof of work allows for what Keynes called "Bancor". BTC is succesful because unlike fiat central banks, the money supply isn't dictated by interest rates (and thus loans) but by the effort of participants. The price of BTC is almost irrelevant, BTC itself is a paradigm shift.
Regarding the fixed supply, it's only fixed because participants agree to the consensus algorithm that fixes it. Many cryptocurrencies have different tokenomics, such as ETH's rules under PoS. BTC miners could vote onchain for a hard fork to change the 21M cap - or another solution.
So the comparison here is that you would rather trust a password manager with a CLI that imports hundreds of third-party dependencies over a first party password manager with a CLI that comes with the OS?
I don't think macOS Keychain uses NPM and it isn't in TypeScript or Javascript and, yes it does not need a CLI either.
The NPM and Java/Typescript ecosystem is part of the problem that encourages developers to import hundreds of third-party libraries, due to its weak standard library which it takes at least ONE transitive dependency to be compromised and it is game over.
> You initially complained about CLIs, not the dependency mess of the JS ecosystem.
I complained about both. What does this say from the start?
>> Once again, it is in the NPM ecosystem.
> You still have not said why this is an issue of having a CLI.
Why do you need one? Automation reasons? OpenClaw? This is an attractive way for an attacker to get ALL your passwords in your vault. The breach itself if run in GitHub Actions would just make it a coveted target to compromise it which makes having one worse not better and for easier exfiltration.
So it makes even more sense for a password manager to not need a CLI at all. This is even before me mentioning the NPM and the Javascript ecosystem.
>Why do you need one? Automation reasons? OpenClaw? This is an attractive way for an attacker to get ALL your passwords in your vault.
I need one because I am not always using a graphical interface. What exactly in a GUI do you think makes it harder/less attractive for an attacker?
If the GUI code is compromised in the same way as the CLI, it'll have the same level of access to your vault as soon as you enter your master password, exactly the same as in the CLI.
It does not much matter if it imports 300 or 30 of them, those vulns will land somewhere in those 30 with equal frequency statistically. If you are advocating developing without dependencies at all, then please start (with any language) and show us all how much you actually ship.
JS is a target of these dumb accusations because it's literally the best cross-platform way to ship apps. Stop inventing issues where there are none.
> It does not much matter if it imports 300 or 30 of them, those vulns will land somewhere in those 30 with equal frequency statistically.
The point is the risk is far higher with more dependencies as I said from the very start. But it happens much more frequently in the NPM ecosystem than in others.
> If you are advocating developing without dependencies at all, then please start (with any language) and show us all how much you actually ship.
The languages in the former (especially Go) encourages you to use the standard library when possible. Javascript / TypeScript does not and encourages you to import more libraries than you need.
> JS is a target of these dumb accusations because it's literally the best cross-platform way to ship apps. Stop inventing issues where there are none.
Nope. It is a target because of the necessity for developers to import random packages to solve a problem due to its weak standard library and the convenience that comes with installing them.
You certainly have a Javascript bias towards this issue yourself and there is clearly a problem and you ignoring it just makes it worse.
If it wasn't an issue, we would not be talking about yet another supply chain attack in the NPM ecosystem.
Hopefully current hysteria will not result in some bs decisions like this.
reply