Your project works, it is tested, it is measured and a machine watches it on every push. And yet it still lives on your laptop, where it is no use to anybody. Deploying is what turns a repository into a product, and it is also the moment when the problems no development environment teaches you show up: the routes that worked on localhost and give a 404 on the server, the cache that serves the old version for a week, the service worker stuck with code from three deployments ago, the API key you thought was protected and that anybody can read in two clicks, and the security headers nobody configures because nobody has explained them. In this lesson you will learn to prepare the production build while understanding what each part does and why no secret key can live in the client; to choose where to host with an honest comparison table; to configure the server properly — SPA routes, caching consistent with hashing and with the service worker, compression and security headers explained one by one; to decide what to do about the backend without writing one, with the warning that client-side validation never replaces server-side validation; to set up continuous deployment with per-branch previews and a rollback strategy that works at three in the morning; to monitor in production without becoming a privacy problem; and to update an already-installed PWA without leaving anybody on an old version. You will finish with the application deployed over HTTPS, its continuous deployment pipeline and a signed launch checklist.

1. What changes when the code leaves your machine
2. The production build
3. Environment variables and why there are no secrets in the client
4. Where to host: an honest comparison table
5. Domain, HTTPS and certificates
6. SPA routes and the index.html fallback
7. Caching: the part most often done wrong
8. Compression
9. Security headers, one by one
10. The backend: what options exist without writing a server
11. Client-side validation never replaces server-side validation
12. Continuous deployment with GitHub Actions
13. Per-branch preview environments
14. Rollback strategy
15. Error monitoring in production
16. Field metrics with web-vitals
17. Updating an already-installed PWA
18. The launch checklist
19. Common Mistakes and Tips
20. Exercises
21. Conclusion

In development, Vite does an enormous number of things for you that in production simply do not exist. It is worth seeing the full list first, because every row is a source of surprises:

The practical consequence is a golden rule that saves a great deal of time:

Never deploy anything you have not tested with npm run build and npm run preview on your machine.

preview serves the real build from dist/, and that is where half the problems show up: badly resolved routes, images that were not copied, dynamic imports that worked by accident in development, and environment variables that were not injected.

And a second rule, from the tip in 11-01 that I hope you followed: the first deployment is done with the application empty, at milestone H1. If you did that, this section is a recap. If not, do it now before going on: discovering configuration problems with a blank page costs an hour; discovering them with the whole product on the line costs a weekend.

And what it produces, annotated:

Four things happen here and each one is worth understanding.

1 · Bundling. The hundreds of ES modules in src/ are combined into a few files. In development every import was a request; in production there are three or four downloads. It is what makes the "≤ 4 requests" budget from 11-01 achievable.

2 · Code splitting (09-05). The screens not shown at startup come out in separate chunks, loaded when they are needed:

3 · Minification. Whitespace, comments and long names are removed, and optimizations like tree shaking are applied: if you import one function from a module and do not use the other five, the other five are not included. This only works with static ES modules, which is one of the reasons 05-04 insisted on them.

4 · Filename hashing. index-C4f8a2b1.js contains a digest of the content. If the content changes, the name changes. This is the piece that makes the caching strategy in section 7 possible, and it is worth seeing clearly:

It is an elegant solution to a problem that looked unsolvable, and it explains why index.html does not carry a hash: somebody has to be the stable entry point pointing at the hashed files.

Annotated Vite configuration:

base is the number one cause of broken deployments. If you serve at https://user.github.io/orbita/, the absolute paths /assets/... would point at the root of the domain, where there is nothing. With base: '/orbita/', Vite generates /orbita/assets/.... On Netlify, Vercel or your own domain, where the application is at the root, base must be '/'.

About sourcemap: true, which has a nuance worth deciding consciously: source maps let you debug in production seeing your original code instead of the minified one, and they are essential for an error-tracking service to give readable stack traces. The trade-off is that they expose your source code. For a portfolio project with a public repository, there is no reason to hide it. In a commercial product, the usual practice is to generate them and upload them to the error service without publishing them on the server.

Vite injects into the bundle any variables starting with VITE_:

And here comes the most important point in the whole lesson, which has to be understood without ambiguity:

import.meta.env.VITE_WHATEVER is literally substituted with its value at build time. That value ends up written into a .js file that gets downloaded into anybody's browser. It is not a variable: it is a public constant.

Check it yourself, and do it now:

What can go in the client and what cannot:

Why people get this wrong, and with what consequences. The faulty reasoning is: "it is in an environment variable, and environment variables are secret". They are on the server. In a client build, the environment variable only describes where the value was written, not where it ends up. And the value ends up in a public file, minified but perfectly readable with Ctrl+F.

The consequences are real and expensive: cloud service keys leaked into public repositories are detected automatically by bots within minutes, and the result is usually a bill for somebody else's usage.

What to do if your project needs to talk to a service requiring a secret key. There is only one correct answer: a server-side intermediary.

Netlify Functions, Vercel Functions and Cloudflare Workers let you do this in twenty lines and without setting up a full server. That is section 10.

And the repository rule: .env in .gitignore, always, with a versioned .env.example documenting which variables are needed and with sample values. If you ever commit a secret by mistake, rotating it is mandatory: deleting it from the history is not enough, because it is already in any clone made in the meantime.

An application like yours is a static site: HTML, CSS, JavaScript and a few images. There is no server process running your code. That opens up plenty of options and all of them are good; the differences are in the details.

What the table does not say and is worth knowing:

GitHub Pages is the simplest option and has one limitation that directly affects this project: it does not allow configuring HTTP headers. That means you cannot set a real Content-Security-Policy (only the <meta> version, which is more limited), nor control Cache-Control, nor configure the SPA fallback except with the 404.html trick. For a portfolio it is perfectly valid; for practicing section 9 of this lesson, it is not.

Netlify, Vercel and Cloudflare Pages do essentially the same thing from a static site's point of view: you connect the repository, every push to main deploys, every PR generates a preview URL, and you have a configuration file for headers and redirects. Choosing between them for this project is a matter of preference; all three are excellent.

Your own server with Nginx is the only one that forces you to understand what is going on, and precisely for that reason it is instructive. It is also the only one where you are responsible for security updates, backups and the certificate.

A warning about free tiers, because honesty is called for: they are generous and sufficient for a personal project, but they have limits (build minutes, bandwidth, function invocations) and they change over time. Read the current limits before committing, and bear in mind that a project that grows may end up needing a paid plan.

Recommendation for this module: deploy on Netlify or Cloudflare Pages. You get per-PR previews, configurable headers and server functions if you need them, at no cost and with nothing to administer. And if you want the full exercise, set up an equivalent Nginx configuration as well, even if only locally: understanding the configuration file teaches more than any control panel.

HTTPS is not optional, and not only for security:

On top of that, the data travels in the clear: on public wifi, anybody can read and modify what is sent.

How you get it. On the platforms from the previous section, automatically and for free: they issue and renew the certificate for you. On your own server, with Let's Encrypt and certbot:

The domain. A domain of your own costs ten to fifteen euros a year and completely changes how the project is perceived. Configuration is a DNS record:

And one decision you have to make and not leave half-done: choose one canonical form — with www or without — and redirect the other with a 301. Having both live duplicates the content for search engines, splits the cache and confuses users. The same applies to http → https, which must be a permanent redirect.

HSTS (Strict-Transport-Security) tells the browser never to try connecting over HTTP to your domain:

It is one of the most effective headers there is. With one important warning: it is hard to undo. Once a browser has seen it, it refuses to use HTTP on that domain for the max-age even if you remove the header. Start with a small value (max-age=300), check that everything works, and then raise it to a year.

This is the problem that surprises everybody on their first deployment.

Your router (11-01) uses the History API: when you navigate to the report view, the URL becomes https://orbita.example/report. It works perfectly… until somebody reloads the page or shares that link.

The cause is simple: the server knows nothing about your router. It looks for a file called report and there is none.

The solution is called the index.html fallback: any route that does not correspond to a real file returns index.html, and then your JavaScript boots, reads the URL and renders the right screen.

With one important caveat: the fallback must return status 200, not 404, or search engines will index your routes as errors.

On Netlify (public/_redirects):

On Vercel (vercel.json):

On Cloudflare Pages (public/_redirects): identical to Netlify.

On Nginx:

try_files tries in order: the exact file, the directory, and if neither exists, index.html. It is exactly the logic you need.

On GitHub Pages there is no server configuration, so a trick is used: create a 404.html identical to index.html. GitHub serves it for non-existent routes and the application boots. It works, but it returns status 404, which is bad for SEO. It is one of the reasons to prefer another platform if indexing matters to you.

And the detail that breaks the fallback: if you apply the rule to everything, /api/tasks will also return index.html, and your code will receive HTML where it expected JSON — with a baffling parse error. Exclude the API routes before the general rule:

Caching is where people go wrong most, and it produces two opposite and equally bad failures:

The correct solution takes advantage of the hashing from section 2, and it boils down to a two-line rule:

Files with a hash in the name: one-year cache, immutable. The index.html, the service worker and the manifest: never cached.

The logic is impeccable: if the content changes, the name changes, so a hashed file never needs revalidating. And index.html, which is what points at the new names, must always be requested.

The complete table:

no-cache does not mean "do not store". It means "store, but revalidate with the server before using". With ETag, revalidation usually returns a 304 with no body: minimal cost and always up to date. The one that stores nothing is no-store.

On Netlify or Cloudflare Pages (public/_headers):

On Nginx:

The special case of the service worker deserves emphasis because it produces the most baffling failure of all. If sw.js is served with a long cache, the browser does not download the new one, so the old service worker keeps serving the old version of your application indefinitely. The user reloads, clears their history, and keeps seeing the same thing. Modern browsers limit sw.js caching to 24 hours by default, but do not rely on that: set an explicit no-cache.

How to check it is configured correctly:

Compressing is the best effort-to-result optimization there is: one line of configuration and between 60 % and 80 % fewer bytes on text.

Managed platforms do it by themselves and you have nothing to configure. On Nginx:

Two important nuances:

• Do not compress what is already compressed. PNG, JPEG, WebP, MP4 and WOFF2 already are. Recompressing them burns CPU and sometimes increases the size.
• Your budget from 11-01 is in compressed bytes. The 60 kB in the budget is measured in the Network panel's "Transferred" column, not "Size". Confusing the two makes you think you are over budget when you are under, or the other way round.

These headers are free, configured once, and they close off entire classes of attacks. They are explained one at a time because copying them without understanding them produces broken sites nobody knows how to fix.

It is the most powerful and the most delicate. It declares where your page may load resources from; everything else is blocked by the browser.

Directive by directive:

Why CSP is so effective: it is the second line of defense against XSS. In 11-03 you learned the first — textContent instead of innerHTML — and CSP is the reserve parachute: even if an attacker manages to inject <script>alert(1)</script> into your page, script-src 'self' prevents it from running, because it does not come from your origin.

The two practical pitfalls:

1. Inline styles. If your code does element.style.color = 'red', CSP with style-src 'self' blocks it. The correct solution is to use CSS classes instead of inline styles — which is better practice anyway. The lazy solution is 'unsafe-inline', which disables much of the protection. Avoid it.
2. Inline scripts. If you have a <script> with code inside the HTML, it is blocked. Vite does not generate any by default, so it is usually not a problem.

How to roll it out without breaking anything: start in report-only mode, which blocks nothing and tells you what it would block:

Navigate through your whole application, look at the console warnings, adjust the policy, and only then remove the -Report-Only.

On Netlify or Cloudflare Pages (public/_headers):

How to verify it. There are public services that analyze your headers and give you a score with explanations. It is also enough to run:

Getting a good security-headers score is a small detail that carries a lot of weight in a technical review: it shows you have thought about deployment, not just about the code.

Your project can work perfectly without a server: the data in localStorage, everything in the browser. It is a legitimate decision if it is documented with its limitations (single device, no real privacy, no sharing).

If you need more, there are three paths:

Backend as a service. Services like Supabase, Firebase or PocketBase give you a database, an automatic API, authentication and sometimes real time, through configuration rather than code. For a portfolio project that needs users and shared data, it is the option with the best effort-to-result ratio.

What you should know before choosing one:

• You depend on the provider. Migrating later has a cost. Mitigate it by keeping your repository boundary (11-02): if the BaaS lives behind SupabaseRepository, changing it means rewriting one file.
• The security rules are your responsibility. These services expose the database directly to the client, protected by rules you configure. One badly written rule exposes every user's data. It is the most frequent and most serious failure on these platforms.
• Free tiers have limits and the service can change its pricing or disappear.

Serverless functions. When all you need is to hide a key or perform an occasional server-side operation:

Notice that the variable does not carry the VITE_ prefix: that is exactly what keeps it out of the client bundle.

Your own backend. It is the natural path if you want to grow, and it is the subject of lesson 11-07: Node.js with Express or Fastify, a database, token authentication, and all the server logic your application needs. It requires learning new things and is worth it, but it is not a requirement of this project.

This section is short, it has no nuances, and it is one of the most important.

You have fifteen business rules, R1 to R15, implemented and tested in domain/. They work perfectly… in the browser. And the browser is an environment the user controls entirely:

• They can open DevTools and call your functions with whatever they like.
• They can modify your code before it runs.
• They can skip your entire application and call the API with curl.

If the server accepts that, your fifteen rules are worth nothing.

Client-side validation is a convenience for the user. Server-side validation is what protects the data. They are not alternatives: they are two layers with different purposes, and both are mandatory as soon as there is a server.

The good news is that your architecture is already prepared for this. domain/ is plain JavaScript with no browser dependencies — that was the first boundary in 11-01. If you write the backend in Node.js, you can import exactly the same files and run the same rules on the server:

One single implementation of the rules, executed on both sides. That is what made it worth keeping the domain free of dependencies throughout the whole project, and it is an excellent argument to tell in an interview (11-06).

And what the server must validate on top of your rules, because these are things the client cannot do:

Continuous deployment means that what is merged into main reaches production automatically, with no manual steps. With the CI from 11-04 protecting the branch, that is safe: nothing reaches main without lint, tests, coverage, budget and journeys all green.

The file's decisions:

The smoke check is an idea worth internalizing: a minimal, quick verification that what was deployed responds and contains what it should. It costs five lines and catches the "an empty folder was deployed" case, which happens more often than you would think.

Repository secrets (Settings → Secrets and variables): NETLIFY_AUTH_TOKEN and NETLIFY_SITE_ID go in as secrets (encrypted, not visible even in the logs); API_URL goes in as a variable (it is not secret and so it can be read). Never write a token directly into the YAML: the file is in the repository.

A preview environment is a temporary deployment of a branch, with its own URL. Netlify, Vercel and Cloudflare Pages do it automatically when a Pull Request is opened.

Why it is worth it, even when you work alone:

Three important precautions:

1. noindex on previews. If Google indexes deploy-preview-42--orbita.netlify.app, you will have duplicate content competing with your site. Platforms usually set it, but check.
2. Never point a preview at production data. A destructive test on a preview that writes to the real database is an avoidable disaster. Use a separate data environment.
3. Previews are public. Anyone with the URL gets in. Do not test there with anybody's real data.

Any deployment can go wrong. The question is not whether it will happen, but how long you will take to fix it when it does — probably at an inconvenient hour and in a hurry.

The options, from best to worst:

The first is the good one, and you have to test it before you need it. Managed platforms keep every previous deployment and let you go back to any of them with one click, because each deployment is an immutable set of static files.

The written procedure, which should be in your README or in docs/operations.md:

Point 1 is counterintuitive and it is the right one. The temptation is to investigate while the site is broken. But every minute of investigation is a minute of downtime, and hurry leads to worse decisions. Rolling back is reversible; fixing in a hurry is not.

Point 7 is what turns an incident into learning. And the key post-mortem question is not "who made the mistake" but "why did CI not catch it", because the answer is always a new check that prevents a whole family of future failures.

A caution about the database: if your deployment included a data migration (like the ones in 11-03), rolling back the code does not roll back the data. That is why migrations should be backward-compatible whenever possible: add fields, do not rename or delete them in the same deployment that stops using them. The safe sequence takes two deployments: first add and write to both places, then stop using the old one.

In development, an error shows up in your console. In production, it shows up in a user's console that they are not going to look at and are not going to tell you about: they will simply stop using your application.

In 11-02 you set up a local log with the two global safety nets (error and unhandledrejection). Now it has to be sent somewhere.

The options:

Error-tracking services. Sentry, Bugsnag, Rollbar and similar have free tiers that are sufficient for a personal project, integrate in three lines and group identical errors — which matters a lot: a bug happening 400 times is one entry, not 400 emails.

And here comes the part you have to get right:

An error-tracking service sends your users' data to a third party. That is a privacy decision, not just a technical one.

What has to be configured before enabling it:

Two details of the code: location.pathname instead of location.href avoids sending query parameters that may contain searches or identifiers; and sendBeacon sends without blocking and works even while the page is closing, which is exactly when many errors occur.

Warning. Do not send personal data to an external service without having covered it in your privacy notice and without knowing where it is stored. In a learning project with fictional data the risk is nil; in a real product, switching on a tracking service without more thought is a compliance problem, not a technical detail.

In 09-01 you learned the distinction that avoids the most confusion: lab (your Lighthouse, your machine, your network) versus field (real users, real devices, real networks). Field numbers are always worse, and they are the ones that matter.

How to read the results, which is where the value is:

That last point is what justifies the whole effort: sending the version with every metric lets you attribute a regression to a specific deployment. Without it, all you know is that it got worse at some point.

And a privacy note: performance metrics are not personal data as long as they include no identifiers. Do not add a user identifier "so we can correlate"; the 75th percentile does not need one.

This is the most specific problem in deploying a PWA, and it produces an exasperating situation: the user has the application installed, you deploy a fix, and they keep seeing the old version. They reload, and nothing.

The cause is in the service worker lifecycle (07-05):

The "Waiting" state is the problem. By default, a new service worker waits for all the application's tabs to close. And since many people never fully close an installed PWA, that wait can last days.

The complete solution, in three pieces.

Piece 1 · The service worker allows skipping the wait on demand:

Piece 2 · The application detects there is a new version and says so:

Piece 3 · The notice, which must be discreet and accessible:

The four rules of updating a PWA:

1. Never reload without warning. The user may be typing. A surprise reload that loses a form is unforgivable.
2. The reloading flag is essential. Without it, controllerchange can cause a reload loop: it is a real and very unpleasant bug.
3. sw.js with Cache-Control: no-cache (section 7). Without that, none of this works because the browser does not even download the new service worker.
4. Clean up old caches in activate. Otherwise versions pile up and you end up occupying hundreds of megabytes on somebody else's device.

The emergency plan, worth having written down: if you deploy a broken service worker that breaks the application for everybody who has it installed, the way out is to publish a minimal sw.js that unregisters itself and clears every cache:

Save it. The day you need it, you will be grateful.

The milestone's final deliverable. You walk through all of it, tick it off, and save it signed and dated in docs/launch.md.

Legal warning. Points 27 and 28 are not formalities. In the European Union, informing people about the processing of personal data is an obligation, and the use of cookies or storage that is not strictly necessary requires prior, informed and revocable consent — a banner that only says "accept" does not comply. If your project is an exercise with fictional data and no analytics, the practical risk is nil, but get into the habit of including the notice. If one day you publish a product with real users, this requires specific legal advice: neither this lesson nor any technical documentation is a substitute.

An honest privacy notice for a project like this one is short and takes ten minutes to write:

Putting a secret in a VITE_ variable. It ends up written into a public file anybody can read with Ctrl+F, and the bots that crawl repositories find it within minutes. Anything granting access to anything goes behind a server function. Check dist/ with grep before every deployment, and automate it in the pipeline.

Not configuring the SPA fallback. Everything works when navigating from the home page and gives a 404 on reload or when opening a shared link — which is exactly how the people you show the project to will arrive.

A long cache on index.html. Users stay on the old version for days and there is no way to force them to update. Hashed files get a one-year cache; the entry point gets no-cache.

Caching sw.js. It produces the most baffling failure there is: the user reloads, clears their history, reinstalls, and keeps seeing the application from three deployments ago.

A badly configured base. On GitHub Pages with a subdirectory, without base: '/repo/' the page loads blank and the console fills with 404s on /assets/…. It is the number one first-deployment failure.

Adding 'unsafe-inline' to the CSP to make it stop complaining. It disables much of the XSS protection, which is exactly what CSP existed to provide. Fix the inline style or script; it is almost always two lines.

Trusting client-side validation alone. Anybody can call your API with curl. With a server, the rules go there too — and your dependency-free domain means it is the same code.

Deploying without having tested the rollback. The day you need it, with the site down and in a hurry, is not the moment to find out how it works. Test it today, in the cold.

Reloading the PWA without warning when there is a new version. The user may be typing. A discreet notice, a button, and a reload only when they ask for it — with the flag that avoids the reload loop.

Sending personal data to an error-tracking service. It is a compliance problem, not a style one. Filter before sending, send pathname and not href, and declare the service in your privacy notice.

Tip · Deploy from day one and often. One deployment a week for two months is boring and safe. One huge deployment on the last day is the recipe for a disaster.

Tip · Have a diagnostics panel in production. A discreet route showing the version, the commit, the build date, the service worker state, the space used and the last logged errors. When somebody tells you "it does not work for me", that screen answers in ten seconds.

Tip · Save a snapshot of your production baseline. Lighthouse against the real URL, with a date. Six months from now you will know whether you improved or got worse, and you will have the evidence.

Tip · Test your deployed site on a real phone. Not on the emulator. On mobile data, not wifi. You will discover things no simulated throttling teaches you.

These exercises are milestone H6, part one: the application deployed over HTTPS, its continuous deployment pipeline and the signed checklist.

Exercise 1 — The build and the deployment.

1. Configure vite.config.js with the right base for your platform, sourcemap, manualChunks and chunkSizeWarningLimit set to your budget.
2. Create a versioned .env.example and an ignored .env.production, and document in the README which variables are needed.
3. Build and audit dist/: total size, number of files, and a grep for secrets. Document the results.
4. Test the whole application with npm run preview before deploying. Note the problems that only show up in production (there will be at least one).
5. Deploy on the platform of your choice, with your own domain or a platform subdomain, and HTTPS active.
6. Configure the SPA fallback and check with curl -I that it returns 200 on an internal route.
7. Configure the complete caching setup per the table in section 7 and verify it with curl -I on a hashed file, on index.html and on sw.js.
8. Configure the five security headers, with the CSP first in report-only mode and then active, with no unsafe-inline.
9. Document every decision in docs/deployment.md: which platform, why, and what it implies.

Exercise 2 — Continuous deployment, previews and rollback.

1. Write .github/workflows/deploy.yml with: prior verification, a build with the commit version, an automatic secrets check, deployment and a smoke check.
2. Configure the repository's secrets and variables correctly (encrypted secrets, plain variables).
3. Enable per-PR previews and check the three precautions: noindex, separate data, and awareness that they are public.
4. Genuinely test the rollback: deploy a visible change, roll back to the previous one, check the site comes back, and publish the new one again. Time how long you take.
5. Write docs/operations.md with the seven-step rollback procedure adapted to your platform.
6. Configure error monitoring with personal-data filtering, and demonstrate that a deliberately triggered error arrives with the stack trace and without user data.
7. Instrument web-vitals sending the version, and collect at least one session of field data.
8. Implement the PWA update with the three pieces from section 17, and demonstrate it: install the application, deploy a change, and check that the notice appears, that the button updates and that there is no reload loop.

Exercise 3 — The launch.

1. Walk through the 33 checks from section 18 against your deployed site. Tick each one with evidence (the command run, a screenshot or a URL), not from memory.
2. Complete the content block: <title>, description, Open Graph with a 1200×630 image, favicons in five sizes, robots.txt, sitemap.xml, a custom 404 page and a complete manifest.json.
3. Write the privacy notice using the template from section 18.3, adapted to what your application actually does.
4. Add the license to the repository.
5. Run Lighthouse against the production URL (not locally) and compare with your budget from 11-01 and your baseline from 11-04. Document the differences and explain them.
6. Run the site through a security-headers analyzer and document the score.
7. Open it on a real phone with mobile data and note everything that does not work as you expected.
8. Sign and date docs/launch.md.

Acceptance criteria for exercise 1 — Deployment

Rubric for exercise 1 (21 points)

Threshold: 15/21, with a mandatory 3 in "Secrets". A leaked secret invalidates the exercise: it is the only failure in this lesson with real consequences outside the project.

Acceptance criteria for exercise 2 — Continuous deployment and operations

Acceptance criteria for exercise 3 — Launch

Overall rubric for milestone H6 part one (24 points)

Threshold: 17/24. With one condition that cannot be traded away: zero secrets in the bundle. Everything else can be improved in the next iteration; a leaked key cannot.

Self-assessment for milestone H6:

Your project no longer lives on your laptop: it is on the internet, over HTTPS, and anybody can use it.

You know what changes when the code leaves your machine — nine differences, each one a source of surprises — and you have the rule that avoids half of them: never deploy anything you have not tested with build and preview. You know the production build from the inside: bundling that reduces requests, code splitting that defers what is not visible, minification that only works well thanks to the static ES modules from 05-04, and filename hashing, the elegant piece that lets you have a one-year cache and immediate updates at the same time — and that explains why index.html is the only one without it. With base configured properly, which is the number one cause of blank first deployments.

You are completely clear on the most important thing in the lesson: there are no secrets in the client. import.meta.env.VITE_* is not a variable: it is a public constant written literally into a file that gets downloaded. You know what can and cannot go in, you know that the faulty reasoning ("it is in an environment variable") confuses where the value was written with where it ends up, and you know that the only correct answer when a key is needed is a server-side intermediary. With the grep verification automated in the pipeline, because good intentions are forgotten and the bots crawling repositories are not.

You know where to host with an honest table that includes what the comparisons do not say: that GitHub Pages does not allow real headers, that Netlify, Vercel and Cloudflare Pages are equivalent for a static site, that your own server is the only one that forces you to understand what is going on, and that free tiers have limits that change. And you know why HTTPS is not optional: without it there is no service worker, no PWA, no secure contexts and no trust.

You know how to solve the problem that surprises everybody — SPA routes — with an index.html fallback returning 200 and not 404, on all four platforms, and with the API route exclusion that stops you receiving HTML where you expected JSON.

You have caching done properly, which is where people go wrong most: a year and immutable for anything hashed, no-cache for the entry point, the service worker and the manifest. You know that no-cache means "revalidate", not "do not store". And you know that a cached sw.js produces the most baffling failure there is: users trapped on a version from three deployments ago no matter how much they reload.

You know how to configure the security headers one by one, understanding them: CSP as the second line of defense against XSS — with connect-src preventing exfiltration, frame-ancestors preventing clickjacking, and the warning that 'unsafe-inline' disables exactly what the policy was there to give — rolled out first in report-only mode; nosniff, Referrer-Policy, Permissions-Policy and HSTS with its progressive max-age because it is hard to undo.

You know what to do about the backend: that not having one is legitimate if it is documented with its limitations; that a backend as a service solves multi-user without writing a server, with the warning that the security rules are yours and one badly written rule exposes all the data; that a twenty-line serverless function is enough to hide a key; and that writing your own is the path in 11-07. And you know, without nuance, that client-side validation never replaces server-side validation — with the reward that your browser-independent domain can be imported as is into Node and run the same R1–R15 on both sides, which is exactly why the first boundary in 11-01 was worth it.

You have continuous deployment with prior verification, the commit version injected — which makes it possible to attribute a regression to a deployment — an automatic secrets check and a smoke test, because a deployment finishing does not mean the site works. With per-branch previews and their three precautions, and with a rollback strategy whose rule is counterintuitive and correct: roll back first, investigate afterwards, because rolling back is reversible and fixing in a hurry is not. With the post mortem whose key question is not who made the mistake but why CI did not catch it.

You know how to monitor in production without becoming a privacy problem: filter before sending, pathname instead of href, sendBeacon because it works while the page is closing, and awareness that a tracking service is a third party receiving your users' data. And you know how to collect field metrics with web-vitals, with the lab-versus-field distinction from 09-01, and with the version attached so you can attribute.

You know how to update an installed PWA, which is the most specific problem in deploying a modern web application: the "waiting" state that can last days, the three pieces that solve it, the four rules — always warn, the flag against the reload loop, no-cache on sw.js, clean up old caches — and the emergency service worker worth having saved before you need it.

And you have the launch checklist with its 33 points in three blocks: technical, content and discoverability, and legal and operational — including the honest and specific privacy notice, the warning that cookie consent has legal requirements an "accept" button does not meet, and the license.

The product is published. And here is what separates a finished project from a project that is also useful for something: nobody knows it exists, nobody knows what decisions lie behind it, and you have not yet practiced how to tell that story. Work you cannot show or defend is worth, in practice, far less than it is. Turning it into something somebody understands in two minutes, that you can demonstrate in five, and that you know how to explain in a technical interview without sounding either insecure or boastful, is Project Presentation and Review.