DEV Community: SandeepKomal

I turned my GitHub year into a 3D solar system for my profile README

SandeepKomal — Fri, 16 Oct 2026 19:44:25 +0000

GitHub's contribution graph is a grid of green squares. It's useful, but it doesn't tell much of a story, and everyone's looks the same.

So I built Git3D Universe: a free GitHub Action that turns your year of contributions into a small 3D solar system, drawn as one self-contained SVG for your profile README.

⭐ Source (MIT): github.com/SandeepKomal/Git3D-Universe

What's in the picture

🥧 Your year as a 3D pie. One wedge per month, read clockwise like a clock face. Each wedge rises with that month's contributions and carries its name.
🏆 Your busiest month in gold. It's outlined, with its name and total floating above the pie.
🪐 Your repos as planets. Your top repositories orbit the pie, sized by stars, passing behind it on the far side and in front of it on the near side. The most-starred one gets rings.
📊 Your contribution mix. A small upright 3D pie in the corner shows how your year splits between commits, pull requests, issues and code review, with each share labelled, so it never depends on colour alone. The four colours were checked for colour-blind separation.
📅 Your peak day in a glass card in the corner.
✨ A glowing core in the middle, and planets that orbit with plain CSS animation.

Day and night, in your own timezone

There are two themes:

aurora: deep space, with a navy sky, stars and nebulas.
daylight: a soft dawn sky with the same colour wheel (teal, sky, indigo, violet, rose and gold).

The example workflow checks once an hour, works out the time in your timezone, and switches between them. Your profile is daylight during your day and deep space at night.

Add it to your profile in 2 steps

You need a profile repository: a public repo with the same name as your username (your-username/your-username).

Step 1: add the workflow

Create .github/workflows/git3d-universe.yml in your profile repo. The full workflow, with timezone switching and checks on the generated image, is in the README. The core of it is one step:

- name: Generate Git3D Universe
  uses: SandeepKomal/Git3D-Universe@v2.0.0
  with:
    username: ${{ github.repository_owner }}
    github-token: ${{ secrets.GITHUB_TOKEN }}
    theme: aurora            # or daylight
    output: profile/git3d-universe.svg

Set your timezone at the top of the workflow (for example Asia/Kolkata, America/New_York or Europe/London). Then open the Actions tab and run Git3D Universe once by hand.

Step 2: show it in your README

![Git3D Universe](./profile/git3d-universe.svg)

That's it. The workflow keeps the image up to date and commits it only when something changed.

Built to be trusted

A profile widget runs on your repo every hour, so I kept it small and boring where it matters:

No hosted rendering service. The image is drawn inside your own GitHub Actions run. Data comes straight from GitHub's GraphQL API.
No npm dependencies at runtime.
Uses the built-in GITHUB_TOKEN. No personal token is needed, and the token is passed through an environment variable, never on the command line.
Least privilege. The workflow needs only contents: write, to commit the SVG.
Safe text. Repo names, descriptions and language colours are escaped and checked before they go into the SVG.
Reduced motion respected. Turn the orbits off with no-motion: true.
Pin a release. Use the v2.0.0 tag or a commit SHA rather than main.

Try it locally first

Want to see it before touching your profile? It runs on Node 18+ with no dependencies:

git clone https://github.com/SandeepKomal/Git3D-Universe
cd Git3D-Universe

npm run sample      # draws a sample universe in out/, no network needed
GITHUB_TOKEN=<token> node src/cli.mjs --user YOUR_LOGIN --out profile/git3d-universe.svg

Options: --theme aurora|daylight, --no-motion, --sample.

Want a whole profile, not just the universe?

Git3D Universe is also built into my other project, README-Glassfolio. It makes a complete profile README (banner, stats, heatmap, languages, projects and Connect buttons) with the 3D universe included, and publishes it in one click.

Tell me what your universe looks like

It's free and open source (MIT):

💻 GitHub: SandeepKomal/Git3D-Universe
🐛 Ideas or bugs: open an issue

If you add it to your profile, drop your GitHub link in the comments. I'd love to see whose busiest month is December. 😄 A ⭐ on the repo helps other developers find it.

Happy orbiting! 🪐

I built a free GitHub profile README generator with no badge APIs, no backend and a 3D contribution universe

SandeepKomal — Fri, 16 Oct 2026 19:15:52 +0000

Your GitHub profile is often the first thing a recruiter, a hiring manager or a possible collaborator sees. For most of us it's a contribution graph and six pinned repos. That's a missed chance.

So I built README-Glassfolio: type your GitHub username, pick a theme, and get a complete profile README with a banner, stats, a contribution heatmap, a 3D "contribution universe", a languages card, a timeline, project cards and Connect buttons. Then publish it to your profile in one click.

👉 Try it: readme-glassfolio.in
⭐ Source (MIT): github.com/SandeepKomal/README-Glassfolio

The problem with most profile README tools

If you've made a fancy profile README before, you've probably pasted in a stack of image URLs pointing at somebody else's server: a stats card here, a streak counter there, a typing banner on top. It looks great until:

the free service hits its rate limit and your profile fills with broken images,
the service shuts down,
or you realise every visit to your profile is pinging a third party.

README-Glassfolio takes a different approach: everything is drawn as plain SVG files that live in your own <user>/<user> repo. No badge APIs, no stats services, no backend. Data comes straight from api.github.com, and every card is rendered in your browser.

What you get

Here's a README made with it (Royal theme, default options), shown on GitHub's dark and light pages:

Wave header and footer: a gradient banner with your name, title and top skills, with gently drifting waves.
Stats and streak cards: commits, PRs, issues, stars, followers, current and longest streak.
Contribution heatmap: laid out like GitHub's own graph, with best day and daily average.
🪐 3D contribution universe: your year as a 3D pie of month wedges round a glowing core, with your top repos orbiting as planets sized by stars, plus a mini pie of your commit / PR / issue / review mix.
Languages card, timeline, project cards (pick the ones you want featured, in your order) and Connect buttons.
An optional changelog layout that shows your repos as release notes, and a Recently pushed card.

8 themes, or your own colours

aurora, cyber, sunset, emerald, royal, graphite, the light paper, or auto, which picks colours from your username so every profile looks different. Want your brand colours? Choose Custom, pick two accents, and it adjusts them so text stays readable. The tests throw 300 random and extreme colour pairs at it to check that.

Day and night, automatically

By default you get two complete image sets, dark and light, wrapped in <picture> with prefers-color-scheme. Visitors in dark mode see the dark set; visitors in light mode see the light one. Nothing looks out of place on either page.

Publish in one click, and it stays fresh

Create your profile repo (your-username/your-username, public).
Create a fine-grained token limited to only that repo, with Contents and Workflows set to read and write.
On readme-glassfolio.in, enter your username, tweak the options, press Publish to GitHub and paste the token.

All files land in one commit. The token goes only to api.github.com, stays in memory, and is cleared after publishing.

A README is normally a snapshot, so "Keep my stats fresh every day" is on by default. It adds a small GitHub Action to your repo that rebuilds the README once a day and commits only when something changed. It has no uses: lines (no third-party actions), no secrets, one permission (contents: write), and a copy of the generator sits in .readme-patch/ so you can read every line that runs. If GitHub's API is down that day, it changes nothing, so you never end up with a half-empty profile.

Prefer not to use a token? Download the zip and drag the files into your repo.

How often it updates

⚠️ GitHub pauses scheduled workflows after 60 days without activity in a repo. If your profile stops updating, open the Actions tab and re-enable the workflow. It takes one click.

README and cards: once a day, at a time worked out from your username, so runs are spread out without anyone setting a cron time. The page shows your time before you publish.
3D universe: every 6 hours, by a second small workflow.
Only real changes are committed, so there are no empty commits. Refresh any time with Run workflow in the Actions tab.
GitHub caches README images for a few minutes, so a new commit can take a moment to show.

📘 New to profile READMEs? There's a step-by-step guide with screenshots (also as a PDF) that walks through every click.

Safe to paste a token into

I took security seriously, because I'm asking people to paste a token into a web page:

A strict Content-Security-Policy: scripts only from the site itself, network requests only to the site and api.github.com, no inline scripts, no eval.
No innerHTML anywhere. The live preview builds elements from a whitelist, so markup hidden in a bio or repo description can't do anything.
Tokens are never stored and can't end up in a share link.
The browser tests actually attack the page (injected scripts, inline handlers, eval, fetch/XHR/image/iframe/WebSocket to another host) and check that everything is blocked.

For terminal fans: there's a CLI

Same engine, zero dependencies, Node 18+:

git clone https://github.com/SandeepKomal/README-Glassfolio
cd README-Glassfolio

node cli.js your-username --theme cyber --role "Cloud Engineer" --stack "AWS, Terraform"
node cli.js --sample                       # try it with no network
GITHUB_TOKEN=github_pat_xxx node cli.js your-username --publish --daily

Output goes to ./out/: README.md, banner.svg and cards/.

A few small touches I'm proud of

A preview that tells the truth. It shows your README inside a mock GitHub profile at GitHub's real widths (896px desktop, 390px phone), with light/dark switching.
Text that always fits. A fuzz tool renders about 1,800 cards with extreme repo names (90 characters, million-star counts) in a real browser and measures every text box so nothing collides.
Motion that respects people. Animations are plain CSS inside the SVGs. With "reduce motion" on, visitors see the finished still image.
Share links like ?user=octocat&theme=cyber rebuild the same setup, and a 1280×640 share image is ready for LinkedIn or X.
A "Make it even better" checklist scores your profile and points to what's missing.

Try it and tell me what you think

It's free, open source (MIT), and runs entirely in your browser:

🌐 Web app: readme-glassfolio.in
💻 GitHub: SandeepKomal/README-Glassfolio

If you make your profile with it, drop your GitHub link in the comments. I'd love to see what themes people pick. A ⭐ on the repo helps more developers find it, and issues and PRs are welcome. Next on my list is a compact card design that reads better on phones.

Happy profile-polishing! ✨

How I Reduced Docker Pull Time from 3 Minutes to 3 Seconds

SandeepKomal — Sun, 26 Oct 2025 08:45:51 +0000

Optimizing Docker performance often starts with small changes that lead to massive results. Slow image pulls can severely impact developer productivity, CI/CD efficiency, and deployment times. In my environment, pulling a single image used to take close to three minutes. After a series of systematic optimizations, I reduced that time to just three seconds.

This article walks through both the practical steps I followed and general best practices that can help any team achieve similar improvements.

Understanding the Bottleneck

When analyzing CI/CD pipelines, I discovered that over 30% of the total job time was spent pulling Docker images from a remote registry. The image was over 1 GB in size and included build dependencies, unused tools, and large OS layers.

Running:

docker pull myregistry.com/app/backend:latest --verbose

showed sequential layer downloads and poor caching utilization. The problem wasn’t Docker itself but rather image design, caching strategy, and network latency.

Step 1: Optimize the Docker Image (Java Example)

The original Dockerfile was straightforward but inefficient:

FROM openjdk:11
COPY . /app
WORKDIR /app
RUN ./gradlew build
CMD ["java", "-jar", "build/libs/app.jar"]

This setup embedded both build and runtime dependencies in a single layer. The result was a 1.1 GB image.

The optimized version used a multi-stage build with a minimal runtime image:

# Stage 1: Build the application
FROM gradle:7.6-jdk17 AS builder
WORKDIR /app
COPY . .
RUN gradle clean build -x test

# Stage 2: Run the application
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY --from=builder /app/build/libs/app.jar .
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

Impact: Image size reduced to ~240 MB.
Approach: Separated build tools from runtime, reduced layers, and used a lightweight base image.

Step 2: Enable Layer Caching in CI/CD Pipelines

Next, I enabled caching for image layers across builds. Using Docker Buildx in GitHub Actions:

- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v3

- name: Build and push
  uses: docker/build-push-action@v6
  with:
    push: true
    tags: myregistry.com/app/backend:latest
    cache-from: type=registry,ref=myregistry.com/app/backend:cache
    cache-to: type=registry,ref=myregistry.com/app/backend:cache,mode=max

This allowed CI/CD pipelines to reuse existing layers instead of redownloading or rebuilding identical ones. Pull time dropped from 180 seconds to roughly 20 seconds.

Step 3: Set Up a Local Registry Mirror

To eliminate external network latency, I configured a local Docker registry mirror:

docker run -d -p 5001:5000 \
  -v /opt/registry-mirror:/var/lib/registry \
  --name registry-mirror \
  registry:2

Then updated /etc/docker/daemon.json:

{
  "registry-mirrors": ["http://localhost:5001"]
}

From this point, frequently used images were fetched locally rather than from remote registries. Pull time dropped to three seconds.

Step 4: Apply Docker Image Optimization Best Practices

Beyond specific optimizations, several universal Dockerfile best practices contribute to faster image builds, smaller layers, and better cache utilization.

1. Choose a Minimal Base Image

Use small base images such as Alpine or Scratch instead of large distributions.

Example:

# Bad (large)
FROM ubuntu:20.04

# Good (small)
FROM alpine:3.19

Alpine is roughly 5 MB, compared to Ubuntu’s 70–100 MB footprint.

2. Use Multi-Stage Builds

Compile your application in one stage and copy only the final output into a minimal runtime stage.

Example:

# Stage 1: Build
FROM golang:1.22 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp .

# Stage 2: Minimal runtime
FROM alpine:3.19
WORKDIR /app
COPY --from=builder /app/myapp .
CMD ["./myapp"]

Result: Only the compiled binary is included in production, not build tools or dependencies.

3. Remove Unnecessary Files

Clear package caches and temporary files after installation to prevent bloat.

Example (Alpine):

RUN apk add --no-cache git && rm -rf /var/cache/apk/* /tmp/*

Example (Debian/Ubuntu):

RUN apt-get update && apt-get install -y git && rm -rf /var/lib/apt/lists/*

4. Combine RUN Instructions

Each RUN command creates a new layer. Combine related operations to reduce layers and image size.

Example:

# Bad
RUN apt-get update
RUN apt-get install -y git
RUN rm -rf /var/lib/apt/lists/*

# Good
RUN apt-get update && apt-get install -y git && rm -rf /var/lib/apt/lists/*

5. Use `.dockerignore`

Prevent unnecessary files (e.g., .git, logs, and node_modules) from being sent to the Docker build context.

Example .dockerignore:

.git
node_modules
*.log
*.tmp

This ensures a smaller build context and faster build times.

Summary of Best Practices

Use small base images (e.g., Alpine, slim, scratch).
Apply multi-stage builds.
Remove caches and temporary files.
Use .dockerignore effectively.
Combine related commands to minimize layers.
Avoid copying unnecessary files into the image.

Step 5: (Optional) Use CDN Acceleration

For distributed or multi-region teams, host your registry (ECR, Harbor, or Artifactory) behind a CDN such as AWS CloudFront or Cloudflare. This ensures geographically optimized image pulls for global developers.

Final Results

After implementing all these optimizations:

Pull time reduced from 3 minutes to 3 seconds.
CI/CD execution time improved by over 60%.
Network utilization became predictable and efficient.
Developer feedback loops became almost instantaneous.

Conclusion

Docker image optimization is often undervalued, but its impact is significant. Through smaller base images, efficient multi-stage builds, cache utilization, and registry mirroring, I reduced image pull time from minutes to seconds.

These practices don’t just improve performance — they scale across environments, pipelines, and teams, forming the foundation of efficient containerized systems.

DEV Community: SandeepKomal

I turned my GitHub year into a 3D solar system for my profile README

What's in the picture

Day and night, in your own timezone

Add it to your profile in 2 steps

Step 1: add the workflow

Step 2: show it in your README

Built to be trusted

Try it locally first

Want a whole profile, not just the universe?

Tell me what your universe looks like

I built a free GitHub profile README generator with no badge APIs, no backend and a 3D contribution universe

The problem with most profile README tools

What you get

8 themes, or your own colours

Day and night, automatically

Publish in one click, and it stays fresh

How often it updates

Safe to paste a token into

For terminal fans: there's a CLI

A few small touches I'm proud of

Try it and tell me what you think

How I Reduced Docker Pull Time from 3 Minutes to 3 Seconds

Step 1: Optimize the Docker Image (Java Example)

Step 2: Enable Layer Caching in CI/CD Pipelines

Step 3: Set Up a Local Registry Mirror

Step 4: Apply Docker Image Optimization Best Practices

1. Choose a Minimal Base Image

2. Use Multi-Stage Builds

3. Remove Unnecessary Files

4. Combine RUN Instructions

5. Use .dockerignore

Summary of Best Practices

Step 5: (Optional) Use CDN Acceleration

Final Results

5. Use `.dockerignore`