Three easy ways to deploy an Angular app for free
Using Github pages, Amazon S3 bucket, and Heroku
Making an AngularJS application can be a lot of fun and a great way to experiment with front-end frameworks. One downside is that you can’t see your project deployed on the web unless you are using a framework on the back-end / server-side such as Meteor, NodeJS, Rails, etc. or you are already paying for a server instance. Luckily for us, there are many ways to get around this and I’ll show you three super-easy ways to get your set of “static” (technically you are only hosting one index page thanks to SPA magic) pages out there on the web.
Option 1: Github Pages
There’s a chance you’ve already been checking your code to source control on Github. If so, there are only a couple more steps you have to follow to get your app deployed as a live web page using Github pages:
- First create a branch called exactly gh-pages in your current project repository. You can do so by typing git checkout -b gh-pages in your terminal or from their website.
- Then make sure your index.html file is at the top/root level of the directory and that it imports all your stylesheets and scripts from the right directories.
Optional: In addition to this (and something that I consider a downside) you will have to check any bower components you are using, so make sure you remove this folder from your .gitignore file for this branch. In case you do not want to do this, or if a library is too large for Github (50MB per file size limit), I recommend using a CDN.
If you have any issues getting this working you can check their short step-by-step guide here. In this case, we want a “Project site” and we are “Start[ing] from scratch.”
Note: The only file that Github uses to generate the page is your index page, so other files like a 404 won’t be used (instead, it’ll show a generic Github 404).
Pros:
- Easy to deploy once set up— just push your changes to your gh-pages branch when ready.
- Ability to customize domain name.
- It’s truly free and has a pretty decent uptime.
Cons:
- If you have a complex directory structure where you include folders for other things like testing and index isn’t in the top level, it can be a hassle to make builds compatible with gh-pages.
- Like any other static page content delivery, you can’t use preprocessors like SASS, CoffeeScript, etc.
- I believe they set cache headers on your content after the first load so, even if you push your changes, you may not see the latest version. You’ll have to implement your own solution to have control over this.
Option 2: Amazon S3 bucket
Ok, so this one is not exactly free, but you get a full one-year free trial for signing up. After that your payment is very minimal (something like $0.03 per GB of storage and $0.004 per 10,000 GET requests) so in case you expect high traffic, this may be a very viable option. To get your app running you must:
- Log into your AWS console > select S3 management > and create a new bucket that’ll hold your app.
- After that click on the properties tab, > and enable website hosting.
- Set index document to your main HTML file.
- Upload all the files used by your app, making sure you set the permissions to make everything public.
Pros:
- There is greater flexibility with your directory, and you have more control over your files.
- Like Github, you also the ability to customize domain name.
- Your app does not have to be open-sourced (although all client-facing files are public). Any files you do not want to share can be easily set private and Amazon will send a 403 error if there’s an attempt to access them.
- Your app has guaranteed 24/7 uptime (It is very rare when Amazon servers are down).
Cons:
- While it is very cheap, it not entirely free after the free year trial.
- No preprocessors either.
- You’ll probably have to learn a better way to push code changes to your bucket using Cyberduck or a direct SSH connection from a terminal window (not sure if this is possible, but it would be cool).
Help:
- Hosting a static website on Amazon S3
- Configuring a bucket for website hosting
- S3 Pricing (yes, you will need a debit/credit card even for the trial)
Option 3: Heroku
Another good option is to deploy to Heroku. By default, they don’t have buildpacks to host pure front-end apps (that I know of), so we’ll just add a minimal express/node server script to get it working. If you’re using Github already, then it is also extremely easy. For this, I will assume you know the basics about Heroku and that you already installed the Heroku toolbelt.
- Add Procfile, package.json, and server.js files (content below).
- Create a new Heroku app and add a new remote for your application by typing heroku create from the root level of your project in your terminal window.
- Deploy with heroku push origin master.
That’s it!
Pros:
- You can finally do the right thing and not upload all the bower components! Just have your bower.json file and make sure you run bower install in your package.json post-install.
- Like Github and S3, you also the ability to customize domain name.
- Super easy to deploy. Can easily be even with your master branch as you have control over the public assets directory including the index page.
- You can use pre-processors. Just make sure to configure your node dependencies and scripts appropriately.
Cons:
- Uptime is not guaranteed for free-tier. In fact, I think your app must sleep at least 6 hours each day. Also, your app is powered down after a period of inactivity and it takes about 30 seconds to start up a server instance (dyno) when someone visits the site.
- Well, we have the overhead of running a Node server when we really are just serving an Angular.js app. Node is lightweight compared to other frameworks (say Ruby on Rails), but it’s still an addition to the app load time.
Help:
Let me know if there’s anything that needs to be corrected. Happy hacking!