Deployment - lesson 4 | HackIndia Skills

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

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

Quick check