Meteor deployments on Scalingo just got 30% faster

Release after release, Meteor builds have been slower and slower. We’ve observed such trend for almost a year now, as the biggest part of a Meteor app deployment is the ‘build’ part. We’ve just released a new version of our Meteor deployment system which decreases deployment durations of an average of 30%.

An upgrade for all Meteor applications

Our customers are deploying production Meteor applications daily on the platform because it just works. However the bigger the application, the slower the deployment. One of our goals is to remove the pain of deploying your products, the experience has to be fluent and instant. If you have time to have a coffee, it is probably too long. So from your feedbacks we’ve been working on optimizing Meteor deployments and this is the first result of our research.

We’ve just released a patch to our Meteor buildpack, which decreases significantly the deployment duration of a Meteor application. This patch has no effect on the initial build, but ensure better performance for all the deployments that follow.

Example

As an example, let’s take the open-source project Wekan (Wekan is an open-source alternative to Trello written with Meteor).

It is worth to mention that Wekan, but also Telescope and RocketChat are one-click deployable, you will find more information about this feature in our previous blog post.

What has changed

So far we were using demeteorizer, an open-source tool to transform a Meteor application to a “simple” NodeJS application. The tool was required to deploy early releases of Meteor. Today, such tool is not necessary and we’re using the following command directly:

meteor build

From this build, multiple build artefacts are generated in the directory $BUILD_DIR/.meteor/local. Among these files, cached packages, generated javascript files and css files. We are now storing all these files from deployment to deployment. As a result, the ‘build’ command won’t re-generate everything again and will use the previously built files when possible. (When nothing has changed in the code)

To conclude

Using more efficienly the deployment cache is a first step to faster deployment. This change is already having a strong impact on all your Meteor applications. We keep experimenting new ways to improve this part and provide a more instant user experience.