Skip to main content

Our Guarantees

We want everyone make use of our services for a better experience with putting things online. Personally, the reason I (the founder) created this service because I once struggled to find a web hosting service that's good enough for a university project.

With that said, we have to be honest that we can't provide everything. We have to draw a line between what we can and can't do. This page is about that.

The NOT guarantees

These are the things that we will not guarantee:

It will not be scalable

Roughly saying, a system can be defined as scalable if it can handle a large number of users, say, hundred thousands of visitor every day; or it's targeted for worldwide audience and visitor wouldn't worry about latency wherever they are.

Honestly, our platform won't solve that problem, because our servers is monolithic by design. Monolithic means only one machine located in one place will handle your website. It will never can be scaled horizontally.

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 and easy to use.

It will not be always tolerable

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 train a machine learning mode here, but it's discouraged. We have to draw a line where we can't tolerate a website that takes too much CPU or RAM resources.

In addition of training ML models, we don't allow crypto, phising, DoS, spam, and other malicious activities. We have a terms of service that you should read.

We don't measure nor limit RAM/CPU usage because it's nature. But, we have an alert if the CPU usage is too high continously. If it does happen, we have to kill the process forcibly so it doesn't impact other websites for too long. We could terminate an account if it comes again repeatedly.

If your website has too much traffic, memory or CPU usage, but your website is legitimate, we may contact you so we can take an alternate agreement such that your website resource usage doesn't impact other websites.

It will not be always available

By design of monolithic system, it's prune to single point of failure. Maintenance sometimes happen. We do have a uptime status monitoring system and we strive to keep the uptime as high as possible.

If your website runs for a mission critical project, you might need to consider alternate cloud provider that guarantees uptime and scalability.


Don't mind will all the drawbacks above? Great! Here are the things that we think you will like:

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 way to avoid 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. Most people gave up using horizontally scalable system because it's too complex to manage.

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 e.g. npm install, the existing node_modules will not be cleared, thus speeding up the overall build time.

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.


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 discussion forum or emails.