 Hello Angular fans, my name is Matt Rabel. Today I'd like to show you how to deploy an Angular application to Heroku, Firebase, Netlify, and S3. Let's get started. This screencast is based on a blog post that I wrote called Angular deployment with the site of Spring Boot. Angular and Spring Boot are two of the most popular combinations to use when deploying a modern web application. You'll often find that people deploy them as either separate artifacts or one specific artifact where the Angular app is inside of Spring Boot. Today I'm going to show you how to deploy them as separate artifacts. In the future I'll show you how to combine them in a single jar and deploy them using Docker. At the bottom of this blog post is a GitHub repo. There's a link to it right here. I have that open in this tab and within here I have a demo.adoc file. It's just a format that I like to use instead of Markdown. In this file I have a number of demo steps. These demo steps will show you how to deploy everything that we're doing today. I just condensed the blog post. If I click on the raw button I can view it in ASCII doctor. I have an ASCII doctor plugin that allows me to toggle on and off. You'll need Java 11, Node 12 Docker, and an Okta developer account to get started. The good news is Okta developer account we can actually create from Heroku so you don't need to create that right now. If I were to open up a terminal and put that on the right you can see I have Java 11, 12, and the latest version of Docker. I'm going to put these steps on the left here and then we'll make this a bit bigger. These are the steps we'll go through. We'll prepare an Angular and Spring Boot application for deployment. We'll deploy it to Heroku and then we'll deploy Angular and Heroku using Heroku's build packs and then we'll use Angular CLI's ngDeploy to deploy it to all the other providers. We're just going to use Spring Boot on Heroku for the back end for all the different providers and I'll show you how that works. We'll start by cloning the Angular Bootstrap example which is the previous tutorial I wrote before this one. Then we'll go into there and we can open it up in IntelliJ. The first thing you'll need to do is create a Heroku account. If you go to heroku.com, id.heroku.com, you can sign up for a new account or log into your existing one. I'm already logged in to mine so I'll create a new app. We'll call it bootable Angular and then make this a bit bigger. If we go to the resources tab we can add a new add-on called octa. This is a free add-on. It uses our developer plan which is free for life. You get a thousand monthly active users for free and we'll provision that. One thing you might want to be aware of is that to add Heroku add-ons you do have to have a credit card and Heroku system. It's a form of security verification. You can see over here we have this little free toggle going and now it's ready to go. If we were to click on settings and reveal the configuration variables you can see it's populated all of those. Back to our instructions. What I'm going to do is create an octa.env file in the notes API directory and copy the octa variables into it and paste that in there. If we go and grab those values we'll have the issuer here. With just those values we can actually start our service now. If we were to do cd into notes api source octa.env and run cradle w boot run. You'll see it starts right up and if we were to go to localhost we can use these values that we have in here to log in. So grab that one and we'll save that. Now prompt you for a security question. This is so you can do password recovery. So I can say what is your favorite security question. This one. Now you'll notice it comes back to this page and it gives a 400 error. Well that's kind of strange. You'll notice it's a 404. So if you actually go to an endpoint that exists then you'll get your data. So it's talking to an h2 database right now and everything seems to be working including octa for authentication. So now we'll need to configure our client but one thing I wanted to show you beforehand is that if you did want to run it directly from your IDE you can just modify the spring boot demo application and go to the environments and copy and paste these environment variables in here. Of course you'll need to remove the export here but now you can run it directly from your IDE so I can cancel this one and run it directly from here. And so in the Angular application the octa configuration is defined in auth routing module. So you see we have the issuer and the client ID here. So we'll grab that issuer to 605309 so change that one. And then you want to use the client ID for the spa so grab that value, put it right there and then we can run the Angular application. First of all we'll need to run npm install so do that from IntelliJ or you can do it from the command line. Now that everything is installed for the client we can go into that directory and run ng serve then if we were to open up localhost 4200 and click login and it gives us an error here so it's gone on. Looks like it's trying to go to an old one so let's go to application, clear site data hopefully you won't have to do this because I'm using different octa tenants so my last one is still stuck in there. Now if we go to login it all works and it comes back and you can view your notes so if we were to go to view notes create a new one and say first local note ee-haw that's saved in spring boot so if we were to go back to our spring boot process you can see that all working. So the next thing that I want to do is first of all commit everything to get go to terminal here go to the top little directory and commit everything so we have our octa OIDC configuration and the next thing is preparing spring boot and Angular for production so one of the first things that I like to do whenever I'm working on a new project or maybe updating an old one is update all its dependencies to the latest version this gets you security updates and other goodness so there's a couple plugins for Gradle you can use use latest versions plugin and the versions plugin to actually configure it to automatically update and not so much automatically but when you run a command it will update this will upgrade from spring 2.2 to 2.3 and that requires a new version of Gradle and so you do need to update Gradle before you do that using this command which is Gradle wrapper Gradle version at least 6.3 I'm going to do 6.5 since that's the latest one at the time of this writing or the time of the screencast distribution type equals bit and then we can run Gradle W use latest versions and you'll notice now we're using spring boot 2.3 for a look at the get difference you'll see we've got that new version of spring boot and we got a new version of octa spring boot starter as well and we'll enable auto reload on our Gradle script and now let's verify everything still works here so it's all up and running we can go to api notes verify that we didn't break anything that's still coming back and we're reauthenticated so everything's working now for Angular you can use npm check updates which is an npm package that just upgrades your dependencies so you can go ahead and install that and then if you were to run ncu it'll print out all the current versions and their upgrades so you can see there's a whole bunch mostly Angular 9.0 to 9.1 and a number of other things so you can use ncu-u to upgrade and this will upgrade TypeScript from 375 to 395 and Angular 9 only works with 383 so you do need to downgrade TypeScript after running that so if you go into your package.json scroll down to the bottom change it back to 3.8.3 and then you can run npm install so you'll see that resulted in 73 low severity vulnerabilities well I personally don't like any vulnerabilities so let's get rid of those with npm audit fix ok so you see it fixed 73 of 73 that's great let's run ng-serve and make sure we don't break anything and once that's completed log out and log back in to make sure this is all working create another new note another one so we didn't break anything that's great let's commit all those changes to get cd into the parent and update the dependencies to the latest version the next thing we'll need to do is configure production URLs and this means various things one it means that Angular shouldn't hardcode localhost 8080 as its api URL and Spring Boot shouldn't hardcode localhost 4200 as its allowed origins there's also database URLs in production you're not going to want to use h2 you're going to want to use something more robust like Postgres in demo application that's where hardcodes localhost 4200 and in our angular app it's auth interceptor and the note service so let's start with the demo application on the Spring Boot side of things you'll notice it has localhost 4200 right here so we're going to change it to use an allowed origins property this will be read from a properties file or an environment variable you'll need to import that value annotation and then down here we'll change this localhost 4200 to use that property and then in application.properties specify allowed origins equals htp localhost 4200 and make sure and don't use htps I just did that out of habit so that's good it's good habits htps and then in the angular app there's environments so there they have the concept of environments built in this will be your development environment this will be your production one and the difference is when you run ng build dash dash prod it uses production when you're just doing regular ng serve it uses development so we're going to add an api url and we'll set that to localhost and then for production let's grab that we'll use what we specified for Heroku which is that beautiful now we'll change the auth interceptor which is under app shared octa auth interceptor change this to use environment and you'll need to import environment get it spelled right there we are and then in the note service as well which is under note service so we'll start with that first one environment right here and import and then down in the user notes we need to use it there as well so we fixed all the urls we're no longer hard coding localhost and we can edit build.gradle next to basically switch between h2 and postgres so under this change this runtime only for h2 to look for a prod property being passed in and then we can add profile information so if the project has that prod passed in then use prod profile else dev and so when you're running boot run we can say hey the profile that's activated for spring is either prod or dev and then when it processes a resource when it creates the jar we want to take that dev or prod and make that application.properties and that'll be the default another way to do it is actually keep them both in there and always have to specify the profile but I like to make it so you don't have to specify the profile many with different ways to do it and so now in application.properties we can rename that to application-dev and we'll keep that allowed origins and we'll add a data source URL and all this does is set it so h2 uses a file based system instead of in memory and so if you do restart the app it actually keeps the data if you refresh or delete all the files if you run gradle clean then your data will be gone of course and then one thing we can do to test postgres is use docker compose so if you go to source main docker here called docker postgresql and we'll go ahead and add it to get paste that in there and that uses postgres12 and then we'll have this application prod that uses postgres by default you'll see that still allows 4200 uses auto update so it creates a schema and uses that data source URL for postgres one thing that happens when you do this is user is a keyword in postgres so if I tried to start it right now it actually wouldn't work we have to go and change from using user to username so I'll do that in my entity first and that changes everything all the way from there for instance all my jpa queries need to change find all by username now instead of user so that's in the rest repository and then for setting a username on a new note and then in data initializer to make a similar change there and then in our user controller find all by username so that's all you need to do to change from user to username and then for the data initializer let's make it so this only initializes in development and now we can test these profiles using docker compose so we can go into the notes api directory docker compose source main docker that starts it up it's ready to accept connections and go ahead source octa-dev first I'm going to kill 8080 just in case something's running there so source octa-m wrong directory and run gradle boot run dash pprot so now we're connected to postgres to prove that and go ahead and refresh our notes oh that's not running and you serve so you can see that worked if we look back at our run not that one in our terminal here you can see it entered it in so that's working we're talking to postgres and we have those different profiles configured so now we'll commit that code to git git commit alright now let's deploy spring boot to heroku so you'll need the heroku cli to get started so heroku login if you don't have it just go to this dev center articles heroku cli there and we'll start by mentioning that usually heroku has you have one application and one github repo but they do have a mono repo buildpacks plugin that allows you to specify that hey this directory goes to this app this directory goes to this app so that's what I'm going to be using so we'll start by opening a browser to log into heroku so we'll start by specifying the app name and configuring this app to use that existing bootiful angular one we created so I'm just going to do an export app name equals bootiful angular and then I'm going to say heroku git remote is that app name so now if you see we have the origin right that's the one we cloned from and then heroku has a bootiful angular one as well we can run these commands first of all set the app base to be that notes api directory and then we'll add the mono repo build pack as well as heroku's gradle build pack and then we'll add postgres as an add on and then by default gradle build pack uses gradle build and doesn't run the tests but we wanted to use gradle w bootjar and pass in prod so we can set the gradle task variable to be bootjar dash prod there's variables that octa created if we look at heroku config edit we can see all those variables and by default the octa spring boot starter expects a client ID a client secret and an issuer and you'll notice these variables have a web on the end so I'm just going to modify those and this will allow to override what spring boot starter will look like and then we'll do control x and yes and I'll update that configuration and then we're ready to deploy so we can run git push heroku master so now you can run heroku open or you can just click on those links and open them in your browser so we're actually logged in at this point if we were to expand this out a little and go to api notes you can see that there are no notes but we are logged in otherwise just octa and so if we go back to here this is a 404 because we have nothing to find at the root so let's fix that let's create a root home controller and so you might have noticed I just typed a couple characters and boom it spits out all this code those are intelligent live templates and if you were to scroll up to the top here I have a link to the ones that I use so these are all in github and you can import my live templates into your project and create a similar download to mine so we've created that home controller and now we can commit that and then git push heroku to the main branch so now that's completed let's see if that worked so that's taking a little while to load let's look at the logs heroku logs tail and you'll see right as I did that it starts up so that's how you can see the logs going it did take a little while I've noticed if you just do a brand new start it takes like 10 seconds but a restart can take a little while there so now it says hello to the full name from the user so that's all working we have spring boot running on heroku now let's work on angular we'll start by creating a new application for angular so heroku create clear out our terminal here heroku apps so this afternoon woodland 21849 we'll set that as a app name okay and then we'll go ahead and configure the base to be notes for that and then the mono repo and we'll add node js as the two build packs and then we'll need something to run the actual angular app so we can use http server spa for that so in package.json we can change this start script uses http server spa and then there's a special heroku post build script we can use to do the angular build ng build dash dash prod and install http server spa so we'll go ahead and commit that code and then we'll add the new git remote we'll call angular and then git push angular master when that completes you can run heroku open specify that angular is the remote if we're to try to log in here you'll get a 400 error and this is a common error that developers see and I don't blame them for being confused because it says the redirect uri parameter must be an absolute uri but it doesn't really tell you what the uri parameter is but if you look in the url way up here it actually has it so the redirect uri is that afternoon woodland slash callback so if we were to go back to our app just to get that url to the spa that heroku creates so if we were to log in via that resources octa tab we can go to applications and then to the spa app and click on general and edit and then add that uri as a allowed origin now if we're to go back to notes here try again now we're in and if we wanted to view our notes we could say hey first heroku yes there's an error there and if we were to look at our console we'll see that the page at afternoon woodlands was loaded over HTTPS but it tried to make a request to bootflying which is on HTTP so I messed that up but if I went into environment prods this should be HTTPS so if I change that and redeploy that'll work but at the same time I also need to modify the back end to allow this new origin alright so run this command and you can see now that's an allowed origin on the back end and now you should be able to add a note if I redeployed that production one but what I wanted to do before that is to make the security headers better so if we were to go to securityheaders.com and take this url here and put that in there you'll see we get an F there's no good security headers that our Angular app is outputting there's no content security policy there's no X-Frame options or anything like that so let's fix that and the way you can fix it is using Heroku's static build packs they allow you to define a static.json like this one that has a content security policy, a refer policy all those headers it's looking for as well as turn it so it's HTTPS only because what happens right now is if you go to HTTP it'll still work but you'll notice again it doesn't work that's because it's using pixie and auth code flow in the browser pixie stands for public key code exchange and that basically creates a one time code that's used by a browser to authenticate with octa so we want to make sure it forces HTTPS and that's what this file will allow us to do it also configures a spa right so it routes everything to index.html so we'll go ahead and create that in the notes directory Heroku's static.json and then for it to be ready I have to use this Heroku's static build pack and because we're using Heroku's static build pack it'll actually use our scripts instead of us having to write anything specific like we did with our ng start so we want to change this build to use ng build because that's the command it's going to call so we'll go into package.json we'll revert these changes and then commit our changes to git add the static build pack and push it one more time so now that that's finished let's see if our security headers have improved they have we're up to an A and then if we were to go and try to use the app we can view the notes let's make sure there's no errors in our console and we can say first note on Heroku this time it worked alright so that's sweet the next step I want to do is showing you how to deploy everything with Angular to a number of different providers Firebase, Amazon S3 as well as Netlify and we'll use Angular CLI's ng deploy command for that but one thing I forgot to do is in my spring boot app I never changed the spring jpa hibernate ddl auto what happens right now is if you restart the spring boot app it'll recreate the schema and lose all that data so let's go ahead and set that and I'll just make sure it's not set so Heroku config remote is Heroku you'll see it's not specified there so set that spring jpa hibernate ddl auto and now when it restarts it actually won't recreate the schema so that's something that's nice when you first deploy it creates a schema and then you set that property and it won't recreate the schema so I'm going to start by creating a Firebase branch let's make sure we have no changes in here so get check out the Firebase and then we'll go to firebase.google.com and I want to log in with my gmail account and go to the console and we'll create a project and I'll call it ng notes and no Google Analytics okay so that finished and you will need to have the Firebase CLI installed I already have that installed and configured for my account now you can install the ng deploy package for Firebase that's Angular Fire so ng add Angular Fire you have to be in the notes project or in an Angular project to do that and as long as you're logged in locally in your terminal with the same account that you are through your browser your new project will show up right here and then I'll create that Firebase JSON Firebase RC and update your Angular JSON and then you can run ng deploy and unlike Heroku this isn't based on git so you don't have to commit anything it just takes what's in your actual directory right now once your app is available on Firebase you'll need to make it so your spring boot app will log it in so grab that URL make sure we got it and we can go that's not quite as good as I want I don't want it to have the line break in there so let's go ahead there we go grab that tighten everything back up here and then we can go to Heroku config edit and the remote is Heroku that's where spring boot app is running and we'll need to modify the allowed origins so that's been updated it'll restart our app and then we also need to modify the spa app on octa right to have that URL so if we were to expand this bit and go to edit call it back if we were to open it up click on login you can see it's working for viewing the notes and if we were to click on the notes we should see that one from Heroku come up there we are so that's all working let's check it with securityheaders.com ooh a D not so good but you'll notice it does have the strict transport security header so the beauty of that is if I try to go to HTTP it redirects me to HTTPS so at least that header is present by default so we can configure our security headers in firebase.json so we'll go ahead and always add new files to get there and then we can add a new key called headers I have a headers firebase shortcut for that you'll see it creates a content security policy it allows connection to octa and Heroku app so if you need to do connection to another end point you'll want to go ahead and add it there and then just the rest of the security headers like we did for Heroku and now we can do engine deploy we'll get an issue in our package.json so if we mess that up there run engine deploy again let's try it again security headers now we got an A alright so let's commit those changes and you'll notice it did add this dot firebase hosting cache so I don't know if you need to check that into source control but if you want to make sure it knows what you deployed last time I suppose you could. The next thing is deploying to Netlify so we'll go ahead and check out the main directory the main branch and create a new one for Netlify and before running the command to add Netlify support you need a Netlify account and I just login with github and you'll see I already have an account so you might have to do a little setup there but once you have that it expects you to be connected to git and we want to use engine deploy rather than connecting to git but obviously git is a good choice because it's very easy for CINCD but I just want to show engine deploy so the easiest way is to create a temporary directory put an index.html file in it and then deploy that so I already have one of those on my desktop if you go into the tmp directory here index.html it just says hello world so I'll go ahead and drag and drop that here and boom it's deployed right that's pretty quick that's one of the beauties of Netlify so now we'll need to get an API ID and an access token for the engine deploy plugin for Netlify the first thing is our site settings has that app ID so right here we'll just create a new scratchpad we need to create a new access token so that's under user settings applications new access token we'll just call it angular grab that and then back to our instructions we'll go ahead and run ng add Netlify builder deploy make sure we're in that nodes directory and it'll basically prompt us for these two values our app ID and our access token so grab the app ID paste it in there I don't know if that worked the way you can tell if it worked is if you go into angular.json it actually writes those values into the file so you'll notice it didn't work it didn't put those in there so my copy and paste skills aren't working so well so we can just manually do that hopefully your copy and paste skills are better than mine and it works when you do it and now we can go ahead and run ng deploy now if we open up our application on Netlify we won't be able to log in because we need to add this to our octa application go ahead and edit add that as a log out as well and then we'll need to add it to our spring boot app so Heroku config edit remote is Heroku now we should be able to log in you'll notice what happened here is it actually came back to our app and gives us page not found there well that's because Netlify isn't configured to know it's a spot app right now so we have to configure it so it knows that any request should go to index.html so to do that you'll create a redirect file so under the source directory go ahead and name it redirects and then all that you'll have is this one line that says all requests should go to index.html and then you'll need to modify angular.json to actually include that file so under the assets here we can add source redirects and then we'll run ng deploy again now if you were to try again try from the very beginning hmm ah so I figured out the problem it's listed under test not the actual deployment so should be under build not test so fix it in angular.json and then do ng deploy again now if we try again this time it'll work and we're logged in and if we click on view notes we should see the one from Heroku show up and we can add a new one that says new nope so let's check our security headers score yikes a D but we have that strict transport security again so it will handle the HTTP to HTTPS to fix security headers you can create a headers file next to that redirects file so new file of headers and you'll see it's got all those similar content security policies all the rest of the security headers but we also need to add one for Heroku app.com and then we can do modify the angular.json to include that headers and run ng deploy now let's test our security headers again we got an A alright so now let's commit all that to source control now I should warn you that this does check in these values right for Netlify and these are not something that you want to put in a public source control setting even maybe a private one this is like a problem with using ng deploy in Netlify in fact when I first did this when I checked it into GitHub I got warnings, emails that said hey you checked in a Netlify API token but I like to do is go and delete it after I've demoed it so we'll go to Netlify.com and log in and we'll go here to user settings and applications and delete that personal access token and so that way even if it does get into source control no one can really use it maliciously the last platform I'll show you how to deploy to is Amazon's S3 so let's start by checking out master again then we'll create a new branch called AWS and before running the commands to deploy to S3 you'll need to create an S3 bucket and have an AWS region name get a secret access key and an access key ID so you'll need an AWS account I already have one so if I log into it and go to the S3 console I can create a new bucket I'll just call it ngnotes and I'll just accept all the defaults and then to create a secret access key you can go to the security credentials page this is for the IAM and click on access keys and create new access key and then we'll grab the values from this and we'll go back to our scratch file here put them in there and then you'll add this schematic and what Amazon allows you to do is actually define all of these as environment variables so I'm going to go ahead and do that let's do export access key ID equals this I did not work to copy out of my scratch file we'll just use non-environment variables so add this sucker here ng add and ideally use environment variables because then it doesn't get stuck in your Angular.json but this is just a demo so I'm fine with it getting stuck and then I'll go ahead and delete those access keys from AWS once I'm done with this I believe we did US West One let's double check here US West One, Oregon and then the bucket name is ng notes and our secret access key is this make sure we can paste it somewhere else okay then get in there oh, we'll try the access key ID and then just use the default so put it on AngularJson and if I go into AngularJson at the bottom it's got those missing values again so I'll paste them in there, access key ID and now we can run ng deploy and once it's finished uploading your files you'll need to enable static website hosting so you can go here go to properties static web hosting and we'll use this bucket to host a website you're going to need this URL grab that for later and we'll specify an index document index.html and eras index.html as well so that will handle it being a spa and we can save it and then we'll also need to change the permissions so we're not blocking all public access so under permissions edit and when you're creating it you could have done this as well I just wanted to accept all the defaults and then you'll also need a bucket policy or whatever your bucket name is alright so now we should be able to go to this URL and it'll render our site but it's HTTP not HTTPS so if we were to try and even click on login it wouldn't allow us to right so to use HTTPS with S3 what I found is the best solution is cloud front so you can open up a cloud front console here and we'll go ahead and create a distribution a web distribution and if you click here it'll bring up your S3 bucket so click in the origin domain name bring up your S3 bucket viewer protocol policy redirect HTTP to HTTPS and then you'll also need to set the default root object at the bottom here to index.html and then scroll down and click create distribution and so this can take some time to run I've even seen it take up to 20 minutes to deploy so what you'll want to do is expand the browser so you can see the status refresh because that table tries to be responsive and you'll see it's in progress so when that changes from in progress to not in progress then it should be available at this domain name here so that domain name is cloudfront.net so we can start adding this to our various Okta and Heroku configurations so we'll go into Okta here and you do have to add HTTPS and callback and we'll update spring boot as well let's grab that full URL HTTPS and then edit so you can see that it's finished deploying we can grab that URL try it out and now if we click login it looks like it does a different URL than the one so you notice how it redirected me to ngnotes so after waiting for 20 minutes and still having that redirect problem I figured out what I needed to change the distribution settings point to that S3 bucket but it should really point to the URL rather than the bucket so I'm going to go ahead and just create a new one so create a new distribution get started and then instead of selecting that S3 bucket we actually want the URL and you'll put that in there not the actual S3 bucket and then the redirect HTTPS and the index.html and then close the default root object and create a distribution so we want to delete our old one and then for the new one that's the URL we'll want to add everywhere so we just have that value there and go to octa change that and then now we'll wait 5-10 minutes whatever it takes for that new distribution to deploy that's finished deploying let's try it woohoo it works now we should be able to log in and lucky there talking to heroku yep we can even create a new one aws note it works so if we were to take this and try security headers we get an F so this is something that is a little more difficult to configure on aws than it is on netlify or firebase you have to actually use a lambda console and create a lambda function that adds the security headers after the response processes so we'll go to the lambda console here the one thing that I've noticed is you do need to specify a specific region so us east 1n so us east and then it looks like I have one here so let's delete that and create a new one and name it security headers click create under permissions from aws policy templates enter a name so we'll call this security headers role and we'll do basic a lambda edge permissions for cloud front trigger and click create function and then in the function code section right here we'll need to change that index.js to have this code in it and that sets all the content security policy headers and then save it select cloud front as a trigger and deploy to lambda edge and so that's our distribution and then origin response and I acknowledge and deploy and if we go back to our cloud front console it's in progress or not that one's in progress we should see that va1 is in progress so yeah I chose the wrong distribution because I had that other one in there so once that completes then we should get better security headers let's try scanning for security headers again hmm and deploy hmm still got the last function in there because I wasn't able to delete it well maybe it works now no such luck alright well it worked the first time I did it so I'm just going to go ahead and say that aws and lambda edge is much harder to add security headers than with netlify and heroku and the others but you know this should work I'm sure if you choose a proper distribution the first time unlike I did then you'll have much better success so you can commit you know your code nothing really as far as the headers was configured in the code so not a big deal we can just say commit the aws3 deployment and then you'll want to go ahead and delete your access key and delete that one because in case you check that angular json into source control you don't want that to be exposed so thank you for watching this video and if you want to check out the blog post that's angular deployment at the site of spring boot and the github repo is at octa developer octa angular deployment example so I hope you enjoyed this if you like this video you can follow my team on twitter at octa dev you can follow me on twitter at mrable and we publish videos like this one to our octa dev youtube channel chances are you're watching it right now on there so make sure and subscribe and have a great day