How to Deploy a Student Project and Add It to Your Resume

You built something. It runs on your laptop at 2am. Now you need a URL that a recruiter in Bengaluru can open on a phone, on patchy 4G, without you standing next to them explaining what went wrong. That gap — between "works on my machine" and "works for a stranger" — is where most student projects die. This guide covers what to deploy, where to host it, how to keep a free tier from embarrassing you during placement season, and how to write the resume bullet so the link actually gets clicked.

What does "deployed" mean for your project type?

Deployed means a stranger can open a URL and use the thing without installing anything. That definition changes depending on what you built. A React frontend, a Node-plus-Postgres app, and a Jupyter notebook are three different deployment problems, and picking the wrong host for your category is the single most common reason student deploys fail.

Match your project to the row below before you sign up for anything.

If you're a mechanical, civil, or ECE student, the Python/Streamlit row is your friend. A Streamlit dashboard that reads a CSV and plots results is a legitimate deployed project. It doesn't need a backend, a database, or a domain. It needs to load.

Which free host should you actually pick?

For a static frontend, GitHub Pages is the lowest-friction option because your repo and your deploy live in the same place — push to main, the site updates. Netlify and Vercel add preview deploys and a slightly nicer dashboard, which matters if you're iterating fast. For a full-stack app, Render and Railway are the usual starting points; both give you a free web service plus a managed database, with the caveat that the free web service sleeps after a period of inactivity.

That sleep behaviour is the trap. A sleeping backend takes somewhere between 30 and 60 seconds to wake on the first request, and if your frontend fires an API call on page load, the user sees a spinner, then a timeout error, then they close the tab. You never find out. The interviewer just assumes the project is broken.

Use all three mitigations, not one. The uptime pinger keeps the service warm during placement season. The README note sets expectations if it still sleeps. The demo video is your insurance policy when the free tier dies entirely — and it will, usually the week you need it most.

How do you fix "works locally, 500s in production"?

Nine times out of ten, the cause is an environment variable that exists in your local .env file but was never added to the host's dashboard. Your code reads process.env.DATABASE_URL, finds nothing, and throws. The fix is mechanical: list every variable your app needs, open the host's environment settings panel, and add them one by one with the exact same names.

The second most common cause is a hardcoded localhost in your frontend. Your fetch call points to http://localhost:5000/api/data, which works on your laptop and means nothing on the internet. Replace it with your deployed backend URL, ideally through an environment variable so you don't hardcode it again.

The third cause is CORS. Your deployed frontend lives on one domain, your deployed backend on another, and the browser blocks the request by default. Your backend needs to explicitly allow your frontend's origin. This is a five-line fix in Express, Flask, or FastAPI, and it's worth learning once because you'll hit it on every full-stack project you ever deploy.

Never commit API keys, database passwords, or secret tokens to GitHub. If you already have, rotate the key immediately — assume it's compromised the moment it hits a public repo. Then add a .gitignore entry for .env and commit a .env.example with placeholder values so anyone reading the repo knows what's required.

Do you need a custom domain, or is a free subdomain fine?

A free yourproject.vercel.app or yourproject.netlify.app link is completely acceptable for internships and most fresher roles. Recruiters care that the link loads and the project is real. Nobody has ever been rejected for not owning a domain.

A custom domain earns its keep in two situations. First, final-year portfolios where you're applying to product companies and a personal site is part of the signal. Second, freelance or client work, where a .in or .dev domain reads as more professional than a random subdomain. Expect to pay somewhere in the ₹700–₹1,200 per year range depending on the registrar and first-year offers.

Connecting it is a DNS step: you add a CNAME record pointing your domain to the host's provided target, then wait for propagation. Most hosts walk you through it in their dashboard. If DNS intimidates you, skip it. A working free link beats a broken custom domain every single time.

How should the deployed link appear on your resume?

The link goes on the same line as the project title, or immediately below it, and it must be visible as text — not buried behind a hyperlink that vanishes when the PDF is printed. Recruiters often review printed or screenshot resumes. If your URL isn't readable, it doesn't exist.

Write the bullet in three parts: what problem the project solves, what stack you used, and one measurable outcome. Most students write only the middle part. That's the weakest of the three.

Notice the "40+ students" number. It doesn't need to be impressive. It needs to be true and specific. If nobody used your project, say "built for a class of 60" or "handles a 10,000-row dataset." Any concrete scope beats vague adjectives like "advanced" or "robust."

For more on structuring the rest of the resume, see how to write project bullets on a fresher resume.

Why your README is the real second interview

A recruiter clicks your link. A senior engineer on the panel opens your GitHub repo. That engineer spends maybe 90 seconds scanning your README before deciding whether to read your code. Most student READMEs are a single line — the project name — and that's where the shortlist is lost.

A README that survives the scan has five things, in this order:

• One paragraph on what the project does and who it's for.
• Setup steps that actually work from a clean clone — including the .env.example and the install command.
• At least one screenshot or GIF of the working app.
• A short architecture sketch — boxes and arrows are fine, a text diagram is fine.
• A "known limitations" and "what I'd do next" section.

That last section is the one that separates you from every other candidate. Writing "the free tier sleeps after 15 minutes, so the first load may take a minute" tells the engineer you understand your own deployment. Writing "I'd add pagination and move the image processing to a background job" tells them you can think past the assignment. Both cost you ten minutes.

If your repo has no README structure at all, start with build a GitHub portfolio that recruiters actually open before you deploy anything else.

What if the live link dies during placement season?

It will, eventually. Free tiers change their terms, databases hit row limits, and a backend you haven't touched in three months quietly stops responding. The students who survive this are the ones who treated the live URL as one of three proofs, not the only one.

The three proofs are: the live link, the GitHub repo with a real README, and a 60–90 second screen recording. Record the demo on your phone or with a screen recorder, narrate what you're doing, and upload it as an unlisted YouTube video or drop it in your repo's /assets folder. Link it right next to the live URL on your resume as "Demo video."

Now if the link is down when an interviewer opens it, they still have the video, and the video still shows a working product. That's the difference between "the link is broken" and "the link is broken but here's proof it works."

Does the deployment actually matter for placement outcomes?

It matters differently depending on where you're applying. Service companies — TCS, Infosys, Wipro, Cognizant — screen primarily on aptitude and communication, so a deployed link is a nice-to-have that helps in the HR round if you can talk through it. Product companies, startups, and GCCs weight the project more heavily, and there the link is often the first thing a technical interviewer opens.

Either way, the deployment itself changes how you interview. When your project is live and someone has used it, you answer questions differently — you talk about the cold start you fixed, the CORS error you debugged, the environment variable that broke production. Those are real engineering stories. "I built a CRUD app" is not.

If you're still deciding what to build, start with final-year project ideas worth deploying, and if you're navigating the non-campus route, the off-campus placement preparation guide covers how the timeline differs. Before you spend another weekend on features, it's worth knowing where you actually stand — check your coding round readiness or take the free aptitude assessment so you're deploying the right thing for the roles you're targeting.

Frequently asked questions

Is a free hosting link good enough for a placement resume?

Yes, for internships and most fresher roles. Recruiters care that the link works and the project is real. A custom domain helps mainly for final-year portfolios and freelance work. If you buy one, a .in or .dev domain runs roughly ₹700–₹1,200 per year and connects in about ten minutes via CNAME.

My deployed project works locally but shows an error online. What's wrong?

Three usual suspects: environment variables missing from the host's dashboard, a hardcoded localhost URL in your frontend, or a free-tier backend that has slept or hit its monthly limit. Check the host's build logs first — they almost always name the missing variable or the failed step.

Will recruiters actually open my project link?

Many will, especially at product companies and startups. Service companies screen on aptitude first, so the link matters less there but still helps in the technical discussion. Assume it gets opened on a phone with patchy data, and test it that way before you share it.

Is a simple CRUD app worth deploying?

Yes, if you frame it honestly. A deployed CRUD app with a clean README, screenshots, and a "what I'd improve" section beats an undeployed "advanced" project, because it proves you can ship. Don't call it production-grade. Describe the scope, the stack, and one thing you'd change.

How do I keep my free-tier project from sleeping during placement season?

Three layers: a README note that the first load may take 30–60 seconds, a free uptime pinger hitting your backend every 10–14 minutes, and a 60–90 second demo video linked next to the live URL. Never let a single free backend be your only proof of work.