Good start, but there are many, many things that should be improved if you are running this as a production setup.
Including node & PM2 update to the latest, running PM2 as a systemd service, or simply ditching PM2 altogether, as well as backups, performance settings, and monitoring, log rotation, and cleanup, etc.
Beware of using the same server for running the apps and for building the app. Quite often, building the app needs a lot of RAM and CPU, so it is undesirable to do it on the same host.
I have enterWith working perfectly with async/sync flow - all operations between request and response are logged with request id transparently. I am using custom server for both standalone build & dev server, nextjs 14, node 22.
I should mention Non-Sleep-Deep-Rest (NSDR), which, while not changing a state of consciousness, helps in relaxation and focus. Only in 20 mins. Based on my one single anecdata point.
Generated by AI libraries will by definition have all the security bugs you might encounter in the open, since it trains on them.
I would say, it is better maintain your own AI improved forks of the libraries and I am hoping that pattern will be more common and will also benefit upstream libraries as well.
If you are given only 5 days to comply with some request, that's how complicated your infra at AWS should be - so you can migrate to another provider in that time.
Just use EC2 and basic primitives which are easy to migrate (ie S3, SES)
Hi,
The infrastructure was not complex at at all, i can transfer it in 1 day.
I was hospitalized, in another city, with all the computer at home, and locked behind 2FA.
They send me is on notice on Thursday, by Monday evening, all access was revoked.
For weeks i asked for a readonly access to my data, then they could take anytime they want to verify, they refused.
And he more i ask about my data, they more they avoid to speak about it.
Think about it , you could be sick, on a trip, having jetlag, in some festival, getting married... by the time you are back online, the delay was gone.
True. I get that you can blame someone for having no backups and yoloing their thing. But OP did so much right if the threat model doesn't involve "corporate behemoth anti-user automation nukes everything including backups".
Everyone saying "you should've had offsite backups" certainly has a point but 99% of the blame lies with AWS here. This entire process must've crossed so many highly paid "experts" and no one considered freezing an account before nuking it for some compliance thing.
It's just baffling.
Hope these cases will lead to more people leaving the clouds and going back to on-prem stuff.
EC2? S3? Yes. That kind of "cloud" tech was invented at AWS. Nothing like the ec2 API existed before Amazon. It's what made AWS big. Maybe my graybeard is showing, but I remember when that kind of pre-containerization cloud provisioned VM resources was a radically new idea.
FreeBSD jail predates Amazon Web Services, and so does SWsoft's Virtuozzo that was subsequently open-sourced as OpenVZ. For Amazon SES, DJB's qmail made it possible to send a ridiculous amount of subscription emails very efficiently, too.
I've been using a VPS powered by Virtuozzo since like 2002 or 2003, how is EC2 all that different? Just the API?
Per https://en.wikipedia.org/wiki/FreeBSD_jail, FreeBSD jail was committed into FreeBSD in 1999 "after some period of production use by a hosting provider", and released with FreeBSD 4.0 in 2000.
EC2 services aren't tied to a machine, just a region. The details of what machine to instantiate a VM on, or the details of moving a VM between hosts, attaching remote drives over IP, or handling the networking that makes this all possible, that was worked out by Amazon to host Amazon.com, which they then resold as a service under the banner AWS. The pieces were there, but not a unified "cloud" architecture.
This is smelling like the classic "Dropbox isn't anything new" HN comment.
TODAY amazon services are just re-packaged OSS packages, yes. That wasn't the case before.
OK, so, you're saying migration and remote drives over IP is the secret sauce of AWS / EC2?
Per Wikipedia, live migration was added to OpenVZ in April 2006, one year after OpenVZ was open-sourced in 2005, five years after Virtuozzo was first released as a commercial product in 2000, 3 years after the company was started in 1997. Straight from Wikipedia. I would guess that prior to April 2006, live migration was already available as part of commercial Virtuozzo for quite a while, probably.
Not to mention Xen. Isn't it common knowledge that EC2 was powered first by Xen, then by Linux-KVM, switching in 2017? What exactly is their secret sauce, except for stealing OSS and not giving back?
Dropbox is a little different, but, even then, doesn't everyone simply use Google Drive today? What's so special about Dropbox in 2025?
Just look at Virtuozzo. Why did SWsoft/Parallels open-source it into OpenVZ? The decision makes no sense, wasn't Virtuozzo their whole product they were selling to the hosting providers?
The answer lies in the complexities of the kernel code. By open-sourcing the underlying technology, they're ensuring immediate compatibility with all upcoming kernel changes. Had they kept it in-house, it'd be a nightmare to continue to integrate it with each upcoming Linux release, riddling the technology with preventable bugs, and eventually losing to competitors, including Xen and Linux-KVM at the time. OpenVZ was extremely popular in the VPS community until just a few years ago, before we had more RAM than we known what to do with, before Linux-KVM replaced both Xen and OpenVZ in the majority of the hosting environments in the last 10 years as of 2025.
I do agree with the other commenter that you're just rewriting the history here. All of these EC2 clouds are simply repackaged OSS (Xen and then Linux-KVM in the case of AWS EC2). If Amazon had actually developed some truly unique kernel stuff, we'd see it OSS by now, because of the difficulty with maintaining those kinds of kernel forks locally. But we don't. Because they haven't.
You are failing to understand that the product is not the technology. The product is the interface. One of the products you listed had the “cloud” interface we are familiar with today.
I didn’t realize Xen migrations were made available from a uniform web API accessible from remote tools and fully abstracted/automated at the cluster level.
You are focused on the details and missing entirely the point of my post.
That's 2001, and Virtuozzo was already advertised supporting migrations.
OpenVZ remained super popular for at least like 10 years after it was open-sourced as OpenVZ in 2005, well into 2015, at least. Primarily because it allowed over-provisioning of RAM and all the other resources, which wasn't possible in other environments without the memory balloon drivers and other issues.
I imagine the major reason OpenVZ has declined in popularity is because nowadays memory is cheap enough that over-provisioning of RAM isn't that much of a selling point, and not being able to run your own kernel with processor-guaranteed virtualisation, is deemed too old-fashioned and less secure for true multitenancy than Linux-KVM, which has basically taken over the entire market, from both Xen and OpenVZ, and VMware, and everybody else. Even Amazon EC2 is based on Linux-KVM now, whereas previously it was based on Xen.
Just use pages router, it is still supported and works, also static generation for SEO also works.