DEV Community: Nishant Gaurav

Your Code Runs Locally. GitHub Actions Makes It Run Everywhere, Automatically.

Nishant Gaurav — Tue, 16 Jun 2026 14:30:00 +0000

You've pushed code to GitHub before. You know the drill: write something, commit it, push it, then manually do whatever comes next. Run the tests. Deploy the site. Update the docs. Every time, by hand.

GitHub Actions is the answer to "what if that next step just happened on its own?" It lets you define automated workflows that trigger whenever something happens in your repository. A push, a pull request, a schedule, even a manual button click. The workflow runs on GitHub's servers, not yours. You define the steps in a YAML file, commit it to your repo, and GitHub takes it from there.

This article walks through exactly how that works, using a real project as the example throughout: recLog, an automated pipeline that fetches articles from Dev.to and injects them into a portfolio's HTML without any manual update.

The Problem: Manual Steps After Every Push Don't Scale

Here's the situation that recLog was built to solve.

You write an article on Dev.to. You publish it. Now your portfolio is out of date because it lists your articles as static HTML that you maintain by hand. So you open your portfolio repo, copy in a new article card, adjust the HTML, commit, and push. Every. Single. Time.

This is fine once. It's annoying at ten articles. By twenty, you've already stopped doing it, which means your portfolio is quietly going stale while your actual writing keeps going.

The broader pattern is everywhere in software development. You push code and need to run tests before merging. You merge to main and need to deploy. You update a dependency and need to check if anything breaks. These are predictable, repeatable steps. Doing them manually introduces delay, inconsistency, and the very human tendency to skip them when you're in a hurry.

GitHub Actions turns these steps into automated workflows that live inside your repository. When the trigger fires, GitHub spins up a fresh machine, runs your defined steps in order, and reports back what happened. No server to maintain, no third-party CI tool to configure separately, no deploy keys to manage outside the repo.

How GitHub Actions Actually Works

The mental model

GitHub Actions is built around four concepts you need to understand before writing a single line of YAML: workflows, events, jobs, and steps.

A workflow is the top-level automation unit. It's a single YAML file that lives in .github/workflows/ inside your repository. One repo can have multiple workflow files, and each one is independent.

An event is what triggers the workflow. Push to main, open a pull request, publish a release, or run on a cron schedule. You define which events activate a given workflow in the on: block at the top of the file.

A job is a collection of steps that run together on the same machine. By default, jobs in the same workflow run in parallel. If one job depends on another, you declare that explicitly and GitHub sequences them accordingly.

A step is a single action within a job. It's either a shell command you write directly, or a pre-built action from the GitHub Actions marketplace that someone else wrote and you call by name.

Every job runs on a fresh virtual machine, called a runner, that GitHub provisions and discards after the job completes. This means each run starts from a clean state. Anything you need (dependencies, credentials, files from your repo) has to be explicitly set up within the workflow.

The workflow file

Here's the recLog workflow file, which is the actual file that keeps the portfolio in sync automatically:

# .github/workflows/main.yml

name: Sync Dev.to Articles

on:
  push:
    branches: [main]          # runs whenever code is pushed to main
  schedule:
    - cron: '0 */6 * * *'    # also runs every 6 hours automatically

jobs:
  sync:
    runs-on: ubuntu-latest    # GitHub provisions a fresh Ubuntu machine for this job

    steps:
      # Step 1: check out the repository so the runner has access to the code
      - name: Checkout repo
        uses: actions/checkout@v3

      # Step 2: install Python on the runner
      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'

      # Step 3: install the project's dependencies
      - name: Install dependencies
        run: pip install -r requirements.txt

      # Step 4: run the pipeline (fetch, deduplicate, inject)
      - name: Run sync pipeline
        run: python main.py
        env:
          DEVTO_API_KEY: ${{ secrets.DEVTO_API_KEY }}  # pulled from repo secrets, never hardcoded

      # Step 5: commit and push the updated index.html back to the repo
      - name: Commit updated portfolio
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          git add index.html
          git diff --staged --quiet || git commit -m "chore: sync articles $(date -u +%Y-%m-%dT%H:%M:%SZ)"
          git push

Walk through what this does. When code is pushed to main or when the 6-hour cron fires, GitHub provisions a fresh Ubuntu machine. It checks out the repository, installs Python 3.11, installs the dependencies from requirements.txt, runs main.py (which calls the Dev.to API, deduplicates articles against the existing HTML, and injects new cards), and then commits the updated index.html back to the repo. The portfolio updates without anyone touching it.

The git diff --staged --quiet || before the commit is worth noting. If main.py ran but found no new articles, index.html won't have changed. Without that check, the workflow would fail trying to commit a file with no changes. The || means: if the diff is empty (exit code 0), skip the commit.

How `uses` and `run` differ

You'll notice two kinds of steps in the file above.

Steps with uses: call a pre-built action. actions/checkout@v3 is maintained by GitHub and handles cloning your repo onto the runner correctly, including dealing with authentication. actions/setup-python@v4 installs Python and adds it to the runner's PATH. These are reusable building blocks from the Actions marketplace, versioned with the @v3 syntax so your workflow doesn't silently break when the action gets updated.

Steps with run: execute shell commands directly. This is where your own logic lives. Anything you'd type into a terminal, you can write here.

Secrets

Notice ${{ secrets.DEVTO_API_KEY }} in the workflow. This is how GitHub Actions handles credentials. You store the actual key value in your repository's Settings under Secrets and Variables, and reference it in the workflow using the ${{ secrets.NAME }} syntax. The value is never written to the workflow file, never visible in logs, and never committed to source control.

For recLog, this is where the Dev.to API key lives. The workflow reads it at runtime, passes it to the Python script as an environment variable, and the script uses it to authenticate against the Dev.to REST API.

The cron trigger

The schedule: event uses standard cron syntax. 0 */6 * * * means "at minute 0 of every 6th hour." GitHub runs this on UTC.

┌──── minute (0-59)
│  ┌─── hour (0-23)
│  │   ┌── day of month (1-31)
│  │   │  ┌─ month (1-12)
│  │   │  │  ┌ day of week (0-7, Sunday is 0 or 7)
│  │   │  │  │
0  */6  *  *  *

For recLog, this means the portfolio checks for new articles four times a day without any manual trigger. If you publish at 2am, the site reflects it by 8am at the latest.

Where It Gets Tricky

The runner starts empty every time

The runner GitHub provisions do not know your previous runs. It doesn't have your dependencies cached, it doesn't have your environment variables set, it doesn't have any state from the last time the workflow ran. This catches beginners every time.

If your script writes a file during one run and expects that file to exist on the next run, it won't. Everything ephemeral needs to either be committed back to the repo (like recLog does with index.html), stored in an external service, or regenerated each run.

For recLog this was a deliberate design choice. The deduplication logic reads the current state of index.html in the repo to know which articles already exist. The runner checks out the repo fresh each time, runs the diff, and commits only changes. The repo itself is the state store.

Workflow permissions for committing back

By default, the GITHUB_TOKEN that GitHub provides to each workflow run has read-only access to the repository contents. If your workflow tries to git push without the right permissions, it will fail with a 403.

To fix this, go to your repository Settings, then Actions, then General, and set "Workflow permissions" to "Read and write permissions." Alternatively, you can set it per-workflow in the YAML:

permissions:
  contents: write

This is one of the most common silent failure points for beginners writing their first workflow that commits back to the repo.

Cron schedules aren't guaranteed

GitHub's documentation states that scheduled workflows may be delayed during periods of high load on their infrastructure. A workflow scheduled for 6:00 UTC might run at 6:07, or occasionally later. For most use cases, this is fine. For anything where exact timing matters, scheduled Actions aren't the right tool.

There's also a lesser-known behaviour: GitHub will disable scheduled workflows on repositories that have had no activity for 60 days. If your portfolio repo goes quiet for two months, the sync stops. The fix is either to push something (anything) to keep the repo active, or to trigger the workflow manually from the Actions tab when you notice it's stopped.

Secrets in forks and pull requests

If someone forks your repo and opens a pull request, workflows triggered by that PR will not have access to your repository secrets. This is a security measure, not a bug. It means a fork-based PR can't exfiltrate your API keys. But it also means if your workflow requires a secret to run, it will fail on PRs from forks. Keep this in mind if you ever open-source a project that has required secrets in its workflow.

Building recLog's Pipeline Step by Step

Here's how to set up a workflow like recLog's from scratch, assuming you have a repository with a Python project that you want to automate.

Step 1: create the workflow directory

mkdir -p .github/workflows

Step 2: write the workflow file

Create .github/workflows/main.yml and start with the trigger and job definition:

name: Sync Dev.to Articles

on:
  push:
    branches: [main]
  schedule:
    - cron: '0 */6 * * *'

jobs:
  sync:
    runs-on: ubuntu-latest

Step 3: add the checkout and Python setup steps

These two steps appear in nearly every Python-based workflow. The checkout action clones the repo onto the runner. Without it, the runner has no access to your code.

    steps:
      - name: Checkout repo
        uses: actions/checkout@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'

Step 4: install dependencies and run your script

      - name: Install dependencies
        run: pip install -r requirements.txt

      - name: Run sync pipeline
        run: python main.py
        env:
          DEVTO_API_KEY: ${{ secrets.DEVTO_API_KEY }}

Step 5: add the secret to your repository

Go to your repository on GitHub. Settings, then Secrets and variables, then Actions, then "New repository secret." Name it DEVTO_API_KEY and paste in your Dev.to API key. The workflow will now have access to it at runtime.

Step 6: commit and push if the output changed

This is the step that closes the loop. The git diff --staged --quiet || guard ensures the commit only runs when there's actually something new to commit:

      - name: Commit updated portfolio
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          git add index.html
          git diff --staged --quiet || git commit -m "chore: sync articles $(date -u +%Y-%m-%dT%H:%M:%SZ)"
          git push

Once this file is committed and pushed to main, GitHub picks it up automatically. You'll see the workflow appear in the Actions tab of your repository. Every run shows the status of each step, the logs, and how long it took.

What You Now Understand

A GitHub Actions workflow is not magic. It's a YAML file that tells GitHub: when this event happens, spin up a machine, run these steps in order, and report back. Every concept in that sentence is something you now have a working mental model of: events, runners, steps, secrets, and how to commit results back to the repo.

The recLog pipeline is a clean example of the pattern in its simplest useful form: trigger on push and on schedule, run Python, commit the output. That structure applies directly to dozens of other automation problems: syncing data, running tests, publishing packages, and generating reports.

Your next step is to open the Actions tab on any of your existing GitHub repositories and look at the starter workflows GitHub suggests. Pick the simplest one that applies to your stack, read through it line by line against what you've learned here, and run it. Seeing a green checkmark on your first workflow is how the mental model becomes a reflex.

GitHub Already Knows When You Push. It Can Do a Lot More Than Just Watch.

Nishant Gaurav — Wed, 10 Jun 2026 14:30:00 +0000

Every time you push code to GitHub, something happens on their end. A record is created, your repo updates, collaborators can see the change. GitHub is already reacting to your push. The question is whether you want it to stop there, or do something useful with that event.

That's the idea behind GitHub Actions. It's GitHub's built-in automation layer. When something happens in your repository, a workflow runs. That workflow can test your code, deploy your app, send a notification, sync data, or do anything else a computer can do. No external service required. No separate CI tool to configure. It lives inside your repo, runs on GitHub's infrastructure, and triggers off the same events your repository already produces.

Why GitHub Built This When AWS Already Exists

This is a fair question. AWS CodePipeline, Jenkins, CircleCI, and a dozen other tools already handle CI/CD. Why did GitHub build their own?

The honest answer is friction. Every existing tool required you to leave GitHub, set up an account somewhere else, connect it to your repo via webhooks or API tokens, configure a pipeline in a separate interface, and then debug failures across two different platforms. For large engineering teams with dedicated DevOps engineers, that cost is manageable. For an individual developer or a small team, it's enough friction to skip automation entirely.

GitHub Actions removes the "leave GitHub" part. Your workflow file lives in .github/workflows/ inside your repo. It's version-controlled alongside your code. You see the results in the same tab where you see your commits and pull requests. When something breaks, the logs are right there.

AWS and other cloud platforms are still the right choice when you need deep infrastructure control, complex deployment pipelines across multiple environments, or tight integration with AWS-specific services. GitHub Actions is not trying to replace that. It's solving a different problem: making basic automation accessible to anyone who already uses GitHub, without requiring infrastructure expertise to get started.

How It Actually Works

GitHub Actions is built on four concepts. Understand these and everything else is just syntax.

Workflows are the top-level unit. Each workflow is a YAML file in .github/workflows/. One repository can have multiple workflows, and each one is completely independent.

Events are what trigger a workflow. A push to main, a pull request being opened, a release being published, or a scheduled time. You define which events activate a workflow in the on: block at the top of the file.

Jobs are groups of steps that run together on the same machine. Multiple jobs in a workflow run in parallel by default. If one job needs the output of another, you declare that dependency explicitly.

Steps are individual tasks within a job. A step is either a shell command you write directly using run:, or a pre-built action from the marketplace that you call using uses:.

Every job runs on a fresh virtual machine that GitHub provisions for the duration of the job and discards afterward. This machine is called a runner. The most common choice is ubuntu-latest. The runner starts with nothing except a base OS, so anything your workflow needs (Python, Node, dependencies, credentials) has to be set up explicitly within the steps.

Your First Workflow

Here's a minimal workflow that runs your Python tests automatically every time code is pushed to the main branch:

# .github/workflows/ci.yml

name: Run Tests

on:
  push:
    branches: [main]      # triggers on every push to main

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3      # clones your repo onto the runner

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'

      - name: Install dependencies
        run: pip install -r requirements.txt

      - name: Run tests
        run: pytest

To use this, create the file at .github/workflows/ci.yml in your repo, commit it, and push. GitHub picks it up automatically. Go to the Actions tab in your repository and you'll see the workflow run in real time.

That's it. No external accounts. No webhooks to configure. The workflow file being in the right directory is all GitHub needs.

Secrets: Credentials Without Hardcoding

Almost every real workflow needs a credential of some kind: an API key, a deploy token, a database password. You should never write these directly in your workflow file, because workflow files are committed to your repository and potentially public.

GitHub solves this with secrets. You store the value in your repository settings (Settings, then Secrets and variables, then Actions), and reference it in the workflow using ${{ secrets.YOUR_SECRET_NAME }}. The value is masked in logs and never exposed in the workflow file itself.

      - name: Call external API
        run: python sync.py
        env:
          API_KEY: ${{ secrets.API_KEY }}    # injected at runtime, never hardcoded

Where GitHub Actions Fits (and Where It Doesn't)

GitHub Actions handles most automation needs for individual projects and small teams well: running tests on pull requests, deploying static sites, syncing data on a schedule, publishing packages on release. The setup cost is low and the integration with GitHub is tight.

It starts showing limits when you need long-running jobs (there's a 6-hour cap per job), complex multi-environment deployments with approval gates, or workloads that need dedicated infrastructure rather than ephemeral runners. For those cases, dedicated platforms like AWS CodePipeline or a self-hosted Jenkins instance are still the right tool.

For most projects, though, GitHub Actions covers what you need without requiring you to leave the platform you're already using.

Setting Up Your First Workflow: The Short Version

In your repository, create the directory .github/workflows/
Add a YAML file inside it (the name can be anything, e.g. ci.yml)
Define your trigger in the on: block
Define a job with runs-on: ubuntu-latest
Add steps using uses: for marketplace actions and run: for shell commands
Commit and push. Check the Actions tab.

Any secrets your workflow needs go in Settings, then Secrets and variables, then Actions, referenced in the workflow as ${{ secrets.NAME }}.

What Comes Next

Once this mental model is solid, the natural next step is building a workflow that actually does something specific to your project: runs your test suite, deploys on merge, or automates a repetitive task you currently do by hand.

A deeper walkthrough of a complete real-world pipeline (fetching data, transforming it, committing the result back to the repo automatically) is covered in the follow-up article: Building an Automated Content Pipeline with GitHub Actions.

The foundation is what this article covered. The follow-up shows what it looks like when you apply it to a production project from start to finish.

You Don't Have a "Works on My Machine" Problem. You Have a Dependency Problem.

Nishant Gaurav — Mon, 08 Jun 2026 05:53:48 +0000

Every developer has said it. You write code, it runs perfectly on your laptop, you push it to a server or hand it to a teammate, and something breaks. Wrong Python version. A library installed globally that you forgot about. An environment variable that was set in your shell profile but nowhere else.

Docker doesn't fix your code. It fixes the gap between the environment where you wrote your code and the environment where it runs. That's the whole job. And once you see that clearly, everything else about Docker follows logically.

The Problem: Environments Are Invisible Dependencies

Here's a scenario that plays out constantly on engineering teams.

A developer builds a data processing script. It works on their machine. They hand it to a teammate. The teammate runs it and it crashes because a library is the wrong version, or isn't installed at all. So they spend an hour aligning their setups. Two weeks later, it's deployed to production. It crashes again because the server is running a different OS version, and a native dependency that compiled fine locally doesn't compile there.

None of this is a code problem. The code is fine. The problem is that every machine carries hidden state: installed packages, runtime versions, system libraries, OS quirks. And your application depends on all of it, invisibly.

The traditional solutions are painful. You write a requirements.txt or a package.json and hope everyone runs it. You write a setup script. You document the expected environment in a README that gets out of date. You use a virtual environment, which helps for language-level dependencies but doesn't capture system-level ones. You use a VM, which captures everything but is heavy, slow to start, and awkward to share.

Docker solves this by packaging the application and its entire environment (OS libraries, runtime, config, dependencies) into a single portable unit. That unit runs the same way everywhere Docker is installed.

How Docker Actually Works

The core idea: containers vs virtual machines

The most common misconception about Docker is that it's a lightweight virtual machine. It isn't, and the difference matters.

A virtual machine emulates hardware. When you run a VM, your computer pretends to be a different computer, running a full operating system on top of fake hardware. That's expensive. A VM typically takes seconds to minutes to start and consumes gigabytes of RAM just for the OS layer.

Docker uses a different mechanism called containerisation. Containers don't emulate hardware. They run as isolated processes directly on your actual OS kernel, using two Linux features to create the illusion of separation.

Namespaces give each container its own view of the system. A container has its own process list, its own network interfaces, its own filesystem tree. From inside the container, it looks like it's the only thing running.

cgroups (control groups) limit how much CPU, memory, and I/O a container can consume. This is how Docker prevents one container from starving others.

Because containers share the host kernel rather than running their own, they start in milliseconds and use a fraction of the memory a VM would. A container running a Python web app might consume 50MB of RAM. A VM running the same app would consume 50MB for the app plus roughly 500MB for the guest OS.

Images and containers

Docker has two concepts you need to keep straight: images and containers.

An image is a read-only template. It describes an environment: which OS layer to use, which packages to install, which files to include, which command to run on startup. An image is not running anything. It's a blueprint, like a class definition in code.

A container is a running instance of an image. When you tell Docker to run an image, it creates a container: a live, isolated process using that image as its starting state. You can run ten containers from the same image simultaneously and each will be isolated from the others. This is the class-vs-object analogy made literal.

Images are built in layers. Every instruction in your image definition adds a layer on top of the previous one: start with a base OS layer, add a Python layer, add your application code. Docker caches each layer separately. If you rebuild an image after changing only your application code, Docker reuses the OS and Python layers from cache and only rebuilds the final layer. This makes rebuilds fast.

The Dockerfile

You define an image with a Dockerfile, a plain text file that lists the build instructions.

# Start from an official Python base image (OS + Python bundled together)
FROM python:3.11-slim

# Set the working directory inside the container
WORKDIR /app

# Copy and install dependencies first so this layer gets cached
# as long as requirements.txt doesn't change
COPY requirements.txt .
RUN pip install -r requirements.txt

# Now copy your application code (this layer rebuilds on every code change)
COPY . .

# Tell Docker what to run when the container starts
CMD ["python", "app.py"]

The ordering here is deliberate. requirements.txt is copied and installed before the application code. Because Docker caches layers, if you change your code but not your dependencies, Docker will reuse the cached dependency layer and only redo the final COPY. If you put COPY . . first, every code change would invalidate the dependency cache and reinstall everything, turning a two-second rebuild into a two-minute one.

The Docker Hub and base images

You don't build images from scratch. You start FROM an existing image, usually an official one from Docker Hub, which is a public registry of images. python:3.11-slim is an image that includes Debian Linux and Python 3.11, maintained by the Python team. There are official base images for nearly every language runtime, database, and common tool.

The slim suffix is a convention for smaller variants that strip out documentation and tools you don't need at runtime. For production use, smaller images mean faster deploys and a smaller attack surface.

Docker Compose

A real application is rarely just one container. You have your app, a database, maybe a caching layer. Docker Compose lets you define and manage multiple containers as a single unit.

# docker-compose.yml defines a web app and its database together
services:
  web:
    build: .                    # build from the Dockerfile in this directory
    ports:
      - "8000:8000"             # map port 8000 on your machine to port 8000 in the container
    depends_on:
      - db                      # don't start web until db is running
    environment:
      DATABASE_URL: postgres://user:pass@db:5432/mydb

  db:
    image: postgres:15          # use the official Postgres image directly
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
      POSTGRES_DB: mydb

With this file in your project, docker compose up starts both containers with the right configuration. A new developer on your team clones the repo and runs one command. No database installation required.

Where It Gets Complicated

Persistence: containers are ephemeral by default

A container's filesystem is disposable. When you delete a container, anything written inside it is gone. For a stateless web app that's fine because you rebuild and redeploy. For a database, it's a disaster.

Docker handles this with volumes: directories on your host machine (or a managed storage backend) that get mounted into containers. Anything the container writes to the volume path persists even after the container is removed.

Beginners consistently skip volumes when running databases locally, then wonder why their data disappears every time they restart. Add this to your Compose file for the database:

db:
  image: postgres:15
  volumes:
    - postgres_data:/var/lib/postgresql/data   # named volume for persistence

volumes:
  postgres_data:   # declare the named volume

Image size creep

The single most common mistake when writing Dockerfiles is producing images that are far larger than they need to be. A Python image built naively can easily reach 1-2GB. The production version of the same app can be under 100MB with multi-stage builds.

Multi-stage builds let you use one image to build your application (with compilers, test tools, all of it) and a separate, leaner image to run it. The final image only contains what the runtime needs.

# Stage 1: build stage with full tooling
FROM python:3.11 AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --prefix=/install -r requirements.txt

# Stage 2: runtime stage, slim and minimal
FROM python:3.11-slim
WORKDIR /app
COPY --from=builder /install /usr/local   # copy only the installed packages
COPY . .
CMD ["python", "app.py"]

Secrets and environment variables

Don't put secrets in your Dockerfile. If you write ENV API_KEY=abc123 in a Dockerfile and push it to a registry, that key is baked into every layer of the image and visible to anyone who pulls it.

Pass secrets at runtime using environment variables, Docker secrets, or a tool like Vault. Your Compose file can reference variables from a .env file that you never commit to source control.

Networking between containers

Containers on the same Docker network can reach each other by service name. In the Compose example above, the web app connects to db:5432. The name db is not a hostname you configured anywhere. Docker's internal DNS resolves it to the database container automatically. This trips up beginners who try to use localhost inside a container and can't reach a sibling container. Inside a container, localhost refers to that container, not the host machine or anything running alongside it.

A Concrete Scenario: Onboarding Without the Setup Tax

Here's where the value becomes tangible. You're working on a team building a backend API in Python. The app needs Python 3.11, PostgreSQL 15, and Redis. Without Docker, onboarding a new engineer means installing Python 3.11 (maybe using pyenv, maybe not), installing and configuring PostgreSQL, installing Redis, setting a dozen environment variables, and running migrations. This takes anywhere from 30 minutes to half a day, and something always breaks on someone's machine.

With Docker, the repository contains a docker-compose.yml and a .env.example. The onboarding instruction is two commands:

cp .env.example .env
docker compose up

The first run downloads base images, which takes a few minutes once. Every subsequent run starts in under five seconds. The entire environment (exact Python version, exact Postgres version, exact Redis version, correct config) is encoded in files that live in version control alongside the application code.

When you upgrade from PostgreSQL 15 to 16, you change one line in docker-compose.yml and commit it. Every developer on the team gets the upgrade on their next pull. No announcement in Slack. No "make sure you've upgraded your local Postgres" in the README.

This is Docker's most underrated value for teams. The environment becomes a first-class artifact of the project, versioned, reproducible, and reviewable just like the code.

What You Now Understand

The phrase "it works on my machine" describes a configuration management failure, not a code problem. Docker's answer is to make the environment part of the artifact, not documented alongside it but included inside it.

That's the shift. Not "write better setup instructions." Bundle the setup into something that runs.

Your concrete next step: take an existing project, a simple web app or a script, and write a Dockerfile for it. Don't worry about making it production-perfect. Get it building and running locally. The feedback loop of seeing what breaks and why is how this becomes intuition rather than theory.

Once you're comfortable with that, the natural next steps are multi-stage builds for smaller production images, volumes for stateful workloads, and eventually Kubernetes for running containers across multiple machines. But those are layers built on top of this foundation. Get the foundation first.

How to Build a Portfolio Website From Scratch – A Complete Journey

Nishant Gaurav — Fri, 13 Feb 2026 20:22:01 +0000

PART 1: The Full Journey

Preview: Light Mode

1. When I Started Building My Portfolio

When I decided to build my portfolio, I knew I didn’t want it to look like a “template-based” website. I wanted my site to show who I was as a developer: organized, clean, and systematic.

So long before I wrote even one line of code, I planned:

The sections I wanted to show on my portfolio.
How do recruiters view portfolios?
What is shown at the top of my portfolio (above the fold).
How to balance content with images on my portfolio.

The final structure is as follows:

Navbar
Hero / About
Projects
Skills
Achievements & Certifications
Contact
Footer

Goal:
“If someone spends 30 seconds on my site, they should be able to identify who I am technically.”

2. Structuring the HTML Layout

I built everything using semantic HTML + Bootstrap grid.

Each section was wrapped inside a <section> tag:

<section id="about"></section>
<section id="projects"></section>
<section id="skills"></section>

This allowed me to achieve:

Anchor navigation
SEO-friendly structure
Clean scroll targeting

Layout scaffolding:

<div class="container">
  <div class="row">
    <div class="col-md-6"></div>
  </div>
</div>

Bootstrap handled responsiveness, while custom CSS handled visual identity.

3. Designing the Navbar

Since the navbar is the first thing people see when they enter the application, it was important for me to keep it in the following ways:

Fixed at the top
Minimal
Navigation-focused

Key decisions:

Logo + Name branding
Anchor navigation links
Theme toggle switch

<nav class="navbar navbar-expand-lg fixed-top custom-header">

Hover animation:

.navbar-nav .nav-link::after {
  width: 0;
  transition: width 0.3s ease;
}

4. Building the Hero / About Section

This section had to communicate:

Who I am
What I do
What I’ve achieved

Two-column layout:

<div class="row align-items-center">
  <div class="col-md-5">Image</div>
  <div class="col-md-7">Content</div>
</div>

UI decisions:

Rounded profile image
Shadow wrapper
Using GIFs for accents.
Using bold text for highlights.
Resume links

.about_img--wrapper {
  box-shadow: 0 6px 18px rgba(0,0,0,0.1);
}

5. Projects Section: Card Architecture

I designed projects as product tiles.

<div class="col-md-6 col-lg-4">
  <div class="project-card"></div>
</div>

Design decisions:

25px radius
Muted teal background
Hover lift

.project-card:hover {
  transform: translateY(5px);
}

6. Skills Section: Visualizing Competence

Custom progress bars:

<div class="skill-bar">
  <div class="skill-fill" style="width:85%"></div>
</div>

.skill-bar { background: #7c8d8f; }
.skill-fill { background: #1f2022; }

Split into two columns for balance.

7. Achievements & Certifications:

Image-driven proof cards.

.achievement-img-wrapper {
  height: 260px;
  overflow: hidden;
}

Hover zoom:

.achievement-card:hover .achievement-img {
  transform: scale(1.05);
}

8. Contact Section:

Two layers:
Quick Links

LinkedIn
Email
GitHub

Contact Form

<form>
  <input type="text">
  <textarea></textarea>
</form>

Hover elevation:

.contact-card:hover {
  transform: translateY(5px);
}

9. Footer: Closing Identity

Logo
Copyright
Social icons

.footer-icon:hover {
  transform: scale(1.1);
}

10. Dark & Light Mode Implementation:

Theme toggle via JS & Persistence:

toggleBtn.addEventListener("change", () => {
  body.classList.toggle("dark-mode");
});

localStorage.setItem("theme","dark");

Dark Mode

Dark-Mode Decisions:

body.dark-mode {
  background-color: #0f1115;
  color: #e6e6e6;
}

Adjustments:

Gradient cards
Teal skill bars
Dark inputs

Goal: Reduce eye strain.

11. Layout Engineering:

Bootstrap Grid → Structure
Flexbox → Alignment

display: flex;
align-items: center;

12. Color & Typography:

Palette:

#7eaeb4 Accent
#393E46 Dark
#f4f5f7 Light

.card-title {
  font-family: 'Courier New';
}

13. Responsiveness:

@media (max-width: 767px) {
  .skill-bar { height: 12px; }
}

14. Challenges:

Dark mode contrast
Card consistency
Image scaling
Navbar shadows

15. Micro-UI Decisions:

Hover lifts
Underline nav animation
Skill transitions
Icon scaling
Section accents

PART 2: What I Learned

HTML Semantics

<section id="projects"></section>

CSS Positioning

position: fixed;

Flexbox

display: flex;

Grid

<div class="row"></div>

Responsive Design

img { max-width: 100%; }

Media Queries

@media (max-width:768px) {}

Theme Switching

localStorage.setItem("theme","dark");

Clean UI Principles

Spacing
Contrast
Hierarchy

Final Reflection

This portfolio became more than a website.

It taught me:

UI architecture
Theme systems
Responsive thinking
Developer storytelling

And it represents me better than any resume.

Building Production-Grade Networking Foundations — From Single Server to Kubernetes

Nishant Gaurav — Thu, 05 Feb 2026 17:49:44 +0000

Why Networking Fundamentals Are Important for CS/IT Students

For any CS/IT student, networking is not just a subject; it is the backbone of all digital systems.

Whether you are building:

Web applications
Mobile backends
Cloud systems
Microservices architectures

Everything depends on Data Communication across networks.

Understanding networking helps in:

Debugging production issues
Designing scalable systems
Securing applications
Cracking system design & interview rounds

It bridges the gap between coding and real-world deployment.

1. Evolution of Modern Application Networking

Let’s start with the big picture — how application networking evolves as systems scale.

This visual represents the journey from:

Single Server → Multiple Servers
Security Segmentation
Internet Access
Cloud Migration
Docker Containers
Kubernetes Orchestration

It shows that networking is not static; it grows with system complexity. As applications gain users, traffic increases. This forces architectural and networking transformations.

2. Single Server Architecture — The Starting Point

Every application begins simply.

At this stage:

The entire application runs on one machine
Backend, frontend, and database share resources
Deployment and networking are straightforward

How Users Reach the Server

This introduces IP Addressing.

An IP address is a unique numeric identifier assigned to every device on a network.

Example: 203.0.109.88

When a user sends a request:

The browser contacts the IP
Request travels via routers
Server responds

This process follows the TCP/IP Model, where:

IP handles addressing
TCP ensures reliable delivery

Role of DNS

Humans cannot remember IPs, so we use DNS (Domain Name System).

DNS translates:

travelDestination.com → 203.0.109.88

It works like the internet’s phonebook.

Without DNS, accessing websites would require memorizing numeric IPs.

3. Multiple Applications on a Single Server

As applications grow, multiple services run on the same server.

Example services:

Web Application
MySQL Database
Payment Service

But they share the same IP.

So how does the server differentiate requests?

Answer: Ports

Ports are logical communication channels.

Common ports:

80 → HTTP (Web)
443 → HTTPS (Secure Web)
3306 → MySQL

Port range: 0 – 65535

Think of:

IP → Building address
Port → Apartment number

This mapping happens at the Transport Layer (OSI Model).

4. Security & Network Segmentation

Running everything together creates risk.

Problem: Single Point of Failure

If one layer is compromised:

The entire system is exposed
The database becomes vulnerable

Solution: Network Segmentation

The network is divided into subnets:

Frontend Layer (Subnet 1)
Application Layer (Subnet 2)
Database Layer (Subnet 3)

This improves:

Security
Traffic control
Fault isolation

Supporting Components

Routers

Direct traffic between subnets
Choose optimal paths

Firewalls

Control incoming/outgoing traffic

Types shown:

Host-based firewall
Network firewall

This layered approach reduces the attack surface, a key cybersecurity principle.

5. Private Servers & Internet Access (NAT)

When databases and backend services move to private networks, they lose direct internet access.

Private servers use private IP ranges like:

10.x.x.x
172.16.x.x
192.168.x.x

These are not routable on the public internet.

Solution: NAT (Network Address Translation)

NAT allows private servers to access the internet via a gateway.

Working:

Private server sends a request
NAT gateway replaces private IP with public IP
Internet responds
Gateway maps response back

Benefits:

IP conservation
Security masking
Controlled exposure

Limitations:

Bottleneck risk
Latency increase
Mapping overhead

6. Moving to the Cloud

To overcome hardware and scaling limits, systems migrate to cloud platforms.

Concept

Instead of owning servers, we rent infrastructure.

This introduces Cloud Networking.

Key Component: VPC (Virtual Private Cloud)

A VPC is an isolated virtual network inside the cloud.

It contains:

Public Subnet → Frontend
Private Subnet → App & DB

Internet Gateway

Connects VPC resources to the internet.

Benefits

High availability
Auto scaling
Managed infrastructure
Better isolation

Cloud networking still follows TCP/IP and OSI principles, just virtualized.

7. Containerization with Docker

As microservices grow, dependency management becomes complex.

Problem

Different runtimes
Library conflicts
Deployment inconsistency

Solution: Containers

A container package:

Code
Runtime
Libraries
Dependencies

So it runs identically everywhere.

Container Networking

Bridge Network (Single Host)
Containers communicate internally.

Overlay Network (Multi-Host)

Containers communicate across servers.

Port Mapping

Example:

9090 → 9090

Maps the host port to the container port so external users can access services. This integrates container workloads into existing network stacks.

8. Orchestrating with Kubernetes

When containers scale across many servers, orchestration is required.

Kubernetes automates:

Scheduling
Scaling
Auto-healing
Networking

Pods

Smallest deployable unit.

Contain one or more containers
Get temporary IPs

Problem: Pods are dynamic.

If a Pod dies, its IP changes.

Kubernetes Services

Provide:

Stable IP
Load balancing
Service discovery

They act as a bridge between users and Pods.

Ingress Controller

Handles external traffic routing.

Functions:

Single entry point
URL-based routing
Reduces need for multiple public IPs
This is production-grade networking.

Additional Networking Concepts (Value Add)

To connect everything academically:

OSI Model in This Architecture

Layer	Role Here
Application	Web apps, APIs
Transport	TCP ports
Network	IP routing
Data Link	MAC communication
Physical	Cloud/DC hardware

TCP/IP Model Mapping

Application → HTTP, DNS
Transport → TCP/UDP
Internet → IP, NAT
Network Access → Ethernet, Wi-Fi

Network Types

LAN → Within data center/VPC

MAN → City-wide ISP networks

WAN → Internet backbone

Cloud systems operate across WANs.

Conclusion

My journey through Networking Fundamentals transformed how I view software systems.

Key takeaways:

Applications start simple, but networking grows with scale
IP addressing and DNS enable global connectivity
Ports allow multi-service communication
Segmentation improves security
NAT enables controlled internet access
Cloud networking virtualizes infrastructure
Docker standardizes deployments
Kubernetes orchestrates at scale

Building Production-Grade Networking Foundations — From Single Server to Kubernetes

Nishant Gaurav — Thu, 05 Feb 2026 17:49:44 +0000

Why Networking Fundamentals Are Important for CS/IT Students

For any CS/IT student, networking is not just a subject; it is the backbone of all digital systems.

Whether you are building:

Web applications
Mobile backends
Cloud systems
Microservices architectures

Everything depends on Data Communication across networks.

Understanding networking helps in:

Debugging production issues
Designing scalable systems
Securing applications
Cracking system design & interview rounds

It bridges the gap between coding and real-world deployment.

1. Evolution of Modern Application Networking

Let’s start with the big picture — how application networking evolves as systems scale.

This visual represents the journey from:

Single Server → Multiple Servers
Security Segmentation
Internet Access
Cloud Migration
Docker Containers
Kubernetes Orchestration

It shows that networking is not static; it grows with system complexity. As applications gain users, traffic increases. This forces architectural and networking transformations.

2. Single Server Architecture — The Starting Point

Every application begins simply.

At this stage:

The entire application runs on one machine
Backend, frontend, and database share resources
Deployment and networking are straightforward

How Users Reach the Server

This introduces IP Addressing.

An IP address is a unique numeric identifier assigned to every device on a network.

Example: 203.0.109.88

When a user sends a request:

The browser contacts the IP
Request travels via routers
Server responds

This process follows the TCP/IP Model, where:

IP handles addressing
TCP ensures reliable delivery

Role of DNS

Humans cannot remember IPs, so we use DNS (Domain Name System).

DNS translates:

travelDestination.com → 203.0.109.88

It works like the internet’s phonebook.

Without DNS, accessing websites would require memorizing numeric IPs.

3. Multiple Applications on a Single Server

As applications grow, multiple services run on the same server.

Example services:

Web Application
MySQL Database
Payment Service

But they share the same IP.

So how does the server differentiate requests?

Answer: Ports

Ports are logical communication channels.

Common ports:

80 → HTTP (Web)
443 → HTTPS (Secure Web)
3306 → MySQL

Port range: 0 – 65535

Think of:

IP → Building address
Port → Apartment number

This mapping happens at the Transport Layer (OSI Model).

4. Security & Network Segmentation

Running everything together creates risk.

Problem: Single Point of Failure

If one layer is compromised:

The entire system is exposed
The database becomes vulnerable

Solution: Network Segmentation

The network is divided into subnets:

Frontend Layer (Subnet 1)
Application Layer (Subnet 2)
Database Layer (Subnet 3)

This improves:

Security
Traffic control

- Fault isolation

Supporting Components

Routers

Direct traffic between subnets
Choose optimal paths

Firewalls

Control incoming/outgoing traffic

Types shown:

Host-based firewall
Network firewall

This layered approach reduces the attack surface, a key cybersecurity principle.

5. Private Servers & Internet Access (NAT)

When databases and backend services move to private networks, they lose direct internet access.

Private servers use private IP ranges like:

10.x.x.x
172.16.x.x
192.168.x.x

These are not routable on the public internet.

*Solution: NAT (Network Address Translation)
*
NAT allows private servers to access the internet via a gateway.

Working:

Private server sends a request
NAT gateway replaces private IP with public IP
Internet responds
Gateway maps response back

Benefits:

IP conservation
Security masking
Controlled exposure

Limitations:

Bottleneck risk
Latency increase
Mapping overhead

6. Moving to the Cloud

To overcome hardware and scaling limits, systems migrate to cloud platforms.

Concept

Instead of owning servers, we rent infrastructure.

This introduces Cloud Networking.

Key Component: VPC (Virtual Private Cloud)

A VPC is an isolated virtual network inside the cloud.

It contains:

Public Subnet → Frontend
Private Subnet → App & DB

Internet Gateway

Connects VPC resources to the internet.

Benefits

High availability
Auto scaling
Managed infrastructure
Better isolation

Cloud networking still follows TCP/IP and OSI principles, just virtualized.

7. Containerization with Docker

As microservices grow, dependency management becomes complex.

Problem

Different runtimes
Library conflicts
Deployment inconsistency

Solution: Containers

A container package:

Code
Runtime
Libraries
Dependencies

So it runs identically everywhere.

Container Networking

Bridge Network (Single Host)
Containers communicate internally.

Overlay Network (Multi-Host)

Containers communicate across servers.

Port Mapping

Example:

9090 → 9090

Maps the host port to the container port so external users can access services. This integrates container workloads into existing network stacks.

8. Orchestrating with Kubernetes

When containers scale across many servers, orchestration is required.

Kubernetes automates:

Scheduling
Scaling
Auto-healing

- Networking

Pods

Smallest deployable unit.

Contain one or more containers
Get temporary IPs

Problem: Pods are dynamic.

If a Pod dies, its IP changes.

Kubernetes Services

Provide:

Stable IP
Load balancing
Service discovery

They act as a bridge between users and Pods.

Ingress Controller

Handles external traffic routing.

Functions:

Single entry point
URL-based routing
Reduces need for multiple public IPs

This is production-grade networking.

Additional Networking Concepts (Value Add)

To connect everything academically:

OSI Model in This Architecture

Layer	Role Here
Application	Web apps, APIs
Transport	TCP ports
Network	IP routing
Data Link	MAC communication
Physical	Cloud/DC hardware

TCP/IP Model Mapping

Application → HTTP, DNS
Transport → TCP/UDP
Internet → IP, NAT

- Network Access → Ethernet, Wi-Fi

Network Types

LAN → Within data center/VPC

MAN → City-wide ISP networks

WAN → Internet backbone

Cloud systems operate across WANs.

Conclusion

My journey through Networking Fundamentals transformed how I view software systems.

Key takeaways:

Applications start simple, but networking grows with scale
IP addressing and DNS enable global connectivity
Ports allow multi-service communication
Segmentation improves security
NAT enables controlled internet access
Cloud networking virtualizes infrastructure
Docker standardizes deployments
Kubernetes orchestrates at scale

DEV Community: Nishant Gaurav

Your Code Runs Locally. GitHub Actions Makes It Run Everywhere, Automatically.

The Problem: Manual Steps After Every Push Don't Scale

How GitHub Actions Actually Works

The mental model

The workflow file

How uses and run differ

Secrets

The cron trigger

Where It Gets Tricky

The runner starts empty every time

Workflow permissions for committing back

Cron schedules aren't guaranteed

Secrets in forks and pull requests

Building recLog's Pipeline Step by Step

What You Now Understand

GitHub Already Knows When You Push. It Can Do a Lot More Than Just Watch.

Why GitHub Built This When AWS Already Exists

How It Actually Works

Your First Workflow

Secrets: Credentials Without Hardcoding

Where GitHub Actions Fits (and Where It Doesn't)

Setting Up Your First Workflow: The Short Version

What Comes Next

You Don't Have a "Works on My Machine" Problem. You Have a Dependency Problem.

The Problem: Environments Are Invisible Dependencies

How Docker Actually Works

The core idea: containers vs virtual machines

Images and containers

The Dockerfile

The Docker Hub and base images

Docker Compose

Where It Gets Complicated

Persistence: containers are ephemeral by default

Image size creep

Secrets and environment variables

Networking between containers

A Concrete Scenario: Onboarding Without the Setup Tax

What You Now Understand

How to Build a Portfolio Website From Scratch – A Complete Journey

PART 1: The Full Journey

Preview: Light Mode

1. When I Started Building My Portfolio

2. Structuring the HTML Layout

3. Designing the Navbar

4. Building the Hero / About Section

5. Projects Section: Card Architecture

6. Skills Section: Visualizing Competence

7. Achievements & Certifications:

8. Contact Section:

9. Footer: Closing Identity

10. Dark & Light Mode Implementation:

Dark Mode

Dark-Mode Decisions:

11. Layout Engineering:

12. Color & Typography:

13. Responsiveness:

14. Challenges:

15. Micro-UI Decisions:

PART 2: What I Learned

HTML Semantics

CSS Positioning

Flexbox

Grid

Responsive Design

Media Queries

Theme Switching

Clean UI Principles

Final Reflection

Building Production-Grade Networking Foundations — From Single Server to Kubernetes

Why Networking Fundamentals Are Important for CS/IT Students

1. Evolution of Modern Application Networking

2. Single Server Architecture — The Starting Point

How Users Reach the Server

3. Multiple Applications on a Single Server

4. Security & Network Segmentation

5. Private Servers & Internet Access (NAT)

These are not routable on the public internet.

6. Moving to the Cloud

Connects VPC resources to the internet.

How `uses` and `run` differ