Acquia BLT short Drupal8 howto

Working with vm’s makes everything simpler and easier. Easy to reproduce bugs, easy to reproduce features between environments and, most importantly, between developers.

In the past I’ve been working with different solutions, custom mainly, based on puppet, ansible…. Until I arrived to Acquia. Local environments as it happens is a recurrent topic on every team, a clear pattern… and when there is a pattern, you can write something to save some time to those lazy developers ;-). Enter BLT (Pronounced BOLT).
BLT is basically an environment that has everything ready for fast developer on-boarding, easy deployment on different environments (dev, staging, prod, … and of course, local), but also for quick automation of repetitive tasks, like rebuilding your sites, pulling databases...
Configuring BLT is very straightforward, but it will take some reading from you. Keep reading for a TL;DR version:
First, install the requirements:
In Mac it is very easy to do it simply following the brew requirements.
brew tap caskroom/cask

brew install php56 git composer ansible drush

brew cask install virtualbox vagrant
Once this is installed you have blt in your command line:
  blt --version
That’s it, you are ready.
Note: for other operating systems please visit:
Once we have all the tools installed in our computer we can start building apps. It couldn’t be simpler:
    composer create-project --no-interaction acquia/blt-project MY_PROJECT
That will create a base directory from which you can start building your Drupal app. First thing I’d do is moving this to your git repo, i.e. GitHub:
  $ git add .

  $ git commit -m "BLT-00 first commit."

  $ git remote add origin

  $ git push -u origin master
Now, let’s move inside the repo and start doing the magic. Let’s initialise the vm (I am assuming here that we’ll be working on a virtual machine):
  blt vm
It will ask if you want to install Drupalvm, to which we’ll say yes, and afterwards if we want to boot it. Yes again.
At the end of the process you should see a green message like this one:
"Drupal VM booted successfully. Please use vagrant commands to interact with your VM from now on.”
Your vm is ready. Last stop, install a site:
  # Since blt 9.x, you have to do this from inside the vm, so:
  vagrant ssh 
  blt setup
This will install a default Drupal 8 site in docroot. You could put your custom site here, or for example install lighting ( instead of the default one. The best practice for that road would be using composer, although I’ll leave this for a different post.
Now, next step you need is to actually connect your new vm to your Acquia Cloud (AC) environments. You have to do this drush level and BLT level, drush to be able to execute drush against the environments, BLT to be able to sync the databases, build artifacts, etc…
First bit, BLT settings. Edit:
And add in remotes the url to AC. You’ll find this url in AC. Go to, select your application and, in the list of environments, you’ll see on top right an icon called “Application Information”. Click and the first url is what you need. IE: [email protected]:YOUR-APP.git
Your yml file will look like this:

  default_branch: master


   - 'lightning[email protected]:lightningalex.git'
Lastly, your drush settings. Go to your AC profile page:
Select Credentials and, after confirming your password, you should see 'Drush integration’ in the new page. Download and place the hidden files in your $HOME.
Time to deploy your stuff to Acquia Cloud (or theoretically any other host provider). First thing, you’ll need to add your ssh keys to Acquia Cloud, just:
If you don't have any ssh keys yet there are some good short tutorials out there, it shouldn't take you more than 10 minutes to generate a new ones.
Ready to go, do:
blt deploy -Ddeploy.commitMsg='BLT-000: Deployment test' -Ddeploy.branch='master-build'
Answer ‘y’ to create a tag, return for the default commit message, and write your tag (i.e.: 1.0.3-build)
If your keys are good to go you should see some magic happening, and your artefact being deployed to the Acquia Cloud remote server. Now simply go to Acquia Cloud, select the tag that you have just created and deploy it in your environment. 
All done… although now I am thinking on changing the title of the article… not that short after all :-)
Bonus: Some commands
- Rebuild your local with the remote db:
blt sync
Equivalent to: drush sql-sync @remote @local

Apache not sending changes in js and css (virtual box)

I am using a solution of vbox (virtual box) and shared folders in our windows work environment (yes, unfortunatelly, but the IT team is in his right to decide which machines we have to use).

Everytime the vbox start, it mounts "automagically" one of the shared folders in the linux host (centos and archlinux, one day I will explain why). So then, apache has all what he needs in /var/www/html/ (simply mounted with "mount /var/www/html") (see automatically mount directories in vbox).

So far, everything was working fine... until I started to make small changes in small files. Absolutely surprising because when I deleted the complete code in the css or js file, for example, and I updated the browser, the screen appeared white, so everything seemed ok. But not at all, dealing with small changes, like adding a line in your css simply add no effect, the change is here, but seems that Apache or the browser didn't like it, simply it was being ignored.

After a while struggling about the browsers cache and even restarting the virtual box I finally decided to dig into Google.

I found the problem in the frankooh blog and it seems that it is a vbox problem, exactly a vboxsf problem with Apache.

The solution is simple, go to you apache configuration (in centos /etc/http/conf/httpd.conf) and uncomment the line:

EnableSendfile Off

After restarting Apache all the changes were sended to the browser without problems, even the small ones.

PS: be carefull with case sensitive off != Off 

warning: date(): It is not safe to rely on the system's timezone settings

The error is quite enoying:

warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'GMT/0.0/no DST' instead

But it is quite simple to correct. It is not a drupal problem, but a linux/apache. Just go to your php.ini, for example /etc/php.ini in CentOS and add this line:

date.timezone = Europe/London

reboot apache and the problem will have dissapeared.


changing vhost.conf without restarting apache

Sometimes you need to change some parameters to your apache virtual host. Then, when you need to check the changes, in plesk you'd probably will have to execute the next command to see the changes:

/usr/local/psa/admin/sbin/httpdmng --reconfigure-domain

Otherwise, restarting apache (/etc/init/apache2 restart) could not make the trick.

I allways forgot this little trick... never more, because Programadores Web will remind it me :-).


Developing under Linux Apache in windows

Contradictory? Yes, a bit, but you cannot allways choose the systems and architecture in which you are working.

solution? Runing apache under linux instead of runing wamp or some weird solutions like that (i don't like at all, sorry).

First, install vbox:

Second, download the iso of your preffered linux distro, and install it.

Third, when you machine is running, go to Devices>install guest additions.

Now you have to come back to your linux machine, and install a few things, kernel upgrades included (if needed).


  • yum install gcc -y
  • yum install kernel sources -y
  • yum install kernel-devel -y



Reboot your system, and mount:


  • mkdir /media/VirtualBoxGuestAdditions
  • mount -t vboxsf /dev/cdrom /media/VirtualBoxGuestAdditions





Centos tips



  • Configuring your network to start when booting: chkconfig network on (via
  • configuring services to start apache (or any other daemon) when system boots: chkconfig --level 2345 httpd on
  • ... more coming
  • Override Apache permissions problem: "You don't have permission to access ... on this server". Simply execute: setenforce 0



Accessing centos apache/httpd from vbox host

This is the scenario. You installed vbox in your Mac, windows or Linux computer. Then you´ve installed Centos or Red Hat (or any other Red Hat flavor) in this virtual box.

Next step, installed httpd (apache2) and... even it is running and httpd status confirms it with a "running" message, it cannot be accesible from your host machine.

The problem is on iptables. Red Hat by default denies access to this machine from other (external) machines. Solution? Very easy, open iptables file:

vim /etc/sysconfig/iptables

(vim is my favourite editor for a loooong long time)

Look for this line:

-A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT

and after that, add this one:

-A INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT

Restart your services and everything done:

service iptables restart

Thank to