Host on Azure App Service (Autoscale, Zero-downtime deploy, Multi-region)

Github Repo:

We’re releasing this into the wild after using it to host a few production apps in-house.

Deployments are super-simple through the native git-based CI & should be compatible with any version of Meteor >1.4 (there were issues with Node 0.10.x).

Feel free to open any issues you may have on that repo - we are actively maintaining this.


Before going to galaxy, I once tried azure with failed. Look like Azure doesn’t support Meteor

What’s the technique you use?

Azure supports Node.js out of the box, so it was just a matter of writing a custom deployment script to handle the compilation steps before pushing.

Is there available any step-by-step guide?

Yeah, the setup instructions are on the Github repo.

Update: We’ve just pushed a number of architectural changes that should significantly improve reliability. There is also now an example repo for those that are interested.

Thank you! We’ve been using Azure’s VM’s and handling the build process ourselves. We’ve wanted access to the auto-scaling, etc. that the WebApp provides. Hopefully this works out!

1 Like

Good to hear - we were in a similar position a few months ago.

Let us know how it goes & if you run into any issues/pain points.

1 Like

Official statement from Azure team (see full thread):

Thanks to Meteor 1.4 supporting Node 4.x, which solved some native module compilation issues,
this can now be done with a relatively simple custom deployment script. You can see a sample here:

We’re investigating the next steps here now – like how to make it so we can detect your Meteor app and not require the custom deployment script. Stay tuned.

Chris – App Service PM


I just tried meteor-azure and it is BY FAR the easiest way to deploy a Meteor app outside Galaxy. Hell, you can even run it for free if you upgrade your instance to basic to deploy and downgrade it to free after.


Glad you found it useful!

@manuel, how did you do it , I try to do it but nothing shown, blank page :frowning: ;
can you show me you azure config please?

I just deployed a project with the latest meteor-azure without a problem. The only gotchas I’ve seen is that you need at least a Basic instance (not free or shared) and you shouldn’t npm install bcrypt.

@manuel what you means by basic instance? how to get it?

You are already on the basic instance otherwise it would not have compiled properly.

As I said on GitHub: it looks like your problem is app-specific (the repo did not run locally for me).

Was not aware of any catch with bcrypt, can you open an issue about this?

@ramijarrar what’s weird is that same code turn properly on and locally for me but not on azure, also in the log all is ok;
how to know what’s happen ?


I’m getting the following error while trying to run your app locally (on macOS):

import {Mongo} from 'meteor/mongo';
SyntaxError: Unexpected reserved word
     at Object.exports.runInThisContext (vm.js:53:16)
     at /Users/moe-talos/koufa_complet/.meteor/local/build/programs/server/boot.js:292:30
     at Array.forEach (native)
     at Function._.each._.forEach (/Users/moe-talos/.meteor/packages/meteor-tool/.
     at /Users/moe-talos/koufa_complet/.meteor/local/build/programs/server/boot.js:133:5

=> Exited with code: 1                        
=> Your application is crashing. Waiting for file change.

Once you fix this, I’m happy to continue helping you with configuration in

Sorry, it was probably another issue. I just deployed an instance with bcrypt without a problem.

1 Like

Okay, good to hear.

I actually dealt with a few edge cases recently (involving legacy atmosphere packages) and ended up replacing the entire sync mechanism in v1.1.2 to be much more robust/resilient against similar issues in the future.

Let me know if you run into anything else.