Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Pardon and excuse the self promotion, but just yesterday night I did a small blog post on deploying Rails Apps with Puma. The deployment part is really quite naive and I'm working on part 2 of the post.

http://jasdeep.ca/2013/07/deploying-rails-apps-with-puma-and...



For Rails 4, you don't need to modify script/rails. Might be good to mention in your article.


I haven't had a chance to set this up with a Rails 4 app yet, But you might be right. Thanks for pointing this out. I'll update the article.


What was naive about [your deployment section], and what needs updating?


Well, I did outlined how simple my approach was in the article I wrote. The approach really works brilliantly for simple projects with one or two servers where you can log on to each machine and just git pull your code and run the migrations etc and be done with the deployment.

For more scalable architectures I prefer putting multiple of these app instances behind a Load Balancer such as Nginx reverse proxy. That is part 2 of my post :)

I'm running Puma in production for a simple project which we have behind a Nginx load balancer.


I think that he meant the deployment section in his post was naive, not yours :).

I appreciate the compare and contrast.


I know, that's I meant too. :) I meant to ask, what was naive about his deployment section?

Perhaps he meant putting Puma directly on port 80. Although I usually wouldn't do that, I am not entirely sure whether one shouldn't do that. For example Unicorn is multi-proces single-threaded so it should never be used without a buffering web server, but Puma is different. We'll need the Puma author to make a statement about this.

I'm glad the comparison was useful to you. :)




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: