I think you charge too little to assure serious users that you will be around in the future.

A few things regarding the pricing page - firstly, the text underneath the 'Quota' box makes little to no sense to a native English speaker. I cant even offer a translation myself, whcih I would be happy to do, since I don;t understand what you are trying to say.

Secondly, alot of your pricing package details are in very small fractions of GB. It would be easier for people to make comparisons, and thus realise you may be cheaper, if you used megabytes instead, no?

Thnaks for your comment.

At first, we are in the process of refine the phrases on the Web with some native English speakers, and will clarify the description soon.

Second, we just use GB instead of MB because we will increase the free quota in future. Current quota is for temporal use to avoid paying too much unexpected infrastructure cost.

Thanks for your advice.

That is not a good enough reason not to use MB. You can always change the M to a G later.

So incredibly pedantic, but since it's better than no one telling you: typo on https://www.fluxflex.com/about, "Share you applications with one click" header

Otherwise, looks pretty damn cool. Definitely will watch this :)

edit: also, under that header, "applicatoins" in the second bullet

Also "Statictics"

Kei, I've just installed the node_sample "Hello World!" project on the free plan, and noticed it was running a bit slow. Apache bench shows an avg of 1471ms/req over 100 requests (from NJ). Do you provide faster response-times on the other plans? Where are the data-centers located?

We are based on Amazon Web Services (ELB + EC2 + nginx + powerdns + apache + FastCGI). I admit the current response time is very slow, but our team members make a lot of effort to improve it.

It may be the different issue, but some node hackers may disagree to use Node.js with Apache + FastCGI. However, it is our challenge to make the node technology available not only to geeks but also to light users who will take advantage of server side javascript.

We'll improve the performance and I welcome any advices!

I would humbly suggest that you drop ELB in favor a software based solution that you control like haproxy. ELB just isn't up to the job unless you are a really big customer of Amazon's.

Also, if you are using small or micro instances, you probably don't want to do that either. Don't use anything less than a large instance if you want even semi-decent performance.

Thanks for your advice. I think chnaging load balancers to 64-bit instances is the first thing I should do. And also I heard several times about the performance of ELB, so we will change our architecture to some alternatives.

How would this compare to something like Django Zoom? Can you give some background as to how you came up with your service and the goals of it?

Hi Andrian. We bring the power of social coding (GitHub) into a cloud hosting platform (fluxflex), and I believe the multi-language support is critical point to achive it. Taking advantage of social knowledge and cllaboratoin with other developers will reduce initial learning curves for trying new technologies, and will amplify the joyful energy instead. Our goal is to let the web application development faster, easier and more amusing.

Now you can install various popular applications with one-click. These applicatoins include Rails, Node.js, Coffee script, Django, Catalyst, Mojolicious, Lokka, Haskell and so on. Because we use GitHub on its backend, you can access to the source code easily, and fork it to start developing your original applications.

On ther other hand, if you have an existing repository on GitHub, you can automate the deployment process by specifying the reposity in a form on fluxflex.

As the result of these collaborations, I believe web applications development will become more pleasant.

I think you will succeed. But you can charge $2.

What NPM (NodeJs) modules do you support? How does one enable them?