# Deploying only what you need with Capistrano? **URL:** \ **Category:** Rails\ **Created:** [August 16, 2006, 7:18pm UTC](https://www.ruby-forum.com/t/deploying-only-what-you-need-with-capistrano/65194 "2006-08-16T19:18:34Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Charles\_O\_Nutter](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/aeb1de/32.png) [@Charles\_O\_Nutter](https://www.ruby-forum.com/u/Charles_O_Nutter)\ **Post date:** [August 16, 2006, 7:18pm UTC](https://www.ruby-forum.com/t/deploying-only-what-you-need-with-capistrano/65194/1 "2006-08-16T19:18:34Z")
The recent Rails security issue highlighted a concern I’ve had about Rails deploys; namely, you shouldn’t deploy anything to production that you don’t need there. Rails apps have a number of scripts–potential security holes or DOS targets in this case–along with all the other application code you need. There’s no reason you should have script/server, console, plugin, generate, or any of the others on a production machine, as far as I can tell. I’m sure there’s other items that could be cleared out as well, and/or Ruby and Rails features explicitly turned off. Is this contrary to the Rails way? It’s always been considered a best practice on my projects, but do folks in the Rails world share my concerns? Is there a way to make Capistrano only deploy what you need? ---
**Author:** ![Charles\_O\_Nutter](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/aeb1de/32.png) [@Charles\_O\_Nutter](https://www.ruby-forum.com/u/Charles_O_Nutter)\ **Post date:** [August 16, 2006, 10:15pm UTC](https://www.ruby-forum.com/t/deploying-only-what-you-need-with-capistrano/65194/2 "2006-08-16T22:15:56Z")
Since capistrano’s deployment tasks really only automate the performing of “checkout” from a repository (and usually through subversion), it is really the developers job to “ignore” files that shouldn’t be checked in. There are good reasons, I agree, to not include developer tools like breakpointer and such. And, on the other hand, if you need to setup another developer, they could always check out the production limited code-base and run “rails .” on the current dir to get the latest dev tools like script/server that have been removed anyways. In the case of schema.rb (highglighted by attacks), this file is generated when you run rake migrate, thus it would be worthy to have a: desc “After deploy\_with\_migrations callback” task :after\_deploy\_with\_migrations, :roles =\> [:app, :db] do run “rm db/schema.rb” end Continuing along that path, it would perhaps be feasible to alter Capistrano to remove files that developers have checked in and will continue to get checked out or generated. The after\_ callbacks are a good place to do this. My recommendations: - alter anywhere you see svn practices (like the subversion setup rails wiki page) to not include script/\* and to ignore dispatch.rb, etc. - we could beef up capistrano and have default affer\_deploy tasks, or even alter to have a mode of deployment, so the deploy to staging or deploy to dev box task keeps files, but the deploy to production just exports code. ## I’m with you, and I agree. Charles Brian Q. self-promotion: [www.seebq.com](http://www.seebq.com) highgroove studios: [www.highgroove.com](http://www.highgroove.com) slingshot hosting: [www.slingshothosting.com](http://www.slingshothosting.com) On 8/16/06, Charles O Nutter [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > practice on my projects, but do folks in the Rails world share my concerns? > removed\_email\_address@domain.invalid > [http://lists.rubyonrails.org/mailman/listinfo/rails](http://lists.rubyonrails.org/mailman/listinfo/rails) - ---
**Author:** ![Charles\_O\_Nutter](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/aeb1de/32.png) [@Charles\_O\_Nutter](https://www.ruby-forum.com/u/Charles_O_Nutter)\ **Post date:** [August 16, 2006, 10:30pm UTC](https://www.ruby-forum.com/t/deploying-only-what-you-need-with-capistrano/65194/3 "2006-08-16T22:30:59Z")
On 8/16/06, Charles Brian Q. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Since capistrano’s deployment tasks really only automate the > performing of “checkout” from a repository (and usually through > subversion), it is really the developers job to “ignore” files that > shouldn’t be checked in. There are good reasons, I agree, to not > include developer tools like breakpointer and such. I agree with keeping Cap simple in principal; my concern is to try to avoid having to hand-roll a less-than-perfect production scrubber, as well as trying to keep up with new “fluff” in future Rails releases that I don’t want to deliver with applications. There ought to be some reasonable conventions for removing community-accepted fluff before a production release. And, on the other hand, if you need to setup another developer, they > could always check out the production limited code-base and run “rails > .” on the current dir to get the latest dev tools like script/server > that have been removed anyways. Not a bad thought, but it pushes the onus on the Rails end-user to know which files shouldn’t go to production, rather than having a “safe by default” scrubber already available. It also eliminates some of the agility of Rails development if I’m always forced to prime a newly-checked-out application before getting back to work. Still, it’s not bad. In the case of schema.rb (highglighted by attacks), this file is > continue to get checked out or generated. > deploy to dev box task keeps files, but the deploy to production just > exports code. This is exactly in line with what I’m thinking. At a minimum, there should be a number of files you’d never want delivered to production, and a reasonable set of defaults “after” tasks to prevent that from happening without explicit permission. I’m not sure I’m the right person to say what files those are, however, nor to make appropriate changes to HOWTOs or code… ---
**Author:** ![Charles\_O\_Nutter](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/aeb1de/32.png) [@Charles\_O\_Nutter](https://www.ruby-forum.com/u/Charles_O_Nutter)\ **Post date:** [August 16, 2006, 11:46pm UTC](https://www.ruby-forum.com/t/deploying-only-what-you-need-with-capistrano/65194/4 "2006-08-16T23:46:06Z")
Weeeelll, We actually do like having testing on prod that so that we know everything is working. A quick full test of your app on a production server will sure let you know quick if you’re missing a gem, dependency, or expect certain file paths/system conventions to work. To be completely honest: I’m currently working on a new tool for deployment that utilizes Capistrano – and has some really slick stuff for automating its usage. It’s based off our RailsDay2006 entry: [http://heartbeat.highgroove.com/](http://heartbeat.highgroove.com/) In the mean time, I’d love to share some best practices for capistrano recipes – let’s get this thread together, and I’ll patch up the default capistrano recipes with an option to turn on in your deploy.rb file – this would enable after\_ callback tasks to clean up everything for a real prod deploy. The maintainers are rails core (Jamis B. and DHH), so when we’re done I’ll submit on the rails trac – I also have some changes to our capistrano setup for our new tool, but these changes don’t necessarily need to be pushed upstream. ## cheers, Charles Brian Q. self-promotion: [www.seebq.com](http://www.seebq.com) highgroove studios: [www.highgroove.com](http://www.highgroove.com) slingshot hosting: [www.slingshothosting.com](http://www.slingshothosting.com) ---
**Author:** ![Charles\_O\_Nutter](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/aeb1de/32.png) [@Charles\_O\_Nutter](https://www.ruby-forum.com/u/Charles_O_Nutter)\ **Post date:** [August 16, 2006, 10:30pm UTC](https://www.ruby-forum.com/t/deploying-only-what-you-need-with-capistrano/65194/5 "2006-08-16T22:30:59Z")
On 8/16/06, Charles O Nutter [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > This is exactly in line with what I’m thinking. At a minimum, there should > be a number of files you’d never want delivered to production, and a > reasonable set of defaults “after” tasks to prevent that from happening > without explicit permission. I’m not sure I’m the right person to say what > files those are, however, nor to make appropriate changes to HOWTOs or > code… Another thought: test cases. It’s generally a serious no-no to deliver test code to a production server, but current Cap will do it happily, yes?