Skill reading | HackIndia

1. Why Docker Fixes Setup Pain

4 min

The setup problem

You build a web app on your laptop. It runs because your machine has the right Node, Python, Java, database client, environment variables, and port settings.

Then your teammate clones it in hostel Wi-Fi before a hackathon demo. It fails. Their laptop has a different version, missing package, or no database running.

Key point

One idea

Docker makes your app’s running setup explicit. Instead of saying “install some things and try npm start”, you describe the OS-level environment, dependencies, ports, variables, storage, and start command.

What Docker adds

A Dockerfile is a text file with commands used to assemble an image. The image is the packaged version of your app setup.

A container is a running copy of that image. If the image is built the same way, the app has a much better chance of running the same way on another laptop.

Example

Plain project story

Without Docker, your README may depend on hidden local setup. With Docker, the important setup starts moving into files that a reviewer can run.

You will write the real Dockerfile in the next lesson. For now, notice the shape: choose a base, set a folder, copy code, install dependencies, start the app.

FROM node:22-alpine
WORKDIR /app
COPY . .
RUN yarn install --production
CMD ["node", "./src/index.js"]

Where Compose fits

Most useful web apps need more than one process. For example, your app plus Postgres. Docker Compose is used to run these services together from one Compose file.

2. Write Your First Dockerfile

4 min

Key point

One mental model

A Dockerfile is a recipe for your app image. It starts from a base image, adds your app files, installs dependencies, documents the port, and sets the start command.

What goes inside

Docker reads the Dockerfile from top to bottom. Each line should make the app closer to being runnable on another laptop.

For a beginner web app, keep it boring. Pick the runtime image, set a working folder, copy files, install packages, and set the command that starts the server.

Example

Node app example

Use this shape for a basic Node app. Change the start file or command to match your project.

The first line asks Docker BuildKit to use the current stable Dockerfile syntax. The FROM line must come before normal build instructions.

# syntax=docker/dockerfile:1
FROM node:22-alpine

WORKDIR /app

COPY . .

RUN yarn install --production

EXPOSE 3000

CMD ["node", "./src/index.js"]

3. Build And Run Your Image

4 min

Key point

One loop

The loop is: build an image, run a container, open the app, fix errors, rebuild. Your Dockerfile is not proven until the app works from the image on your laptop.

An image is the packaged app. A container is a running copy of that image.

Your to-do

Build the image

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 a terminal in the folder that has your Dockerfile.
Choose a short image name, usually your project name.
Run the build command with the current folder as the build context.
Wait for Docker to copy files, install dependencies, and set the startup command.
Fix Dockerfile or dependency errors, then build again.

0 of 5 done

5. Add Compose For App Plus Database

4 min

Key point

One file, two services

Compose is for running a small stack, not just one container. In this lesson, your stack has an app service built from your Dockerfile and a database service pulled from an image.

The app talks to the database by service name, like db. Compose creates the network for you.

What Compose adds

Your Dockerfile says how to build your app image. compose.yaml says which containers run together, which ports are published, and which volumes keep data.

Use docker compose, with a space. Older tutorials may show docker-compose with a hyphen. Treat that as old style.

Example

Basic compose file

This example is for a Node app and Postgres. Change the app port, command, and database variables to match your project.

4. Keep Data With Volumes

4 min

Why data disappears

A container is meant to be replaceable. If you remove it, anything written only inside that container can go with it.

That is fine for code. It is bad for a database, uploaded images, SQLite files, or generated reports you need after a restart.

Key point

The core idea

Use a volume when data must outlive a container. The image gives the app its starting files; the volume keeps changing data outside the container lifecycle.

What volumes hold

A volume can store database files, user uploads, cache files, or local development data. For your hackathon repo, it matters most for the database.

Without a volume, your reviewer may run the app, create test data, restart containers, and lose everything. That looks broken even if your app code is fine.

Example

Compose volume shape

You will build the full app plus database Compose file in the next lesson. For now, read the volume part.

This example uses a named volume called pgdata and mounts it where the database stores its files.

services:
  db:
    image: postgres
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

Named versus host path

Compose volumes can mount named volumes or host paths into service containers. Named volumes are usually easier for a shared college project because Docker manages the storage location.

Host paths are useful when you want a local folder from your laptop visible inside the container, like live source code during development. They are easier to mess up across Windows, macOS, and Linux laptops.

Common mistake

Mounting over app files

A common beginner mistake is mounting a volume onto the same folder where your image copied the app code. The mount can hide the files already in the image.

Mount data folders only. For example, mount a database data directory or uploads directory, not the whole app folder unless you know why.

Tip

Prefer clear names

Name volumes after what they store, not after the tool. pgdata, mongo-data, uploads, and redis-data are easier to review than data1.

In current Compose files, reusable volumes should also be declared in the top-level volumes section. Older examples may skip this or include an old top-level version field; you do not need that version field in current Compose examples.

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.

List the data your app creates, such as database rows, uploads, logs, or reports.
Mark which data should survive after containers are removed.
Choose a clear named volume for each important data folder.
Write down the container path where that tool stores its data.
Avoid mounting over your app source folder unless you are doing live development on purpose.

0 of 5 done

6. Handle Environment Variables Safely

4 min

Key point

One rule

Do not bake secrets into your image. Pass them at runtime through Compose, and commit only safe example values.

A Dockerfile ENV value stays in the image and can be viewed later. Use it only for harmless defaults, not passwords, API keys, JWT secrets, or database URLs.

Two env files

You usually need two files. One real file for your laptop, and one example file for the repo.

The real file is named .env and should be ignored by Git. The example file can be named .env.example and should be committed.

Example

File setup

Your repo can show reviewers exactly what to create without leaking secrets.

Use values that make sense locally. For a hackathon project, a simple local password is fine in .env.example if it is only for local Docker development.

.gitignore
.env
node_modules

.env.example
APP_PORT=3000
DATABASE_URL=postgres://app_user:app_password@db:5432/app_db
POSTGRES_USER=app_user
POSTGRES_PASSWORD=app_password
POSTGRES_DB=app_db

Example

Compose wiring

Compose can read variables from a .env file in the project directory. It can then pass them into each service container.

Inside the app container, the database host is db because that is the Compose service name.

services:
  app:
    build: .
    ports:
      - "127.0.0.1:${APP_PORT}:3000"
    environment:
      DATABASE_URL: ${DATABASE_URL}
    depends_on:
      - db

  db:
    image: postgres:16
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

Your to-do

Use it safely

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 .env by copying .env.example.
Change secrets in .env if the project will be used beyond local testing.
Read env variables in your app code, not from hard-coded strings.
Run the app with the modern docker compose command.
Open the app and test one feature that touches the database.

0 of 5 done

cp .env.example .env
docker compose up --build

Common mistake

Common leak

Beginners put DATABASE_URL or API keys in the Dockerfile with ENV. That makes the value part of the image metadata.

Another common issue is committing .env by mistake. Check git status before pushing your repo.

git status

Tip

Check AI output

If you ask ChatGPT or Gemini to write Compose config, check three things before using it.

It should use docker compose, not old docker-compose. It should start with services:, not a top-level version:. It should not publish database ports unless you really need them from your laptop.

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.

Add .env to .gitignore.
Create .env.example with every required variable and safe sample values.
Update compose.yaml to read values with ${VAR_NAME}.
Remove secrets from your Dockerfile and source code.
Run docker compose up --build from a fresh terminal.

0 of 5 done

7. Make The Repo Recruiter-Ready

4 min

Key point

One simple test

A recruiter-ready repo passes the fresh laptop test. Someone should clone it, create the required environment file, run docker compose up, and see the app locally.

Do not assume they know your college project folder, your local database name, or your secret keys.

What reviewers look for

Your Dockerfile and Compose file prove the app can run outside your laptop. Your README proves another human can use it.

Think of the README as your project’s first interview answer. It should explain what the app does, how to run it, and what to check after it starts.

Your to-do

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.

Add a short project description at the top of README.
List prerequisites: Docker Desktop or Docker Engine with Docker Compose.
Show the exact env file name to create, such as .env.
Show one run command using docker compose, not the older docker-compose.
Mention the local URL and the expected page or API response.
Add a screenshot or short screen recording link if your app has a UI.

0 of 6 done

Example

README run section

Use a copy-paste section. Keep it boring and exact. Replace the names and ports with your project details.

Run locally with Docker

1. Clone the repo
   git clone https://github.com/your-name/your-project.git
   cd your-project

2. Create the environment file
   cp .env.example .env

3. Start the app and database
   docker compose up --build

4. Open the app
   http://localhost:3000

Expected result
You should see the login page. If you are testing the API, open http://localhost:3000/health and expect {"status":"ok"}.

Tip

Use .env.example

Commit .env.example, not .env. The example file tells reviewers what variables exist without leaking passwords, tokens, or UPI/payment test keys.

Use safe dummy values. If a value must be created by the reviewer, write a comment beside it.

# .env.example
APP_PORT=3000
DATABASE_URL=postgres://app_user:app_password@db:5432/app_db
POSTGRES_USER=app_user
POSTGRES_PASSWORD=app_password
POSTGRES_DB=app_db
JWT_SECRET=change_me_for_local_testing

Common mistake

Common weak README

Beginners often write only: run npm install, start Postgres, set env, run the app. That defeats the point of this track.

If the project uses Compose, the main path should be Docker first. Native setup can be a second section, not the main proof.

Your to-do

Test like a reviewer

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.

Move to a different folder outside your coding workspace.
Clone your own public repo again.
Create .env from .env.example and change only what the README says.
Run docker compose up --build.
Open the listed URL and confirm the expected result appears.

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.

Add or update README with the Docker run section.
Create .env.example with every required variable and no real secrets.
Check that your Compose file starts with services, not an old version field.
Run a fresh clone test using docker compose up --build.
Push the changes and ask a friend to run the repo from the README only.

0 of 5 done

Docker

1. Why Docker Fixes Setup Pain

The setup problem

One idea

What Docker adds

Plain project story

Where Compose fits

2. Write Your First Dockerfile

One mental model

What goes inside

Node app example

3. Build And Run Your Image

One loop

Build the image

5. Add Compose For App Plus Database

One file, two services

What Compose adds

Basic compose file

Common wrong belief

Use AI carefully

Do this now

Read each line

EXPOSE is not publish

Ask AI carefully

Do not hide secrets

Do this now

Run a web app

What port mapping means

Name your container

Rebuild after changes

Debug first failures

Do this now

4. Keep Data With Volumes

Why data disappears

The core idea

What volumes hold

Compose volume shape

Named versus host path

Mounting over app files

Prefer clear names

Do this now

Run the stack

Publish the app only

Do not expose publicly

Keep database data

Do this now

6. Handle Environment Variables Safely

One rule

Two env files

File setup

Compose wiring

Use it safely

Common leak

Check AI output

Do this now

7. Make The Repo Recruiter-Ready

One simple test

What reviewers look for

Repo checklist

README run section

Use .env.example

Common weak README

Test like a reviewer

Do this now