Monday, August 29, 2016

Introducing the First of Bitnami's Multi-VM Applications

Bitnami's applications in the cloud are trusted by developers, small businesses, and enterprises around the world to run critical business functions. The key reason for this is our ability to deliver the most up-to-date and patched versions, consistently and quickly. These applications are also available in multiple different formats, such as virtual machine images, containers, and local installers, so you can run them anywhere. 

As our customers environments grow in size and complexity, an important concern is being able to extend applications in different ways, with the ease of use that's expected of a Bitnami app. Bitnami is now splitting out our application catalog into multi-vm architectures. Different types of architectures give customers the flexibility to extend workloads in the cloud, and tailor the application for the use case. Types of Multi-VM architectures include: 

Multi-Tier Application

  • Horizontal and Vertical scaling of both parts of the application
  • Your data and your application are separated into two different VMs. This enables:
      • Simplified backups and updates (version upgrades, patches, etc)
      • Improved security and access control by separating data from code
      • Ability to  performance tune each tier independently

An example of this application is Bitnami Multi-Tier Wordpress, in Azure. 

Clustered Application

  • Higher availability, with a three node configuration that permits a leader election inside of the cluster. In this environment, each of the nodes are treated as part of the same set and can be promoted based on consensus inside of the configuration.
  • The ability to add capacity by increasing the number of nodes in the cluster.
  • Increased resiliency in the face of individual node failures and the ability to divide a cluster across multiple availability zones.
An example of this application is Bitnami Production MongoDB, in Azure.

Master / Worker Application

  • Elastic capacity, with the ability to add workers as needed for increased application throughput based on application needs. With this type of architecture, scaling your application can be responsive to additional demand. Both programmatically and manually an application back-end can be scaled to meet need.
  • The worker based model works well with ephemeral storage common on cloud platforms as state is not needed after the job is finished.

An example of this application is Bitnami Production Jenkins, in Azure.

If your application requirements can benefit from the above, Bitnami Multi-VM can help you reach your goal. We want customers to be able to launch these applications quickly and easily. Bitnami now has 6 multi-vm templates (Wordpress, Drupal, Redmine, Magento, MongoDB, and Jenkins) available in the Azure Marketplace, and one (MongoDB) in the Google marketplace.

It’s also simple and easy to launch MongoDB on the Google Cloud Platform as well. Navigate to the Google Cloud Launcher using your Google Cloud Platform account, and simply follow the steps to set up your desired environment in one click. 

Of course, if your application does not need higher throughput or a distributed architecture, you can always use Bitnami’s one-click Single VM images, suitable for smaller environments. Bitnami is looking into developing more applications in more application topologies, and investing in expanding beyond our current offerings at this time. We welcome suggestions for improvements and look forward to improving production delivery with these templates; please email with your feedback.

- Raj Rikhy, Product Manager - Cloud Platforms, Bitnami

Have a few more questions?  Hopefully these FAQ’s can clear things up:

1. Will you make a multi-vm template for every Bitnami app?

Not every application in the Bitnami Catalog will be delivered as Multi-VM. The applications scheduled for release have a set of criteria such as benefiting from cluster configuration, or requiring horizontal scale as the application size increases.

2.  How do you decide which apps to select?  If I want a multi-vm version of a particular app, how can I request that?

Please reach out to us directly if you have any requests or would like to see your applications available as multi-vm. You can reach out to us at

3. You mentioned APIs -- do I have to be a software developer to utilize your multi-vm templates?

Not at all! Our Multi-VM templates will work with a single click-to-deploy through the cloud marketplace providers, and use the same experience that any bitnami application provides.

4. What's the benefit of using the Bitnami version vs building my own template?

Building your own template using a specific cloud provider can be done using any cloud specific template. However, keeping the application up-to-date, using a production configuration specific to the application, and consistent experience across clouds are where Bitnami’s applications can make your life easier.

5. Do multi-vm templates improve disaster recovery?  Or provide failover?

Bitnami’s templates are not designed to incorporate disaster recovery or failover at this time. You can still use the same backup and Disaster Recovery tooling for your applications that you currently use, however, since these applications will launch the same compute resource as our single-vms.

6. How much do you charge for this?

Bitnami’s templates are free of charge, and there is no cost for the software.

Thursday, August 18, 2016

Intel PGO Optimizations Lead to 20% Faster WordPress on AWS

Profile-guided Optimization (PGO) is a technique that improves the performance of applications. It requires profiling data, which is later passed to the compiler and can be obtained after a test run of the application. The profiling data contains information about code areas that are most frequently used, and by knowing these areas, the compiler is able to be more selective and specific in optimizing the application.

Bitnami has been working with Intel on adding Profile-guided Optimizations to selected Bitnami stacks and we started with a Bitnami WordPress stack. In summary, we saw the following:
  • Applying Profile-guided Optimizations to the Bitnami WordPress stack resulted in a 20% improvement in the page-load speed.
  • Additionally, applying some tweaks to the MariaDB configuration, we were able to decrease the page-load time a total of 34%, including the PGO change.
The machine used to get the results of these tests consisted of an AWS m3.medium instance with HVM and SSD, using a Ubuntu 14.04 image.

In order to test the improvements in page-load time, we are making use of the "php-cgi" executable which is included in the Bitnami WordPress stack. A sample command for testing a WordPress stack located at "/opt/bitnami" would be the following:

sudo /opt/bitnami/php/bin/php-cgi -c /opt/bitnami/php/etc/php.ini -T10,1000 /opt/bitnami/apps/wordpress/htdocs/index.php >/dev/null

The test will launch a total of 1000 requests, 10 at-a-time, and measure the time it takes until the last request finishes. With this result, we will be able to measure how quick our WordPress installation reacts.

Executing the command above in an original Bitnami WordPress stack, the results will look something like this:

$ sudo /opt/wordpress-4.5.3-2/php/bin/php-cgi -c /opt/wordpress-4.5.3-2/php/etc/php.ini -T10,1000 /opt/wordpress-4.5.3-2/apps/wordpress/htdocs/index.php >/dev/null

Elapsed time: 30.819571 sec

An important difference for the stack built with PGO-optimizations is that it bundles MariaDB (not MySQL), and that we added a few tweaks to the database configuration. These changes consist of a few added lines to the "mysqld" section in the database's "my.cnf" configuration file:


These changes can be applied to the original WordPress installation too, resulting in an improvement in page-load speed up to 17,5% (comparing to the result of the first test):

$ sudo /opt/wordpress-4.5.3-2/php/bin/php-cgi -c /opt/wordpress-4.5.3-2/php/etc/php.ini -T10,1000 /opt/wordpress-4.5.3-2/apps/wordpress/htdocs/index.php >/dev/null

Elapsed time: 25.431113 sec

Now, combining the PGO-optimizations with the database tweaks mentioned above, it is possible to get up to 34% improvement in page-load time compared to the original Bitnami stack, and up to 20% if we compare it with the tweaked-database installation:

$ sudo /opt/wordpress-4.5.3-2/php/bin/php-cgi -c /opt/wordpress-4.5.3-2/php/etc/php.ini -T10,1000 /opt/wordpress-4.5.3-2/apps/wordpress/htdocs/index.php >/dev/null

Elapsed time: 20.310336 sec

As you can see, we get a 20.1% improvement in the page-load speed that are PGO-only related.
If we compare it with the original and non-modified WordPress stack (which does not include any database tweaks), the page-load time is reduced up to 34.1%:

Are you interested in trying the PGO-optimized Bitnami WordPress stack? You can download it below:

Friday, August 12, 2016

Security Notification: Off-Path TCP Linux Kernel Vulnerability (CVE-2016-5696)

[UPDATE: 2016-08-22]

BCH images have been updated properly. You can now launch new servers that mitigate the vulnerability.

[UPDATE: 2016-08-18]

All the affected cloud images and virtual machines have been successfully patched.

If you are using a Bitnami Cloud Hosting instance, you can easily patch it following the guide below while we upgrade the base images. 

[UPDATE: 2016-08-17]

The Bitnami Team is happy to announce that the images of Google, Azure, 1&1 and GoDaddy have been updated properly. Additionally, we continue working on releasing the images for our all of our cloud platform partners, virtual machines and the native installers.


A new security vulnerability in the linux kernel has been discovered. You can find out more information about it in the following research report: "Off-Path TCP Exploits: Global Rate Limit Considered Dangerous".

Since the Linux kernel code affected was implemented in 2012 (in Linux Kernel 3.6), all Bitnami-packaged images might be affected by this issue if the kernel hasn't been updated. At the time of writing this post, a new patched kernel has NOT been released for Debian and Ubuntu distributions that are the base OS for most of the Bitnami Virtual Machines. We will keep you updated in this blog post.

We believe it is of the utmost importance to quickly address any security issues in applications distributed by Bitnami and our team is working to update all of the affected Virtual Machines and Cloud Images available through Bitnami for all Cloud Providers. 

In the meantime, you can mitigate this problem by applying the following patch in your system:
sysctl net.ipv4.tcp_challenge_ack_limit=1073741823; grep -q tcp_challenge_ack_limit /etc/sysctl.conf || echo "net.ipv4.tcp_challenge_ack_limit=1073741823" >> /etc/sysctl.conf
Please, note that this is just a temporary solution that makes it a lot harder for attackers to succeed in exploiting this vulnerability. You can find more information about this temporary fix in a writeup on the Akamai blog.

Once the new kernel is available, you can update it by running the following commands (you must run the command specific to your distribution):

  • Ubuntu 
sudo apt-get update && sudo apt-get dist-upgrade 
You will have the fixed version of the kernel after rebooting your server.

  • Debian 
sudo apt-get update && sudo apt-get dist-upgrade 
You will have the fixed version of the kernel after rebooting your server.

  • Oracle Linux 
sudo yum update
sudo yum upgrade
You will have the fixed version of the kernel after rebooting your server.

  • Amazon Linux & RedHat Linux
sudo yum clean all
sudo yum update kernel
You will have the fixed version of the kernel after rebooting your server. 

If you have any questions about this process, please post to our community support forum and we will be happy to help! 

Wednesday, July 20, 2016

Security notification: httpoxy A CGI application vulnerability (CVE-2016-5385, CVE-2016-5387, CVE-2016-1000110)

On July 18th, a vulnerability named ‘HTTPoxy’ was announced, affecting some server-side web applications that run in CGI or CGI-like environments, such as some FastCGI configurations.

A number of CVEs have been assigned, covering specific languages and CGI implementations:
  • CVE-2016-5385: PHP
  • CVE-2016-5386: Go
  • CVE-2016-5387: Apache HTTP Server
  • CVE-2016-5388: Apache Tomcat
  • CVE-2016-1000109: HHVM
  • CVE-2016-1000110: Python
More information about the vulnerability can be found on the httpoxy website.

Any PHP-based, Python-based or Tomcat-based Bitnami application is affected by this security issue.

We believe it is of the utmost importance to quickly address any security issues in applications distributed by Bitnami and our team is working to update all of the affected Cloud Images, Virtual Machines and Native Installers available through Bitnami.

Please take a moment to check if your image is vulnerable by following the instructions in the security section of our wiki.

You can mitigate the issue by blocking the Proxy request headers as early as possible, and before they hit your application. This is easy and safe.


  • Modify the <IfModule headers_module> in the /opt/bitnami/apache2/conf/httpd.conf file of Apache to unset the Proxy header. It will look like this:
<IfModule headers_module>
    RequestHeader unset Proxy

  •  Save the file and restart the service of Apache
sudo /opt/bitnami/ restart apache 


  • Add this line at the end of the file at /opt/bitnami/nginx/conf/fastcgi_params.
fastcgi_param  HTTP_PROXY "";

  • Save the file and restart the service of Nginx
sudo /opt/bitnami/ restart nginx 

If you have any questions about this process, please post to our community support forum and we will be happy to help!

Update: 2016-07-22

The Bitnami Team has been working on releasing all the affected stacks in the different cloud vendors and we have to announce that the images of Google, Azure, 1&1 and GoDaddy have been updated properly. 

We continue working on releasing pending cloud platforms, virtual machines and the native installers. 

Update: 2016-07-26

All the cloud images, virtual machines and native installers that were affected by this security issue have been successfully patched and they are already available through Bitnami and our cloud partners. 

If you are using a Bitnami Cloud Hosting instance, you can easily patch it following the guide above while we upgrade the base image. 

Update: 2016-07-29

We patched the base images of Bitnami Cloud Hosting successfully and you can now launch a non-affected instance using Bitnami. You can also check the bundled components of the new images using this link

Monday, June 27, 2016

Develop Collaboratively with Eclipse Che, Now on Bitnami!

Eclipse Che is an open source cloud IDE and developer workspace server featuring containerized workspaces that accelerate agile software development. Containerized workspaces let developers bootstrap projects without having to install software, and collaborate on projects from anywhere. With Eclipse Che in Bitnami, you can now launch the application in your own cloud account on the most popular platforms like AWS, Google Cloud Platform, and Oracle, in just a few clicks.

Shareable workspace server

Each Eclipse Che instance is given its own hostname, and is designed to be accessed by multiple clients at the same time- the only limit is the system’s disk and memory.

Each developer workspace in Eclipse Che consists of a project (your code) and the runtime for the language the project is written in. You can use the included runtimes or create your own by referencing Docker images or Dockerfiles. The Eclipse Che configuration file encompasses project sources, build/debug runtime, and execution commands in a single JSON object. The config file is used to launch the workspace in its own Docker container, thereby eliminating conflicts among dependencies no matter how many runtimes you are using. Developers can use the Eclipse Che workspace from its lightweight browser IDE or use their favorite desktop IDE by mounting the workspace over SSH. Workspaces are even reachable via API, enabling them to be created/altered programmatically or run as part of your CI/CD system.

Thin, lightweight, yet powerful IDE

The application’s browser IDE enables developers to access the workspace from any device and from anywhere in the world without needing to download any software. Hosting the IDE in the cloud and running it in the browser eliminates time wasted configuring and maintaining the environment for each individual contributor. The browser IDE allows you to work in multiple workspaces in different browser tabs so you can switch back and forth between projects with a simple keyboard shortcut.

Extensibility and open source community

Eclipse Che has a vibrant community, with contributions from large corporations like Microsoft and Red Hat alongside individual open source contributors from across the globe. There is a large and growing number of extensions for the IDE, the workspace agent, or core server, and you can also develop your own custom extensions using the SDK.

This introduction only scratches the surface of what Eclipse Che is capable of -- for more information on the application’s features, please visit their features page. Or you can launch Eclipse Che in your own cloud account and get up and running in just a few minutes!

Saturday, June 25, 2016

Security Release: Node.js 4.4.6

The Node.js project has just released a new version that fixes a vulnerability under certain conditions: V8 may improperly expand memory allocations in the Zone::New function. This is related to the CVE-2016-1669.

Read more about the security issue on the Node.js blog.

We want to let Bitnami users know that Node.js 4.4.6 installersvirtual machines and cloud images have been updated and released. We strongly suggest that you update your Node.js applications to the latest version.

If you work with containers, Stacksmith already has the latest versions of Node.js available.

Do you have questions about Bitnami Node.js or the security issues? Please post to our community forum and we will be happy to help.

Security Release: PHP 5.5.37

A PHP security issue that affects previous versions of PHP was recently announced. A signedness vulnerability (CVE-2015-8874) is present that allows remote attackers to cause a denial of service via a crafter imagefilltoborder call. 

We want to let Bitnami users know that all MAMP, LAMP, WAMP Stacks installersvirtual machines and cloud images have been updated and released. We strongly suggest that you update your PHP stacks to the latest version.

If you work with containers, Stacksmith already has the latest versions of PHP available.

Do you have questions about Bitnami PHP stacks or the security issues? Please post to our community forum and we will be happy to help.

Sunday, June 19, 2016

Introducing Bitnami Development Containers

Folks who have known me for a while, know that I love to make things easy for developers. From my days as a usability engineer on the Visual Studio team, to my pet projects, to my tutorials and samples, making programming easy and fun has been a theme of my work since 1998.

Now at Bitnami, I am happy to be working with a team who is as excited about this as I am. We have started a project that takes advantage of Docker to make developing with whatever framework you choose easy and fun. We call this project “Bitnami Development Containers.” This project is an extension of the development process that we have created for our own internal development. It only made sense to share our experience with developers everywhere.

We are in the beginning phase of the public part this project, and we are practicing the “release early and often” strategy, so let’s see what people think.

The basic idea behind the project is that if you have Docker enabled on your development machine, trying a framework should be as simple as what I affectionately call, “curling up”. That means that all you need to do is curl (download) a docker-compose file, and then run it with the docker-compose up command. After those two steps, and only those two steps, you can see your app running and start coding. It is that easy.

To accomplish this, we had to do a couple of things:
  1. First, we created custom containers that are meant specifically for developing with the frameworks of interest. These containers have an entry point that is designed to get developers going with zero configuration. We take care of all the configuration and any code generation necessary to get started.
  2. We include any necessary infrastructure and orchestrate them together using a simple docker-compose file. That means that if your framework of choice requires a database, maybe a specific database configured in a specific way, you don’t have to worry. We took care of all the work to set it up that way. You can just start coding.
So, for any framework that we support, with a development container, for example, if I wanted to write some good old Ruby on Rails code, I would just do this:

$ mkdir myrailsapp
$ cd myrailsapp
$ curl -L "" > docker-compose.yml
$ docker-compose up

Then open my browser, go to my docker-machine’s ip address at port 3000. And there’s the Rails welcome page. 

The exact same process works for Express:

$ mkdir express
$ cd express
$ curl -L "" > docker-compose.yml
$ docker-compose up

Then open my browser, go to my docker-machine’s ip address at port 3000. And there’s the Express welcome page. It’s always the same simple steps.

One important thing to note is that the containers are designed to work as immutable infrastructure. By that, I mean, none of the code that is generated or that you write is on the container. Rather, it is also mounted in a volume. That is important because it means that the containers support easy reproducibility. So, if you change some code, you can check in that code, and someone else can check it out, and docker-compose up just works with the existing code.

Ok, let’s just try it. I heard about Laravel. My team says it's pretty cool, but I never really knew what it was. So, I am going to using Bitnami’s Development Container to quickly get started with it.

First thing, I will create a directory for the application that I will write. Then I will download the docker-compose file into that dir. Again, the same simple steps, “curl up.”

$ mkdir laravel
$ cd laravel
$ curl -L "" > docker-compose.yml

Screen Shot 2016-06-19 at 11.19.40 AM.png

That went fast, so let’s take a look:

$ cat docker-compose.yml

Screen Shot 2016-06-19 at 11.20.18 AM.png

Ok, that is a nice and simple file. I can see that I am going to get a copy of MariaDB along with it. That’s handy, since as far as I can tell, Laravel and MariaDB go together like peanut butter and jelly. Note also that the port is already mapped for me.

Finally, note that it mounts a volume called “./app”. This is very important and interesting. What this means is that the application code that is generated and that I will modify is NOT in the container, but rather right on my desktop. This is how we achieve the immutability I mentioned above. This way, besides being easy to manage with source control, it is also trivially easy to edit with my desktop editor.

So, I curled, now I up. Of course, make sure that Docker is running before you do this:

$ docker-compose up

Screen Shot 2016-06-19 at 11.22.34 AM.png

The first time I run this, Docker will download the images first. Then it will start the containers.

Screen Shot 2016-06-19 at 11.23.24 AM.png

Looks like the container is started. Let’s check out the app.

First, I’ll check the ip address of my Docker VM:

$ docker-machine ip

Screen Shot 2016-06-19 at 11.24.09 AM.png

Now that I have that, I can navigate to port 3000. Port 3000 is a typical port for development web servers to run on. I could also tell I needed to port 3000 from the docker-compose file.

Screen Shot 2016-06-19 at 11.25.08 AM.png

It works! Let’s pause for a moment and consider how cool this is. In a matter of minutes I went from having an empty Docker environment to having a running Laravel 5 app. And I’ve never used Laravel before.

Of course, the first thing I want to do is to change the default to prove to myself that I have some control over the content.

Because this is my first experience with Laravel and I know almost nothing about it, I will have to poke around a bit. I’ll just guess that the string displayed in the default web page will help me out, so I will start with a recursive grep.

$ grep "Laravel 5" -R ./

Screen Shot 2016-06-19 at 11.28.11 AM.png

That “welcome.blade.php” file looks like a promising start for making my first change. Keep in mind, I have never even written PHP code, much less Lavarel code. But, I love to learn by doing, so I am just going to dive in with my editor and see if I can make a change.

Screen Shot 2016-06-19 at 11.30.40 AM.png

And …

Screen Shot 2016-06-19 at 11.31.57 AM.png

Yup! It’s that easy. Within minutes, I have made a change!

Let’s take another look at my Mac’s directory:

Screen Shot 2016-06-19 at 11.33.18 AM.png

As I mentioned before, you can see that the application code is on my development machine, NOT in the container. Furthermore, the docker-compose.yml file that sets up the development environment is in the same directory. That means I can easily commit this directory and share it. Anyone could check it out from source control, and run $ docker-compose up, and end up with the exact same environment. So, a team of developers could easily use the Bitnami Development Containers to collaborate on projects, and easily stay in sync with both the development environment and the code.

Today we have 3 development frameworks ready. Rails, Express, and Laravel, with more on the way. Please try them out and give us feedback. And please let us know what other frameworks you think we should do next! You can reach us at

- Rick Spencer, Bitnami VP of Engineering

Thursday, June 16, 2016

Security Release: Drupal 7 and 8

The Drupal project released a new update that fixes several security vulnerabilities. We strongly recommend upgrading your existing Drupal 7 and 8 sites.

Information regarding the additional changes is available in the official security advisory. In response to the new Drupal version, we have released the following: Bitnami Drupal 7 and 8 installers, virtual machines, and cloud images.

Two notable issues include:
  1. A vulnerability exists in the User module, where if some specific contributed or custom code triggers a rebuild of the user profile form, a registered user can be granted all user roles on the site. This would typically result in the user gaining administrative access.
  2. An access bypass vulnerabilty exists in the Views module, where users without the "View content count" permission can see the number of hits collected by the Statistic module for results in the view.
Our new releases fix the known security issues. There are no new features or non-security related bug fixes in these releases.

If you have questions about Bitnami Drupal or these security issues, please post to our community forum and we will be happy to help you.

Automated Container Delivery Using Stacksmith with GitHub

When developing with Docker containers, updates to an application’s stack or environment are rolled out by stopping outdated containers and replacing them with an updated container image. Docker is a popular toolchain for developing applications in containers that makes it incredibly easy to conduct these container image updates. However, the process of deploying updated container images is still a repetitive series of manual steps that can be mechanized. Bitnami built Stacksmith to automate this process.

Stacksmith automates the deployment of container images by maintaining a base Dockerfile, and by keeping each stack up-to-date against version updates and security vulnerabilities. Conveniently, Stacksmith integrates with GitHub so that when there’s an update to an application’s stack, a developer simply has to merge an automatically generated pull request from Stacksmith that contains the updated container image.

This post walks through how you can use Stacksmith with your application on GitHub to provide continuous delivery of your application container images.

Before you get started

This tutorial assumes you have Git, Docker (1.10+) and Docker Compose (1.6+) installed, and that you have some familiarity with these tools.

For this tutorial, we we will run Scotch’s Node Todo App on containers. The Node Todo App is a small, multi-tier and open source application that consists of an ExpressJS application server which connects to a MongoDB server for persistence. This architecture is referred to as a MEAN stack.

Once you confirm that you have the correct tools (Git/Docker/Docker Compose) installed, you are ready to get started by forking the Node Todo App repo on GitHub.

Create Your first Stacksmith Node.js stack

Stacksmith uses stacks to define the environments that make up your Dockerfiles. A stack is comprised of one or two components, most typically a runtime, as well as the base operating system. To run our Node Todo App on containers, we will create a stack that contains the Node.js runtime on top of Stacksmith’s Debian base:

On the Stacksmith homepage, select Node in the dropdown and click on ‘Create Stack’ to start configuring your stack.

Next, follow the instructions to connect your GitHub account to Stacksmith, and select your forked repository, the Node Todo App, in the dropdown list. By connecting your GitHub account with your Bitnami account, Stacksmith will be able to automatically add a Dockerfile to your repository that is configured based on your stack specifications. When there is an update to your stack, Stacksmith will automatically submit a pull request to your GitHub repository keep your application’s container image up-to-date.

Now select Node.js in the components dropdown. This will be the main component in our stack. We suggest that you select ‘6.x’ in the version dropdown, to ensure you only automatically update to security and patch fixes.

Once your components are entered, Stacksmith will prompt you to specify the flavor of Dockerfile you need. In this case, the Node Todo App is an ExpressJS application, so you will select ExpressJS in the dropdown to get a Dockerfile that is most suited to running your application.

To complete the stack creation process, leave the base operating system as Debian, and click the ‘Create stack’ button to go ahead and create your stack. The new stack that you created will show up in the ‘Your Stacks’ page with the same name as your GitHub repository.

Merging in your new Dockerfile

To merge your Dockerfile into your forked repository, visit your repository on GitHub by clicking the link at the bottom of your “Stack Info” screen. You will see that Stacksmith automatically opened a pull request to add your new Dockerfile to the repository. Accept the change which adds the Dockerfile to your repository by clicking on the green “Merge pull request” button.

Building and running your application container

Cloning the GitHub repository

Now that your application code has a Dockerfile checked in, you should try it out by running the application. First, clone the repository from GitHub into a directory on your local machine.

> git clone<GITHUB-USERNAME>/node-todo.git
> cd node-todo/

Remember to replace the clone URL with your GitHub repository’s remote URL.

Setting up your Docker Compose file

Docker Compose is a tool that makes it easier to run multi-tiered applications in containers. Using Compose, a developer is able to define each service needed to run their application in a container by creating YAML configuration file. A developer is then able to use Compose to manage the group of containers, specifically by bringing them up and tearing them down as necessary.

Your repository already has a Dockerfile that can be used to run the ExpressJS server, so you can configure Compose to build the image using this Dockerfile with the following directive:

 build: .
- 3000:8080
We suggest configuring a port mapping to access the web server from outside the container.

For MongoDB, you will need to reference the Bitnami MongoDB Docker image that can be pulled directly from Docker Hub. This container image will come with everything you need to run a MongoDB server out of the box.

 image: bitnami/mongodb
The full docker-compose.yml file should look like this:
version: “2”
   build: .
 - 3000:8080
restart: always
     - mongodb
   image: bitnami/mongodb

Building and running your application using Docker Compose

Now that we’ve setup our Compose file, we can go ahead and run the application. To start all the services, run:
> docker-compose up
Oops, it failed! Check the logs to see what went wrong. The issue seems to be that your ExpressJS container is expecting to run the application using the npm start command, however, the Node Todo App hasn’t been configured to specify the correct start script to run in the package.json. To fix the issue, you can modify your package.json file to run the server.js script when using npm start, or you can more easily change the container startup command in the Stacksmith generated Dockerfile.

We suggest the latter option in order to demonstrate how you can go about customizing the Dockerfile generated by Stacksmith. In your Dockerfile, change the CMD line from:

CMD [“npm”, “start”]


CMD [“node”, “server.js”]

If you rebuild and run the application again, you will see that the Node Todo App crashes because it is unable to connect to MongoDB. By default, the Node Todo App is configured to connect to MongoDB on localhost. The host needs to be changed to use the Service Discovery on the Docker Network that Compose sets up for us. To do this, change config/database.js to:

module.exports = {
   remoteUrl : 'mongodb://',
   localUrl: 'mongodb://mongodb/meanstacktutorials'

Now run docker-compose up --build and you will see that both containers start successfully, and you should try to access the Node Todo App in your browser at DOCKER_IP:3000, replacing DOCKER_IP with the IP address of your Docker Machine (if running in a VM), or localhost if running locally.

To find out the IP address of your Docker Machine instance, you can run the following command:

> docker-machine ip $(docker-machine active)

Committing and pushing your changes to GitHub

Now that you have made changes to the Dockerfile to run your container, you should commit and push your changes to GitHub.

After pushing the changes to GitHub, visit Stacksmith to see that your changes have been tracked correctly. This will ensure that when there is an update for your stack, your changes will be kept when you regenerate the Dockerfile.

Automating your container builds using Docker Hub Automated Build

To have your container continuously built when you update your application code, or when there is an update in your stack, you can setup an Automated Build repository in Docker Hub. For documentation on setting this up with your repository, visit the Docker Docs:

Receiving a stack update from Stacksmith

At this point you should have the following setup:
  1. Stack in Stacksmith that defines your application’s runtime requirements.
  2. Dockerfile generated by Stacksmith for building your application container.
  3. Connection to Docker Hub automated builds that automatically build and push your container to the Docker Hub Registry when you make changes in your repository.

What happens when a new version of Node.js is released? Or what happens when there is a security patch available for either Node.js or one of the packages in the Debian base image? In the container world the existing procedure for dealing with this scenario is to rebuild the whole application container on top of the new, updated and secure stack. Stacksmith introduces a new and easier way to deal with updates to your stack.

For example, it may turn out for you that within days or weeks of creating your stack, an update to Node.js may become available. When an update is released, Stacksmith will notify you via email, Slack, or a custom webhook.

For me, several days after I created my Node Todo App stack I received an email notification that I can update to Node.js 6.2.1. Below are the steps I followed to regenerate my Dockerfile:

Going back to Stacksmith to view my stack, I can see that I am currently using 6.2.0 and I can regenerate my Dockerfile to update to 6.2.1.
I click the “Regenerate” button to instruct Stacksmith to create a new stack with the updated version.
Next, I head over to my forked repository on GitHub where I can see that Stacksmith also created a new pull request with an update to the Dockerfile. The Stacksmith Bot leaves my Dockerfile modifications unchanged, and simply updates the referenced version of Node.js and the metadata about the new stack.

After I merge the pull request from Stacksmith, my Docker Hub integration kicks off an automated build using the new Dockerfile. Then after a few moments, I have a new Docker image for running my Node Todo App on top of the latest Node.js version. I can then reference the new Docker image in the Compose file, or a Kubernetes manifest and re-deploy my application.

If I want a more complete workflow for a production use-case, I can automate the deployment with an existing CI/CD pipeline that will kick-off after the merge of the Stacksmith pull request.

That’s all! If you are using Stacksmith to run your applications in development or production, please let us know! We’re eager to hear how we can improve Stacksmith for you.

Watch a demo of our Stacksmith and GitHub integration: