DEV Community: Shubham

I got tired of writing Postman scripts to pass tokens, so I built a visual API chainer

Shubham — Fri, 11 Sep 2026 08:11:38 +0000

Hey devs! 👋

Let's be honest. We’ve all been there: You want to test a simple API sequence.

Hit the /login endpoint.
Extract the JWT token from the response.
Pass that token into the Authorization header of the /get-profile endpoint.

In traditional API clients, doing this requires switching to a "Tests" or "Scripts" tab, writing something like pm.environment.set("token", response.json().token), managing environment variables, and hoping you didn't make a typo.

There are visual tools out there (like Postman Flows), but they often feel like heavy cloud-automation monsters built for enterprise orchestration, not simple local debugging. Plus, they lock you into recurring team subscriptions.

I just wanted a lightweight, local, and visual way to see my data flow from API to API. So, I built one.

Enter Aaptics_Flow 🚀

I've spent the last few weeks building a purely visual API canvas that runs entirely in your browser. You can check it out here: flow.aaptics.in

Instead of writing scripts, you drop API nodes onto a canvas and draw wires to connect the output of one API directly into the Headers, Query Params, or Body of the next.

✨ Why build another API tool?

I wanted to focus on three main things that frustrated me with existing tools:

1. 100% Local & Private Execution 🔒
Most visual API tools run your requests through their cloud servers. If you are dealing with sensitive production databases or internal auth tokens, that's a security nightmare. My tool executes requests directly from your client/browser. Zero server-side logging. Your data stays yours.

2. Visual Debugging, No Scripts 🔗
If an API fails, you can visually see exactly where the chain broke. You can inspect the exact payload that was passed through the wire from Node A to Node B. No console.log() needed.

3. Goodbye CORS Issues ⚡
To make browser-based execution work smoothly without CORS blocking every request, I built a lightweight proxy using Cloudflare Workers. It acts as a seamless bridge so you can test any public or private API without tearing your hair out over preflight errors.

🛠️ The Tech Stack

For those curious about how it's built:

Frontend: React (Handling the drag-and-drop node canvas rendering smoothly).
Backend/Proxy: Cloudflare Workers (Extremely fast edge proxy to handle CORS and license validation).
Payments/Auth: Dodo Payments (Merchant of Record to handle global checkouts seamlessly).

I need your feedback! 🙏

I just deployed the free version and I would love for the Dev.to community to tear it apart.

Is the drag-and-drop UX intuitive?
What node types or features are missing for your daily workflow?
Did you hit any bugs?

Try it out for free: https://flow.aaptics.in

Let me know what you think in the comments! Happy chaining. ✌️

Aeglis Intelligence: Building an Open-Source API-First Security Analysis Backend

Shubham — Fri, 11 Sep 2026 05:46:26 +0000

Aeglis Intelligence: Building an Open-Source API-First Security Analysis Backend

Modern threats rarely arrive in a single format. A phishing attempt may look like a shortened URL, a fake payment request, a malicious document, an infected archive, or an Android application that behaves differently from what it promises.

This is the problem I wanted to work on with Aeglis Intelligence: an open-source cybersecurity and risk-analysis backend that brings multiple detection workflows behind one Python and FastAPI-based service.

Repository: github.com/Shubhamorigin/Aeglis-Intelligence

What Is Aeglis Intelligence?

Aeglis Intelligence is built for applications, developers, and security-focused teams that need to inspect suspicious content and receive useful risk intelligence through APIs.

It can be used to analyze:

Suspicious URLs and phishing pages
Scam messages and risky text content
Office documents and PDFs
ZIP archives and scripts
JavaScript, SVG files and images
Malware patterns
Android APKs
Domain reputation and external threat signals

The goal is not only to return a binary safe-or-unsafe answer. Aeglis is designed to combine multiple signals and produce a practical verdict, risk score, and supporting explanation that can be used by a dashboard, consumer application, moderation system, or automated security workflow.

Why Multiple Signals Matter

A single security check is often not enough. A domain may be new but not malicious. A file may contain an unusual pattern without being harmful. A URL may look normal while redirecting users through a phishing flow.

Aeglis approaches analysis as a layered process. Depending on the input, it can combine:

Local security rules and heuristics
Text and input classification
Domain intelligence and RDAP checks
Static file inspection
Browser-based URL analysis
Reputation lookups through external services
AI-assisted risk classification

This layered approach makes it possible to use fast local checks where they are enough and bring in deeper analysis when the input deserves more investigation.

The Architecture

Aeglis is organized into separate modules so that API handling, detection engines, storage, authentication, and result delivery do not become one large block of application logic.

API Layer

The central application lives in main.py and is built with FastAPI. It coordinates public routes, authenticated consumer routes, developer APIs, billing workflows, support tickets, and webhook configuration.

The service includes rate limiting through SlowAPI, CORS middleware, JWT-based authentication for protected consumer actions, and API-key validation for developer endpoints.

Detection Layer

The detection responsibilities are split across specialized modules:

core_engine.py handles domain intelligence, whitelist checks, Redis access, and high-level risk assessment.
scanner_engine.py performs deep analysis of documents, archives, scripts, JavaScript, SVG, PDFs, APKs, and images.
scan_url.py handles browser-based URL detonation and phishing checks.
input_classifier.py classifies suspicious text and payment-related scam patterns.
security_engine.py generates API keys and stores hashes rather than relying on plain-text key storage.

This separation makes it easier to improve one analysis path without rewriting the rest of the backend.

Data and Storage Layer

Supabase provides the main persistence and authentication layer. The project uses it for:

User authentication and profiles
API keys and usage plans
Scan history and API logs
Support tickets
Billing records
Developer webhook configuration

Redis can be used as a cache for domain results and scan information. For one-off file processing, the application uses a local temp_uploads/ directory at runtime.

Integration Layer

Aeglis can connect to external services for additional signals and analysis, including:

VirusTotal for hash reputation
AlienVault for threat intelligence lookups
WebRisk for malicious URL checks
Groq for AI-assisted classification and verdict generation
Playwright for browser automation and URL analysis

External services are treated as supporting signals. The application also has local logic so that the system can continue using fallback paths when optional services such as Redis are unavailable.

Consumer and Developer Workflows

Aeglis supports two main types of users.

Consumer Applications

A consumer safety application can send text, URLs, downloaded content, or uploaded files for analysis. The response can then be shown as a warning, a risk score, or a more detailed explanation before a user opens a link or file.

The backend includes routes for signup, login, Google authentication flows, text scanning, deep file scanning, scan history, profile data, and history management.

Developer and B2B Integrations

Developers can use protected endpoints to add security analysis to their own products. The developer workflow is based on API keys, quotas, structured scan requests, and optional webhooks for asynchronous result delivery.

The current developer-oriented routes include:

POST /v3/api/scan
POST /v3/api/deep-scan
POST /v3/dashboard/generate-key
POST /v3/dashboard/webhook
GET /v3/dashboard/api-logs
GET /v3/dashboard/api-data
GET /v3/dashboard/reports

A developer API key is sent through the Authorization header:

Authorization: Bearer sk_live_xxx

A text scan can be sent as JSON:

POST /v3/api/scan
Content-Type: application/json
Authorization: Bearer sk_live_xxx

{
  "input_text": "Check this suspicious link: https://example.com",
  "end_user_id": "customer-123"
}

This structure allows an integrating product to associate scans with its own end users without exposing the internal authentication model of Aeglis.

Webhooks for Automation

Polling for every scan result is not always the best integration pattern. Aeglis includes webhook configuration and dispatch support so that developer systems can receive results after a scan is completed.

A typical workflow looks like this:

A developer creates an API key.
The application sends text or a file for analysis.
Aeglis processes the input through the relevant detection engines.
The result is stored and returned through the API or delivered to a configured webhook.
The integrating application uses the verdict and risk context in its own workflow.

This can be useful for moderation queues, security dashboards, customer support tooling, download protection, or automated incident workflows.

Database Setup

The repository includes a complete Supabase schema in database.sql.

The schema supports the tables and database objects required by the backend, including profiles, API keys, API logs, scans, support tickets, and billing records. To set up a development environment:

Create a Supabase project.
Open the Supabase SQL Editor.
Copy the contents of database.sql into the editor.
Run the script.
Add the project URL and keys to the local environment file.

The application also references a storage bucket named cold-storage for exported reports and archival files.

Running the Project Locally

Clone the repository and move into the project directory:

git clone https://github.com/Shubhamorigin/Aeglis-Intelligence.git
cd Aeglis-Intelligence

Create a virtual environment if you want to isolate the project dependencies:

python -m venv .venv

Activate it on Windows:

.venv\Scripts\Activate.ps1

On macOS or Linux:

source .venv/bin/activate

Install the dependencies:

pip install -r requirements.txt

For browser-based URL analysis, install the Playwright browsers:

python -m playwright install

Start the application with either command:

python main.py

or:

uvicorn main:app --host 0.0.0.0 --port 8000 --reload

Environment Variables

Create a .env file in the project root. The required integrations use variables similar to these:

ALIENVAULT_API_KEY=your_alienvault_api_key
GROQ_API_KEY=your_groq_api_key
SB_ANON_KEY=your_supabase_anon_key
SB_API_URL=your_supabase_api_url
SB_SECRET_KEY=your_supabase_secret_key
VIRUSTOTAL_API_KEY=your_virustotal_api_key
WEB_RISK_API_KEY=your_web_risk_api_key
REDIS_URL=your_redis_url

Some integrations are optional during local development. Redis can fall back to local or Supabase-backed paths when it is not available, but a properly configured Redis instance is recommended for better performance.

Never commit real API keys, service-role keys, or database credentials to the repository. Keep .env outside source control and use a secret manager for production deployments.

Security Considerations

A security-analysis service must protect both the service itself and the data it processes. Aeglis includes several controls that help establish that boundary:

Rate limits for public and authenticated routes
JWT validation for protected consumer actions
API-key validation for developer endpoints
Hashing for stored API keys
CORS and origin validation
File upload size limits, including a 50 MB application limit
Temporary file handling for uploaded content
Webhook configuration and secret support

Production deployments should still restrict CORS origins, enforce HTTPS, protect Redis and Supabase networking, validate every uploaded file, and keep all third-party credentials in a secure secret manager.

What Makes the Project Useful

Aeglis is intentionally more than a collection of scanners. It provides the surrounding platform pieces needed to turn detection logic into a product capability:

A single API surface for multiple input types
Consumer authentication and scan history
Developer API keys and quotas
Webhook delivery for integrations
Persistence for logs, profiles, support, and billing workflows
A ready-to-run Supabase schema
Local fallbacks for some optional infrastructure
Modular engines that can evolve independently

This makes it suitable as a foundation for consumer safety tools, security dashboards, content moderation systems, developer products, and internal security automation.

Open Source and Contributions

Aeglis Intelligence is released under the MIT License and is available on GitHub:

github.com/Shubhamorigin/Aeglis-Intelligence

The most useful contributions will likely be improvements to detection quality, better test coverage, safer integration defaults, new file-format support, clearer result explanations, and documentation for deployment scenarios.

When contributing, keep secrets out of commits, test changes against representative inputs, and document any new environment variables or external service requirements.

Final Thoughts

Threat detection becomes more useful when it is available where decisions are made: inside an application, a download flow, a moderation queue, or a developer workflow.

Aeglis Intelligence is an attempt to make that integration practical by combining local analysis, external intelligence, AI-assisted reasoning, persistence, authentication, and delivery mechanisms in one open-source backend.

Explore the repository, run the database schema, try the API locally, and adapt the detection layer to the needs of your own application.

Repository: github.com/Shubhamorigin/Aeglis-Intelligence

Built by: Shubham

I got tired of updating my portfolio, so I built a Headless Identity Hub & API for Developers 🚀

Shubham — Thu, 06 Aug 2026 05:26:26 +0000

Hey everyone! 👋

Like most developers, I love building projects but absolutely hate updating my personal portfolio website. Copy-pasting the same bio, experience, and project links across my website, GitHub README, and social media was getting exhausting.

So, I decided to build a centralized ecosystem for it.

Meet Aaptics ID — A digital identity, portfolio hub, and headless CMS built specifically for developers.

Here is a breakdown of what I built and why:

1. The Digital "PVC" Identity Card

I wanted the profile to feel premium, almost like an Apple Wallet pass or a physical PVC card. Users can claim their short @username, list their core tech stack, add experience, and generate a downloadable digital card.

2. The Developer Arsenal (The Engine) ⚙️

This is my favorite part and the main reason I built Aaptics. Having a profile is cool, but developers need infrastructure. I added a "Dev Arsenal" section which provides:

Headless Config (REST API): You can use Aaptics as a CMS for your personal Next.js/React portfolio. Just update your details on Aaptics, and fetch them anywhere using your private Bearer token. Build once, update everywhere.
Live Readme Widget: It generates a live SVG render of your Aaptics Elite Card that you can directly embed into your GitHub readme.md.
Shortlink Engine: No more messy Vercel/Netlify URLs for hackathons. Generate clean aaptics.in/go/my-app links right from your dashboard.

3. The Central Hub & Cohort Billboard 🌐

To make it a community, I built a Central Grid. It features a "Dev of the Day" spotlight and a Live Leaderboard based on profile views and activity.

But the most fun feature is the Cohort Billboard. It’s a 120-character, 24-hour disappearing broadcast board. Perfect for sharing quick elevator pitches, looking for hackathon teammates, or launching a side project without the spam of traditional feeds.

🛠️ The Tech Stack

Frontend: React / Next.js
Styling: Tailwind CSS (Obsessed with dark mode aesthetics)
Backend/Database: Python (FastAPI) & PostgreSQL / Supabase
Hosting: Vercel

Let me know what you think!

I just pushed this live and I would love for the dev.to community to tear it apart. Roast my UI, critique the UX, or test out the API.

You can claim your short handles before they are gone here: aaptics.in

What features would you want in a developer identity platform? Let me know in the comments! 👇

Stop Googling "Indian PAN Card Regex" — I Built an Open Vault for Us 🇮🇳

Shubham — Tue, 28 Jul 2026 19:17:25 +0000

How many times has this happened to you?

You’ve built a flawless React component, set up a beautiful CI/CD pipeline, and structured your database perfectly. But then, you hit a simple user onboarding form and spend the next 20 minutes Googling: "Valid regex for Indian GSTIN format" or "Aadhaar card regex javascript".

Sometimes StackOverflow gives you a pattern from 2013, and sometimes ChatGPT hallucinates a format that rejects valid inputs.

I got tired of searching for the same validation codes for every new project. So, this weekend, I built The Indian Regex & Validation Vault.

It is a completely free, minimalist, zero-bloat directory of 100+ Indian-specific regular expressions and validation rules. No sign-ups, no paywalls—just search, copy, and paste.

Here are 5 essential patterns from the vault you can use right now:

1. Indian PAN Card Validation

The Permanent Account Number (PAN) is a 10-character alphanumeric identifier. The first 5 characters are uppercase alphabets, the next 4 are numbers, and the last is an alphabet.

const panRegex = /^[A-Z]{5}[0-9]{4}[A-Z]{1}$/;

console.log(panRegex.test("ABCDE1234F")); // true

2. Aadhaar Card Validation (With or Without Spaces)

The Aadhaar number is a 12-digit unique identity number. It never starts with a 0 or 1.

// Accepts: 123456789012 or 1234 5678 9012
const aadhaarRegex = /^[2-9]{1}[0-9]{3}\s?[0-9]{4}\s?[0-9]{4}$/;

3. GSTIN (Goods and Services Tax Identification Number)

This is a 15-digit alphanumeric code. The first two digits are the state code, followed by the PAN, one digit for entity number, the letter 'Z' by default, and a checksum character.

const gstinRegex = /^[0-9]{2}[A-Z]{5}[0-9]{4}[A-Z]{1}[1-9A-Z]{1}Z[0-9A-Z]{1}$/;

4. Indian UPI ID

Validates standard UPI virtual payment addresses (e.g., username@oksbi or number@ybl).

const upiRegex = /^[a-zA-Z0-9.\-_]{2,256}@[a-zA-Z]{2,64}$/;

5. Indian Vehicle Registration (Number Plate)

Validates formats like MH 12 AB 1234 or DL1A1234.

const vehicleRegex = /^[A-Z]{2}[ -]?[0-9]{1,2}(?:[ -]?[A-Z])?(?:[ -]?[A-Z]*)?[ -]?[0-9]{4}$/;

🚀 Get the rest of the 100+ Patterns

If you need validations for Voter ID, Indian Passports, IFSC Codes, Landline numbers with STD codes, or even state-specific Pincodes, I have compiled them all in one place.

I've also added detailed explanations for how each regex works under the hood so you aren't just blindly copying code.

👉 Bookmark the vault here: Aaptics.in - The Indian Regex Vault

(Bonus: There is also a second directory on the site explaining unknown developer system files and extensions like .npmrc or .safetensors!)

Let me know in the comments if I missed any specific Indian document format, and I'll add it to the vault today! Happy coding! 👨‍💻🇮🇳

GitHub Actions is Silently Burning Your Budget — Here's How to Calculate It

Shubham — Wed, 29 Apr 2026 05:17:50 +0000

You enabled GitHub Actions, set up a few workflows, and moved on. Smart move. But did you ever check what it's actually costing you?

Most developers don't. Until the bill arrives.

The Problem Nobody Talks About

GitHub Actions is brilliant. CI/CD straight from your repo, zero setup overhead, tight GitHub integration. It's one of those tools that just works — so you stop thinking about it.

And that's exactly when it gets expensive.

Here's how it happens:

You start with one workflow. Then two. Then a matrix build.
You add a scheduled job that runs every hour.
Your team grows. PRs multiply. Every push triggers a run.
You're on a paid plan, so you have a minutes budget — but no one's tracking it.

Three months later, you're staring at an overage charge and wondering where it came from.

How GitHub Actions Billing Actually Works

Let's get technical for a second, because the pricing model has some sharp edges.

Free tier:

Public repos: unlimited minutes
Private repos: 2,000 minutes/month (Free plan)

Paid plans (private repos):

Team: 3,000 minutes/month
Enterprise: 50,000 minutes/month

Sounds generous. Until you factor in OS multipliers.

Runner OS	Multiplier
Linux	1x
Windows	2x
macOS	10x

That's not a typo. macOS runners cost 10x more than Linux — minute for minute.

So if your workflow runs for 6 minutes on macOS, GitHub counts it as 60 minutes from your quota. One workflow. One push. 60 minutes gone.

Run that 10 times a day across a team of 5 developers, and you've burned through 3,000 minutes in a single day.

The Math That Nobody Does

Let's say your setup looks like this:

15 pushes/day across your team
A workflow that runs 8 minutes on macOS for tests
22 working days/month

That's: 15 pushes × 8 min × 10 (macOS multiplier) × 22 days = **26,400 minutes/month**

Your Team plan gives you 3,000. You're 23,400 minutes over.

At $0.08/minute for macOS runners, that overage alone is $1,872/month.

From one workflow. That nobody audited.

Why This Is Hard to Track Manually

GitHub does show you usage in Settings → Billing. But it doesn't show you:

Per-workflow breakdown of costs
Projections based on your current usage patterns
What happens if you switch a runner from macOS to Linux
How much you'd save by optimizing run frequency

You'd have to pull data, do the math yourself, and repeat every time something changes. Most developers don't. Most startups don't.

The Tool I Built to Fix This

I got tired of doing this math in spreadsheets, so I built a free calculator: githubactionscost.online

You plug in:

Your GitHub plan
Number of workflows
Average run duration
Runner OS (Linux / Windows / macOS)
Runs per day

And it instantly tells you your estimated monthly cost, quota consumption, and overage charges — before they hit your invoice.

No signup. No BS. Just the number.

Quick Wins to Cut Your GitHub Actions Bill

Before you even touch the calculator, here are three things you can do right now:

1. Switch macOS runners to Linux wherever possible
Unless you're testing Apple-specific builds, Linux handles most CI tasks perfectly. Going from macOS to Linux cuts that runner cost by 10x immediately.

2. Add path filters to your workflows

on:
  push:
    paths:
      - 'src/**'
      - 'tests/**'

This stops workflows from triggering on README edits, docs updates, or config file changes. Zero cost, instant savings.

3. Cache your dependencies aggressively

- uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}

Caching cuts run times significantly. Shorter runs = lower cost.

The Bigger Picture

GitHub Actions isn't expensive by default. It becomes expensive when nobody's watching.

The same way you'd set up alerts for AWS costs or monitor your database query times, your CI/CD pipeline deserves the same attention. It's infrastructure. It scales with your team. And it bills accordingly.

Take 2 minutes, plug your numbers into githubactionscost.online, and find out exactly where you stand.

You might be fine. Or you might find an easy $200/month sitting there waiting to be saved.

Either way — now you know.

Built by a developer who got tired of surprise CI bills. If this helped, share it with your team.

I got tired of guessing my cloud bills, so I built 12 free developer cost calculators (No login, No BS).

Shubham — Thu, 02 Apr 2026 14:40:54 +0000

Hey everyone,

I kept running into the same problem: trying to figure out exactly how much a CI/CD pipeline or a cloud service was going to cost before getting the actual bill at the end of the month. Comparing GitHub Actions vs GitLab CI, or trying to understand AWS Lambda vs EC2 costs, usually meant digging through endless pricing docs and doing the math manually.

So, I built a solution: a suite of 12 free, privacy-first developer cost calculators.

Here are a few of the tools included:

GitHub Actions Cost Calculator: Paste your YAML workflow and instantly see the exact per-run and monthly costs across Ubuntu, Windows, and macOS runners. (Did you know macOS runners cost 10x more than Ubuntu?)
CI/CD Cost Comparison: Compare GitHub Actions, GitLab CI, and CircleCI side-by-side to find the cheapest platform for your specific workflow.
AWS Tools: Lambda vs EC2 calculators, comparing x86 vs ARM Graviton2 architecture (switching to ARM can save you 20% on Lambda).
AI API Rate Limit Calculator: Figure out your max concurrent users and daily request budgets for OpenAI, Claude, Gemini, etc.
Tech Stack Cost Estimator: Estimate your total monthly infra cost combining tools like Vercel, Supabase, Clerk, Resend, etc.

Why I made it free:
Every developer deserves accurate pricing data without hitting a paywall, an email wall, or needing a credit card.

No Signup/Login: Just open and use it.
Fully Private: All calculations run entirely in your browser. Your data never leaves your device.
Up-to-date: Pricing data is updated for 2026.

I've put together a GitHub repo that lists all 12 tools, explains what they do, and has the direct links to use them.

You can check out the full list and access the calculators here:
👉 https://github.com/Shubhamorigin/cloud-cost-calculators

U can directly use it - https://githubactionscost.online
Let me know if you find it useful or if there are any other specific calculators you'd like to see added! Feedback is always welcome.

GitHub Actions Changed Pricing in 2026 — Here's Exactly What You're Paying Now

Shubham — Sat, 28 Mar 2026 04:57:43 +0000

In January 2026, GitHub updated their Actions runner pricing. Most teams didn't notice. Here's exactly what changed and how to calculate your new bill.

2026 Pricing Table

Ubuntu: $0.006/min (was $0.008 — 25% cheaper)
Windows: $0.010/min (was $0.016 — 37.5% cheaper)
macOS: $0.048/min (was $0.080 — 40% cheaper)

Good news — prices dropped.

Bad news — macOS still costs 8× more than Ubuntu. Most teams don't realize this until month-end.

The macOS Trap

10-minute macOS job: $0.048 × 10 = $0.48 per run
10-minute Ubuntu job: $0.006 × 10 = $0.06 per run

20 pushes/day:

macOS → $9.60/day → $288/month
Ubuntu → $1.20/day → $36/month

Same test output. $252/month difference.

5 Ways to Reduce Your Bill

Switch lint/typecheck jobs to Ubuntu — identical output, 8× cheaper
Use path filters — skip CI on docs-only commits
Cache node_modules, pip packages aggressively
Run tests in matrix parallel — same cost, faster
Only use macOS when you genuinely need Apple frameworks

Free Calculator

Paste your YAML → see exact monthly cost:

githubactionscost.online/github-actions-cost-calculator

No signup. Runs in browser. 2026 pricing.

How I Built 11 Cloud Cost Calculators to Solve "Bill Shock" (And Why I'm Moving On)

Shubham — Tue, 24 Mar 2026 15:27:52 +0000

Every developer has been there: You launch a side project on Vercel or AWS, and suddenly, you're hit with a bill you didn't expect.

I decided to solve this by building githubactionscost.online — a suite of 11+ high-precision calculators for Vercel, Netlify, Supabase, and more. Today, I want to share the technical journey and why I'm looking for a new owner to take this forward.

🛠️ The Tech Stack: "Keep it Simple & Static"

I wanted these tools to be lightning-fast and cost $0 to maintain.

Frontend: Pure HTML5, Tailwind CSS, and Vanilla JavaScript.
Architecture: No database. No heavy backend. Everything is calculated client-side for privacy and speed.
Ad-Blocker Proof: Instead of intrusive ads, I hardcoded "Native Recommendation Slots." They are part of the UI, meaning zero revenue loss to ad-blockers.

📈 The Results: 100% Organic Growth

Without spending a single penny on marketing, the platform started ranking for high-intent keywords.

Top Traffic Source: United States (High-intent devs and founders).
Secondary Sources: France, Germany, Canada.
SEO: The calculators rank for keywords where users are actively looking to switch providers—making it a lead-gen goldmine.

🧠 The Pivot: Moving to Aaptics

So, why sell a growing asset?

I’m currently building Aaptics, an AI platform designed to learn and clone your unique writing style. Aaptics is scaling fast and requires my 100% technical focus and capital for GPU infrastructure.

As a founder, I’ve realized that to build something great (Aaptics), I have to let go of other successful projects.

🤝 Looking for a New Owner

I am looking for a strategic exit this week to inject capital into Aaptics' growth.

What you get: Full GitHub repository, premium domain, and a ready-to-monetize Tier-1 traffic engine.
Target Price: Looking for a quick buyout in the $4,000 - $5,000 range.

If you’re a DevOps agency, a hosting provider, or an indie hacker looking for a high-authority asset, let’s talk!

DM me here or reach out via Twitter.

GitHub Actions Changed Pricing in 2026 — Here's Exactly What You're Paying Now (Free Calculator Inside)

Shubham — Mon, 23 Mar 2026 05:49:43 +0000

The Bill That Started This

In January 2026, GitHub quietly updated their Actions pricing.
Ubuntu went from $0.008/min to $0.006/min — a 25% reduction.
macOS went from $0.080/min to $0.048/min — a 40% drop.

Good news, right? Cheaper CI/CD.

Except most teams had no idea this happened.
And many teams are still paying for macOS runners
when Ubuntu would do the same job for 8x less.

The 2026 GitHub Actions Pricing (Official Numbers)

Runner	Old Price	New Price (Jan 2026)	Change
Ubuntu (Linux)	$0.008/min	$0.006/min	-25%
Windows	$0.016/min	$0.010/min	-37.5%
macOS	$0.080/min	$0.048/min	-40%

These are the overage rates after free tier.
Free tier: 2,000 min (Free), 3,000 min (Pro),
50,000 min (Team).

The macOS Problem Nobody Talks About

macOS runners cost 8x more than Ubuntu runners
on the new pricing. Before the update, it was 10x.

Still 8x.

Here's what that means in practice:

# This job on macOS: $0.048/min × 10 min = $0.48 per run
# This job on Ubuntu: $0.006/min × 10 min = $0.06 per run
jobs:
  test:
    runs-on: macos-latest  # ← costs 8x more than ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

If you push 20 times per day, that's:

macOS: $9.60/day → $288/month
Ubuntu: $1.20/day → $36/month

For the same test results.

The Windows Trap

Windows runners are 1.67x more expensive than Ubuntu:

Ubuntu: $0.006/min
Windows: $0.010/min

Many teams run cross-platform tests on Windows "just in case"
without checking if their Linux tests already cover it.

Self-Hosted Runner Change (March 2026 Controversy)

GitHub announced charges for self-hosted runners
(ephemeral, network access) — $0.002/min starting March 2026.

This is still significantly cheaper than hosted runners
but it caught many teams off guard who assumed
self-hosted = always free.

Free Minutes — Do You Know Your Limit?

Before any overage kicks in, you get:

Plan	Free Minutes/Month
Free	2,000
Pro	3,000
Team	50,000
Enterprise	50,000

With OS multipliers applied:

2,000 Linux minutes on Free plan
But only 200 macOS minutes (10x multiplier)
Or 666 Windows minutes (3x multiplier)

How to Calculate Your Actual Cost

I built a free calculator that does this instantly:

🔗 GitHub Actions Cost Calculator

Paste your workflow YAML → instant cost breakdown across
all 3 runner types → AI suggestions to reduce costs.

No signup. No account. Runs in browser. Nothing stored.

5 Ways to Reduce Your GitHub Actions Bill

1. Switch lint/type-check jobs to Ubuntu

# Before — expensive
lint:
  runs-on: macos-latest

# After — 8x cheaper, identical output
lint:
  runs-on: ubuntu-latest

2. Use path filters — skip CI on docs changes

on:
  push:
    paths:
      - 'src/**'
      - '!docs/**'
      - '!*.md'

3. Cache dependencies aggressively

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}

4. Run jobs in parallel instead of serial

strategy:
  matrix:
    test-suite: [unit, integration, e2e]
# All 3 run simultaneously — same total time, 
# same total cost, but faster wall-clock

5. Only run macOS when you truly need it

test:
  strategy:
    matrix:
      os: [ubuntu-latest, macos-latest]
  runs-on: ${{ matrix.os }}
  # Ask: does your macOS test find bugs Ubuntu misses?
  # If not, remove macos-latest from the matrix

The Bigger Picture — 11 More Billing Surprises

GitHub Actions is just one piece.

After I built that calculator, I realized the same problem
existed across the whole developer tooling ecosystem:

Docker Hub now throttles unauthenticated pulls to
10/hour (down from 100/6hr) — shared CI runner IPs
mean your builds fail because of other users
Firebase bills per Firestore document read —
one bad list query can cost $179/month
Netlify's new credit system makes bandwidth overage
cost $0.55/GB vs Vercel's $0.15/GB — 3.7x difference

I built free calculators for all of these:

→ DevCost Tools — All 12 Calculators

CI/CD, AWS Lambda, CodeBuild, Vercel vs Netlify,
Supabase vs Firebase, Docker Hub, CircleCI, GitLab CI,
AI API rate limits, full tech stack estimator.

All free. All 2026 pricing. All browser-side calculations.

Quick Reference — 2026 Pricing Cheat Sheet

GitHub Actions
  Ubuntu:  $0.006/min  (1x multiplier)
  Windows: $0.010/min  (1.67x multiplier)  
  macOS:   $0.048/min  (8x multiplier)

GitLab CI
  All OS:  $0.010/min flat  (no multiplier!)
  macOS:   6x compute minutes consumed

CircleCI
  Linux:   $0.006/min (10 credits/min)
  macOS:   $0.060/min (100 credits/min)
  1 credit = $0.0006

AWS Lambda
  x86:     $0.0000166667/GB-s
  ARM:     $0.0000133334/GB-s  (20% cheaper)
  Free:    1M requests + 400K GB-s/month

Docker Hub
  Unauth:  10 pulls/hour per IP
  Free:    100 pulls/hour per user
  Paid:    Unlimited

Which of these billing surprises caught you off guard?
Let me know in the comments 👇

And if this saved you from a surprise bill —
share it with one teammate who runs macOS builds.

Stop Flying Blind: How to Calculate and Optimize GitHub Actions Costs in Real-Time

Shubham — Sun, 22 Mar 2026 05:30:09 +0000

The Problem: The "Bill Shock" of 2026

In January 2026, GitHub updated its pricing model for runners and introduced new fees for certain self-hosted configurations. For many teams, CI/CD went from a "background cost" to a major line item on the monthly invoice.

The problem isn't just the cost; it's the unpredictability. How much does that new integration-test.yml actually cost per month? Usually, you only find out after the bill arrives.

Introducing GitHubActionsCost.online

I built githubactionscost.online to give developers a free, instant way to estimate and optimize their workflow spend before they even hit "git push."

🧠 How it Works: Technical Deep Dive

1. Zero-Trust YAML Parsing

Privacy is a major concern when handling infrastructure code. Instead of sending your YAML files to a backend server, the tool uses Client-Side Parsing.

The parsing logic is written in vanilla JavaScript that runs directly in your browser.
Your workflow secrets, job names, and logic never leave your machine.
It calculates costs based on the duration ($T$) and the specific runner rate ($R$) using the formula: $$Cost = T \times R$$

2. Side-by-Side Runner Comparison

The tool fetches the latest 2026 rates for Ubuntu, Windows, and macOS runners. It provides a clear comparison so you can see exactly how much you save by switching OS or using smaller instances.

3. AI-Powered Workflow Optimization

This is where the real savings happen. By integrating with the OpenRouter API, the tool analyzes your YAML structure to find "leaks."

Missing Timeouts: Jobs that hang can drain your credits.
Caching Opportunities: Identifying steps where actions/cache can shave off minutes.
Matrix Optimization: Consolidating jobs to reduce overhead.
Impact: Users have seen cost reductions of 40% to 60% just by following these AI suggestions.

🛠 The Stack

Frontend: Vanilla HTML/CSS/JS (for maximum speed and no-bloat).
Hosting: Vercel (Global Edge Network).
AI Engine: OpenRouter (providing access to the latest LLM models for workflow analysis).

Why I Built This

CI/CD should be a leverage, not a liability. By providing a transparent way to calculate costs—per run, per day, or per year—developers can make informed decisions about their automation infrastructure.

If you're tired of guessing your GitHub bill, give it a try. It’s open, free, and privacy-first.

Check it out: githubactionscost.online

I Built a Free GitHub Actions Cost Calculator Over a Weekend. Here's What 7 Days of Data Taught Me.

Shubham — Sat, 21 Mar 2026 05:14:57 +0000

Last month I got an email from GitHub.

Pricing changes. Effective January 2026. Self-hosted runners now have a per-minute fee attached.

I did the math for our team's workflows. The numbers were not catastrophic, but they were not small either. And the frustrating part was that I had to do that math manually — in a spreadsheet, looking up runner rates, estimating step times, multiplying everything out.

There had to be a better way.

So I built one.

What I Built

githubactionscost.online — a free GitHub Actions cost calculator.

Paste your workflow YAML. Get the exact cost per run, daily, monthly, and yearly. See what the same workflow would cost on Ubuntu, Windows, and macOS runners side by side. Then get AI-powered suggestions with copy-paste YAML code to cut your bill.

No account. No signup. No credit card. Your YAML never leaves your browser for the calculation part.

I built it in a weekend. Shipped it. And here is what happened.

The Numbers After 7 Days

I did not promote it anywhere. No Reddit post. No Hacker News. No tweet. Just deployed it and watched Google Analytics.

109 active users in 7 days.

That might sound small. But zero promotion, seven days, and a very niche developer tool? I will take it.

What surprised me more than the traffic was where it came from.

United States — 46 users (42%)
Makes sense. GitHub's largest user base.

France — 10 users (9%)
Did not expect this at all.

India — 6 users (5.5%)
Smallest number but by far the most engaged. Average session time of 6 minutes and 5 seconds. Engagement rate of 58%. These users actually used the tool.

Germany, Netherlands, UK, Poland, China, Colombia — all showed up organically.

Organic traffic from 10 countries in 7 days with zero promotion tells me the search intent is real right now.

Why GitHub Actions Costs Are Confusing

Most developers set up a workflow, get it working, and forget about it. The billing is abstracted away until the monthly invoice arrives.

Here is what catches people off guard.

GitHub charges different rates depending on which runner you use. And the difference is not small.

Runner	Cost Per Minute
Ubuntu (Linux)	$0.008
Windows	$0.016
macOS	$0.080

That macOS number deserves a moment of attention.

macOS runners cost 10 times more than Ubuntu runners. Per minute.

If you have a 10-minute workflow running on macos-latest instead of ubuntu-latest, and it triggers 20 times per day, the annual cost difference is over $5,000.

Most developers using macOS runners do not need macOS runners. They copied a workflow template, it had macos-latest in it, it worked, and they moved on. Nobody audited the runner choice.

That is exactly the kind of thing this tool surfaces.

A Real Example

Here is a standard Node.js workflow:

name: CI Pipeline
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'
      - run: npm install
      - run: npm run build
      - run: npm test
  deploy:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - uses: actions/checkout@v3
      - run: docker build -t myapp .
      - run: docker push myapp

Running this 10 times per day costs approximately $205 per month.

The AI suggested three changes:

1. Add npm caching

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}

Saves about 2 minutes per run by not re-downloading packages every time.

2. Add concurrency groups

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

Cancels outdated runs when new commits push quickly. If you push 3 times in 5 minutes, only the last one runs.

3. Use npm ci instead of npm install

- run: npm ci

Faster and more deterministic in CI environments.

Result: estimated monthly cost drops from $205 to around $85. That is 58% savings from three YAML changes.

How the Cost Calculation Actually Works

The tool parses your YAML using js-yaml in the browser. Then it estimates time for each step based on a database of known action timings.

actions/checkout — approximately 15 seconds.
actions/setup-node — approximately 20 seconds.
npm install — approximately 120 seconds.
docker build — approximately 180 seconds.
npm test — approximately 180 seconds.

It adds these up, rounds up to the nearest minute, multiplies by the runner's per-minute rate, and shows you per-run, daily, monthly, and yearly costs for every job.

Then it shows you the same job's cost across all four runner types side by side — Ubuntu, Windows, macOS, and self-hosted — so you can see immediately if you are on an expensive runner unnecessarily.

The AI suggestions come from a serverless function that sends your workflow structure to an LLM and asks for specific optimizations. The model returns JSON with titles, descriptions, savings estimates, priority levels, and copy-paste YAML code examples.

What I Learned Building This

The non-code work takes longer than the code.

Building the actual tool took a weekend. The domain purchase, DNS setup, Vercel deployment, SSL, privacy policy, terms, Google Analytics, Search Console verification, sitemap submission — that took another 3 days. For small solo projects, the launch infrastructure is real work.

Zero-friction tools get organic traffic.

I did not promote this anywhere and 109 people showed up in 7 days purely from search. Developer tools that solve a specific, searchable problem get found.

Timing matters more than most people think.

GitHub's pricing change in January 2026 created a search spike. The keywords "github actions price" and "github actions cost" are trending right now. Building a tool that matches a trending search intent is different from building a tool and then hoping people search for it.

The most engaged users are not always the largest segment.

India was 5.5% of my traffic but 58% engagement rate and 6 minutes average session time. The US was 42% of traffic but 4% engagement and 1 second average session. Knowing which segment actually uses your product versus which one bounces is important for understanding who you are really building for.

What Is Next

The tool is live and working. Promotion starts now — starting with this article.

After that: Hacker News, Reddit communities, and finding the right GitHub repositories where cost-conscious developers are already having this conversation.

If you use GitHub Actions and have not audited your runner choices recently — paste a workflow into the calculator. It takes about 30 seconds and might save you more than you expect.

githubactionscost.online — free, no signup, no data stored.

Built with vanilla HTML/CSS/JS, Vercel serverless functions, and OpenRouter for the AI suggestions. The entire frontend is a single HTML file.

The 3-line YAML mistake that quietly drains your GitHub Actions minutes (and how I built a local parser to catch it)

Shubham — Fri, 20 Mar 2026 04:43:24 +0000

We’ve all been there. You want to ensure your open-source library or SaaS works across all operating systems, so you proudly write this beautiful, innocent-looking matrix strategy in your .github/workflows/ci.yml:

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]

Looks harmless, right?

What GitHub’s documentation buries in the fine print is the Runner Multiplier Tax.
While Ubuntu runs at the base rate ($0.008/min), Windows costs 2x more, and macOS costs a staggering 10x more ($0.080/min).

If your test suite takes 15 minutes to run, that single macos-latest line just cost you $1.20 per run. If you have a team pushing 10 commits a day, you are burning hundreds of dollars on macOS runners for code that probably only needed Linux testing.

The Problem: Bill Shock is a lagging indicator

By the time you see the GitHub billing dashboard at the end of the month, the damage is already done. I wanted a way to see the exact cost before I committed the YAML.

But here is the catch: No sane developer is going to paste their company’s proprietary CI/CD infrastructure code into a random third-party website.

The Solution: A 100% Client-Side Cost Calculator

I decided to build a standalone web tool to solve this: GitHub Actions Cost Calculator.

Instead of building a backend that ingests and stores your YAML (which is a massive security red flag), I built the entire parsing engine to run locally in your browser.

Here is how the architecture works:

Zero Server Dependency: You paste your YAML, and a client-side JS parser breaks down the jobs, steps, and runs-on variables.
The 10x Exposer: It immediately splits the cost projection side-by-side (Ubuntu vs. Windows vs. macOS), exposing exactly how much that matrix strategy is costing you per day/month/year.
AI Optimization: It runs a quick heuristic check to suggest caching (actions/cache) and runner downgrades to slash the bill by up to 60%.

Because everything happens in your browser DOM, your YAML is never stored, logged, or sent to a database. ### Test your heaviest workflow

If you are managing CI/CD for your team, I challenge you to drop your heaviest, most complex workflow file into the calculator. You might be surprised by how much that one macOS job is silently eating your budget.

Try it out here (no signup required): www.githubactionscost.online

I'm a solo dev building this out, so if you find any edge cases with complex matrix arrays or reusable workflows that the parser misses, let me know in the comments! How do you guys currently monitor your Actions billing?