In this scenario, the cpu cycles required to read from the database and render to PHP will all be handled by a single core, ie they will be handled one after the other. This will be about the slowest way to deliver website traffic out of your server.
Each time a request is made, a certain amount of memory is occupied by PHP. You can test the actual amount, but you can only ever be sure it is not greater than memory_limit. Based on a use of no more than 256MB per Drupal site request, you can divide your 1GB of memory by that number (minus some memory for apache, MySQL and the OS). The result are 3 requests fit into memory only. You certainly do not want to allow more, because either your system runs out of Ram or it will use swap disk space.
The use of swap disk space is even worse, as it will slow down requests even more and consumes cpu itself.
3 requests can be used up quickly by some Ajax requests in the page or your Admin backend, either one likely bringing the server to its knees. It would be best to check in Chrome inspector how many PHP requests the site makes on frontend and backend.
Your situation will improve somewhat if you can dial down your PHP memory limit to say 64mb, but you still have the single core as the bottleneck.
So the key to keep this stable is to reduce the number of requests allowed either in apache or php-fpm to a number multiplied by PHP memory limit that stays smaller than your 1gb memory.
Your best option would be to copy out your Drupal pages to a static website every time a change is made. A transparent way for this is to put a cdn in front of your website. However you need to be sure.
Another non technical practical solution is to quadruple your hosting budget and find a sponsor or side gig to pay the charges.