Security Measures
This article describes the security measures that implemented in the system.
DOM Cloud is essentially a Linux VPS server that's shared for all users. While this maybe seems like a bad idea, when it done correctly it will work fine and save a lot of infra cost for most users.
DOM Cloud has six servers with different spec tier level:
Tier I: 2 vCPU 4 GB RAM
sga.domcloud.co(Singapore)nyc.domcloud.co(New York)
Tier II: 1 vCPU 1 GB RAM
fra.domcloud.co(Frankfurt)tyo.domcloud.co(Tokyo)blr.domcloud.co(Bangalore)sao.domcloud.co(Sao Paolo)
These hardware specs may change as the time goes with available budget.
If you're happen to close with tier II servers, think of your website usecase. If you only want to host and simple website, go to in Tier II because ping time really matters. If your app can't run in Tier II, or it loads so long or hangs too commonly, then try moving it on Tier I server.
No Sudo
When you create a website in DOM Cloud, you will be given a SSH access, which then you can used it to install additional software or libraries in order to make your app working correctly.
The only restriction is this: You can't elevate access with sudo. There are many tutorials out there that requires sudo, these will not work here as that will compromise the entire system, including other users data.
Of course, there are some actions that requires sudo access, such as configuring NginX or DNS records. This is why the deployment system exists, it facilitates some sudo actions in a safer way.
The deployment system also has some shortcut to install language compilers, such as Node.JS, Python, Rust, Go, and many more. Refer to its features section. These will be installed to the user's home dir (usually ~/.local/bin) so it's isolated with system-wide software.
No Background Services
CPU and RAM are limited resources. To make room for everyone, server processes need to be shut down when it's no longer in use. In another word, there can't be any process run 24/7, it will be terminated when there's no traffic for more than 15 minutes.
This is enforced by NginX proxies (PHP-FPM and Passenger) plus many many other daemons that's running in the background.
If your web apps requires some kind of background processes that must stays on for 24/7, then you might have designed its system architecture wrong. The most noticeable impact from this restriction is Chatbot. All chatbot must work by webhook, not by actively polling social media APIs.
We recently allowing users to bypass the 'No Background Services' policy for Kit and Pro plan users because of our ability to use Docker within our service.
Do not install any third-party background services that pings all the time such as Uptime Bots. This will cause your account to be terminated as it is direct violation for Fair Use (forcing the process to always run 24/7).
Listing every other users
Due to how linux works, we can't hide usernames and domains for all users in the server.
Anyone with SSH access can do ls /home or cat /etc/passwd and determine what's domain other users has. We encourage everyone to not assume all URLs are private, and taken security measurements properly as if anyone public can open the website.
Note that this doesn't mean anyone can read your server code. We treat security seriously.
SSH/Server Password
Server passwords must be treaten as personal password, exposure on public can lead to anyone see and override your website internal data!
Avoid managing your website in public devices. If you have to do that, make sure you do it in private browsing/incognito mode.
If you have leaking your server password, please change it ASAP wither from Webmin UI or our Portal UI.