Series: ember-cli-deploy

ember-cli-deploy-Lightning Strategy part 2-Production

Published on Jun 17, 2016

We continue our journey with the ember-cli-deploy Lightning Strategy. Here we get our production build working on Heroku, and then we fix a localhost bug created in the previous episode.



module.exports = function(deployTarget) {
  var ENV = {
    s3: {
      prefix: ''
module.exports = function(defaults) {
  var env = EmberApp.env();
  var isProductionLikeBuild = ['prod', 'deploy-dev'].indexOf(env) > -1;

  var app = new EmberApp(defaults, {
    // Add options here
    fingerprint: {
      prepend: '',
      enabled: isProductionLikeBuild


Hey and welcome back to our series on ember-cli-deploy and our second episode dealing with the ember-cli-deploy-lightning-pack. In the last episode, we got it working on development. So notice it’s running on localhost:3000, which is where our Rails server is served, instead of 4200 where Ember is usually served. So this means it’s coming from our Rails server. And not just our Rails server, our Rails server is grabbing stuff from AWS. It’s following the lightning strategy that was outlined a couple of years ago by Luke Melia. So your server, it serves stuff, it grabs the correct version of Redis, and then you pull in stuff from S3. But that’s enough of a review. We need to get this going on our API server that’s on Heroku.

First, we’ll install the heroku-redis plugin. We’ve already got it installed, but this is what you would type in if you didn’t. This will automatically put in the config variable REDIS_URL. You’ll need to find that by typing in heroku config. I’m not going to actually enter this command because it’ll show you some of my other keys. But do that, find the one that’s REDIS_URL, and then go back to your application.

Then you should create a new file called So these are the keys that we’ll use when we’re deploying to the prod environment. So we’ll sign REDIS_URL and paste in what we got from heroku config. Off-screen I’m going to paste in my AWS_ACCESS_KEY and AWS_SECRET_KEY as well. So now we’ve got everything in our .env file that we’ll need for deploying to production. We will have to change a little bit here in our deploy.js. We’ll take the PROD_ off of this, and now that they’re the same between dev and prod, we can go ahead and have them in common instead of within the specific deployTarget branches. We’ll just assume that we have a REDIS_URL defined in development and not use this or [02:48]. And a quick correction. Let’s go ahead and rename this to instead of That is very important to get that right.

So let’s try deploying this. We’ll deploy it to prod and activate it immediately. Alright, so it’s looking for something. It’s connecting to something. That is progress. But there appears to be an error. And since I’ve done this before, I know what this error is. So it’s looking for something in assets/ember-2-0-frontend blah-blah-blah. But where we put it is was ember-2-0-frontend/assets then the file name. So the reason this comes about is because of the s3 prefix. And so we can just delete this and then we’ll deploy again. And now it works on production. Hurray. But we’re not quite finished yet. Yes, this is working on production, but in our haste to do this, we might have messed up a few things on development. So let’s get it so everything is working.

So this is our app at 4200, and you’ll see that it’s trying to grab stuff that isn’t there. But it’s not really the problem that it isn’t there. It’s a problem that it’s trying to grab stuff from AWS when it’s trying to serve it from ember. So that means even if it did connect, it wouldn’t update your changes as you made them. You have to ember-deploy to see the results of your changes, and that’s no good. So the problem is created with the fingerprint. And so we’ll go ahead and put this as enabled: false and restart our server, and then our app will work again.

So this is something we introduced in the previous screencast to get ember-deploy working, but we didn’t check to make sure it would work with our development workflow. So the trick is to make it depend on the environment. So go ahead and put this code in here, and then enabled is true if it’s a ProductionLikeBuild. And so we have our current build prod and deploy-dev. The reason I’m putting deploy-dev in here is because we don’t want regular development to have this enabled, but we do want our dev environment that we deployed to to be enabled. So we’ll change this to deploy-dev. This will get things working both served directly from Ember at 4200 and served from Rails at 3000.

So there you go. That is the fabled Lightning Strategy, deployed both in development and production, and not interfering with serving from your local Ember app. This is the end of our series on ember-cli-deploy, but if you feel that there are other resources about other subjects related to this that users should know, please put them in the comments so that people can see them. If there’s anything particularly noteworthy that I feel the series isn’t complete without, then I’ll put it in the description so everyone can find it. Alright, I’ll see you next week.


Subscribe to our mailing list