Learn Angular - Deployment & Hosting

#Introduction

The build is green, all tests pass, and the application is ready to use. Now it's time to leave the local machine and place the application in a production environment accessible to many users. This stage is called deployment.

Episode 20 covers deployment options on Firebase, Vercel, Netlify, and AWS, server-side rendering with Angular Universal, static site generation and prerendering, and production deployment best practices. You'll choose the hosting strategy that best fits your project's needs.

Deployment isn't just uploading files. Decisions about the hosting platform, rendering strategy, cache, and security determine the speed and availability of the application in production.

#Deployment Options: Firebase, Vercel, Netlify, and AWS

#Firebase Hosting

Firebase Hosting serves static files from a global CDN with automatic HTTPS and deep integration with Firebase Auth, Cloud Functions, and Cloud Storage. Start by installing the Firebase CLI:

npm install -g firebase-tools
firebase login
firebase init hosting
firebase deploy

firebase init hosting asks for a public folder — point it to dist/toko-online/browser. After that, firebase deploy uploads the files to the CDN and immediately gives you a production URL. One more Firebase advantage: you can connect a custom domain through the Firebase Console without manually setting up DNS.

#Vercel and Netlify

Vercel and Netlify are both serverless platforms that are friendly to frontends. Vercel detects Angular projects automatically, provides preview deployments for every branch, and has zero-config for SSR output:

npm install -g vercel
vercel --prod

Netlify uses a publish directory and a _redirects file for SPA routing fallback. For an Angular application with BrowserRouter, add the following line so a reloaded page doesn't return a 404:

/*    /index.html    200

Both platforms are free at small scale and handle CI themselves, from push to production.

#AWS S3 and CloudFront

AWS gives you full control over the infrastructure. The build is uploaded to an S3 bucket configured as static website hosting, with CloudFront set up as a CDN in front of it:

aws s3 sync dist/toko-online/browser s3://toko-online-bucket --delete

CloudFront provides HTTPS, edge caching, and predictable pricing. Because everything is separate, AWS also requires you to manage IAM permissions, bucket policies, and cache invalidation yourself.

#Server-side Rendering with Angular Universal

An ordinary Angular application only contains an empty HTML file that's filled in by JavaScript in the browser. For better SEO and first paint, Angular provides Universal:

ng add @angular/nguniversal
ng build

The ng add @angular/nguniversal command adds a new builder to produce a server bundle, a server.ts file, and build:ssr scripts. As a result, the application is rendered on the server into complete HTML, while JavaScript still runs in the browser for interactivity. Episode 21 covers Universal in depth.

#Static Site Generation and Prerendering

If the application's data rarely changes, prerendering can be the simplest choice. Every route is turned into a static HTML file at build time:

ng build --prerender

The list of routes to prerender is configured in angular.json under the prerender.routes option. The prerendered static files can be uploaded to any host without a server. Combining prerendering for public pages and server-side rendering for dynamic pages is a common pattern in large applications.

#Production Deployment Best Practices

#Configuration per Environment

A production build uses strict configuration:

ng build --configuration=production --base-href=/app/

--base-href matters if the application is served from a sub-path, for example /app/. Make sure the production environment file contains the correct API URL and that no credentials leak into the bundle.

#Cache and Compression

Angular build files already contain content hashes in their filenames, so it's safe to give them immutable cache headers:

location / {
  try_files $uri $uri/ /index.html;
}
location /assets/ {
  expires 1y;
  add_header Cache-Control "public, immutable";
}

try_files returns index.html for SPA routes that don't match a physical file. Gzip or brotli should be enabled at the hosting or CDN level to shrink data transfer.

#Rollback and Monitoring

Keep release versions and prepare a rollback strategy, for example using Git tags or deployment slots. Combining a short TTL on the HTML CDN cache and long TTL on hashed assets ensures users get the latest version without clearing their browser cache.

#Wrap Up

Key takeaways:

• Firebase Hosting and Vercel suit fast deployments with a global CDN.
• Netlify uses a _redirects file for SPA routing fallback.
• AWS S3 plus CloudFront gives full control over the infrastructure.
• Angular Universal lets an application be rendered on the server.
• Prerendering produces a static file for every route at build time.
• Immutable cache and try_files are the foundation of a healthy Angular deployment.

In the next episode, episode 21, we'll go deeper into server-side rendering and Angular Universal — the Universal basics, the difference between prerendering and SSR, SEO and initial load improvements, and hydration and the interaction between server and client.