Many, many years ago a built my own CMS that ran very successfully for over 10 years before it was decommissioned.
I am now ready to write one again and would love some advice and insights.
My original CMS had my master server account (WHM and cPanel) that had all the master files and then each server account I created for a client had files added to it that linked back to the master account, files, DB etc so that when I made an update to the system I made it in the master account and then all accounts had access to it.
The server admins did something to my server to allow each account to talk to each other however, from memory, it was not very secure for the server.
I am thinking I would like to make the new CMS like this so that each client has their own server account.
The alternative is to have everything under 1 server account and create subdomains etc.
I am not too sure about this approach as I could end up with one MASSIVE account and I am not too sure if I can track the diskspace and bandwidth that each users is using.
I have been building a cloud optimized 0 cost content publishing framework. The architectural vision of Druid will be hosting sites as static assets on a GitHub org repo or cdn in the cloud like s3. This eliminates the costs of servers completely.
These are two such demonstrations.
This is a pre-rendered angular page part of GitHub org pages site. This cost nothing to run.
The editor is hosted as a static app on aws s3 with cloudfront. This has no cost associated with it for a year. After a year very low or can be moved elsewhere.
The full angular project can be viewed here on GitHub.
For object storage, search, and authentication aws is used for the core platform. Those aws services are as follows.
cognito (authentication)
s3 (file storage)
open search (search capabilities)
cloudfront (content delivery network)
A significant advantage of using aws for auth is that signed requests can be used directly in the browser. If you were to dissect the network tab of the first link in this post you would see that there is no intermittent server between the browser and aws requests. That can only be achieved securely using aws cognito. It enables Druid to speak to any aws service going forward directly in the browser securely using zeros trust signed requests. This eliminates the need for servers relying completely on the cloud instead.