All the reading

Deployment

7 lessons, about 28 minutes. The check's questions come from these.

Secrets, databases, and build logs

3. Set production environment variables

4 min

Key point

One rule

Your deployed app cannot read your laptop’s .env file. You must add production environment variables in your hosting provider’s dashboard.

The name must match exactly. DATABASE_URL and database_url are different.

What goes in env

Environment variables store values that change between local and production. They also keep secrets out of GitHub.

Common examples are API keys, database URLs, auth secrets, email service keys, payment keys, and public frontend settings like an API base URL.

Common mistake

Do not commit secrets

Never push .env to a public repo. Recruiters can open your repo, and so can anyone else.

Domains, phones, and submission

6. Add domain and phone checks

4 min

Key point

One final check

A live URL is not enough. Your project should open cleanly from a custom domain if you use one, and it must work on a phone.

Recruiters and judges may open your link on mobile data between meetings. Make the first screen load, fit, and explain the project fast.

Domain basics

A custom domain is optional for many hackathon submissions, but it looks cleaner than a long platform URL. You can use your host URL if you do not own a domain.

If you use a domain, connect it from your hosting dashboard first. Then update DNS records in your domain provider. DNS changes can take time, so do this before the deadline day.

Your to-do

Connect the domain

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

10 questions, 7 to pass.

Example

Write your host plan

Add a short deployment plan to your README before you deploy. It shows recruiters that you understand your production setup.

This is not final documentation. It is a clear decision you can update in later lessons.

## Deployment plan

App type: Vite React frontend + Express API
Frontend host: Vercel
Backend host: Render
Database: MongoDB Atlas

Why:
- Frontend builds to static files using npm run build
- Backend needs a running Node.js server
- Database must be online, not local MongoDB

Commands:
- Frontend build: npm run build
- Backend start: npm start

Environment variables needed later:
- VITE_API_URL
- MONGODB_URI
- JWT_SECRET

Example

Package scripts

For a Vite React app, your scripts may look like this. The build creates the production files. The preview command lets you test them locally.

{
  "scripts": {
    "dev": "vite --host 0.0.0.0",
    "build": "vite build",
    "preview": "vite preview --host 0.0.0.0"
  }
}

Your to-do

Test it locally

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Stop the dev server if it is running.
Run the build command from the project root.
Fix every error shown in the terminal.
Run the preview command after a successful build.
Open the preview URL and test the main user flow.

0 of 5 done

npm run build
npm run preview

Tip

Ask AI carefully

Paste your build error into ChatGPT, Gemini, or Claude and ask for the smallest fix. Also paste your package.json if the error is about scripts or dependencies.

Check the answer before applying it. Make sure it does not remove important code, downgrade random packages, or add secrets into files.

Prompt:
My npm run build fails for this Vite React app. Give the smallest safe fix.
Here is the terminal error:
[paste error]
Here is package.json:
[paste package.json]

Example

Use a safe example

Keep a sample file in the repo so someone can set up the project. It shows names, not real values.

This is useful for your HackIndia submission because reviewers can see what the app needs.

# .env.example
DATABASE_URL=
NEXTAUTH_SECRET=
NEXT_PUBLIC_API_BASE_URL=
RAZORPAY_KEY_ID=
RAZORPAY_KEY_SECRET=

Example

Read env in code

Check the exact names your app reads. Those are the names you must create on the host.

For Node.js apps, process.env reads server-side environment variables.

// server/db.js
const databaseUrl = process.env.DATABASE_URL;

if (!databaseUrl) {
  throw new Error("DATABASE_URL is missing");
}

export { databaseUrl };

4. Connect a hosted database

4 min

Key point

One database URL

Your app should read the database connection from an environment variable, usually DATABASE_URL. Do not hard-code the database password in your code.

Local development can use a local database. Production must use the hosted database URL set in your host dashboard.

Pick the right database

Use the same database type your app already uses. If your project uses PostgreSQL locally, choose hosted PostgreSQL. If it uses MySQL, choose hosted MySQL.

Free tiers are enough for most hackathon projects. Neon, Supabase, Render PostgreSQL, Railway, PlanetScale, and MongoDB Atlas are common choices, depending on your database type.

Your to-do

Create the database

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Open your database provider dashboard.
Create a new project or database in the nearest available region.
Copy the production connection string.
Save the username, password, host, database name, and port somewhere private.
Add the connection string to your deployment host as DATABASE_URL.

0 of 5 done

Common mistake

Common wrong move

Many builders paste the hosted database URL into a .env file and commit it. That exposes your password in the public repo.

Your repo should show the variable name, not the real value. Put real secrets only in your host dashboard and your local .env file, which should be ignored by Git.

Example

Env file pattern

Your README can show this example without leaking secrets. Your real .env file should not be committed.

# .env.example
DATABASE_URL="postgresql://USER:PASSWORD@HOST:5432/DB_NAME?sslmode=require"

# .gitignore
.env
.env.local

Your to-do

Set up schema

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Check how your app creates tables: migrations, ORM sync, SQL file, or seed script.
Point your terminal to the hosted DATABASE_URL only when you are ready.
Run the migration command once against production.
Run any seed command only if your app needs starter data.
Open the hosted database dashboard and confirm tables were created.

0 of 5 done

Example

Prisma migration example

If your Node app uses Prisma, run migrations against the hosted database. Do not use db push blindly on a shared production database.

# macOS/Linux
DATABASE_URL="postgresql://USER:PASSWORD@HOST:5432/DB_NAME?sslmode=require" npx prisma migrate deploy

# Windows PowerShell
$env:DATABASE_URL="postgresql://USER:PASSWORD@HOST:5432/DB_NAME?sslmode=require"
npx prisma migrate deploy

Tip

Test one real flow

After deploy, do the smallest database action your app supports. Sign up, create a note, add a listing, place a test order, or save a profile.

Then refresh the page. If the data is still there, your hosted app is using the hosted database correctly.

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Create a hosted database that matches your app.
Add DATABASE_URL in your deployment host environment variables.
Run your schema or migration command against the hosted database.
Deploy again and test one create-read flow on the live URL.
Add DATABASE_URL to .env.example and setup steps to your README.

0 of 5 done

5. Debug host build failures

4 min

Key point

Find first failure

A host build log is a story from top to bottom. Do not start at the last red line. Scroll up and find the first error that stopped the build.

Warnings are usually not the reason your deploy failed. The first error with a file name, package name, or command is your target.

Your to-do

Read the log

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Open the failed deployment in your host dashboard.
Find the build logs or deployment logs tab.
Search for words like error, failed, cannot find, module not found, or command failed.
Copy the first useful error line into your notes.
Check which step failed: install, build, or start.

0 of 5 done

Common failure types

Install failures happen before your app builds. They are often package lock, Node version, or missing dependency issues.

Build failures happen when the host runs your build command. They often come from TypeScript errors, lint errors, missing env variables, wrong imports, or code that only worked on your laptop.

Common mistake

Do not guess

Beginners often change many files, redeploy, and hope. That makes the real fix hard to find.

Change one thing at a time. Commit the fix with a clear message like fix build missing dependency or fix production env check.

Example

Module not found

This error means the build cannot import a file or package. On your laptop, it may work because of cache or case-insensitive file paths.

Check the exact spelling and capital letters. Hosts commonly build on Linux, where Navbar.jsx and NavBar.jsx are different file names.

Error: Module not found: Can't resolve './components/NavBar'

Your file:
src/components/Navbar.jsx

Fix the import:
import Navbar from './components/Navbar';

Example

Missing build command

Your host needs to know how to build your project. Use the same command that works locally after a fresh install.

Test it before pushing. If this fails on your laptop, it will fail on the host too.

npm install
npm run build

package.json
{
  "scripts": {
    "dev": "vite --host 0.0.0.0",
    "build": "vite build",
    "preview": "vite preview"
  }
}

Tip

Use AI carefully

Paste the first error and your package.json into ChatGPT, Gemini, or Claude. Ask for likely causes and the smallest fix.

Check every suggestion. Do not paste secrets. Do not accept random version changes unless the error points to a version problem.

Prompt:
My hosted build fails. Here is the first error and my package.json.
Tell me the likely cause, the smallest fix, and what command to run locally to verify it.
Do not suggest unrelated rewrites.

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Open your latest failed deployment log, or create a fresh deploy if needed.
Copy the first real error into a local note.
Run npm install and npm run build on your laptop.
Fix one cause, commit it, and push again.
Add a short note to your README if the fix changes setup steps.

0 of 5 done

Example

DNS record example

Your host will give the exact values. Do not guess them. The pattern often looks like this.

Type: CNAME
Name: www
Value: your-project.vercel.app

Type: A
Name: @
Value: 76.76.21.21

Tip

Use AI for review

Take two screenshots: desktop and phone. Ask an AI tool to review layout, clarity, and mobile usability. Treat the answer as a checklist, not truth.

Check what it suggests. AI may miss broken buttons, slow loading, auth issues, or database errors. You still need to test the real app yourself.

Prompt:
Review these screenshots of my deployed project.
Tell me only the mobile issues that could hurt a hackathon submission.
Check: first-screen clarity, text size, button size, overflow, and confusing navigation.

7. Submit your deployed repo

4 min

Key point

Make it reviewable

Your submission is not only your app. It is your live URL plus a public repo that explains how to run, build, and configure it.

Assume a recruiter opens it on a phone during a short break. They should understand the project in two minutes.

Your to-do

Final repo checklist

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Set your GitHub repository to public.
Push the latest working code to the default branch, usually main.
Add a README with setup steps, build command, and environment variable names.
Check that the live deployed URL uses the latest commit.
Open the app once on mobile data, not only college Wi-Fi.

0 of 5 done

Example

README starter

Use this as a simple README structure. Do not paste secret values. Only write variable names and what they are for.

# Campus Mess Feedback

A web app for students to submit mess food feedback and for admins to view common issues.

## Live demo
https://your-app-url.com

## Tech stack
- React
- Node.js
- PostgreSQL

## Setup
1. Clone the repo
2. Install dependencies
3. Create a .env file using the variables below
4. Run the app locally

## Commands
npm install
npm run dev
npm run build

## Environment variables
DATABASE_URL=your_postgres_connection_string
JWT_SECRET=your_login_secret
NEXT_PUBLIC_APP_URL=your_app_url

## Test login
Student: [email protected] / password123
Admin: [email protected] / password123

## Notes
The deployed app uses a hosted PostgreSQL database.

Common mistake

Do not leak secrets

Never commit your .env file, database password, API keys, or JWT secret. Reviewers need the variable names, not your real values.

If you already pushed a secret, rotate it in the provider dashboard. Deleting the line later is not enough because Git history may still contain it.

Tip

Use AI safely

Ask ChatGPT, Gemini, or Claude to improve your README. Paste your current README and say: “Make this clear for a recruiter. Keep setup steps, build command, env variable names, live demo, and test login.”

Check the output. AI may invent commands, tools, or features. Keep only what matches your actual project.

Your to-do

Submission check

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Open your GitHub repo in an incognito window and confirm it is public.
Click the live demo link from the README and confirm it opens.
Try the main user flow, such as signup, search, upload, checkout, or dashboard view.
Run a fresh clone locally if you have time, using only the README.
Take note of any known issue in the README instead of hiding it.

0 of 5 done

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Update your README with live URL, setup steps, build command, and env names.
Remove any committed .env file and confirm .gitignore includes it.
Push your final code to GitHub.
Open the deployed app on your phone and test the main flow.
Submit the public repo URL and live deployed URL on HackIndia.

0 of 5 done

Deployment

1. Choose the right host

Pick by runtime

Know your app type

Match common stacks

Common wrong choice

2. Prepare a production build

Build before deploy

Dev is forgiving

Find your build command

3. Set production environment variables

One rule

What goes in env

Do not commit secrets

6. Add domain and phone checks

One final check

Domain basics

Connect the domain

Use free tiers carefully

Write your host plan

Do this now

Package scripts

Test it locally

Do not deploy junk

Ask AI carefully

Do this now

Use a safe example

Add them on host

Know public prefixes

Read env in code

Do this now

4. Connect a hosted database

One database URL

Pick the right database

Create the database

Common wrong move

Env file pattern

Set up schema

Prisma migration example

Test one real flow

Do this now

5. Debug host build failures

Find first failure

Read the log

Common failure types

Do not guess

Module not found

Missing build command

Use AI carefully

Do this now

DNS record example

Common DNS mistake

Check on phone

Use AI for review

Do this now

7. Submit your deployed repo

Make it reviewable

Final repo checklist

README starter

Do not leak secrets

Use AI safely

Submission check

Do this now