I have my test server installed locally with MAMP and so far everything is going fine but one concern I am having is how will I deploy my server remotely once I want to have a live server. Is there an easy workflow to export all your content, fields and views so that I can move them to a remote server using ftp maybe? How does this type of workflow normally work?

3 Answers 3


Here are some links to some articles which might be helpful. I've been compiling them myself, to help figure out how to tackle the same issue you're having.

Exploring Deployment Methods

Moving Configuration out of the Database with Features

Using Git with Drupal (http://github.com)

Useful Contrib Modules

  • 1
    Yeah, I've been scouring the web the past week trying to solve the same issue, and found all of this info. Commented Feb 1, 2012 at 5:26

To move exportable items I use the Features module. Drush is also very useful for dev to live migrations.

Features - From Module Description

The features module enables the capture and management of features in Drupal. A feature is a collection of Drupal entities which taken together satisfy a certain use-case.

Features provides a UI and API for taking different site building components from modules with exportables and bundling them together in a single feature module. A feature module is like any other Drupal module except that it declares its components (e.g. views, contexts, CCK fields, etc.) in its .info file so that it can be checked, updated, or reverted programmatically.

Drush - From Module Description

Drush is a command line shell and scripting interface for Drupal, a veritable Swiss Army knife designed to make life easier for those of us who spend some of our working hours hacking away at the command prompt.


The links provided by @David Csonka are great! I would echo that the Drupal "problem" is making sure to draw the line between content and configuration for deployability (as Drupal by default puts configuration in the DB and the goal is to get config. into version-able files as best possible - use git!). Personally, this has been greatly helped by the features.module and accompanying modules that "export" their configuration so that features can read that configuration (some noteworth great examples are views.module and strongarm.module)

We currently live the "Dev->Stage->Prod" lifecycle at AllPlayers.com - we have talked about it at conferences: http://vimeo.com/33678298

I've also always liked the DevSeed explanation of the direction of features in general (as they're the originators of the module); particularly putting the site-builder in the mindset of building and reusing "packaged" "recipes" on the Drupal "framework".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.