We want to give you more money. It also gives you a little more legitimacy to an already impressive product.
As the great patio11 said[1]: Charge more. Nothing uber crazy since you have to compete with the likes of Github and others you're competing with, but $1 sounds a little ridiculous. But maybe that's part of the gimmick ;)
I totally agree. My first thought was that I want to give you more money than that (as it would give me more confidence in the product). Either that or lower your plan limits a fair bit. Also, if you have a free plan then you are unlikely to scare people off with higher pricing - they can always just try the free plan and see how great the product is, and it is easier to lower prices than raise them :)
I'm the founder of fluxflex, and am willing to answer any questions. Fluxflex now supports PHP, Python, Ruby, Perl, Node.js and Haskell. We'll support additional languages in near 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?
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.
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
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.
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.
So it's nearlyfreespeech.net but with semi-persistent workers like Heroku?
I agree that the pricing is too low for you to make money on top of AWS and also deliver decent service, it's hard to imagine that you could stick around — at the very least you should emphasize how developers don't end up tied into your platform.
The SSL certificate is for "redirector.zerigo.net", and is self signed. If I add an exception to my browser I get through, but all I get is a completely blank page and a 404 status code.
So it looks like the problem was that you updated your DNS but forgot about TTLs. Your new cert has the correct name on it, but you didn't setup the cert chain properly (SSLCACertificateFile under Apache)
You are right. We changed our frontend from Django+Apache to Rails+Nginx, and we forgot to specify the certificate chain in nginx config file. Now I added the description, and confirmed that we can access to the web site via SSL.
This is actually really cool. Its the kind of thing I've been really wanting to get the Cloud9 guys to get working with dotcloud. A huge stumbling block for me has been working on my CR-48. Dotcloud, heroku need you to install their CLI witch will obviously give you much more power and flexibility but cant be done if you don't have terminal access.
Now some will say why would you even try to do any kind of dev work without proper tools but I think this really lowers the bar and gives people another frictionless way to get their hands dirty.
You let people run shell scripts on deployment, is this why your service is down? Seems reminiscent of phpfog's mistake of running post-deploy scripts for users as root.
You can write a configuration file named .flx and we will run commands according to the description in it. "Lokka on fluxflex" is a greate example for understanding how the configuration and the deployment work on fluxflex. You can read the source code at https://github.com/sowawa/lokka.
Various one-click install applications are hosted on GitHub, and you can fork, merge and push on GitHub as well as just install the application on fluxflex.
