Build Angular with ng build, then serve the generated files from a static web server. On PCF/Cloud Foundry, the Staticfile buildpack is the simplest fit for an app that only serves those files; configure it to send client-side routes to index.html. Choose the NGINX buildpack when you need custom server directives, proxying, or environment-based configuration.
Build the Angular app you will deploy
Run ng build with the production configuration intended for the release. The build produces static files; the output path is configurable and is commonly dist/my-app/. Deploy the contents of that output directory, not the Angular source project. Check the generated files and configured output path before preparing the server directory.
Angular’s production configuration applies ahead-of-time compilation and production-mode optimizations, including bundling, minification, mangling, and dead-code elimination. Angular’s deployment guide describes client-side-rendered apps as a natural fit for a static HTML server because their content is generated at build time.
Deploy to PCF with the Staticfile buildpack
For an Angular bundle that needs no custom server logic, use the Staticfile buildpack. It detects a file named Staticfile in the directory being deployed and serves the content through NGINX. The file can be empty for a basic deployment.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors#1 Best Overall
- Build the app with
ng buildand identify its actual output directory. - Put the deployable files and an empty
Staticfiletogether in the directory you will push. - Enable pushstate routing so requests for Angular HTML5 routes reach the app’s
index.html. Use the Staticfile buildpack’s documented setting for the foundation and buildpack version in use. - Set the HTTPS policy if required. Where TLS terminates at the app’s own NGINX layer, the Staticfile configuration supports
force_https: trueor an equivalent environment variable. - Push the app with
cf push, map its route, and request a nested Angular URL directly—not only the home page. Confirm that the route returns the app rather than a platform or server 404.
The Staticfile buildpack documentation also describes options for an alternate root, gzip, HTTP/2, MIME types, and location includes. Use those documented settings when the default behavior is insufficient; do not assume that a setting is available or configured identically across every PCF/Cloud Foundry foundation.
As a capacity reference, the Staticfile documentation describes approximately 20 MB of RAM for NGINX static serving. It also notes that Cloud Foundry containers otherwise receive a 1 GB default allocation unless adjusted. These are platform documentation figures, not independent benchmarks or universal sizing requirements.
Use the NGINX buildpack when the app needs custom server behavior
Select the NGINX buildpack when you need custom directives, MIME types, proxying, module loading, or configuration rendered from environment values. Put nginx.conf beside the static content and configure a location fallback that serves index.html for application routes while allowing real asset files to be served normally.
- Use the buildpack template
{{port}}for the listening port. Cloud Foundry assigns the app’s port; a hard-coded port can prevent the server from receiving traffic. - Use
{{env "NAME"}}where a configuration value needs to be inserted from an environment variable. - Test proxy behavior and internal-route connections during restarts. Internal-route traffic bypasses the Cloud Foundry routing tier and can be affected while an app restarts.
Choose a serving pattern
| Option | Best fit | Routing and configuration | Operational trade-off |
|---|---|---|---|
| Staticfile buildpack | A static Angular bundle with minimal server customization. | Enable pushstate routing for client-side URLs; documented settings cover HTTPS policy and options such as gzip, HTTP/2, MIME types, alternate roots, and location includes. | Least server configuration to own. The cited Staticfile guidance does not specify comparative observability or rollback behavior. |
| NGINX buildpack | Custom directives, proxying, modules, MIME types, or environment-driven configuration. | Write an NGINX configuration with an Angular route fallback and the {{port}} template; use {{env "NAME"}} for substituted values. |
Offers more control, with corresponding responsibility for configuration and restart behavior. Comparative observability and rollback behavior are not stated in the cited NGINX buildpack guidance. |
| Another production server or CDN origin | An existing NGINX, Apache, IIS, object-storage website, or CDN workflow. | Configure that server to serve the static files, return index.html for client-side routes, set correct MIME types, handle compression safely, and enforce HTTPS where TLS terminates. |
Operational ownership, proxy features, and rollback depend on the chosen server and deployment setup; they are not specified for these alternatives in the cited Angular deployment guide. |
The artifact does not need to be tied to PCF: the same build output can be copied to a conventional web server or CDN origin. The deciding question is how much server behavior you need to control. Staticfile keeps configuration light; choose NGINX or another server when you must own rewrites, headers, proxying, modules, or security policy.
Rank #3
Make Angular deep links work
Angular handles many application routes in the browser. A visitor who opens a nested URL directly, refreshes it, or follows a bookmark causes the server to receive that path first. If the server looks only for a file matching the path, it can return a 404 even though in-app navigation works. Configure the server to return index.html for application routes while continuing to serve existing JavaScript, CSS, image, and other asset files normally.
- Test the root URL and at least one nested route by entering each URL directly in a fresh browser tab.
- Refresh a nested route and confirm it still loads the Angular app.
- Check that missing assets do not silently receive the app shell in place of the expected file response.
Handle Cloud Foundry startup and production availability
Cloud Foundry chooses an app’s launch command in this order: a command passed with cf push -c COMMAND, a root-level Procfile, then a buildpack default. If neither an explicit command nor a Procfile is present and the selected buildpack has no suitable default, staging or startup can fail. A static-serving buildpack may provide the default; confirm the behavior of the buildpack version installed on the target foundation before overriding it.
For production apps, Cloud Foundry recommends a minimum of two instances. Treat that as a baseline, not a complete availability design. Verify health checks, route mapping, rolling deployment behavior, cache invalidation, and API connectivity on the target foundation. Two instances do not by themselves establish that those dependencies or deployment paths are healthy.
Quick Recap
Validate the deployment before relying on it
- Build output: confirm the pushed directory contains the generated app files, including
index.html, rather than only source files. - Route handling: test the home page, a direct nested URL, a refresh, and a missing asset.
- Server configuration: confirm the selected buildpack is in use; with custom NGINX, check that it listens on
{{port}}and that route fallback and environment substitution render as intended. - Delivery and dependencies: verify HTTPS at the layer that terminates TLS, API connectivity, health checks, route mapping, and cache invalidation for a new release.
- Availability: confirm the intended instance count and observe how the app behaves during the foundation’s rolling deployment and restart process.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
