Theory
From your laptop to the world
A project that only runs on your laptop is not truly finished. Deployment puts it online, hosted on a platform where real people, including your evaluators, can access it by a link. It is the step that turns your code into a live application.
This lesson covers deploying to platforms like Firebase Hosting, Heroku, and GitHub Pages. You saw Firebase deployment in full-stack development; here it is part of finishing your project. A deployed project is far more convincing than a localhost demo, so it is well worth doing, and doing early enough to test.
Follow along
Deploying your project (general flow)
- Prepare a production build Create an optimised build of your app (e.g. ng build for Angular), not the development version.
- Configure for production Set production settings: environment variables, the production database connection, and keep secrets safe.
- Choose a hosting platform Match the platform to your app: Firebase Hosting (web front end), Heroku (full app/backend), GitHub Pages (static site).
- Deploy Upload/deploy to the platform (e.g. firebase deploy); it serves your app at a public URL.
- Test the live version Check the deployed app works, it can behave differently from your local machine.
Theory
Choosing where to host
Match the platform to your app type. Firebase Hosting is excellent for web front ends and static content, especially if you already use Firebase for auth or data. Heroku (and similar) hosts full applications, including back-end servers. GitHub Pages is ideal for static websites (pure front end with no server).
So a static portfolio site might go on GitHub Pages, an Angular app with a Firebase backend on Firebase Hosting, and a Node/Express app with a database on a platform that runs servers. Many offer free tiers suitable for a student project. Read each platform's steps, they differ, but the pattern (build, configure, deploy) is the same. Pick the host that fits what you built.
Watch out
Deploy early, and test the live version
Two cautions. First, deploy early, not on the morning of your presentation. Deployment often reveals problems that did not appear locally: missing configuration, a production database not set up, environment differences, secrets not provided. Discovering these the night before is a nightmare; discovering them a week early is a fixable inconvenience.
Second, test the deployed version thoroughly, it can behave differently from your local machine. 'It works on my laptop' is not the same as 'it works live'. And keep production secrets (keys, passwords) safe, never hard-coded or exposed. Deploy with time to spare, and confirm the live app really works before you present it.
Quiz
Why should you deploy your project early rather than just before your presentation?
- Because deployment always works instantly and perfectly
- Because deployment often reveals problems that did not appear locally (missing config, production database, environment differences), so deploying early gives time to fix them
- Because the project does not need to be online
- To make the project look unfinished
Show the answer
Because deployment often reveals problems that did not appear locally (missing config, production database, environment differences), so deploying early gives time to fix them
You should deploy early because deployment frequently surfaces problems that never appeared while running locally, missing production configuration, a database not set up for production, environment differences, secrets not provided, and deploying early gives you time to find and fix them before the presentation. Option A is dangerously wrong: deployment rarely works perfectly first time, which is exactly why last-minute deployment is risky. Option C is wrong: a live, deployed project is far more convincing than a localhost demo and is often expected. Option D is nonsense. The lesson mirrors 'integrate early': deploy with time to spare and test the live version, because 'works on my laptop' is not 'works live'.
Think first
Why does a deployed project often behave differently from the one on your laptop?
It ran perfectly on your machine. Why might the deployed version break or differ? Then tap.
Show the answer
Because your laptop and the hosting platform are DIFFERENT ENVIRONMENTS, with different configurations, and code that quietly relies on your local setup can fail when that setup is not reproduced in production. Several kinds of difference cause this. CONFIGURATION: on your machine you may have environment variables, database connections, API keys, and settings that 'just work' because you set them up long ago, but the production environment starts blank, so if those are not explicitly provided (and provided correctly for production), the deployed app fails, this is one of the most common surprises. DATABASE: locally you may use a development database that is already populated and reachable; in production you need a real, correctly configured database with the right connection details, and forgetting to set it up (or pointing at the wrong one) breaks the live app. PATHS and BUILD: the production BUILD is optimised and structured differently from the development version, and things like file paths, base URLs, or assumptions about the server root can differ, so something that resolves locally may not resolve when deployed. NETWORK and SECURITY: production runs over the real internet with HTTPS, CORS rules, and stricter security, so cross-origin calls or insecure assumptions that were tolerated locally can now be blocked. DEPENDENCIES and PLATFORM: the hosting platform may run a different operating system, runtime version, or have different available resources than your laptop, exposing hidden assumptions. All of this means 'works on my machine' is a notorious phrase precisely because the machine's particular environment was silently part of why it worked, and that environment is not automatically present in production. The remedy is exactly the advice given: deploy EARLY so these environment differences surface while you have time to fix them (setting production config, provisioning the database, correcting paths, handling security), and TEST the deployed version thoroughly rather than trusting the local one. Understanding that deployment is a move to a new environment, not just a copy, is what turns a scary last-minute failure into a manageable, anticipated step. Different environment, different behaviour, so deploy early and test live.
Summary
Key takeaways
- Deployment puts your project online, hosted so real people can access it, turning code on your laptop into a live application.
- General flow: prepare a production build, configure for production (settings, database, secrets), choose a hosting platform, deploy, and test the live version.
- Match the platform to your app: Firebase Hosting (web front end), Heroku (full app/backend), GitHub Pages (static site).
- Many platforms offer free tiers suitable for a student project.
- Deploy early, not just before your presentation, because deployment often reveals problems (config, production database, environment differences) that need time to fix.
- Test the deployed version thoroughly and keep production secrets safe; 'works on my laptop' is not 'works live'.
- Memory hook: build, configure, deploy, test live; deploy early because production is a different environment from your laptop.