Our Mission
We want everyone make use of our cloud platorm for a better experience with putting things online. Personally, the reason I (the founder) created this platform because I once struggled to find a web hosting service that's good enough for a university project.
Our mission is to democratize web development. What we mean by that is we want to make web deployment easy for everyone no matter their background and capabilities, and we want to done it as efficient as possible using shared hosting design.
With that said, we have to be honest that we can't provide everything due to shared hosting nature.
What we can't do
These are the things that we won't or can't do:
Horizontal Scaling
We can't scale horizontally because our servers is monolithic by design. Monolithic means only one machine located in one place for all services that your website needs.
Scaling horizontally means using some advanced techniques like load balancing, edge servers, edge functions, containerizations etc. We believe adding technical complexity will just make developers life harder. We want to keep things simple, cheaper and easy to use. Read the cloud exit by DHH and serverless horrors by HeyAndras.
We still can scale vertically by our customer demands.
No Failover
We given users a raw access (SSH) to the server, so they can do whatever they want with it. Practically, one can use our servers abusively, like training a machine learning model. That won't work. We have RAM and CPU limits in place to avoid accidentally freezing our whole server.
Still, things can go offline, for instance during bad root-level configuration by our admins. We strive to make our cloud platform recover from bad things autonomously. But, sometime have to "touch" our servers to keep everyone happy.
A bad actor can sneak up and wreak havoc despite many security protections in place. In that case they're violating ToS like planting phising, DoS, spam, and other malicious activities to our servers. If someone legitimately needed a higher computing spec and it's not measurable by our limits (like storage and data cap) we will contact them.
Most of the time, downtime will not caused by us, could be your bad configuration. Or we do something that brokes your bad configuration. So expect some downtime here and there, but don't hesitate to contact us promptly if something is wrong!
Sudo Access
A shared hosting system is one OS shared for many user. Giving a sudo access mean exposing everyone data under the same OS, which is a disaster. We elaborate more about this limitation in Security Measures.
What we can do
Don't mind with all the drawbacks above? Great! Here are the things that we think you'll love:
File Access
File access is often underrated in today's cloud computing world. The reason you wouldn't see people running PHP web-apps inside containers often is because this language is heavily depends with local file operations (e.g. for sessions and file uploads).
Having file access is the simplest solution to cache and store data problem. If you're not choosing a monolithic service then you would have take alternative solutions like Redis or Memcached for cache and S3 storages for file uploads. Still, most people gave up using horizontally scalable system because it's either too complex or too costly to manage.
Don't follow bad advices that told you need for maximum scalability without market or business validation. Unless you're scaling for international market or put people money or life behind your services, a single monolithic server will be enough for you.
Files in DOM Cloud can be accessed and edited using our Deployment System, Webmin, Filestash, SSH or VSCode Editor.
Incremental Build
If your web app have a particularly large packages depedency, this will help you a lot. Unlike standard CI/CD, when you do depedency installs like npm install, the existing node_modules will not be cleared, thus speeding up the overall build time.
This is because our system is simply a custom-managed Virtual Machine. We don't apply containerization, just raw Linux capabilites.
Simple Hot Fixes
If you spot a bug in production, you have the option to fix it directly by editing the live server. This may risky and inconvenient for large sites. But for those who with little technical human resources, it greatly simplifies the process of bug fixing. When things cooling down, one can see the diff and then reapply a proper fix to stream (git) repository.
As close as running locally
Our servers is literally just a Linux server and you have a full access (non-sudo) to it. You can install any packages you want, run any commands you want, and do anything you want. It's as close as running a server locally.
Support
Currently, DOM Cloud run as a service for community. Core developer resources is minimal but we strive to make this platform autonomous and easy to use. You welcome to ask in the discord or chat in telegram.