Integrating FastBoot into an IIS shop?


I have a set of Ember client apps that will sit in directories served by IIS. Each one will be deployed as a website in IIS terms, although deployment of new versions is fundamentally no more than a file copy. I have a Web.config that will allow me to rewrite our /api requests to go to our API server. If Fastboot is running, it should be able to do a redirect to Fastboot as well to deliver our index.html as well.

What is the best way to integrate FastBoot into this environment?

  • Do we run a single FastBoot server running under Node providing pages for all the apps? Or do we run one per website - (one extra process per app)?

  • Can we tie initiation and shutdown of those processes with the lifecycle of the IIS website, so the admins remotely controlling the site through IIS don’t have to do anything special?

  • Is the code in our dist area sufficient to invoke directly from node to run the fastboot-app-server? Or does fastboot-app-server have to be installed separately in its own area? (What localhost:4200 does behind the scenes is kind of a black box to me. I’m really happy it works for development.)

I want to get a protoype scenario running so I can schedule a meeting with our ops guys to figure out what is feasible on our site.

Beyond this, I haven’t even scratched the surface of what this means in the context of Akamai and Alteon fronting our site. That’s a whole other kettle of fish, but I could use advice on that, too, so I can at least talk intelligently with our ops guys.



Hoping that by chronicling my journey here, I may get helpful hints along the way, here’s where I’ve gotten so far.

The first step was relatively easy. I made a directory, cut/pasted the server.js from the fastboot-app-server github site, and made a minimal package.json that listed fastboot-app-server as a dependency. A quick trip through yarn, editing the server.js to point it at my iis-dist area (which is both a subdirectory of my project, parallel to dist, and a virtual directory under IIS), node server.js and up she comes on http://localhost:4000. Grand!

Looking at the results in the browser, I can see that the page is there but it is having trouble finding most of my assets - like CSS. It’s there, but ugly. The CSS files and images don’t worry me much, because the URLs will work fine when coming through IIS, but the config files do, as I want their contents in my shoebox. The sole objective of FastBoot is delivering that ready-to-rock index.html file. Hmmm…

The difficulty stems from rootURL. My application is on an IIS site with ARR rewrites upstream. This means that URLs from the browser of the form:


end up getting sent to


When loading the site from the browser, supplying a rootURL of /toolsprefix and including {locale}/{toolname} in the route so the client can use the locale, everything comes up fine.

However, running in localhost:4000 in the browser, FastBoot, which has picked up the rootUrl from the build, can’t seem to find any of the collateral files on /toolsprefix/{locale}/{toolname}. It wants them on /{locale}/{toolname}. I tweak the ‘rootUrl’ in the package.json in the iis-dist to /, and everything comes up fine. However, this is not a sustainable solution.

Next problem: I add an ARR rule on the IIS server to rewrite incoming requests for /myprefix/{locale}/{toolname} to the FastBoot server on port 4000. (I’m already using a rewrite for other resources to strip off the /myprefix.) After a little tinkering with the rule, I now am able to navigate to http://myserver/myprefix/{locale}/{toolname}. I can see FastBoot doing its work to deliver the index.html page and reporting it successfully read the configs, I can verify that the FastBoot page shows up in the browser with shoebox intact, and everything comes up, working beautifully.

Not bad for an early afternoon. Remaining interesting problems:

  • Setting up access during the build so that FastBoot can find everything it needs to create the index.html with the config resources in the shoebox, but direct access to all assets from the browser via IIS still works fine.

  • IIS will need a module that starts “node server.js” when the web app is started and stops it when the web app is stopped remotely from the IIS management console. I could perhaps try to use IISNode, but it seems like it will try to do things that fastboot-app-server is already doing, like making more servers.

Any insight on either of these will be appreciated.

When I get all this working and present it to folks on the ops team, :slight_smile: there will inevitably be a whole slew of things to work out with the production infrastructure, CDN, caching, load balancing, etc., etc. But that’s fine. I’ll have something functioning that we can make better.