Will a free Render backend stay online during my viva?

Free web services on Render spin down after about 15 minutes of inactivity and take roughly 30 to 60 seconds to wake on the next request. That cold start is the classic viva failure — the panel opens your link and it hangs. The fix is simple: open your own site a couple of minutes before you present so the service is already awake, and never rely on the very first request happening in front of the panel.

Is the MongoDB Atlas free tier enough for a final year project?

Yes. The Atlas M0 shared cluster is free forever and gives you 512 MB of storage, which is far more than any demo project needs. It is a real, cloud-hosted database on a live URL — exactly what a panel expects to see. The only limits you might notice are shared performance and no automated backups, neither of which matters for a project demo.

Do I still need to deploy if I can demo on localhost?

Deploy anyway. A live URL the panel can open on their own phone is far more convincing than localhost, and it proves you understand hosting, environment variables and CORS — all common viva questions. But always keep the localhost version working as a fallback: college wifi fails often enough that a recorded demo and a seeded local database are non-negotiable insurance.

How To Deploy Your Final Year Project For Free (Live In The Viva)

“It works on my laptop” is not a demo. A project on a live URL that the panel can open on their own phone reads as finished and professional; a project that only runs from your terminal reads as a prototype. Deploying also answers a whole category of viva questions — hosting, environment variables, CORS — before they are even asked.

All of this is genuinely free. The tiers below exist and cost nothing for a project of demo size. Follow the steps in order — database first, then backend, then frontend — because each one needs the URL of the one before it.

1. Put the database on MongoDB Atlas

Your database has to live in the cloud too, or the deployed backend has nothing to talk to. The Atlas free tier is the standard answer.

Create a free M0 shared cluster — free forever, 512 MB, more than enough for a demo.
Add a database user with a password, and note both — this becomes part of your connection string.
Under Network Access, allow 0.0.0.0/0 for the demo so your hosted backend can reach it from any IP.
Copy the connection string; it goes into the backend as a secret next.

For SQL projects the equivalents are the free tiers of Neon or Supabase (Postgres) — same idea, a cloud database on a URL.

2. Deploy the backend on Render or Railway

Your Node/Express or Python/FastAPI API needs a home. Render’s free web service is the most common choice; Railway is a fine alternative.

Push the backend to GitHub — the platform deploys straight from the repo.
Create a new Web Service, connect the repo, and set the build command (npm install or pip install -r requirements.txt) and start command (node server.js, npm start, or uvicorn main:app --host 0.0.0.0 --port $PORT).
Read the port from the platform’s PORT environment variable, not a hardcoded 5000 — this is the most common reason a deploy builds but never responds.
Add your Atlas connection string and any keys as environment variables in the service settings.

Know the trade-off: free Render services sleep after about 15 minutes idle and take 30 to 60 seconds to wake. Plan around it — step six covers this.

3. Deploy the frontend on Vercel, Netlify or GitHub Pages

The user-facing app goes on a static/frontend host. All three below have real free tiers.

Vercel — best for Next.js and React. Import the repo, it detects the framework, and deploys on every push.
Netlify — great for React, Vue and plain static sites; set the build command and publish directory.
GitHub Pages — free and simple for a purely static frontend with no server-rendered pages.

Set your live backend URL as an environment variable here (for example VITE_API_URL or NEXT_PUBLIC_API_URL) rather than hardcoding localhost anywhere in the frontend.

4. Wire the frontend to the backend with CORS and env vars

This is where most first deploys break: the site loads, but every request fails. Two fixes, always both.

Point the frontend at the deployed backend URL through the environment variable from step three — not http://localhost:5000.
Enable CORS on the backend for your frontend’s origin, or the browser blocks the response even though the API worked.
Test in an incognito window; a cached old build hides whether the fix actually took.

5. Handle secrets and environment variables properly

Panels do ask where your keys live, and a repo with a database password in it is a real mark loss.

Keep secrets in each platform’s environment variables settings — Atlas string, API keys, JWT secret.
Locally, keep a .env file that is in .gitignore — never committed.
Commit a .env.example listing the variable names only, so anyone (including the panel) can see what is needed without seeing the values.

6. Test the live URL like a stranger would

You know the happy path; the panel does not. Test the way they will.

Open the deployed link on your phone, on mobile data — not your laptop on college wifi with everything cached.
Run every core flow: sign up, log in, create, read, update, delete.
If the backend is on a free tier, hit it a couple of minutes early so the cold start happens before the panel is watching, not during.

7. Prepare a localhost fallback for when the wifi fails

College wifi fails often enough that you must assume it will. A live deploy is the goal, not the only plan.

Keep the project running locally with a seeded database, ready to launch offline.
Record a short screen capture of every flow working, so a dead network never means a dead demo.
Have the deployed URL, the local build, and the video — three layers, so no single failure sinks the viva.

Every project on this site ships deployed on a real URL, with secrets done properly and the localhost fallback ready — because getting it live is exactly the step students run out of time for. See a MERN e-commerce build or a real-time chat app, or if you want it done for you — built, documented, deployed, and walked through in live sessions — start on the custom build page. Deploying first? Read the report format guide so the document matches what you shipped.

How to deploy your final year project for free