Is it good idea to install modules, which require server config, locally? How? There are few modules which require server side config to work. If you have a hosting and domain, it is not a big problem, but if you are developing locally, then I guess it is a problem.

If you somehow install and use these type of modules on local environment to test, you have to change the config once you move to production. For example Node.js integration, Twitter and other modules which require a setup before you can use them.

I am using acquia dev. I want to test some modules before going live as I mentioned above, but my question is how I can do that?

Note: Using such local environment is for me a way to reduce the cost of testing, since I wouldn't have to purchase hosting for that during a few months. In some cases, nobody would want to purchase a hosting and waste few months or a year for just testing.
The problem is having different configuration in in different environments (production, staging, local dev, etc).

Usually you have production. This is the main site. You have to move it to staging or development environment. Moving implies usually to get the production database with all new added content. But in dev environments you need some changes:


Enable development modules like devel, https://www.drupal.org/project/reroute_email, etc.
Change settings. For example, if your site uses a webservice you may change the endpoint URL to a dev webservice URL. Those settings sometimes are jsut Druipal variables but they may be custom settings stored in a module's custom tables.
Clean sensible data: user emails, user personal data like medical data, confidential content that should not be leaked, etc.


You can:

Override variable in settings.php

As @Jaypan said in comments override $conf['VARNAME'] in settings.php. This allows to easy variable override per environment. 

To have more flexibility you can use Drupa 8 strategy: have  acommon settings.php in source code control  with all common config for all environments and at the end of the settings.php file load a settings.local.php wuth the per environment settings. Typically here you can a have BD config, config to access other service like your node.js, etc.

To do this add this code in your settigns.php.

# Load environment managed conf.
$conf_path = conf_path();
if (file_exists(DRUPAL_ROOT . '/' . $conf_path . '/settings.local.php')) {
  include DRUPAL_ROOT . '/' . $conf_path . '/settings.local.php';
}


Modify environment

Previous solution works but sometimes you need to change more than internal Drupal variables. In that case you should set up a mechanism to execute setup code in your environment. For example you may want to make sure that in your staging or local environment Stage File Proxy is enabled. You can't enable a module directly in settings.php. Also, you may need to execute a query to sanitize data.

In this case there are several options to change things according to environment: 

Using hook_init implementation

hook_init is a Drupal hook that is called on every non-cached request. Here you can place code that checks some condition in your environment and changes it if needed. This solution is simple to implement, but because the hook implementation is called on every non-cached request the checks performed should be very also simple or you may hit a performance penalty.

Also, you can use hook_boot, that's executed on every request, cached or not. You have to be very carefully with this hook because of performance and because is called during Drupal bootstrap and before the theme, modules, or most include files are loaded into memory. 

Creating a custom drush command

Drush allows to create custom commands. At the end, they are just PHP code executed in the Drupal context, so all Drupal functions are available. You can create a custom drush commands that performs the environment check. From here you can enable modules, perform sql queries or any other action Drupal allows.

This command should be executed when the database is loaded into the dev environment, just once. Because of this, there's no problem if the command is resource intensive as it's only executed once.

Extending drush sql-sanitize

This drush command sanitizes the database, setting same password for all users and modifying their address. You can extend it to make more tasks like executing SQL queries.

Script with drush commands

Write a custom sfript with drush commands that modifies the environment. This soltuions is simple but alloww you to make any modification done by a drush command.

For example:

drush en devel -y
drush vset myconf my_dev_value
drush sql-query "MY AWESOME QUERY"