Simple deployment options

Last update on August 19 2022 21:51:37 (UTC/GMT +8 hours)

Before fully deploying your application, you can test the process, build configuration, and deployed behavior by using one of these interim techniques

Building and serving from disk

During development, you typically use the ng serve command to build, watch, and serve the application from local memory, using webpack-dev-server. When 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 builds 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. To 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. You will need two terminals to get the live-reload experience.

On the first terminal, run the ng build command in watch mode to compile the application to the dist folder.

````ng build -watch```

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:

lite-server --baseDir="dist"

The server will automatically reload your browser when new files are output.

Basic deployment to a remote server

For the simplest deployment, create a production build and copy the output directory to a web server

Start with the production build:

ng build --prod

Copy everything within the output folder (dist/ by default) to a folder on the server.
Configure the server to redirect requests for missing files to index.html. Learn more about server-side redirects below.

This is the simplest production-ready deployment of your application.

Deploy to GitHub pages

Another simple way to deploy your Angular app is to use GitHub Pages.

You need to create a GitHub account if you don't have one, and then create a repository for your project. Make a note of the user name and project name in GitHub.
Build your project using Github project name, with the Angular CLI command ng build and the options shown here:

ng build --prod --output-path docs --base-href /<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.
On the GitHub project page, configure it to publish from the docs folder.

You can see your deployed page at https://<user_name>.github.io/<project_name>/.

Server configuration

This section covers changes you may have made to the server or to files deployed to the server.

Routed apps must fallback to index.html

Angular apps are perfect candidates for serving with a simple static HTML server. You don't need a server-side engine to dynamically compose application pages because Angular does that on the client-side.

If the app uses the Angular router, you must configure the server to 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". A deep link is a URL that specifies a path to a component inside the app. For example, http://www.mysite.com/heroes/42 is a deep link to the hero detail page that displays the hero with id: 42.

There is no issue when the user navigates to that URL from within a running client. The Angular router interprets the URL and routes to that page and hero.

But clicking a link in an email, enter it in the browser address bar, or merely refreshing the browser while on the hero detail page - all these actions are handled by the browser itself, outside the running application. The browser makes a direct request to the server for that URL, bypassing the router.

A static server routinely returns index.html when it receives a request for http://www.mysite.com/. But it rejects http://www.mysite.com/heroes/42 and returns a 404 - Not Found error unless it is configured to return index.html instead.

Fallback configuration examples

There is no single configuration that works for every server. The following sections describe configurations for some of the most popular servers. The list is by no means exhaustive but should provide you with a good starting point.

Apache: add a rewrite rule to the .htaccess file as shown (https://ngmilk.rocks/2015/03/09/angularjs-html5-mode-or-pretty-urls-on-apache-using-htaccess/):

RewriteEngine On
    # If an existing asset or directory is requested go to it as it is
    RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -f [OR]
    RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -d
    RewriteRule ^ - [L]
    # If the requested resource doesn't exist, use index.html
RewriteRule ^ /index.html

Live Demo:

It is just a code snippet explaining a particular concept and may not have any output

See the Pen OYzpoa by w3resource (@w3resource) on CodePen.

Nginx: Use try_files, as described in Front Controller Pattern Web Apps, modified to serve index.html:

try_files $uri $uri/ /index.html;

Live Demo:

It is just a code snippet explaining a particular concept and may not have any output

See the Pen OYzpaa by w3resource (@w3resource) on CodePen.

IIS: add a rewrite rule to web.config, similar to the one shown in the code sample below:

<system.webServer>
  <rewrite>
    <rules>
      <rule name="Angular Routes" stopProcessing="true">
        <match url=".*" />
        <conditions logicalGrouping="MatchAll">
          <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
          <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
        </conditions>
        <action type="Rewrite" url="/index.html" />
      </rule>
    </rules>
  </rewrite>
</system.webServer>

Live Demo:

It is just a code snippet explaining a particular concept and may not have any output

See the Pen GayWeX by w3resource (@w3resource) on CodePen.

GitHub Pages: you can't directly configure the GitHub Pages server, but you can add a 404 page. Copy index.html into 404.html. It will still be served as the 404 response, but the browser will process that page and load the app properly. It's also a good idea to serve from docs/ on master and to create a .nojekyll file
Firebase hosting: add a rewrite rule.

"rewrites": [ {
  "source": "**",
  "destination": "/index.html"
} ]

Live Demo:

It is just a code snippet explaining a particular concept and may not have any output

See the Pen QRapXL by w3resource (@w3resource) on CodePen.

Requesting services from a different server (CORS)

Angular developers may encounter a cross-origin resource sharing error when making a service request (typically a data service request) to a server other than the application's own host server. Browsers forbid such requests unless the server permits them explicitly.

There isn't anything the client application can do about these errors. The server must be configured to accept the application's requests.

Previous: Building and serving Angular apps
Next: Angular Language Service