Show HN: Build your own Heroku on your own servers | Hacker News Reader

Show HN: Build your own Heroku on your own servers

cloud66.com

207 pointsksajadi108 comments

I think this targets a real painful need, managing an EC2 app on your own is not lacking frustrations, simple things like creating a rolling backup of instances needs complex shell scripts and cron jobs or 3rd party apps like http://www.skeddly.com, you need to be fluent in linux administration if you want to do simple things like increase your boot storage space (actually need to remove it, create a new volume from it, reattach it). Most developers will figure it out, but I would rather focus on development rather than infrastructure if I don't have to.

EC2 has an auto pilot option, but if I remember correctly it's more targeted for multiple instances, no auto scaling up or down only scaling out.

Developers need to focus on developing, it's always nice to have a developer who can also do the ops part, but I think no one will miss doing the plumbing work if they don't have to.

p.s. I would add a tweet button, this is tweet worthy and you should make it easier on people to both follow and spread the word

Few minor glitches:

- SSL mixed content warning on /how and /about

- / is different than /home (pricing link)

- logo redirects to /home instead of /

Thanks for the feedback! Will address those shortly.

doesn't amazon elastic beanstalk solve the "heroku-ish deploy on EC2" problem?

Yes. Elastic Beanstalk is great for deploying your code to EC2.

However Cloud 66 doesn't end at the end of deployment. It actively manages the app by monitoring the processes, making it extremely easy to add load balancers, scale web servers or background processes, add SSL certificates, schedule backups with one click and a lot more.

It is also not limited to AWS and supports Linode, Joyent, Telefonica Cloud with Rackspace and Digital Ocean coming soon.

This is on top of having all this on your own servers if you would like to have dedicated or colocated one in a data centre for whatever reason.

Actually attended a local user group presentation on elastic beanstalk last night.

Elastic Beanstalk not only handles auto scaling. You can set limits that enable it to launch a replacement server if your pages start responding slowly.

The new console lets you easily add SSL certificates and schedule backups. I was pleasantly surprised how much Amazon has added to it in the last few years.

I confirm all this. Elastic Beanstalk is so good, I don't even touch EC2 anymore. All my webapps are now being deployed through it. It costs more due to fact that each environment needs its own load-balancer even if only one server is involved which is extra $18/month but it is still worth.

If you deploy code that crashes webapp, just revert back to previous version. Problem fixed in a minute on all your servers.

And you don't even need to do that actually, spin new environment with new set of servers. Upload new version to new environment, do the testing, then promote this environment to production status (takes a few seconds), and terminate previous production environment.

Perhaps other companies can offer service like this too, but my platform of choice is ASP.NET which narrows the field quite a bit.

I guess where we are attempting to be different is we are providing this functionality in a vendor agnostic way (ie. also for Linode, Joyent, Telefonica - Digital Ocean and Rackspace coming soon, and support for standalone servers in Hetzner, or your private cloud, or even under your desk for example)

As well as just supporting your preferred vendor (based on price, location, guaranteed location, SLA etc) it means that we can offer you a way to switch between vendors if that vendor has some down-time, or doesn't meet your changing requirements as you move forward.

Also, we are really trying to be as application centric as possible - everything stems from your application code - and then provide the ongoing management tools you need on top of that (for easy scaling, backups, scheduled tasks, migrations, reporting etc)

Great feedback from everyone! We didn't get a whole lot of sleep last night!

This is a neat solution for a reality those of us who have been building web applications for a decade have faced: If you want your application experience (code + infrastructure) to be stable for a number of years, you have to be more and more responsible for your entire stack.

A reality is what's popular today in how a Cloud, or bare metal is used will be outdated in a few years and it creates technical debt in the future.

It amazes me how developers can obsess over development practices, frameworks, etc and without a thought look at the ugly underbelly of their app that grows as their code and userbase does.

Many developers on HN don't seem to have a relationship with a codebase for more than a few years (I could be completely wrong), but that is the perspective I'm speaking from.

It's great to see this kind of tooling that's focused not on management of infrastructure by abdication, but more of a middle ground.

Juju also has me excited, I think it's part of the future in a way VMware and virtualization first emerged 10-12 years ago.

At $9/month I suspect you are drastically under-valuing the service you provide. Sysadmin time is expensive, and your value proposition is the same as Heroku: pay us so you don't waste time sysadmining your boxes. Time is unimaginably precious for small SaaS shops, and if you deliver what you promise, it's worth far more than $9/month.

Not to nay-say, but if you don't price according to value delivered, you don't stay in business long. Your income should grow faster than the infrastructure that you need to run the business.

It's also not clear what company is backing this service and how you're structured. Are you VC-backed? What happens when the money runs out, am I left holding the short end of the stick?

Fair points. We are a new service and are focusing on helping development teams at this point. Your point about the business is very valid and we are working on it to find the right price point.

I think the best point about our service is that since we don't own the infrastructure, you can always pickup the servers in the worst case scenario of us going out of business.

Your last point is DEFINITELY a +1 over Heroku. Although I'd be pissed to lose my deployment & monitoring tools and have to piece it all back together (especially after I thought it was "solved").

Just sayin', this is a tough business, and people get very cranky when things break. :-)

All that said, this is a huge space for new business, and I'm glad to see you guys throw your hat in the ring. Definitely an interesting take on things. Best wishes!

Actually no I think $9/month is appropriate. A heroku dyno is about $35 a month, and you have a full on solid highly supported service. Here you pay $9/month + server fees which say with the micro instances comes out to about $14 bucks a month. So by doing it on my own EC2 with this service a small instance comes out to about $24.

Only thing is though, here you have the option of choosing a larger instance type and by percentage the charge may be to low. To combat that I suggest a more tiered pricing.

Thanks for the suggestion.

I've actually been using this since open beta. This is for those like me, who can do devops when pressed to, but really hate it otherwise. Which is most web devs I know.

The neatest thing is being able to transfer your stuff to another provider within minutes. I haven't tried the manual thingy yet, seemed like too much fiddling, really.

The cost in my case isn't significant, less than an hours worth monthly. I'd have wished for more frameworks as RoR isn't really my weapon of choice.

Thanks for being a great user of Cloud 66. Keep the feedback coming!

Having a platform to simply deploy code is great, but there seems to be a lot of hate for sysadmins over the past few years.

Heroku and the like are fine for prototyping and small apps, but when you start developing complicated and/or popular apps, at some point you are paying a service tons of money to avoid optimizing at the systems level.

I'm a "devops" sysadmin and sitting with my developer every day makes us both so much more effective. "Hey sysadmin, if 1000 requests to this module in my app happen it breaks, can we figure out why it crashes the server?". To which I reply, "yes developer, after we ran some tests, it looks like your code is so efficient and effective, that there aren't enough available tcp/udp ports to support the number of requests it is able to handle. I can increase them on your default AMI if you like. It will result in a 3000% increase in the number of active users we can sustain on a given instance".

The no-ops position is: Let's just pay for more servers. The DevOps position is: Let's optimize.

The difference may seem small, but if you are paying $20k a MONTH for your Heroku bills, not to mention supporting 3k servers for your app on AWS (or insert provider x), do you still think hiring a $100k/year sysadmin is such a bad decision?

The devs can still develop a method to quickly deploy code... or just use Asgard, and avoid all of the chaos that can happen if something goes wrong. The sysadmins understand your code and how it is interacting with the server. You don't end up paying tons of money to support a very basic application that has simply never been optimized.

Sysadmins in a devops world do not usually have any control over when builds can be pushed - they assist with optimizing. So if something breaks, the blame falls on devs, not ops.

Unoptimized app (rapgenius example): $20k/mo = $240k/year Sysadmin: ~$100k+/year and a minor (given devops mentality) increase in deploy time = priceless

Not all cases are the same, but the start-up mentality doesn't usually work at scale.

Where do you find sysadmins for high availability systems willing to work for $100K per year?

Depends on where you're living I suppose. In Chicago, a base of $100k/yr for a systems architect seems fair. In the Bay area and other areas that are more expensive, it will probably be more expensive, but I'm not as familiar with those markets. It certainly depends on the complexity of your product too.

ha. I was actually thinking of people I know in Chicago who charge huge amounts to admin trading systems.

Ah, yes. Did my run in trading. Pay (and experience) is great if you have the stomach for it. I found it soul-sucking and ultimately left. You are correct though, trading is extremely lucrative, not even getting into the other benefits.

Can you give a technical explanation of how this actually works? Heroku works by compiling your git repository with a buildpack into a "slug" and then booting that slug on a cookie-cutter LXC image running on an EC2 VM, according to process types you defined in your Procfile and the scaling you set through heroku's API, and then routing web traffic to your web processes. etc etc.

Can you explain with some technical depth how you are actually deploying/configuring the app, what languages/libraries are supported, where/how DBs & external services are run/connected to, how web traffic gets routed/proxied to the apps, etc?

Thanks for the question - there is a little more detail here: https://www.cloud66.com/help/cloud66_stack

Happy to answer specific questions

How does the nginx fit in? Do you install an instance of nginx onto every single box? Or can you elect to use a web server box as your frontend nginx and proxy request back to a set of separate servers running instances of passenger?

At the moment nginx sits on every frontend box serving Passenger. Unicorn support is coming soon. Split of front end proxy and backend server is further down the line. Feel free to put it down in the Feedback panel on the site and vote it up! Thanks.

I have used this since it's been in beta because I know the guys behind the service. Besides being exceptionally dedicated and cool guys, the service is genuinely good. It definitely solved our problem of going to production with something like Heroku. It's a lot more cost/performance effective and also (as mentioned in one of the comments) you have full access to your box if you need it!

When you know what's in the pipeline, it's even more exciting. Keep up the good stuff guys.

Just looking at the stack docs put me more in mind of Engine Yard than Heroku: HAProxy, nginx, passenger, DB options etc.

And that's a good thing. I realise Heroku is devsexy but having compared the two for a serious production app for bigco (a contest that EY won hands down) this architecture is long-term more resilient and adaptable.

So to me it's a sort of Engine Yard, BYO VMs. Ok. What is that, Devops as a Service? Nice look, btw.

DevOps as a service, WebOps in the cloud or anything you'd like to call it. We made it because we had the same issues as all other devs with Heroku. I hope we built something useful.

Great job, the UI looks really slick, Ubuntu is working on something similar (deploying development stacks to any cloud):

http://www.jorgecastro.org/2012/11/16/deploying-your-rails-a...

Do you guys have any plans to support OpenStack clouds?

Thanks for the comments. Juju is really cool. We are adding Rackspace support very soon. OpenStack is slightly later.

Very impressive. Could you help with the pricing a bit more. The cost is $9 per server per month in addition to costs from the cloud provider with the first server free?

BTW your FAQ still lists $7 https://www.cloud66.com/help/faq

Sorry about that. We are updating the FAQ page.

Yes. The $9 per server per month gives you: starting your app by provisioning, configuring and deploying. Monitoring and managing it as well as on going scaling, backup, add-ons, load balancers and other management features like continuous deployment or central logging features.

When I first opened the page about an hour ago they listed $6/month. Then I saw $7/month listed on the FAQ page, and now the home page says $9/month.

I know we had an issue with the FAQ page (was stating $7 instead of $9 which is the right one). But never $6! Did you see that on the homepage?

For what it's worth, I misread the button at the bottom of the "How it works" page when I first scanned through; I thought it said "Try Cloud $6", but it actually said "Try Cloud 66". Maybe that's what they saw.

Are any of the following possible or planned for development?

1. Hooks in the server configuration process that would allow you to do custom package installation and configuration. I know you can deploy to your own servers, but I'd rather specify configs in my app somewhere and have Cloud66 apply them as needed, a la chef recipes or puppet patterns.

2. Hooks into the deployment process to perform additional deployment related tasks.

Yes and Yes! As a metter of fact deployment hooks (both for packages and scripting like Chef) are available as private beta. Once we are done with the tests they will be released.

As for hooks: We have hooks and API to start a deployment after your git commit or CI gives us a go ahead and are working to add post-deploy hooks so you can chain up the deployment to other systems you have.

Just giving the github repo and the place we want to host, everything is taken care of! Pretty cool! Before i deployed my app to amazon ec2, i had pretty bad time with rubber gem, then with chef-solo and then capistrano, i always thought of something like this. So, it should definitely many who want to go with IAAS services but don't want the hassle of deployment.

Do you have a better pricing page somewhere? $9 per server per month... what kind of server? Micro instance?

Also, is there any Redis support?

That's a valid point. Thank you. Will work on a better pricing page.

For the reference, any server: virtual / physical or any size. Since we don't sell the servers, we only charge for provisioning, deploying and configuring as well as the on-going management (scaling, monitoring, backups, add-ons) per server.

Redis is coming soon (we use it ourselves and deploy our stack with Cloud 66 - so really keen to get it working so we can deploy and managed our own stack fully automated with Cloud 66!)

Nice. As a provider of unsupported hardware, I'd be interested in some "how to make it easy for us to support users on your hardware" page.

I really do think that there is a place in the market for something like this, and the more providers you support, the better off both you and your customers are.

Thanks! We are seeing a lot of folks using us to run their apps on dedicated on servers on Hetzner or OVH in Europe. If you are interested, drop us a line at hello@cloud66.com and we can talk about new providers!

This is awesome! I see there's Linode support built in - any plans to do the same with Digital Ocean?

Yep! Digital Ocean just released the bit of their API we needed - so yes they'll be supported soon!

Awesome! Sounds like I'll be a customer soon then!

I will also plan to move some client apps to this if you support digital ocean. Would love notification on that.

Thanks! We will announce it shortly. In the meantime you can vote up the feature on our site (Feedback panel) so you'd get immediate notification!

Awesome idea solving a real pain. Timely too given recent headaches with AWS sneezes.. Every time AWS has an issue, our site on Heroku is affected. Can you speak to SLA, downtime/uptime of service?

We built Cloud 66 to combine the convenience of PaaS with control of having your own servers. Even if we are down, your servers will still be up on your own preferred cloud vendor serving your users! That's a win for everyone!

This is very cool stuff. Do you guys support (or do you plan to support) any type of cross-provider failover? I.e. if AWS goes down, auto re-deploy to Linode and handle the DNS re-routing, etc.?

Great point! Yes. We already configure DNS records for the stack (load balancers and servers). This allows us to take the same cut of code and build scripts and execute them against another provider like Linode or Joyent when AWS has issues automatically.

THAT is awesome. Is that feature live? How is the failover route configured?

This is an awesome idea. I've been looking for something with the flexibility of managed infrastructure but the ease of use of Heroku for a while. I'll definitely be trying it out.

Heroku does more than rails apps. This seems to only do rails?

You are absolutely right. We are trying to start by helping fellow Rails developers first, more frameworks are coming soon.

What's your plans for self-hosted realtime support (like Socket.io, which seems to be node-only)?

Thanks for your question.

1. node.js support is coming soon! 2. We're going to have at least one self-hosted real-time push solution in our app store (think Socket.io or Faye). 3. The whole reason we started Cloud 66 is to give developers more control over what traditional PaaS doesn't let you do. It's your server, you have full root shell access to it. If we don't do it (yet), you can always do it yourself!

How are you planning to handle network security configurations on AWS? I.e. If I wanted to run an iptables config on my servers?

No mention of what size instances are being created on aws seems a bit scary. Otherwise cool. I'd use it if it were self hosted and available for node.

Actually you get to choose what sizes you want (whichever cloud provider you choose). See here: http://blog.cloud66.com/post/39922150128/custom-server-sizes...

Yeah I just setup two micro instances to play around with it. I'm thinking I'll setup something on DigitalOcean assuming I'm happy with what I'm seeing.

Cool I must have missed that in the video. Thanks!

There's a video?

yup! http://vimeo.com/54524424

Are you considering letting developers charge customers a flat or recurring fee for one-click installation of a preconfigured service?

Awesome service.

Thanks! Would love to talk to you about this further. Can you drop us a line at hello@cloud66.com please?

Does this have a comparable add-on or plugin architecture?

One of the main bonuses of Heroku is not necessarily the web/worker process management but the easy ability to manage: email, SSL, nosql, and tons of other misc stuff you need for an app.

With limited dev resources, its way easier to just let Heroku handle all that config. The default app setup and sys admin is not as big a deal.

That's a good point. Heroku is great because it takes away the pain through the add-ons.

Cloud 66 however doesn't end at the end of deployment. It actively manages the app by monitoring the processes, making it extremely easy to add load balancers, scale web servers or background processes, add SSL certificates, schedule backups with one click and a lot more.

It also has an app store which is growing. We would love to hear you feedback about those features.

Not having looked at this extensively I don't see what about it is more compelling then just using my own servers with git-deploy or a similar infrastructure. If i am going to run Ops i want to run Ops. If I am going to outsource it I want to outsource it. This seems like a middle ground that doesn't add too many compelling features to the party.

Any plans to support nginx/unicorn? Love passenger, but I really need the rolling restarts...

Yes. Unicorn support is in the pipeline (we love the quick restart too!)

Yep thats also already on our roadmap!

Guys I know it's hard to make estimations, but how soon can we expect nginx/unicorn AND digital ocean support ?

My app won't take the load in my current VM unless we run nginx / unicorn.

Whoo, I was expecting a link to OpenRuko, an OpenSource clone of Heroku, working with all technologies supported by heroku, and with the same api. https://github.com/openruko

How is this different from CloudFoundry? Which does this for more than rails apps?

CloudFoundry is great to build a PaaS on your own servers and want to manage it. However if you really don't want to manage and run an infrastructure then you would probably don't want to run a system like CloudFoundry!

Why!?

I assumed (perhaps wrongly) that if you don't want to deal with infrastructure you'd prefer PaaS solutions like Heroku and therefore you wouldn't want to manage not only a software package like CloudFoundry but also the servers that run it.

Well, Cloudfoundry actually offers both:

When you don't want to run the servers yourself, you can use services like appfog and nodejitsu (there may be more like those), which run a CloudFoundry stack.

When you decide "Hey, I want to run it on my server(s)", then you just setup their open source stack (there's even an automatic setup process for this) on your server and you're running on your own machine.

I assume I can't do that with your service, can I?

I don't believe nodejitsu runs on CloudFoundry. The other one I know of is Stackato.

Sorry, mixed them up: It's Joyent. And yes, the third of them is ActiveState (Stackato)

Very cool! Bookmarked! Will definitely be trying this on my EC2 instances.

Why does the FAQ say "Yes! You can deploy to one server for free forever"

Yet when I visit my account (signed up a while ago) it's forcing me to a credit card page regardless of which option I choose?

For the first 30 days everything is free and no CC is required. After 30 days, you can have one server for free after entering your CC. This will only be charged if you add new servers to your stack.

for a still fairly new to intermediate developer like myself, this seems more work than running it on heroku. not a bad concept, but maybe for more advanced developers.

Fair point. What can we do to make it easier for you?

Any love for python/django?

Or maybe will wok on top of the heroku buildpacks?

Yep - we've got Django in our roadmap too!

Is Play framework on the roadmap too?

I see references to scaling web servers but not for dedicated database servers. Is this possible? I'm thinking specifically of hot standby PostgreSQL servers.

1. What happens if I need a binary available on the server? (wkhtmltopdf)

2. Can I choose the linux distribution?

3. Can cron jobs be set up?

4. What about stuff like scout/monit etc ?

5. What about redis/memcaches/mysql/postgres?

1. We support manifest files (in private beta now) to allow you just that. 2. Yes. Both on the server (as you would do normally on any linux box) and through our CRON app. 3. We provide minimal vital signs for all the servers: memory, disk and CPU. 4. MySql and PostgreSQL are supported. Redis is coming soon. Memcache is after that.

However, it is always good to remember, all the boxes are yours and you have shell root access to them. So if we don't support something right now, you can always jump on the box and do it yourself the the Pro way!

Sounds great. The problem with dropping in via shell is that, launching servers become much problematic. I think if you can run custom chef/puppet scripts, that will solve this issue.

What about server security updates? How do you handle normal package updates, restarting services after an update, etc?

We monitor the software/packages/gem/libraries that we deploy and warn users when there is an update or security issue in the dashboard. For some we take control of the upgrade and for some we don't.

We don't want to push our users to fixed upgrade windows, so we let them choose when it's convenient for their business to have the updates and then act accordingly.

I like the notifications when signed in. Is that regular JS or are you using something like Parse?

Thanks! It's regular JS with CSS3

Is this really just Rails, or any Rack-based application (such as a Ramaze site)?

This is Rails only for now. More Rack based frameworks are coming soon alongside node and others.

This, but Python hosting.

Does it come with its own random load balancing, too?

Sorry, couldn't help it ;)

What about security? How do you address it?

We provision the servers to be as secure as possible at the OS level using open source and industry tested best practices. If you are running on a cloud vendor like AWS you can benefit from added security layer provided by our partners at Dome 9 to provide network level security.

Thank you for responding. I'd like to see a page about security in your site. Its important.

Agreed. My first thought was: 'what is being done to secure these instances?' Transparency in security policies would be a welcome addition to your site!

isn't OpenShift Origin better?

OpenShift is a great solution to build your PaaS. Cloud 66 is however provided to you as a service. So if you like PaaS because you don't want to manage or run an infrastructure then you probably wouldn't want to manage and run OpenShift (or CloudFoundry) either.

Why!? (Again)

Reply on news.ycombinator.com