➤ YN0013: │ @webassemblyjs/helper-api-error@npm:1.11.1 can't be found in the cache and will be fetched from the remote registry
➤ YN0013: │ @webassemblyjs/helper-api-error@npm:1.9.0 can't be found in the cache and will be fetched from the remote registry
➤ YN0013: │ @webassemblyjs/helper-buffer@npm:1.11.1 can't be found in the cache and will be fetched from the remote registry
➤ YN0013: │ @webassemblyjs/helper-buffer@npm:1.9.0 can't be found in the cache and will be fetched from the remote registry
➤ YN0013: │ @webassemblyjs/helper-code-frame@npm:1.9.0 can't be found in the cache and will be fetched from the remote registry
➤ YN0000: ⠴ =================---------------------------------------------------------------
Oh sorry -- you can do that, I guess I just jumped to thinking about Docker when you said "build the front end," which may just be revealing the bias in how I am doing things these days.
I'm not sure how much RAM is needed but I would think 1GB would be enough to not have extreme slowness. Maybe it's a network issue instead? top might help you verify whether running out of RAM is the problem.
I just saw the uptime line. That is a high load average. That might mean the CPU is underpowered, or it might mean the CPU is waiting on some other resource (like disk I/O).
I've been lazy and have been using just the Lightsail web console so I can't run top at the same time, but whenever I stop the build and check uptime the load is huge. I didn't think to check vmstat.
Turns out it's not possible to grow a Lightsail instance's RAM so I will make a new one with 2GB of RAM out of a snapshot and see if it gets past this. If so, I'll have my answer...
This is the first verification of system requirements to build, not run, Plone. It should go in the docs.
Both install methods refer to the hardware requirements to run, not build, Plone. I'd accept a PR with text that clarified the difference. Of course, if one person builds a container locally, then pushes that to a repo for others to consume, then the build step is avoided and lacks the extra RAM requirement for consumers.
The impression I have is that you end up needing more RAM solely to support your builds.
One trick would be to create a swap on your VM for this purpose.
Maybe try this swap trick -> How to setup Docassemble with less than 4GBs of RAM
That said, building your docker images ahead of time is another approach that will give your server a ready docker image that will likely need less RAM. Also if you have a semi-useful test of your builds in CI/CD, then failed builds will never propagate to your production machine.
(update: just read @stevepiercy response and he is already making the distinction between build-time RAM needs and run-time RAM needs. The only thing I'm adding here is the use of the swap "trick".)
As always, I would accept a PR to update the Hardware requirements. However I don't see how this would benefit users of not-Docassemble and could be generalized for others.
