{ "id": "guide/deployment", "title": "Deployment", "contents": "\n\n\n
When you are ready to deploy your Angular application to a remote server, you have various options for deployment.
\n\n\nBefore fully deploying your application, you can test the process, build configuration, and deployed behavior by using one of these interim techniques.
\nDuring development, you typically use the ng serve
command to build, watch, and serve the application from local memory, using webpack-dev-server.\nWhen you are ready to deploy, however, you must use the ng build
command to build the app and deploy the build artifacts elsewhere.
Both ng build
and ng serve
clear the output folder before they build the project, but only the ng build
command writes the generated build artifacts to the output folder.
The output folder is dist/project-name/
by default.\nTo output to a different folder, change the outputPath
in angular.json
.
As you near the end of the development process, serving the contents of your output folder from a local web server can give you a better idea of how your application will behave when it is deployed to a remote server.\nYou will need two terminals to get the live-reload experience.
\nOn the first terminal, run the ng build
command in watch mode to compile the application to the dist
folder.
Like the ng serve
command, this regenerates output files when source files change.
On the second terminal, install a web server (such as lite-server), and run it against the output folder. For example:
\nThe server will automatically reload your browser when new files are output.
\nThis method is for development and testing only, and is not a supported or secure way of deploying an application.
\nThe Angular CLI command ng deploy
(introduced in version 8.3.0) executes the deploy
CLI builder associated with your project. A number of third-party builders implement deployment capabilities to different platforms. You can add any of them to your project by running ng add [package name]
.
When you add a package with deployment capability, it'll automatically update your workspace configuration (angular.json
file) with a deploy
section for the selected project. You can then use the ng deploy
command to deploy that project.
For example, the following command automatically deploys a project to Firebase.
\nThe command is interactive. In this case, you must have or create a Firebase account, and authenticate using that account. The command prompts you to select a Firebase project for deployment
\nThe command builds your application and uploads the production assets to Firebase.
\nIn the table below, you can find a list of packages which implement deployment functionality to different platforms. The deploy
command for each package may require different command line options. You can read more by following the links associated with the package names below:
Deployment to | \nPackage | \n
---|---|
Firebase hosting | \n@angular/fire | \n
Azure | \n@azure/ng-deploy | \n
Now | \n@zeit/ng-deploy | \n
Netlify | \n@netlify-builder/deploy | \n
GitHub pages | \nangular-cli-ghpages | \n
NPM | \nngx-deploy-npm | \n
Amazon Cloud S3 | \n@jefiozie/ngx-aws-deploy | \n
If you're deploying to a self-managed server or there's no builder for your favorite cloud platform, you can either create a builder that allows you to use the ng deploy
command, or read through this guide to learn how to manually deploy your app.
For the simplest deployment, create a production build and copy the output directory to a web server.
\nStart with the production build:
\nCopy everything within the output folder (dist/project-name/
by default) to a folder on the server.
Configure the server to redirect requests for missing files to index.html
.\nLearn more about server-side redirects below.
This is the simplest production-ready deployment of your application.
\n\nTo deploy your Angular application to GitHub Pages, complete the following steps:
\nCreate a GitHub repository for your project.
\nConfigure git
in your local project by adding a remote that specifies the GitHub repo you created in previous step.\nGitHub provides these commands when you create the repo so that you can copy and paste them at your command prompt.\nThe commands should be similar to the following, though GitHub fills in your project-specific settings for you:
When you paste these commands from GitHub, they run automatically.
\nCreate and check out a git
branch named gh-pages
.
Build your project using the Github project name, with the Angular CLI command ng build
and the following options, where your_project_name
is the name of the project that you gave the GitHub repository in step 1.
Be sure to include the slashes on either side of your project name as in /your_project_name/
.
When the build is complete, make a copy of docs/index.html
and name it docs/404.html
.
Commit your changes and push.
\nOn the GitHub project page, go to Settings and scroll down to the GitHub Pages section to configure the site to publish from the docs folder.
\nClick Save.
\nClick on the GitHub Pages link at the top of the GitHub Pages section to see your deployed application.\nThe format of the link is https://<user_name>.github.io/<project_name>/
.
Check out angular-cli-ghpages, a full featured package that does all this for you and has extra functionality.
\nThis section covers changes you may have to make to the server or to files deployed on the server.
\n\nindex.html
linkAngular apps are perfect candidates for serving with a simple static HTML server.\nYou don't need a server-side engine to dynamically compose application pages because\nAngular does that on the client-side.
\nIf the app uses the Angular router, you must configure the server\nto return the application's host page (index.html
) when asked for a file that it does not have.
A routed application should support \"deep links\".\nA deep link is a URL that specifies a path to a component inside the app.\nFor example, http://www.mysite.com/heroes/42
is a deep link to the hero detail page\nthat displays the hero with id: 42
.
There is no issue when the user navigates to that URL from within a running client.\nThe Angular router interprets the URL and routes to that page and hero.
\nBut clicking a link in an email, entering it in the browser address bar,\nor merely refreshing the browser while on the hero detail page —\nall of these actions are handled by the browser itself, outside the running application.\nThe browser makes a direct request to the server for that URL, bypassing the router.
\nA static server routinely returns index.html
when it receives a request for http://www.mysite.com/
.\nBut it rejects http://www.mysite.com/heroes/42
and returns a 404 - Not Found
error unless it is\nconfigured to return index.html
instead.
There is no single configuration that works for every server.\nThe following sections describe configurations for some of the most popular servers.\nThe list is by no means exhaustive, but should provide you with a good starting point.
\nApache: add a\nrewrite rule to the .htaccess
file as shown\n(https://ngmilk.rocks/2015/03/09/angularjs-html5-mode-or-pretty-urls-on-apache-using-htaccess/):
Nginx: use try_files
, as described in\nFront Controller Pattern Web Apps,\nmodified to serve index.html
:
Ruby: create a Ruby server using (sinatra) with a basic Ruby file that configures the server server.rb
:
IIS: add a rewrite rule to web.config
, similar to the one shown\nhere:
index.html
into 404.html
.\nIt will still be served as the 404 response, but the browser will process that page and load the app properly.\nIt's also a good idea to\nserve from docs/
on master\nand to\ncreate a .nojekyll
fileFirebase hosting: add a\nrewrite rule.
\nAngular developers may encounter a\n\ncross-origin resource sharing error when making a service request (typically a data service request)\nto a server other than the application's own host server.\nBrowsers forbid such requests unless the server permits them explicitly.
\nThere isn't anything the client application can do about these errors.\nThe server must be configured to accept the application's requests.\nRead about how to enable CORS for specific servers at\nenable-cors.org.
\n\nThe production
configuration engages the following build optimization features.
See ng build
for more about CLI build options and what they do.
In addition to build optimizations, Angular also has a runtime production mode. Angular apps run in development mode by default, as you can see by the following message on the browser console:
\nProduction mode improves application performance by disabling development-only safety\nchecks and debugging utilities, such as the expression-changed-after-checked detection.\nBuilding your application with the production configuration automatically enables Angular's\nruntime production mode.
\n\nYou can dramatically reduce launch time by only loading the application modules that\nabsolutely must be present when the app starts.
\nConfigure the Angular Router to defer loading of all other modules (and their associated code), either by\nwaiting until the app has launched\nor by lazy loading\nthem on demand.
\nIf you mean to lazy-load a module, be careful not to import it\nin a file that's eagerly loaded when the app starts (such as the root AppModule
).\nIf you do that, the module will be loaded immediately.
The bundling configuration must take lazy loading into consideration.\nBecause lazy-loaded modules aren't imported in JavaScript, bundlers exclude them by default.\nBundlers don't know about the router configuration and can't create separate bundles for lazy-loaded modules.\nYou would have to create these bundles manually.
\nThe CLI runs the\nAngular Ahead-of-Time Webpack Plugin\nwhich automatically recognizes lazy-loaded NgModules
and creates separate bundles for them.
You can make better decisions about what to optimize and how when you have a clear and accurate understanding of\nwhat's making the application slow.\nThe cause may not be what you think it is.\nYou can waste a lot of time and money optimizing something that has no tangible benefit or even makes the app slower.\nYou should measure the app's actual behavior when running in the environments that are important to you.
\nThe\n\nChrome DevTools Network Performance page is a good place to start learning about measuring performance.
\nThe WebPageTest tool is another good choice\nthat can also help verify that your deployment was successful.
\n\nThe source-map-explorer\ntool is a great way to inspect the generated JavaScript bundles after a production build.
\nInstall source-map-explorer
:
Build your app for production including the source maps
\nList the generated bundles in the dist/project-name/
folder.
Run the explorer to generate a graphical representation of one of the bundles.\nThe following example displays the graph for the main bundle.
\nThe source-map-explorer
analyzes the source map generated with the bundle and draws a map of all dependencies,\nshowing exactly which classes are included in the bundle.
Here's the output for the main bundle of an example app called cli-quickstart
.
base
taglinkThe HTML <base href=\"...\"/>\nspecifies a base path for resolving relative URLs to assets such as images, scripts, and style sheets.\nFor example, given the <base href=\"/my/app/\">
, the browser resolves a URL such as some/place/foo.jpg
\ninto a server request for my/app/some/place/foo.jpg
.\nDuring navigation, the Angular router uses the base href as the base path to component, template, and module files.
See also the APP_BASE_HREF alternative.
\nIn development, you typically start the server in the folder that holds index.html
.\nThat's the root folder and you'd add <base href=\"/\">
near the top of index.html
because /
is the root of the app.
But on the shared or production server, you might serve the app from a subfolder.\nFor example, when the URL to load the app is something like http://www.mysite.com/my/app/
,\nthe subfolder is my/app/
and you should add <base href=\"/my/app/\">
to the server version of the index.html
.
When the base
tag is mis-configured, the app fails to load and the browser console displays 404 - Not Found
errors\nfor the missing files. Look at where it tried to find those files and adjust the base tag appropriately.
When building web applications, you want to make sure your application is compatible with the majority of browsers.\nEven as JavaScript continues to evolve, with new features being introduced, not all browsers are updated with support for these new features at the same pace.
\nThe code you write in development using TypeScript is compiled and bundled into ES2015, the JavaScript syntax that is compatible with most browsers.\nAll modern browsers support ES2015 and beyond, but in most cases, you still have to account for users accessing your application from a browser that doesn't.\nWhen targeting older browsers, polyfills can bridge the gap by providing functionality that doesn't exist in the older versions of JavaScript supported by those browsers.
\nTo maximize compatibility, you could ship a single bundle that includes all your compiled code, plus any polyfills that may be needed.\nUsers with modern browsers, however, shouldn't have to pay the price of increased bundle size that comes with polyfills they don't need.\nDifferential loading, which is supported in Angular CLI version 8 and higher, can help solve this problem.
\nDifferential loading is a strategy that allows your web application to support multiple browsers, but only load the necessary code that the browser needs. When differential loading is enabled the CLI builds two separate bundles as part of your deployed application.
\nThe first bundle contains modern ES2015 syntax. This bundle takes advantage of built-in support in modern browsers, ships fewer polyfills, and results in a smaller bundle size.
\nThe second bundle contains code in the old ES5 syntax, along with all necessary polyfills. This second bundle is larger, but supports older browsers.
\nWhen you deploy using the Angular CLI build process, you can choose how and when to support differential loading.\nThe ng build
CLI command queries the browser configuration and the configured build target to determine if support for legacy browsers is required, and whether the build should produce the necessary bundles used for differential loading.
The following configurations determine your requirements.
\nBrowserslist
\nThe Browserslist configuration file is included in your application project structure and provides the minimum browsers your application supports. See the Browserslist spec for complete configuration options.
\nTypeScript configuration
\n In the TypeScript configuration file, the \"target\" option in the compilerOptions
section determines the ECMAScript target version that the code is compiled to.\nModern browsers support ES2015 natively, while ES5 is more commonly used to support legacy browsers.
Differential loading is currently only supported when using es2015
as a compilation target. When used with targets higher than es2015
, the build process emits a warning.
For a development build, the output produced by ng build
is simpler and easier to debug, allowing you to rely less on sourcemaps of compiled code.
For a production build, your configuration determines which bundles are created for deployment of your application.\nWhen needed, the index.html
file is also modified during the build process to include script tags that enable differential loading, as shown in the following example.
Each script tag has a type=\"module\"
or nomodule
attribute. Browsers with native support for ES modules only load the scripts with the module
type attribute and ignore scripts with the nomodule
attribute. Legacy browsers only load the scripts with the nomodule
attribute, and ignore the script tags with the module
type that load ES modules.
Some legacy browsers still download both bundles, but only execute the appropriate scripts based on the attributes mentioned above. You can read more on the issue here.
\nTo include differential loading in your application builds, you must configure the Browserslist and TypeScript configuration files in your application project.
\nThe following examples show a .browserslistrc
and tsconfig.json
file for a newly created Angular application. In this configuration, legacy browsers such as IE 9-11 are ignored, and the compilation target is ES2015.
To see which browsers are supported and determine which settings meet to your browser support requirements, see the Browserslist compatibility page.
\nThe Browserslist configuration allows you to ignore browsers without ES2015 support. In this case, a single build is produced.
\nIf your Browserslist configuration includes support for any legacy browsers, the build target in the TypeScript configuration determines whether the build will support differential loading.
\n\nBrowserslist | \nES target | \nBuild result | \n
---|---|---|
ES5 support disabled | \nes2015 | \nSingle build, ES5 not required | \n
ES5 support enabled | \nes5 | \nSingle build w/conditional polyfills for ES5 only | \n
ES5 support enabled | \nes2015 | \nDifferential loading (two builds w/conditional polyfills) | \n
Differential loading is not enabled by default for application projects that were generated with Angular CLI 10 and above.\nThe ng serve
, ng test
, and ng e2e
commands, however, generate a single ES2015 build which cannot run in older browsers that don't support the modules, such as IE 11.
To maintain the benefits of differential loading, however, a better option is to define multiple configurations for ng serve
, ng e2e
, and ng test
.
To do this for ng serve
, create a new file, tsconfig-es5.app.json
next to tsconfig.app.json
with the following content.
In angular.json
add two new configuration sections under the build
and serve
targets to point to the new TypeScript configuration.
You can then run the ng serve
command with this configuration. Make sure to replace <app-name>
(in \"<app-name>:build:es5\"
) with the actual name of the app, as it appears under projects
in angular.json
. For example, if your app name is myAngularApp
the config will become \"browserTarget\": \"myAngularApp:build:es5\"
.
Create a new file, tsconfig-es5.spec.json
next to tsconfig.spec.json
with the following content.
You can then run the tests with this configuration
\nCreate an ES5 serve configuration as explained above, and configuration an ES5 configuration for the E2E target.
\nYou can then run the ng e2e
command with this configuration. Make sure to replace <app-name>
(in \"<app-name>:serve:es5\"
) with the actual name of the app, as it appears under projects
in angular.json
. For example, if your app name is myAngularApp
the config will become \"devServerTarget\": \"myAngularApp:serve:es5\"
.