Skip to main content

Our Philosophy

We want students, teachers, developers with their hobby time make use of our platform for a better experience with putting things online. Personally, the reason I created this because I once struggled to find a host service that's good enough for a university project.

With that said, there are couple drawbacks and benefit to our platform:


1. Not 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 global launch and visitor wouldn't worry about latency wherever they are.

Honestly, our platform don't solves both problem, because it's monolithic by design.

We have to admit there are other better cloud providers that gives scalability for free, especially static websites. But for other websites that need a backend code, it's way too complex.

So far we (the world) have three solutions for scalability (what I know, so far) (Be warned, it's very technical):

  1. Serverless Functions. They're small function represents small pieces of code that can be deployed globally using e.g. AWS Lambda. The problem with that, not every framework can be chunked into small functions (e.g. WordPress and Laravel). Some people with brilliant idea might can turn some existing framework to fit into serverless functions, but I think it's complexity outweights the benefits if you don't look for scalability.

  2. Container and Kubernetes. Kubernetes leverages containers which is about running a server code in an isolated environments. Kubernetes are software managers that clones and kills containers whenever they are needed. With that said, Kubernetes is a bit more complex than serverless functions. Also, you would have to mind the other things to ensure scalability like using Redis instead simple files for cache (e.g. for handling cookie/sessions). You would still have a lot of refactoring to do if the language isn't scalable by default (WordPress still can't do that), but still it's a lot easier than serverless functions.

  3. Use of No-SQL databases. There are recent trends about GraphQL and NoSQL databases, and they're so scalable you can get rid of writing a backend code (provided with correct permissions to ensure security). A popular example for this is when developers create an Android App, mostly they use Firebase for the backend. Firebase already handles most backend aspect ranging from authentication, storage, analytics, to realtime database; This is also true for other services. The downside is that you have to consider this option since beginning, or risk rewriting everything from stratch. You also creates a direct depedency on a service for a major part of your application, and risk major refactor if you want to change from that later.

Those 3 points are actually no problem if you (or your company) has a lot resources to outweight the cost of scalability. So, whether you're flying solo or with a (small) team, and not trying to compete on Facebook, Spotify, FedEx or any other global companies, then you might not need scalability, which this platform is designed for.

2. Fair Usage Limit

We given users a raw access (SSH) to the server, so they can do whatever they want with it. Practically, one can run a Jupyter Notebook on the server (we even provide a recipe for this). A website relates to Machine Learning (ML) research may still be allowed to be hosted here, but under condition: It shouldn't take a lot of RAM/CPU usage.

We don't measure RAM/CPU usage because it's nature, but we still draw a line for fair usage. We have an alert system 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.

The same thing goes for crypto, phising, DoS, and other malicious activities, which clearly against the service of terms we have here.

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.

3. No Guarantee

By design of monolithic system, we don't provide any guarantee that your website will stay up most of time. We do have a uptime status monitoring system, but when a downtime occurred, it's inevitable. If your website runs for a mission critical project, you might need to take a look for alternate cloud provider that guarantees uptime and scalability.


If you don't mind about scalability, a classic monolithic system like our platform is a good choice for you. Here's why:

1. Local File Access

Local file access is often underrated in today's cloud computing world. The reason you wouldn't see people running PHP inside containers often is because this language is heavily depends with local file operations (e.g. for sessions and file uploads). Also, it's the simplest way to cache and store data. If you're not choosing to be monolithic then you would have take alternative solutions like Redis or Memcached for cache and S3 storages for file uploads.

2. Incremental CI/CD Build

If you have 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.

3. 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 fly solo, 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.

4. As close as running locally