When you need to host Angular website files in production, the build is only one part of the job. Your hosting platform must serve the correct output folder, support Angular routing, and use the right base path.
The simplest setup is a production Angular build on a static web server or CDN. SSR and hybrid applications need a Node.js runtime instead. Choose the deployment model first, then configure the server around it.
Choose static hosting or SSR first
Angular applications do not all deploy the same way. Your application type determines the hosting service, build output, and server configuration.
Static Angular applications
A standard Angular single-page application uses client-side rendering. The browser downloads the JavaScript bundles, then Angular displays the requested view.
This setup works on a static host. You upload the generated files and configure the host to return index.html when a route does not match a physical file.
Static hosting is usually the right choice when:
- Your application doesn’t need server-generated HTML.
- SEO for individual application routes isn’t a primary requirement.
- You want a simple deployment with no running Node.js process.
- Your backend already provides APIs separately.
Angular’s official deployment documentation describes this process as building the application, then copying the output to a web server or CDN.
SSR and hybrid applications
Server-side rendering, or SSR, generates HTML on the server before sending the page to the browser. Hybrid rendering can combine server rendering, client rendering, and prerendering across different routes.
Use SSR or hybrid rendering when the first HTML response matters. Common reasons include search visibility, social previews, faster first content, or routes that need server-side data handling.
Static hosting alone cannot run live SSR. You need a Node-capable hosting environment, container, or platform that can start the generated Angular server.
Do not upload only the browser files from an SSR project and expect SSR to work. That deployment removes the server process that produces the rendered HTML.
How to host Angular website files on static hosting
The static deployment path has four main steps: install dependencies, create a production build, upload the correct directory, and configure route fallback.
Create a production build
Run these commands from the Angular project directory:
npm ci
ng build --configuration production
The first command installs the versions recorded in package-lock.json. The second creates an optimized production build. Angular’s current build command documentation covers the available build options and configurations.
ng build normally uses the production configuration for a production build, but writing --configuration production makes the deployment intent clear.
The output is placed inside the dist directory. The exact structure depends on your Angular version and builder. Current application-builder projects commonly place browser-ready files in a path such as dist/my-app/browser. Older projects may place the files directly in dist/my-app.
Open the output directory before uploading it. Find the folder that contains index.html, JavaScript bundles, stylesheets, and assets. That folder is the one your static server must publish.
Upload the folder that contains index.html
A common deployment error is uploading the outer dist directory instead of the actual application directory. The server then looks for index.html in the wrong location.
Check the final URL after upload:
https://example.com/index.htmlshould load the application.- JavaScript and CSS requests should return successful responses.
- Image and font paths should point to the deployed domain.
- The browser console should not show missing bundle errors.
You can upload the build files through a hosting dashboard, FTP, a provider CLI, or a continuous deployment pipeline. The method changes by provider. The required result does not: the public document root must contain the generated index.html.
Keep the last working build available. If a new deployment fails, restore the previous output instead of debugging against an empty or partial directory.
Configure Angular routing so refreshes work
Angular routing happens in the browser after the first page loads. A server does not automatically know that /reports is an Angular route.
When a user clicks a link inside the application, Angular handles the route. When the user refreshes /reports, the browser sends a request for /reports to the server. If the server searches for a physical file named reports, it may return a 404.
Add a fallback to index.html
Configure your static host to return index.html for unknown application routes. The server should still return real files normally, including JavaScript, CSS, images, fonts, and favicon files.
This is often called:
- SPA fallback
- History API fallback
- Rewrite to
index.html - Fallback document
Apache servers commonly use a .htaccess rewrite. IIS commonly uses a web.config rule. Managed hosting services usually provide a setting named SPA fallback, rewrite rules, or fallback routes.
Angular’s older deployment guide describes the same core rule: missing files should resolve to index.html so the Angular router can take over.
Don’t redirect every request blindly. If a JavaScript file is missing because of a bad asset path, returning index.html for that file can create a confusing MIME type error. Route fallback should apply to application routes, not replace normal static file handling.
Test direct navigation
After deployment, test a route in a new browser tab. Don’t test only by clicking through the home page.
Use this sequence:
- Open the home page.
- Click into a nested route.
- Copy that route’s URL.
- Open the URL in a private browser window.
- Refresh the page.
- Test the browser’s back and forward buttons.
If the direct route returns 404, fix the server rewrite. If the page loads but loses its styling, inspect the base path and asset URLs.
Set the correct base href
Angular uses the base href to resolve links, scripts, styles, and other assets. The correct value depends on where the application is hosted.
Hosting at the domain root
For an application at https://example.com/, the base path is usually /.
A root deployment lets Angular request assets such as /main.js and /styles.css. This is the default arrangement for many projects.
Hosting inside a subfolder
If the application runs at https://example.com/tools/, Angular needs /tools/ as its base path. Build it with:
ng build --configuration production --base-href /tools/
The trailing slash matters. Without it, browsers can resolve relative asset paths incorrectly.
You can also configure the base href in the application’s HTML or project settings, depending on your build process. Check the generated index.html after building. It should contain the path where the application will actually be served.
A wrong base path creates recognizable symptoms:
- The page loads without styles.
- JavaScript files return 404.
- Images work on the home page but fail on nested routes.
- Router links point to the domain root instead of the subfolder.
- Refreshes fail only after navigating deeper into the application.
Build for the final path. Don’t build for / and assume the host will repair the URLs later.
Deploy Angular SSR or hybrid applications
SSR changes the deployment model. You still create an Angular production build, but the output includes server-side code that must run.
Add SSR to an existing project
For a new project, Angular supports creating an SSR-enabled application with ng new --ssr.
For an existing application, add SSR with:
ng add @angular/ssr
The schematic updates the project and creates the files needed for server-side rendering. Angular’s current server-side and hybrid-rendering guide explains the supported rendering approach and route configuration.
Review the changes before deploying. Check the server entry point, route configuration, build targets, and package scripts. Browser-only APIs such as window, document, and localStorage can fail during server rendering because they don’t exist in the Node.js process.
Move browser-only code behind a browser check or load it only after the application runs in the browser.
Build and run the server output
Build the SSR application with:
ng build --configuration production
The generated output normally contains separate browser and server artifacts. The exact file names depend on the Angular version and project configuration. Inspect the dist directory and package.json rather than copying a command from an older tutorial.
Many current projects produce a server entry similar to dist/my-app/server/server.mjs. Some projects include a generated npm script for starting the server. Use the script or server entry created by your project.
The production host must:
- Install production dependencies.
- Start the generated Node server.
- Listen on the port provided by the hosting platform.
- Serve the browser assets.
- Keep environment variables outside the client bundle.
- Forward HTTPS traffic correctly if a reverse proxy is used.
A static file upload cannot replace these steps. If the host has no Node runtime, deploy a prerendered or static version instead.
Configure environment values safely
Angular frontend values are bundled into files that users can download. Never put passwords, private API keys, database credentials, or signing secrets in an Angular environment file that ships to the browser.
Use environment files for public values such as:
- API base URLs
- Public analytics identifiers
- Feature flags
- Public application names
- Public authentication configuration
Store private values in the backend or hosting platform’s secret storage. If the browser must call a protected service, route the request through an authenticated backend rather than exposing the service credential in Angular.
Confirm that the production API URL is present in the built application. A deployment can look successful while every data request still points to localhost.
Test the production build before changing DNS
Run a local static server against the built output before publishing it. This catches missing assets and incorrect paths without involving the production domain.
The test should cover:
- The home page.
- At least one nested route.
- A hard refresh on that nested route.
- Mobile and desktop layouts.
- API requests.
- Authentication redirects.
- Images, fonts, and downloadable files.
- Browser console errors.
- Network requests with 404, 403, or 500 responses.
For SSR, test the initial HTML response as well as browser hydration. View the page source or inspect the first document response. The returned HTML should contain the expected server-rendered content when SSR is configured for that route.
Hydration errors often come from different markup being produced on the server and browser. Random values, current timestamps, browser-only conditions, and unstable data can produce mismatches.
After the build passes locally, deploy it to a preview URL. Test the preview before changing the production domain or routing traffic to the new version.
Fix common Angular hosting errors
Most deployment failures fit a small set of patterns.
A refresh returns 404
The host isn’t rewriting unknown application routes to index.html. Add the SPA fallback rule and test a deep route directly.
CSS and JavaScript return 404
The application probably has the wrong base href, or you uploaded the wrong directory. Check the generated index.html, then confirm that the public document root contains the same files referenced by the page.
The page shows a MIME type error
The server may be returning index.html when the browser requests a JavaScript or CSS file. Fix the asset path and narrow the fallback rule to application routes.
SSR fails with window or document errors
A server-rendered application is executing browser-only code in Node. Move that code behind a browser check or delay it until the browser has initialized.
The site shows an old version
A CDN, service worker, or browser cache may still serve previous files. Use content-hashed production assets, review cache headers, and update the service worker when your application uses one. Don’t delete the previous deployment until the new version is confirmed.
Conclusion
The correct way to host Angular website files depends on the rendering model. Static Angular apps need the browser output, a correct base href, and a fallback to index.html. SSR and hybrid apps need the browser output plus a running Node.js server.
Build locally, upload the folder containing index.html, test direct route refreshes, and verify asset paths before changing DNS. Most production errors come from serving the wrong directory or asking a static server to handle a route it doesn’t understand.
