DEV Community: Taqin

I built a 7 MB XAMPP alternative for Windows in pure Go (no Docker, no WSL)

Taqin — Sat, 11 Apr 2026 08:41:10 +0000

A few weekends ago I got fed up with the same Windows web-dev ritual and wrote my own control panel. The result is GoAMPP — a 7 MB single-binary native Win32 app that knows how to download and manage Apache, Nginx, MariaDB, PostgreSQL, Redis, PHP, phpMyAdmin, Adminer, plus four language runtimes (Node.js, Python, Go, Java) and seventeen framework scaffolders.

Repo: github.com/imtaqin/goampp

This post is a brain dump of the design choices I made, the bugs I hit, and the parts of Win32 that bit me along the way. Hopefully somebody else building a desktop app in Go finds the post-mortem useful.

Why not just use XAMPP

Three reasons I ran out of patience with the existing options:

The installers are huge. XAMPP for Windows is around 200 MB downloaded, more after install, even though I only ever use Apache + MariaDB + PHP + phpMyAdmin. The rest is dead weight.
Versions go stale. When PHP 8.5.0 dropped, the bundled version in XAMPP took months to catch up. Same story with MariaDB LTS bumps.
The control panels are fragile. XAMPP's panel hangs when Apache crashes mid-startup and the pid file is stale. Laragon is better but ships with Cmder, a Telegram notifier, and a bunch of stuff I didn't ask for.

The mental model I wanted: ship a tiny control panel, fetch the services on demand, cache them locally, and never bundle anything I'm not actively using. Closer to a package manager than an installer.

The architecture in 30 seconds

GoAMPP is a single Go binary built with -ldflags="-H windowsgui -s -w" so it has no console window and is stripped down to ~7 MB. The GUI uses windigo, a pure-Go binding for the Win32 widget set — no CGO, no webview, no Electron.

Inside the binary there's a DownloadCatalog map keyed on service name. Each entry has the download URL, the install directory, an optional StripTop for archives that wrap everything in a top-level folder, and a PostInstall hook for things like running mariadb-install-db.exe or patching httpd.conf.

Screenshot

"Apache": {
    Version:    "2.4.66 (VS18, win64)",
    URL:        "https://www.apachelounge.com/download/VS18/binaries/httpd-2.4.66-260223-Win64-VS18.zip",
    InstallDir: "bin/apache",
    StripTop:   "Apache24/",
    Kind:       "zip",
    CheckFile:  "bin/httpd.exe",
    PostInstall: func(installDir string, log func(string)) error {
        // patch httpd.conf to fix SRVROOT, ServerName, mod_cgi, etc.
    },
},

When you click Start on a service whose binary isn't on disk yet, the flow is:

Check the catalog for an entry. Bail if missing.
Spawn a goroutine so the UI stays responsive.
Stream the zip into downloads/<filename>.part. Atomic rename on success.
Walk the archive entries, strip StripTop if set, write to bin/<service>/. Guard against zip-slip — refuse any entry whose resolved path escapes the destination.
Run the post-install hook.
Start the process.

The download progress fires through a ProgressFunc callback that the UI uses to drive a ProgressBar widget at ~30 Hz. Text logging fires at 1 Hz in parallel because writing to a multi-line Edit control is expensive — every line is a full WM_SETTEXT round trip.

The Apache bug I lost an evening to

This one's worth its own section because it's the kind of bug that doesn't show up on Linux at all.

The first version of GoAMPP used mod_proxy_fcgi with the standard idiom:

<FilesMatch \.php$>
    SetHandler "proxy:fcgi://127.0.0.1:9000"
</FilesMatch>

Apache logs the script's full filesystem path in the upstream URL. On Linux that produces something sane like fcgi://127.0.0.1:9000/var/www/script.php. On Windows, the script path includes a drive letter (C:/...), and Apache concatenates without inserting a slash:

fcgi://127.0.0.1:9000 + C:/Users/.../script.php
= fcgi://127.0.0.1:9000C:/Users/.../script.php

The proxy URL parser then sees host=127.0.0.1, port=9000C, path=/Users/..., and the DNS resolver loses its mind:

AH00898: DNS lookup failure for: 127.0.0.1:9000c

This is Apache bug 55345, open since 2013. The workaround documented in the comments is to use ProxyPassMatch with the docroot baked into the URL, but I tested that route and PHP-CGI then complained "No input file specified" because the SCRIPT_FILENAME ended up with a leading slash that Windows refused to resolve.

The fix that actually works is to use mod_cgi + mod_actions + a ScriptAlias to point at php-cgi.exe directly. It's the classic CGI approach XAMPP has used for fifteen years. Slightly slower per request than FastCGI but bulletproof on Windows because there's no proxy URL to construct in the first place:

LoadModule cgi_module modules/mod_cgi.so
LoadModule actions_module modules/mod_actions.so

ScriptAlias "/__goampp-php-bin__/" "C:/.../bin/php/"
<Directory "C:/.../bin/php">
    AllowOverride None
    Options +ExecCGI
    Require all granted
</Directory>
AddHandler application/x-httpd-php .php
Action application/x-httpd-php "/__goampp-php-bin__/php-cgi.exe"

Lesson learned: when a Windows Apache config uses proxy:fcgi://, run tail -f error_log and look for 9000c in the DNS error messages. It's never your firewall.

Process management on Windows is harder than it looks

The first time I clicked Stop on Apache, the process exited and the log said [Apache] exited cleanly. Two seconds later I clicked Start again and got port 80 already in use. Reboot. Repeat. The bug took a while to find.

Here's what was happening: Apache's winnt MPM forks a worker child. When you cmd.Process.Kill() the parent, the child keeps running because Windows doesn't have process groups in the POSIX sense. The orphaned worker holds the listening socket on port 80 until you manually kill it via Task Manager.

Fix: use taskkill /F /T /PID <pid> instead of cmd.Process.Kill(). The /T flag ("kill tree") nukes the parent and every descendant in one shot. Since GoAMPP launches services with a known parent PID, the tree kill catches the worker too.

I also added a startup sweep that walks all processes via PowerShell (Get-Process | Where-Object { $_.Path }) and kills anything whose image path is inside <goampp>/bin/. That cleans up zombies left from prior crashes — say, when Apache died because httpd.conf had a syntax error and the worker was already running. Without the sweep, the next launch would hit "port 80 in use" and look broken.

I originally used wmic for the sweep, but Windows 11 22H2+ removed it from the default install. PowerShell ships with every modern Windows so it's a safer dependency.

Native ListView groups: fragile

I wanted the Services view to render with collapsible category headers (Web Servers / Languages / Databases / Tools) using native ListView groups. Win32 supports them via LVM_ENABLEGROUPVIEW + LVM_INSERTGROUP. windigo doesn't expose either, so I tried to do it via raw SendMessage.

The LVGROUP struct has a documented Vista+ size of 148 bytes on 32-bit. On 64-bit, with 8-byte pointers and Go's struct padding, unsafe.Sizeof() returns 152. I tried both values for cbSize. Both rejected. The Common Controls v6 DLL on Win11 silently returns -1 from LVM_INSERTGROUP for reasons I never tracked down.

Eventually I gave up and built a hand-rolled card grid: 12 child Control containers with their own Static for the icon, Static for the name, and four Button widgets per card. Each card's button-click handler captures the source service index in a closure, so I never need a "currently selected service" lookup. The result is more code than the ListView would have been but it actually works and the per-card buttons read better visually.

Sometimes the right answer is "give up on the fancy widget and draw it yourself".

The icons-on-cards trick

Each card has a 32×32 service logo on the left. Apache, Nginx, PHP, MariaDB, PostgreSQL, Redis, phpMyAdmin, Adminer, plus all four runtimes — twelve logos total.

windigo's icon API only supports icons embedded as Win32 resources, not files on disk. I needed to load .ico files at runtime, so the workflow ended up:

A build-time tool (tools/makelogos) reads a PNG from icon/<name>.png, resizes it to 32×32 with golang.org/x/image/draw's Catmull-Rom kernel, encodes the result as a PNG, wraps it in a single-entry ICO header, and writes assets/icons/<name>.ico.
At runtime, installServiceIcons() calls win.HINSTANCE(0).LoadImage(ResIdStr(icoPath), IMAGE_ICON, 32, 32, LR_LOADFROMFILE) for each service and stores the resulting HICON in a per-name map.
Each card's SS_ICON Static gets its icon set via SendMessage(STM_SETICON, hIcon, 0) — windigo doesn't expose STM_SETICON so I define the constant (0x0170) inline and dial SendMessage directly.

Modern Windows accepts PNG-encoded entries inside ICO files, which means each .ico is roughly the size of the resized PNG plus 22 bytes of header. The whole assets/icons/ directory is ~18 KB.

What's in the box today

Services: Apache 2.4.66, Nginx 1.28.3, MariaDB 11.4.10 LTS, PostgreSQL 18.3, Redis 5.0.14.1, PHP 8.5.5 NTS, phpMyAdmin 5.2.3, Adminer 5.4.2
Runtimes: Node.js 22 LTS, Python 3.13 (embeddable, with auto-bootstrapped pip), Go 1.26, Eclipse Temurin JDK 21
Frameworks: Laravel, Laravel + Livewire, Symfony, CodeIgniter 4, WordPress, Next.js, Vite + React, Express, NestJS, AdonisJS, Flask, Django, FastAPI, Go net/http, Gin, Spring Boot, Static HTML
System: auto-vhost (writes hosts file + Apache vhosts.conf), system tray, minimize-to-tray, auto-start at Windows boot, "Add tools to PATH" (writes user PATH in HKCU registry), built-in text editor for service config files

The installer is 5.4 MB, per-user (no admin needed), and lives at github.com/imtaqin/goampp/releases.

What I'd do differently

A few honest retrospectives:

Pick a UI library that doesn't make you fight padding. windigo is great for what it is, but laying out 12 cards in a 4×3 grid by hand-positioning every Static and Button taught me a lot about why Flutter and SwiftUI exist.
Write the elevation helper from day one. I shipped the first version without a "Restart as Admin" button and immediately needed it the first time I tried to write the hosts file. Adding it later was easy; explaining to users why the vhost Apply button silently failed was not.
Don't assume wmic is on every Windows install. Past me would have been less embarrassed by an empty .gitignore than by a startup sweep that silently no-op'd on every Win11 22H2 machine.

If you're building a desktop tool in Go and you want native Win32 widgets without the Electron tax, the answer is windigo + a lot of patience with WM_* messages. Total code for GoAMPP including the installer script is around 6,000 lines.

Try it

Latest installer: github.com/imtaqin/goampp/releases/latest (5.4 MB)

Source: github.com/imtaqin/goampp

Issues, PRs, and questions all welcome. If you hit a download URL that's gone stale, file an issue with the service name and I'll bump the catalog.

I manage 11 Cloudflare domains from my phone now

Taqin — Sat, 04 Apr 2026 11:42:53 +0000

Managing 11 Cloudflare domains used to mean opening the dashboard on a laptop every single time.

Change a DNS record? Laptop. Purge cache? Laptop. Check if traffic is spiking? Laptop.

Got tired of it.

So I made CloudFlare Mobile — an Android app that gives you full control of your Cloudflare account from your phone.

Open source. MIT license. No tracking. No telemetry.

What it does

Zone Management

All your domains in one scrollable list. Search by name, see status badges (active/pending), nameserver count. Tap any zone to dive into its settings.

DNS Records

Full CRUD. A, AAAA, CNAME, MX, TXT, SRV — all record types supported. Toggle Cloudflare proxy (orange cloud) on or off per record. Filter by record type. Search by name.

Adding a record is the same flow as the dashboard — pick type, enter name, content, TTL, proxy status, done.

SSL/TLS

Switch encryption mode between Off, Flexible, Full, and Full (Strict). See current certificate status and HTTPS settings. No more fumbling through the web dashboard to find that one toggle.

Firewall

View and manage firewall rules, IP access rules, rate limiting. See which rules are active. Block or challenge traffic patterns when you spot something suspicious in analytics — right there on your phone.

Cache

One-tap purge all cache. Toggle development mode when you're pushing updates and need to bypass cache for 3 hours. Check cache level and browser TTL settings.

This one alone saves me multiple laptop opens per week.

Analytics

Traffic volume, bandwidth usage, cache hit ratio, threat overview. Quick health check on how your sites are performing without logging into the dashboard.

Workers, KV, R2, Pages

View Worker scripts. Browse KV namespaces. Check R2 buckets. Monitor Pages projects and their latest deployments.

Multi-Account

Got personal and work Cloudflare accounts? Switch between them in settings. No need to log out and back in.

Page Rules

Configure URL-based rules per zone. Forwarding, cache level overrides, SSL mode per path — all manageable.

Security

This matters. You're handing an app your Cloudflare API credentials.

Here's how it works:

Supports API Token (scoped, recommended) and Global API Key authentication
Credentials are stored locally on your device using Android Keystore — hardware-backed encryption
Nothing gets sent anywhere except directly to api.cloudflare.com over HTTPS
No analytics SDK. No tracking. No telemetry. No Firebase. No Sentry. Nothing.
The app is open source — you can read every line of code before trusting it

I use API Tokens with scoped permissions. You should too. Create a token at dash.cloudflare.com/profile/api-tokens with only the permissions you need.

The UI

Dark mode, light mode, or follow system. Switches instantly.

English and Bahasa Indonesia. More languages easy to add — it's just JSON files with i18next.

Sensitive data (emails, account IDs) are masked by default in the UI. There's a toggle to reveal them in settings.

Tech stack

For those who care about what's under the hood:

React Native 0.81 + Expo 54 — cross-platform framework
Expo Router — file-based navigation, feels native
Expo Secure Store — wraps Android Keystore for credential storage
Axios — HTTP client hitting Cloudflare API v4 directly
i18next — internationalization
react-native-svg — entire icon system is custom SVG, no icon font dependencies
TypeScript — full type safety across the app

No state management library. Just React Context for auth and theme. Keeps it simple.

The Cloudflare API client (services/cloudflare.ts) has 100+ typed functions covering zones, DNS, SSL, firewall, cache, analytics, Workers, KV, R2, Pages, and more.

How to get your API Token

This is where most people get stuck, so here's the exact steps:

Go to dash.cloudflare.com
Click your profile icon (top right) > My Profile
Click API Tokens in the sidebar
Click Create Token
Choose a template or create custom:
- Zone:Read — view zones
- DNS:Read/Edit — manage DNS records
- Zone Settings:Read/Edit — SSL, cache, etc.
- Firewall Services:Read/Edit — firewall rules
- Analytics:Read — view analytics
- Worker Scripts:Read/Edit — manage Workers
Click Continue to summary > Create Token
Copy the token — you only see it once

Paste it into the app. Done.

Known limitations

Being transparent about what this can't do:

Rate limiting — Cloudflare API allows 1,200 requests per 5 minutes. Heavy usage may hit the limit.
No offline mode — everything is fetched live from the API. No local caching of zone data yet.
Workers editor — you can view scripts but can't edit code inline. Use the web dashboard for that.
iOS — not tested. Built Android-first. Should work with Expo but hasn't been validated.
Two-factor auth — the app doesn't handle 2FA directly. API Tokens bypass 2FA by design.

Running it yourself

git clone https://github.com/imtaqin/CFMobile.git
cd CFMobile
npm install
npx expo start

Scan the QR code with Expo Go, or run on an emulator with npx expo run:android.

What's next

Some things on my mind:

Offline caching for zone and DNS data
Push notifications for zone status changes
Bulk DNS record operations
More languages
iOS testing and App Store submission

Open to suggestions. What would you actually use?

I Spent 3 Years Learning How Big Tech Scales Their Databases. Here's What Actually Matters.

Taqin — Tue, 03 Feb 2026 15:28:56 +0000

Everyone talks about scaling. Most people have no idea what it actually means.

I used to think scaling meant buying a bigger server. More RAM. Faster CPU. Problem solved. Then I started working on systems that handle millions of requests per second. Turns out, you can't just buy your way out of scale problems.

Let me tell you what actually happens when you need to store billions of records and serve them fast.

The moment everything breaks

Picture this. Your app is growing. Users are happy. Then one day, your database starts choking. Queries that took 50ms now take 5 seconds. Your single PostgreSQL instance is sweating bullets trying to handle 10,000 queries per second.

You throw money at it. Bigger instance. More memory. It helps for a month. Then you're back to square one.

This is where most startups panic. And this is exactly where big tech companies figured out something different decades ago.

They stopped thinking vertically. They started thinking horizontally.

The big idea that changes everything

Instead of one massive database, you use hundreds of smaller ones.

Sounds simple. It's not.

The concept is called sharding. You take your data and split it across multiple databases. User 1 through 1 million goes to database A. User 1 million to 2 million goes to database B. And so on.

Now instead of one database handling everything, you have 50 databases each handling a small piece. Your capacity just multiplied by 50.

Google does this. Facebook does this. Every company operating at serious scale does this.

But here's what nobody tells you about sharding.

The ugly parts nobody talks about

Sharding sounds great until you actually implement it.

First problem. How do you decide which data goes where? If you shard by user ID, what happens when you need to query across multiple users? You're suddenly hitting 50 databases for one request.

Second problem. What happens when you need more shards? You've got 50 databases and they're all getting full. Now you need to move data around without taking the whole system down. This is called resharding and it's a nightmare.

Third problem. Transactions across shards are basically impossible. Try updating two records that live on different databases atomically. Good luck.

I've seen teams spend months fixing issues they created by rushing into sharding without understanding these tradeoffs.

The stack that actually works at scale

After seeing what works and what doesn't, here's what I'd use today if I needed to build something that scales to billions of records.

For the database layer, you've got a few solid options.

CockroachDB or Google Spanner if you need SQL and horizontal scaling. They handle the sharding complexity for you. Your app talks to it like a normal database but underneath it's distributed across machines.

Vitess if you're already on MySQL and can't migrate. YouTube runs on this. It's battle-tested at insane scale.

Cassandra or ScyllaDB if you're write-heavy and can live with eventual consistency. These things can handle millions of writes per second if you design your data model right.

For caching, Redis Cluster is the standard. Most of your reads should hit cache and never touch the database. A good caching strategy can eliminate 90% of your database load.

For coordination, etcd or ZooKeeper. Someone needs to keep track of which shard lives where and which nodes are alive. These tools handle that.

How a request actually flows through this mess

Let me walk you through what happens when a user loads their profile on a system like this.

Request hits a load balancer. Gets routed to one of hundreds of API servers.

API server checks Redis cache first. "Do I already have this user's profile cached?" If yes, return it immediately. Request done in 2ms.

Cache miss. Now we need the database. But which one? The shard router looks at the user ID, does some math, figures out this user lives on shard 47.

Query goes to shard 47. Gets the data. Response flows back up.

On the way back, we populate the cache so next time we don't hit the database.

The whole thing takes maybe 50ms on a cache miss. 2ms on a cache hit.

Multiply this by millions of concurrent users and you see why every layer matters.

The stuff that keeps engineers up at night

The technology is honestly the easy part. The operational challenges are what kill you.

Backups at this scale are wild. You can't just dump a petabyte of data to a file. You need incremental backups, point-in-time recovery, and the ability to restore individual shards without touching others.

Monitoring becomes critical. With 100 database instances, you need to know immediately when one starts acting weird. You need dashboards. Alerts. Automated failover.

Schema migrations are terrifying. Changing a column on a billion-row table that's actively serving traffic? You need online schema change tools and a lot of patience.

Where to actually start

If you're building something new and thinking about scale, here's my honest advice.

Don't prematurely optimize. Start with a single PostgreSQL instance. It can handle more than you think. Most apps never actually need to shard.

But design with distribution in mind. Use UUIDs instead of auto-increment IDs. Keep your queries simple. Don't rely on joins that would be impossible across shards.

When you actually need to scale, evaluate CockroachDB or PlanetScale first. They handle a lot of the distributed complexity so you don't have to.

Add Redis caching early. It's easy to implement and gives you massive headroom before you need to think about database scaling.

The real secret

Here's what took me years to understand.

Scaling isn't really a technical problem. It's a design problem.

The companies that scale well aren't the ones with the fanciest technology. They're the ones who designed their systems to be distributed from the start. They thought about data locality. They minimized cross-service dependencies. They built stateless services that can run anywhere.

Get the design right and scaling becomes manageable. Get it wrong and no amount of technology will save you.

What's the hardest scaling problem you've faced? I'm curious what others have run into.

I Spent Hours Googling Port Forwarding. Then I Found Cloudflare Tunnel

Taqin — Sun, 11 Jan 2026 09:06:51 +0000

I have this internal service running on a server behind NAT. Private IP, no public access. The usual nightmare.

My ISP doesn't give me a static IP. My router's port forwarding UI looks like it was designed in 2003. And every time I finally get it working, my IP changes and everything breaks.

Then I found Cloudflare Tunnel. Took me 10 minutes to expose my service to the internet with a custom domain. No port forwarding. No static IP needed. Free.

Here's exactly how I did it.

The Problem

I had a service running on 192.168.39.231:8088. HTTPS with a self-signed cert. I needed to access it from anywhere, ideally at a nice domain like myapp.mydomain.com.

The traditional approach:

Get a static IP (costs money)
Forward ports on your router (pain in the ass)
Set up dynamic DNS (another thing to maintain)
Deal with SSL certs (Let's Encrypt works but still annoying)

Or just use Cloudflare Tunnel.

Quick Tunnel (The Fast Way)

If you just want to test something quick, there's a zero-config option:

cloudflared tunnel --url https://192.168.39.231:8088 --no-tls-verify

That's it. Cloudflared gives you a random URL like alice-ion-married-knights.trycloudflare.com. Your service is now public.

The --no-tls-verify flag is important if your origin has a self-signed cert. Without it, cloudflared refuses to connect because it can't verify the certificate.

But random URLs suck. Let's set up a proper custom domain.

Named Tunnel (The Right Way)

You need a Cloudflare account and your domain added to Cloudflare for this.

Step 1: Login

cloudflared tunnel login

Opens a browser. You authenticate. It downloads a cert to ~/.cloudflared/cert.pem.

Step 2: Create the tunnel

cloudflared tunnel create my-app

You get output like:

Tunnel credentials written to /root/.cloudflared/8a0b7c44-4677-421e-810b-f5e6de9d0555.json
Created tunnel my-app with id 8a0b7c44-4677-421e-810b-f5e6de9d0555

Save that tunnel ID. You need it.

Step 3: Route your domain

cloudflared tunnel route dns my-app app.yourdomain.com

This creates a CNAME record in Cloudflare pointing your subdomain to the tunnel.

Step 4: Create config

Create ~/.cloudflared/config.yml:

tunnel: my-app
credentials-file: /root/.cloudflared/8a0b7c44-4677-421e-810b-f5e6de9d0555.json

ingress:
  - hostname: app.yourdomain.com
    service: https://192.168.39.231:8088
    originRequest:
      noTLSVerify: true
  - service: http_status:404

Replace the tunnel ID with yours. Replace the hostname with yours.

The noTLSVerify: true is the config file equivalent of --no-tls-verify. You need this for self-signed certs.

The last ingress rule catches everything else and returns 404. It's required.

Step 5: Run it

cloudflared tunnel run my-app

Done. Your service is now live at https://app.yourdomain.com.

Common Issues I Hit

"Unable to reach the origin service"

Your service isn't running, or cloudflared can't reach it. Test with:

curl -k https://192.168.39.231:8088

If curl can't reach it, cloudflared can't either.

"tls: failed to verify certificate"

Your origin has a self-signed cert. Add --no-tls-verify for quick tunnels or noTLSVerify: true in config for named tunnels.

"credentials file doesn't exist"

You forgot to replace <TUNNEL-ID> in the config with your actual tunnel ID. The credentials file path must match exactly what was created in step 2.

Running as a Service

You probably don't want to keep a terminal open forever. Install cloudflared as a system service:

cloudflared service install
systemctl start cloudflared
systemctl enable cloudflared

Now it runs on boot and restarts if it crashes.

Why This is Better

No port forwarding headaches
No static IP needed
No dynamic DNS bullshit
Free SSL from Cloudflare
Works behind strict NATs and firewalls
The tunnel connects outbound, so it works even when inbound ports are blocked

I should have found this years ago.

The Bottom Line

If you're exposing internal services to the internet the old way, stop. Cloudflare Tunnel takes 10 minutes to set up and just works.

The quick tunnel is great for testing. Named tunnels with custom domains are what you want for anything real.

What internal services are you exposing? Hit me up - curious what others are running through tunnels.

I Built a WhatsApp Gateway in Rust Because Node.js Wasn't Cutting It

Taqin — Thu, 01 Jan 2026 08:29:03 +0000

I was running 50+ WhatsApp sessions on a single Node.js server.

Memory usage? 8GB. CPU? Constantly spiking. And every few hours, something would crash.

So I rewrote the whole thing in Rust. Now it handles 200+ sessions on 512MB RAM.

Here's the whole story.

The Problem With Every WhatsApp API Out There

Every WhatsApp gateway I found had the same issues:

Baileys + Node.js — Works great until you scale. Then memory leaks eat you alive.
Python solutions — Slow. Really slow.
Paid APIs — $50/month per number? Fuck that.

I needed something that could:

Handle hundreds of sessions simultaneously
Not crash every 6 hours
Actually be fast
Run on a $5 VPS

Nothing fit. So I built it.

Why Rust?

I know, I know. "Rust is hard." "Just use Go."

But here's the thing — Rust's memory safety isn't just a flex. When you're managing hundreds of WebSocket connections and encryption keys, you need guarantees.

Plus, the whatsapp-rust library exists. Someone already did the hard part of reverse-engineering the WhatsApp Web protocol. I just needed to wrap it in an API.

What I Built: WA-RS

WA-RS is a multi-session WhatsApp REST API gateway. One server, unlimited WhatsApp accounts.

The stack:

Component	Tech
Runtime	Rust (Nightly)
Web Framework	Axum 0.8
Database	PostgreSQL
Templates	Askama
API Docs	OpenAPI 3.0 / Swagger

Features That Actually Matter

✓ Multi-session — Run 100+ WhatsApp accounts on one server
✓ QR Code & Pair Code — Two ways to link devices
✓ Rich Messages — Text, images, video, audio, docs, stickers, location
✓ Webhooks — Real-time events with HMAC-SHA256 signatures
✓ Web Dashboard — Visual management, no CLI needed
✓ Swagger UI — Test endpoints without Postman

Getting Started (It's Stupid Simple)

Option 1: Docker (Recommended)

Pull from Docker Hub:

docker pull fdciabdul/wa-rs:latest

Option 2: Docker Compose (Full Stack)

Create a docker-compose.yml:

services:
  wa-rs:
    image: fdciabdul/wa-rs:latest
    ports:
      - "3451:3451"
    environment:
      - POSTGRES_HOST=postgres
      - POSTGRES_PORT=5432
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=wagateway
      - JWT_SECRET=change-this-in-production
    volumes:
      - wa_sessions:/app/whatsapp_sessions
    depends_on:
      - postgres

  postgres:
    image: postgres:16-alpine
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=wagateway
    volumes:
      - pg_data:/var/lib/postgresql/data

volumes:
  wa_sessions:
  pg_data:

Run it:

docker compose up -d

That's it. Server running on http://localhost:3451.

Option 3: Build From Source

For the masochists who want to compile themselves:

# Clone the repo
git clone https://github.com/fdciabdul/wa-rs.git
cd wa-rs

# Install Rust nightly (required)
rustup default nightly

# Set up your .env
cp .env.example .env
# Edit .env with your Postgres credentials

# Build and run
cargo run --release

The API

All endpoints require authentication. Get your token first (see Authentication section below).

Create a Session

curl -X POST http://localhost:3451/api/v1/sessions \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "id": "my-session",
    "name": "My WhatsApp",
    "webhook": {
      "url": "https://your-server.com/webhook",
      "secret": "webhook-secret",
      "events": ["message", "connected", "disconnected"]
    }
  }'

Connect a Session

curl -X POST http://localhost:3451/api/v1/sessions/my-session/connect \
  -H "Authorization: Bearer YOUR_TOKEN"

Get QR Code

curl http://localhost:3451/api/v1/sessions/my-session/qr \
  -H "Authorization: Bearer YOUR_TOKEN"

Returns base64 PNG. Scan it with WhatsApp. Done.

Get Pair Code (Alternative to QR)

curl -X POST http://localhost:3451/api/v1/sessions/my-session/pair-code \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"phone": "628123456789"}'

Returns an 8-digit code. Enter it in WhatsApp → Settings → Linked Devices → Link with phone number.

Send a Text Message

curl -X POST http://localhost:3451/api/v1/sessions/my-session/messages/text \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "628123456789",
    "text": "Hello from WA-RS!"
  }'

Send an Image

curl -X POST http://localhost:3451/api/v1/sessions/my-session/messages/image \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "628123456789",
    "url": "https://example.com/image.jpg",
    "caption": "Check this out!"
  }'

Send a Video

curl -X POST http://localhost:3451/api/v1/sessions/my-session/messages/video \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "628123456789",
    "url": "https://example.com/video.mp4",
    "caption": "Watch this"
  }'

Send Audio

curl -X POST http://localhost:3451/api/v1/sessions/my-session/messages/audio \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "628123456789",
    "url": "https://example.com/audio.mp3",
    "ptt": true
  }'

Set ptt: true for voice note style, false for regular audio file.

Send a Document

curl -X POST http://localhost:3451/api/v1/sessions/my-session/messages/document \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "628123456789",
    "url": "https://example.com/document.pdf",
    "filename": "invoice.pdf",
    "caption": "Here is the invoice"
  }'

Send a Sticker

curl -X POST http://localhost:3451/api/v1/sessions/my-session/messages/sticker \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "628123456789",
    "url": "https://example.com/sticker.webp"
  }'

Send Location

curl -X POST http://localhost:3451/api/v1/sessions/my-session/messages/location \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "628123456789",
    "latitude": -6.2088,
    "longitude": 106.8456,
    "name": "Jakarta",
    "address": "Jakarta, Indonesia"
  }'

Send Contact Card

curl -X POST http://localhost:3451/api/v1/sessions/my-session/messages/contact \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "628123456789",
    "contact": {
      "display_name": "John Doe",
      "phones": [
        {"number": "+1234567890", "phone_type": "CELL"}
      ]
    }
  }'

Edit a Message

curl -X POST http://localhost:3451/api/v1/sessions/my-session/messages/edit \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "628123456789",
    "message_id": "3EB0ABC123...",
    "text": "Updated message text"
  }'

React to a Message

curl -X POST http://localhost:3451/api/v1/sessions/my-session/messages/react \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "628123456789",
    "message_id": "3EB0ABC123...",
    "emoji": "👍"
  }'

Disconnect a Session

curl -X POST http://localhost:3451/api/v1/sessions/my-session/disconnect \
  -H "Authorization: Bearer YOUR_TOKEN"

Delete a Session

curl -X DELETE http://localhost:3451/api/v1/sessions/my-session \
  -H "Authorization: Bearer YOUR_TOKEN"

The Dashboard

I hate CLIs for management. So I built a web dashboard.

Go to http://localhost:3451/dashboard and you get:

Session overview — See all accounts, connection status at a glance
Create sessions — Point and click, no curl commands needed
QR codes — Scan right from the browser
Pair codes — Link with phone number instead of QR
Webhook config — Set up integrations visually
Settings — View your API token, endpoints, version info

The design is dark mode only. Because light mode is a war crime.

Dashboard Routes

All public, no auth needed:

Route	What it shows
`/dashboard`	Main overview with stats
`/dashboard/sessions`	List all sessions
`/dashboard/sessions/new`	Create new session form
`/dashboard/sessions/:id`	Session detail, QR code, actions
`/dashboard/settings`	API token, endpoints, version

Authentication

Getting Your Token

On first startup, the server generates a superadmin token. Two ways to find it:

Option 1: Check the logs

docker compose logs wa-rs | grep "SUPERADMIN"

You'll see something like:

┌─────────────────────────────────────────────────────────────┐
│  SUPERADMIN TOKEN                                            │
├─────────────────────────────────────────────────────────────┤
│  eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJzdXBlcmFkbWluIiwicm9sZSI... │
├─────────────────────────────────────────────────────────────┤
│  Tip: Set SUPERADMIN_TOKEN in .env to use a fixed token     │
└─────────────────────────────────────────────────────────────┘

Option 2: Dashboard

Go to http://localhost:3451/dashboard/settings — the token is right there.

Using the Token

Include it in every API request:

curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9..." \
  http://localhost:3451/api/v1/sessions

Using Swagger UI

Go to http://localhost:3451/swagger-ui
Click the Authorize button (top right)
Paste your token
Now all requests include the token automatically

Fixed Token (Production)

Don't want a random token every restart? Set it in your environment:

SUPERADMIN_TOKEN=your-fixed-token-here

Webhooks

Real-time events. When someone messages your WhatsApp, your server knows instantly.

Supported Events

Event	When it fires
`message`	Incoming message received
`connected`	Session connected to WhatsApp
`disconnected`	Session disconnected
`receipt`	Message delivered/read
`presence`	Contact online/offline status
`qr_code`	New QR code generated

Webhook Payload Example

{
  "event": "message",
  "session_id": "my-session",
  "timestamp": 1704067200,
  "data": {
    "from": "628123456789@s.whatsapp.net",
    "message_id": "3EB0ABC123...",
    "type": "text",
    "body": "Hello!"
  }
}

Signature Verification

Every webhook includes an X-Signature header — HMAC-SHA256 of the payload using your secret.

import hmac
import hashlib

def verify_signature(payload, signature, secret):
    expected = hmac.new(
        secret.encode(),
        payload.encode(),
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature)

Verify it. Don't trust unverified webhooks.

Register Webhook via API

curl -X POST http://localhost:3451/api/v1/sessions/my-session/webhooks \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://your-server.com/webhook",
    "secret": "your-webhook-secret",
    "events": ["message", "connected"]
  }'

Contacts & Groups

Check if Numbers are on WhatsApp

curl -X POST http://localhost:3451/api/v1/sessions/my-session/contacts/check \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "phones": ["628123456789", "628987654321"]
  }'

Get Contact Info

curl -X POST http://localhost:3451/api/v1/sessions/my-session/contacts/info \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "phones": ["628123456789"]
  }'

Get Profile Picture

curl http://localhost:3451/api/v1/sessions/my-session/contacts/628123456789@s.whatsapp.net/picture \
  -H "Authorization: Bearer YOUR_TOKEN"

List Groups

curl http://localhost:3451/api/v1/sessions/my-session/groups \
  -H "Authorization: Bearer YOUR_TOKEN"

Get Group Info

curl http://localhost:3451/api/v1/sessions/my-session/groups/123456789@g.us/info \
  -H "Authorization: Bearer YOUR_TOKEN"

Presence & Chat State

Set Online/Offline Status

curl -X POST http://localhost:3451/api/v1/sessions/my-session/presence/set \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "status": "available"
  }'

Options: available, unavailable

Send Typing Indicator

curl -X POST http://localhost:3451/api/v1/sessions/my-session/chatstate/typing \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "628123456789@s.whatsapp.net"
  }'

Send Chat State

curl -X POST http://localhost:3451/api/v1/sessions/my-session/chatstate/send \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "628123456789@s.whatsapp.net",
    "state": "composing"
  }'

Options: composing, recording, paused

Blocking

Get Block List

curl http://localhost:3451/api/v1/sessions/my-session/blocking/list \
  -H "Authorization: Bearer YOUR_TOKEN"

Block a Contact

curl -X POST http://localhost:3451/api/v1/sessions/my-session/blocking/block \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "jid": "628123456789@s.whatsapp.net"
  }'

Unblock a Contact

curl -X POST http://localhost:3451/api/v1/sessions/my-session/blocking/unblock \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "jid": "628123456789@s.whatsapp.net"
  }'

Check if Blocked

curl http://localhost:3451/api/v1/sessions/my-session/blocking/check/628123456789@s.whatsapp.net \
  -H "Authorization: Bearer YOUR_TOKEN"

Performance

Real numbers from production:

Metric	Node.js (Baileys)	Rust (WA-RS)
Memory (50 sessions)	~4GB	~200MB
Memory (200 sessions)	Crashes	~800MB
Startup time	3-5 seconds	<1 second
Message latency	100-300ms	20-50ms
CPU usage (idle)	5-15%	<1%

Rust isn't just faster. It's a different league.

Full API Reference

Every endpoint at a glance:

Sessions

Method	Endpoint	Description
`POST`	`/api/v1/sessions`	Create session
`GET`	`/api/v1/sessions`	List all sessions
`GET`	`/api/v1/sessions/:id`	Get session info
`DELETE`	`/api/v1/sessions/:id`	Delete session
`GET`	`/api/v1/sessions/:id/status`	Get session status
`POST`	`/api/v1/sessions/:id/connect`	Start connection
`POST`	`/api/v1/sessions/:id/disconnect`	Disconnect
`GET`	`/api/v1/sessions/:id/qr`	Get QR code
`POST`	`/api/v1/sessions/:id/pair`	Get pair code
`GET`	`/api/v1/sessions/:id/device`	Get device info

Messages

Method	Endpoint	Description
`POST`	`/api/v1/sessions/:id/messages/text`	Send text
`POST`	`/api/v1/sessions/:id/messages/image`	Send image
`POST`	`/api/v1/sessions/:id/messages/video`	Send video
`POST`	`/api/v1/sessions/:id/messages/audio`	Send audio
`POST`	`/api/v1/sessions/:id/messages/document`	Send document
`POST`	`/api/v1/sessions/:id/messages/sticker`	Send sticker
`POST`	`/api/v1/sessions/:id/messages/location`	Send location
`POST`	`/api/v1/sessions/:id/messages/contact`	Send contact
`POST`	`/api/v1/sessions/:id/messages/edit`	Edit message
`POST`	`/api/v1/sessions/:id/messages/react`	React to message

Contacts

Method	Endpoint	Description
`POST`	`/api/v1/sessions/:id/contacts/check`	Check on WhatsApp
`POST`	`/api/v1/sessions/:id/contacts/info`	Get contact info
`GET`	`/api/v1/sessions/:id/contacts/:jid/picture`	Get profile picture
`POST`	`/api/v1/sessions/:id/contacts/users`	Get user info

Groups

Method	Endpoint	Description
`GET`	`/api/v1/sessions/:id/groups`	List groups
`GET`	`/api/v1/sessions/:id/groups/:jid`	Get group
`GET`	`/api/v1/sessions/:id/groups/:jid/info`	Get group info

Presence & Chat State

Method	Endpoint	Description
`POST`	`/api/v1/sessions/:id/presence/set`	Set presence
`POST`	`/api/v1/sessions/:id/chatstate/send`	Send chat state
`POST`	`/api/v1/sessions/:id/chatstate/typing`	Send typing

Blocking

Method	Endpoint	Description
`GET`	`/api/v1/sessions/:id/blocking/list`	Get block list
`POST`	`/api/v1/sessions/:id/blocking/block`	Block contact
`POST`	`/api/v1/sessions/:id/blocking/unblock`	Unblock contact
`GET`	`/api/v1/sessions/:id/blocking/check/:jid`	Check if blocked

Media

Method	Endpoint	Description
`POST`	`/api/v1/sessions/:id/media/upload`	Upload media

Webhooks

Method	Endpoint	Description
`GET`	`/api/v1/sessions/:id/webhooks`	List webhooks
`POST`	`/api/v1/sessions/:id/webhooks`	Register webhook
`DELETE`	`/api/v1/sessions/:id/webhooks/:webhook_id`	Unregister webhook

Other

Method	Endpoint	Description
`GET`	`/health`	Health check
`GET`	`/swagger-ui`	Swagger UI
`GET`	`/api-docs/openapi.json`	OpenAPI spec

Environment Variables

Variable	Default	Description
`POSTGRES_HOST`	localhost	PostgreSQL host
`POSTGRES_PORT`	5432	PostgreSQL port
`POSTGRES_USER`	postgres	PostgreSQL user
`POSTGRES_PASSWORD`	postgres	PostgreSQL password
`POSTGRES_DB`	wagateway	Database name
`JWT_SECRET`	(generated)	Token signing secret
`SUPERADMIN_TOKEN`	(generated)	Fixed admin token
`WHATSAPP_STORAGE_PATH`	./whatsapp_sessions	Session data directory
`RUST_LOG`	info	Log level (debug, info, warn, error)

Troubleshooting

Session won't connect

Check if the session exists: GET /api/v1/sessions/:id
Try disconnecting first: POST /api/v1/sessions/:id/disconnect
Then reconnect: POST /api/v1/sessions/:id/connect
Check logs: docker compose logs wa-rs

QR code not appearing

Make sure session is in connecting state
Wait a few seconds after calling connect
Refresh the QR endpoint

Webhooks not firing

Verify the webhook URL is accessible from the server
Check if events are configured correctly
Verify signature validation isn't failing

Database connection failed

Check if PostgreSQL is running
Verify credentials in environment variables
Make sure the database exists

What's Next

This is open source. MIT license. Do whatever you want with it.

GitHub: https://github.com/fdciabdul/wa-rs

Don't forget to give a star 😜
Documentation: https://wa-rs.imtaqin.id/

Docker Hub: https://hub.docker.com/r/fdciabdul/wa-rs

Final Thoughts

I spent way too long fighting with Node.js memory leaks before I made this switch.

If you're running WhatsApp automation at scale, stop torturing yourself. Rust handles it better. Period.

The learning curve is real. But the payoff is worth it.

Star the repo if this helped. Open an issue if something's broken. PRs welcome.

Built by @taqin. Written in Rust because life's too short for garbage collection.

I Built SonarQube Export Scripts So You Don't Have To

Taqin — Mon, 29 Dec 2025 16:24:24 +0000

Last week I spent 3 hours clicking through SonarQube trying to copy-paste coverage data into a spreadsheet for our sprint planning.

Three. Hours.

My PM wanted a simple list: which files need tests? Which lines aren't covered?

SonarQube has all this data. But getting it out in a format humans can actually use? Pain in the ass.

So I built export scripts that run in your browser console. No installs. No auth tokens. Just paste and go.

Why SonarQube's Export Sucks

Look, SonarQube is great at showing you code quality metrics. The dashboard is nice. The drill-downs work.

But try to:

Export all issues with file paths and line numbers
Get a list of files below 80% coverage
See exactly which lines need tests
Share this with your team in a readable format

You're fu***.

The built-in export gives you JSON or CSV that's basically useless. No proper formatting. Missing context. Can't sort by what matters.

I needed something better.

The Hack: Browser Console Scripts

Here's the thing about SonarQube - it's all browser-based. Which means the data is already there in your browser. You just need to grab it.

Browser console + fetch API = instant access to everything.

No backend needed. No API tokens. No complex setup.

Just open DevTools (F12), paste a script, hit Enter. Done.

Script 1: Export All Issues with File and Line

This one gets every issue - bugs, vulnerabilities, code smells - with exact file paths and line numbers.

const PROJECT_KEY = 'your-project-key';

const exportIssuesWithLines = async () => {
  console.log(' Fetching issues...\n');

  let allIssues = [];
  let page = 1;
  let hasMore = true;

  while (hasMore) {
    const response = await fetch(
      `/api/issues/search?componentKeys=${PROJECT_KEY}&statuses=OPEN,CONFIRMED&ps=500&p=${page}`
    );

    if (!response.ok) break;

    const data = await response.json();
    allIssues = allIssues.concat(data.issues || []);
    hasMore = data.issues && data.issues.length === 500;
    page++;
    console.log(`  Fetched ${allIssues.length} issues...`);
  }

  let report = 'ISSUES REPORT\n';
  report += `Total: ${allIssues.length}\n\n`;

  allIssues.forEach((issue, index) => {
    const filePath = issue.component.replace(`${PROJECT_KEY}:`, '');
    const line = issue.line || 'N/A';

    report += `${index + 1}. ${issue.severity} - ${issue.type}\n`;
    report += `   File: ${filePath}\n`;
    report += `   Line: ${line}\n`;
    report += `   Message: ${issue.message}\n`;
    report += `   Effort: ${issue.effort || 'N/A'}\n\n`;
  });

  const blob = new Blob([report], { type: 'text/plain' });
  const link = document.createElement('a');
  link.href = URL.createObjectURL(blob);
  link.download = `${PROJECT_KEY}-issues.txt`;
  link.click();

  console.log(` Exported ${allIssues.length} issues`);
};

exportIssuesWithLines();

What this does:

The pagination loop is key. SonarQube limits API responses to 500 items max. So we keep calling the API with increasing page numbers until we've got everything.

The replace call strips the project key from the component path. SonarQube returns "PROJECT:path/to/file.ts" but we just want "path/to/file.ts".

The Blob and createElement('a') trick downloads the file directly. No server needed. The browser does all the work.

Script 2: Files That Need Coverage

This one answers: "Which files need tests?"

const PROJECT_KEY = 'your-project-key';

const exportFilesNeedingCoverage = async () => {
  console.log(' Fetching coverage data...\n');

  let allFiles = [];
  let page = 1;
  let hasMore = true;

  while (hasMore) {
    const response = await fetch(
      `/api/measures/component_tree?ps=500&asc=true&metricSort=coverage&s=metric&metricSortFilter=withMeasuresOnly&p=${page}&component=${PROJECT_KEY}&metricKeys=coverage,uncovered_lines,lines_to_cover`
    );

    if (!response.ok) break;

    const data = await response.json();

    if (data.components && data.components.length > 0) {
      allFiles = allFiles.concat(data.components);
      hasMore = data.components.length === 500;
      page++;
    } else {
      hasMore = false;
    }
  }

  const filesBelow80 = allFiles.filter(file => {
    const coverage = file.measures?.find(m => m.metric === 'coverage');
    return coverage && parseFloat(coverage.value) < 80;
  });

  let report = `FILES NEEDING COVERAGE (Below 80%)\n`;
  report += `Total: ${filesBelow80.length} files\n\n`;

  filesBelow80.forEach((file, index) => {
    let coverage = 0;
    let uncoveredLines = 0;
    let linesToCover = 0;

    file.measures?.forEach(measure => {
      if (measure.metric === 'coverage') coverage = parseFloat(measure.value);
      if (measure.metric === 'uncovered_lines') uncoveredLines = parseInt(measure.value);
      if (measure.metric === 'lines_to_cover') linesToCover = parseInt(measure.value);
    });

    const filePath = file.path || file.name;

    report += `${index + 1}. ${filePath}\n`;
    report += `   Coverage: ${coverage.toFixed(2)}%\n`;
    report += `   Uncovered Lines: ${uncoveredLines}\n`;
    report += `   Lines to Cover: ${linesToCover}\n\n`;
  });

  const blob = new Blob([report], { type: 'text/plain' });
  const link = document.createElement('a');
  link.href = URL.createObjectURL(blob);
  link.download = `${PROJECT_KEY}-coverage.txt`;
  link.click();

  console.log(` Exported ${filesBelow80.length} files`);
};

exportFilesNeedingCoverage();

The breakdown:

metricSort=coverage sorts files by coverage percentage (lowest first). So the files that need the most work show up first.

metricSortFilter=withMeasuresOnly skips files without coverage data. Config files, type definitions, etc.

The filter for files below 80% is arbitrary. Change it to whatever threshold your team uses.

Script 3: Get Exact Uncovered Line Numbers

This is the nuclear option. For each file, it fetches the actual source code and identifies which specific lines aren't covered.

const PROJECT_KEY = 'your-project-key';

const exportUncoveredLineNumbers = async () => {
  console.log(' Fetching files...\n');

  let allFiles = [];
  let page = 1;
  let hasMore = true;

  while (hasMore) {
    const response = await fetch(
      `/api/measures/component_tree?ps=500&asc=true&metricSort=coverage&p=${page}&component=${PROJECT_KEY}&metricKeys=coverage,uncovered_lines`
    );

    if (!response.ok) break;

    const data = await response.json();
    if (data.components && data.components.length > 0) {
      allFiles = allFiles.concat(data.components);
      hasMore = data.components.length === 500;
      page++;
    } else {
      hasMore = false;
    }
  }

  const filesBelow80 = allFiles.filter(file => {
    const coverage = file.measures?.find(m => m.metric === 'coverage');
    return coverage && parseFloat(coverage.value) < 80;
  });

  console.log(`Found ${filesBelow80.length} files. Fetching line details...\n`);

  let report = `UNCOVERED LINES REPORT\n`;
  report += `Total Files: ${filesBelow80.length}\n\n`;

  for (const file of filesBelow80) {
    let coverage = 0;
    file.measures?.forEach(m => {
      if (m.metric === 'coverage') coverage = parseFloat(m.value);
    });

    const filePath = file.path || file.name;

    report += `File: ${filePath}\n`;
    report += `Coverage: ${coverage.toFixed(2)}%\n`;

    try {
      const linesResponse = await fetch(
        `/api/sources/lines?key=${encodeURIComponent(file.key)}&from=1&to=5000`
      );

      if (linesResponse.ok) {
        const linesData = await linesResponse.json();
        const uncoveredLines = [];

        linesData.sources?.forEach(line => {
          if (line.lineHits === 0 || line.coverageStatus === 'uncovered') {
            uncoveredLines.push(line.line);
          }
        });

        if (uncoveredLines.length > 0) {
          report += `Uncovered Lines: ${uncoveredLines.join(', ')}\n`;
        }
      }
    } catch (error) {
      report += `Could not fetch line details\n`;
    }

    report += '\n';
  }

  const blob = new Blob([report], { type: 'text/plain' });
  const link = document.createElement('a');
  link.href = URL.createObjectURL(blob);
  link.download = `${PROJECT_KEY}-uncovered-lines.txt`;
  link.click();

  console.log(' Export complete!');
};

exportUncoveredLineNumbers();

Why this matters:

When you tell a dev "AuthController.ts needs more coverage," they have no idea where to start.

When you say "AuthController.ts lines 42, 67, 89-105 aren't covered," they can fix it in 10 minutes.

The sources/lines endpoint returns every line of code with coverage status. We filter for lineHits === 0 which means that line never executed during tests.

CSV Export (For Excel People)

Some teams want spreadsheets. Fine.

const PROJECT_KEY = 'your-project-key';

const exportIssuesCSV = async () => {
  let allIssues = [];
  let page = 1;
  let hasMore = true;

  while (hasMore) {
    const response = await fetch(
      `/api/issues/search?componentKeys=${PROJECT_KEY}&statuses=OPEN,CONFIRMED&ps=500&p=${page}`
    );
    if (!response.ok) break;
    const data = await response.json();
    allIssues = allIssues.concat(data.issues || []);
    hasMore = data.issues && data.issues.length === 500;
    page++;
  }

  let csv = 'File,Line,Severity,Type,Message,Effort\n';

  allIssues.forEach(issue => {
    const filePath = issue.component.replace(`${PROJECT_KEY}:`, '');
    const message = (issue.message || '').replace(/"/g, '""');
    csv += `"${filePath}","${issue.line || 'N/A'}","${issue.severity}","${issue.type}","${message}","${issue.effort || 'N/A'}"\n`;
  });

  const blob = new Blob([csv], { type: 'text/csv' });
  const link = document.createElement('a');
  link.href = URL.createObjectURL(blob);
  link.download = `${PROJECT_KEY}-issues.csv`;
  link.click();
};

exportIssuesCSV();

The double-quote escaping (.replace(/"/g, '""')) prevents CSV injection. If an issue message contains quotes, Excel won't break.

How to Use These

Open your SonarQube project in browser
Press F12 to open DevTools
Go to Console tab
Paste one of these scripts
Change PROJECT_KEY to your project
Hit Enter
File downloads automatically

No npm install. No build step. No deployment. Just works.

Why This Matters

Code quality tools are pointless if the data stays trapped in a dashboard.

Your PM needs to see which features are risky. Your team lead needs to plan test coverage sprints. Your devs need specific line numbers to fix.

These scripts give you that. In seconds.

I use them every sprint planning. Export issues on Monday. Assign them Tuesday. Done by Friday.

SonarQube finally becomes useful instead of just another dashboard nobody looks at.

The Complete Toolkit

I've got like 10 variations of these now:

Export only CRITICAL/BLOCKER issues
Group issues by file
Export duplicated code blocks
Export security hotspots
Quality gate status reports

All browser console. All instant.

Want them? They're in this conversation thread. Pick what you need and customize the PROJECT_KEY.

Or build your own. The SonarQube API is actually pretty straightforward once you realize you can just... call it from the browser.

Stop wasting hours on manual exports. Automate this shit and get back to building.