Deploying Your Portfolio Project: Why It Matters and How to Do It

TL;DR - A GitHub link shows code. A deployed link shows working software. Reviewers notice the difference. - Render, Vercel, Railway, and Fly.io all have free tiers. Pick one based on your stack, not on what's trending. - Free tiers have real limitations (cold starts, sleep modes, limited hours). Know them before your interview. - Put the live URL in your README, on your resume, and in every application that asks for portfolio links. - If the app is asleep when a reviewer visits, a cold start message ("Loading, please wait...") is far better than a blank screen.

Hiring managers and technical reviewers look at a lot of GitHub profiles. After a while, they develop a quick filter: does this project actually run?

Many candidates stop at writing the code and pushing it to a repo. That's understandable. Deployment adds steps, things can break, and it feels like extra work when you're already grinding through applications. But the candidates who deploy their projects signal something specific: they care about finished software, not just finished code.

That's the difference between a project and a product. You want your portfolio to show product thinking.

Why "It's on GitHub" Is Not Enough

A recruiter or hiring manager clicking your repo link will see a wall of files. They probably won't clone the project and run it locally. Even technical reviewers who could do that usually won't, because they're evaluating dozens of candidates.

What they will do: look for a live link. If they don't find one, many will move on. If they do find one, they'll click it. Within thirty seconds they know whether the thing actually works.

A working deployed app also tells them: - You know the gap between "it works on my machine" and "it works in production" - You've dealt with environment variables, build steps, and deployment configs - You understand that software has to run somewhere for someone

None of this is magic. Deployment is learnable. But surprisingly few junior candidates bother with it, which means doing it puts you ahead of the majority.

Which Platform to Use

There's no single right answer. Pick based on your tech stack and how much configuration you want to manage.

Render

Render is a good default for backend-heavy apps. If you're running a Rails API, a Node/Express server, or a Django app, Render will feel familiar. You connect your GitHub repo, set environment variables in a UI, and Render handles the rest.

Use Render if: you have a backend service, you're building with Rails, Node, Python, or Go, and you want a straightforward deployment with minimal DevOps work.

Free tier gotcha: Render's free tier spins down your web service after 15 minutes of inactivity. The next request causes a cold start that can take 30-60 seconds. For a portfolio project, this is fine. Just add a short message on your app's loading state so a reviewer knows what's happening. Some people set up a cron job to ping the app every 14 minutes to keep it warm, though this uses up your free compute hours.

Vercel

Vercel is built for frontend frameworks, especially Next.js (which makes sense, since Vercel created Next.js). If your project is a React, Vue, or Svelte app with an API layer or serverless functions, Vercel is the fastest path to a deployed URL.

Use Vercel if: your project is frontend-focused, uses Next.js, or is a static site with API routes. Deployment is genuinely one of the fastest in the industry. Push to main, get a URL.

Free tier gotcha: Vercel's free tier limits serverless function execution time (10 seconds by default) and bandwidth. For portfolio work, you'll rarely hit these. The bigger limitation is that Vercel isn't well-suited for running persistent server processes, so if you have a long-running backend, look elsewhere.

Railway

Railway sits in a useful middle ground. It handles full-stack apps cleanly: a web service plus a database, both in one project with environment variables shared between them. The developer experience is smooth, and the pricing model (you pay for what you use) is honest.

Use Railway if: you have a full-stack app with a database and you want both running in one place with minimal configuration. It's also good for projects that need a persistent process (like a WebSocket server) where Vercel's serverless model won't work.

Free tier gotcha: Railway has moved to a usage-based model. There's a small free credit each month. A dormant portfolio app will usually stay within it, but if your app has real traffic or runs background jobs, monitor your usage. The credit can disappear faster than you expect.

Fly.io

Fly.io is for people who want more control. You deploy using Docker, which means you can run nearly anything: Rails, Go, Elixir, Rust, whatever your stack is. Fly runs your app on actual machines (VMs), not serverless containers, so you don't get cold start problems the same way.

Use Fly.io if: you're comfortable with Docker, you want global edge deployment, or you have a stack that doesn't fit neatly into the other platforms. It's also good for apps that need persistent connections or long-running background workers.

Free tier gotcha: Fly.io's free allowances are reasonable for small apps, but the setup is more involved. You need to write a Dockerfile and use their CLI (flyctl). If you've never used Docker before, this isn't where to learn it for the first time.

Supabase (for your database)

Supabase deserves a separate mention because it's not a general deployment platform. It's specifically for Postgres databases, with a built-in API layer and authentication.

If your app needs a database and you're not using Railway's built-in Postgres, Supabase is a solid free option. Connect it to your app deployed on Render or Fly.io, keep credentials in environment variables, and you have a complete backend stack.

Free tier gotcha: Supabase pauses inactive projects after 7 days on the free tier. You can unpause manually, but if a reviewer hits your app while the database is paused, they'll get errors. Either upgrade to a paid tier ($25/month) or keep the project active. Some people set up a scheduled query to prevent inactivity pauses.

A Quick Decision Framework

Your stack	Best choice
Rails backend	Render
Next.js / React	Vercel
Full-stack + database	Railway
Docker-based anything	Fly.io
Needs a real Postgres DB	Supabase (pair with another platform)

Handling the Cold Start Problem

Cold starts are real and they affect the reviewer experience. If someone clicks your app and sees a blank screen for 45 seconds, they might think it's broken and close the tab.

A few approaches:

Add a loading indicator. If your frontend makes an initial API call to your backend, show a spinner or a message that says "Loading... (this may take a moment on first visit)." This sets expectations.

Use a free uptime service. Tools like UptimeRobot can ping your app on a schedule. This keeps Render's free tier from sleeping. Just be aware of your platform's fair use policies.

Document it in your README. A sentence like "Hosted on Render's free tier. First load may take ~30 seconds to wake the server." shows self-awareness and professionalism. It's better than leaving a reviewer confused.

How to Document the Live URL

Once your app is deployed, put the URL in three places:

1. Your GitHub repository.

In your README.md, add a "Live Demo" section near the top with a direct link. Don't bury it. Many reviewers go to the repo first, and the README is their entry point. See how to write a README that actually helps your portfolio for the full breakdown.

Also add the URL to the repository's "About" section (the little gear icon on the right side of your repo's main page). This shows the link on the repo listing without anyone having to open the README.

2. Your resume.

Under the project entry, include the deployed URL as part of the project description. For example:

Personal Finance Tracker | Rails, React, PostgreSQL
Live: https://finance-tracker.up.railway.app | Code: github.com/you/finance-tracker

If the URL is long or ugly (some free-tier URLs are), use a custom domain or a link shortener. A clean URL reads better on a resume.

3. Every application that has a portfolio field.

Job applications often have a separate field for portfolio links. Use the deployed URL, not the GitHub link. If there's only one field, use the deployed URL and include the GitHub link in the project's README instead.

Setting Up Environment Variables the Right Way

One reason candidates avoid deployment is that it forces them to think about environment variables properly. But this is a good thing. It's a skill you'll use in every professional job.

The basic rules:

Never commit .env files or API keys to GitHub. Add .env to your .gitignore before you push anything.
Set environment variables through your platform's dashboard (Render, Railway, and Fly.io all have UI for this).
In your README, document which environment variables are required and what they do. Don't include the actual values, just the variable names and a description.

A proper .env.example file in your repo (committed, with placeholder values) shows reviewers what configuration your app needs. This is standard practice in professional teams.

Before You Share the Link

Run through this checklist before adding your deployed URL anywhere:

[ ] Does the app actually load without errors?
[ ] Are there any console errors that a reviewer would notice if they opened DevTools?
[ ] Does the core functionality work end-to-end (not just the homepage)?
[ ] Is the README updated with the live URL?
[ ] Have you tested the link on a different browser or device?
[ ] If it's an API, does your README include example API calls?
[ ] Have you removed any test data or placeholder content that looks unprofessional?

One common mistake: deploying the app and sharing the link without actually testing it in the deployed environment. Things that worked locally often break in production because of missing environment variables, different database configs, or build errors that only show up when the code is compiled. Test it.

The Broader Point

Deployment is table stakes in a professional environment. Every app you'll work on as a software engineer will need to run somewhere. Companies use CI/CD pipelines, staging environments, and production deploys constantly.

A candidate who has deployed their own projects at least understands the concept. They've dealt with environment variables, watched a build fail and debugged it, and seen their code running in the wild. That experience doesn't go unnoticed.

If you haven't picked a project worth deploying yet, read how to pick a portfolio project first. Get the project right before worrying about where to host it.

And once it's deployed, make sure the rest of your GitHub presence reflects the same level of care. Your GitHub profile itself is a portfolio asset.

If you want structured support putting together a portfolio that gets you interviews, here's how the Globally Scoped program works.