Welcome to Aswincloud – an organization focused on developer tooling, performance profiling, and modern web applications.
| Repository | Description | Language | ⭐ | Updated |
|---|---|---|---|---|
| ttperf | A streamlined CLI tool for profiling Tenstorrent's TT-Metal tests and extracting device kernel performance metrics | Python | 4 | 2026-07-27 |
| ttnn-performance-dashboard | Day-by-day performance tracking dashboard for Tenstorrent TT-Metal TTNN eltwise operations. | JavaScript | 1 | 2026-08-22 |
| portfolio | Professional portfolio website built with React, Vite, and Tailwind CSS | JavaScript | 1 | 2026-08-19 |
| whatsapp_bot | WhatsApp AI assistant bot powered by Claude — conversational AI for everyday use | Python | 0 | 2026-08-17 |
| 3d_printing | 3D print portfolio and showcase site — custom figurines, decor, and art pieces. Orders via DM | JavaScript | 0 | 2026-08-22 |
| AiBuddy | AI-powered chatbot for Microsoft Teams — brings conversational AI into team channels and group chats | Python | 0 | 2026-07-27 |
| auth | Shared, framework-agnostic auth primitives for Cloudflare Workers sites — signed sessions, HMAC tokens, PBKDF2 passwords, owner allowlists, OAuth — plus an optional React login UI. Published as @aswincloud/auth. | TypeScript | 0 | 2026-08-03 |
| blog | blog.aswincloud.com - homelab & home automation | CSS | 0 | 2026-08-17 |
| chat | Full-viewport iframe wrapper hosting the self-hosted Chatwoot widget at chat.aswincloud.com | HTML | 0 | 2026-07-27 |
| cheap-domain(archived) | Get a custom subdomain under aswincloud.com for just ₹20/month | – | 0 | 2026-07-25 |
| gh-org-guard | Self-healing GitHub org governance: reconcile branch protection, merge queue, reviews & secret-hygiene across every repo — one weekly workflow. Reference implementation. | Python | 1 | 2026-07-27 |
| ghadiff | Python CLI to compare two GitHub Actions workflow runs — timing, status, and job/step-level diffs with text, JSON, Markdown, and HTML output | Python | 0 | 2026-07-27 |
| invoicer | Create, preview, download and email professional invoices. Cloudflare Pages + Functions + D1. | JavaScript | 0 | 2026-08-17 |
| pr-review-checker | Web app that analyzes GitHub PRs against CODEOWNERS to compute minimum required approvals, with AI-powered approval predictions from team history | JavaScript | 1 | 2026-08-11 |
| resume | Aswin — Software Engineer. Resume built from HTML/CSS, auto-rendered to PDF. | HTML | 0 | 2026-08-20 |
| shiptrack | Free, open-source, self-hostable shipment tracking for Indian & international couriers — built with Next.js + TypeScript | TypeScript | 1 | 2026-08-14 |
| slack-join(archived) | – | JavaScript | 0 | 2025-07-15 |
| status-page | 🟢 Self-hosted, BetterStack-style live status page for a home network — Cloudflare Worker + D1 + a Docker prober, with email & Slack alerts. Runs on the free tier. | TypeScript | 0 | 2026-07-27 |
| tg-torrent | Telegram bot to remotely add torrents to qBittorrent via magnet links or .torrent files | Python | 0 | 2026-07-05 |
| ttnn-ops-coverage | Interactive zero-dependency dashboard for the TTNN (Tenstorrent) op test matrix — every op across dtype × layout × memory, with per-config PCC/ULP accuracy and run-to-run diffs. Deploys to Cloudflare Workers. | JavaScript | 0 | 2026-08-22 |
| ttnn-web-calculator | Web app to test and visualize 150+ Tenstorrent TTNN operations in real time, with PyTorch comparison | HTML | 0 | 2026-07-05 |
| word-game-bot | Telegram word chain game bot (aiogram v3). Fork of jonowo/on9wordchainbot with DB-backed admin & group authorization. | Python | 0 | 2026-08-17 |
Workflows in this repo that run against the whole org:
| Workflow | Schedule | What it does |
|---|---|---|
reconcile-rulesets.yml | Mondays 06:17 UTC | Reasserts the branch-protection baseline on every public repo |
security-sweep.yml | Mondays 06:17 UTC | Audits secret scanning + push protection, opens a tracking issue |
site-probe.yml | every 15 min | Checks every hosted site is serving; fails the run and emails if not |
sync-security-triage.yml | every 6 h | Mirrors open security alerts onto the Security Triage board |
scripts/probe_sites.py requests every site in
scripts/sites.json and fails the run if any is
unhealthy. Stdlib only, no dependencies.
To add or remove a site, edit scripts/sites.json — one object per site:
| Field | Required | Meaning |
|---|---|---|
name | yes | Short label used in the report and the tracking issue title |
url | yes | Exact URL to request |
expect | no | Acceptable status codes, default [200] |
contains | no | Substring that must appear in the body (catches "200 but blank page") |
redirect_to | no | Substring the Location header must contain, when the answer is a 3xx |
note | no | Why a non-200 is correct, for the next reader |
contains is checked only on non-redirect answers and redirect_to only on
redirects, so a site whose healthy answer differs by network can set both and
have each verified against whichever response actually arrives.
Sites are probed at / rather than a health endpoint on purpose: the root is the
user-visible surface and exercises static-asset serving too, which a Worker-only
health route does not.
console expects 302, and that is correct — it sits behind Cloudflare
Access, so a redirect to the login page means it is up. The probe deliberately
does not follow redirects, or that 302 would be invisible. Don't "fix" it
to 200. redirect_to pins where it redirects, because "expect 302" on its own
would pass on any redirect at all.
The homelab services (truenas, watch, torrent) are probed at their real UI
paths rather than /, because the roots redirect. They also use contains so a
reachable-but-broken service is caught: an nginx or reverse-proxy error page
answering 200 would otherwise read as healthy. truenas matches on its <base>
tag because its Angular SPA sends an empty<title>.
truenasanswers differently depending on who asks. It is an Access app with aBypass Home IPpolicy, so from the home network it returns the real UI (200), while GitHub's runners get Access's login redirect (302). Both are healthy, so both are accepted and each is checked against the answer that arrives. Two consequences worth remembering:
- A local
DRY_RUNrun is not the runner's view. Running the probe from home exercises the bypass path only, so a config that is broken for Actions can still look green locally. That is exactly how the first live run failed after a clean local check.- For an Access-gated site, green means Cloudflare's edge is up — not the origin. Access redirects before the request ever reaches the box, so an unplugged NAS still returns a healthy-looking
302. Real origin monitoring for the homelab belongs on status.aswincloud.com, which probes from inside the network.
Email is sent on state change only. An open issue titled 🔴 Site down — <name>
is the state store, so a site that stays down gets one email and one issue, with
later runs adding a comment. Recovery closes the issue and sends one more email.
A site is only declared down after 3 failed attempts, so a single TCP reset
doesn't page anyone.
Secrets (all optional — if any is unset the email is skipped with a warning and
the run still fails, so a missing key can never mask an outage):
RESEND_API_KEY, ALERT_FROM, ALERT_TO.
Run it locally without emailing anyone:
DRY_RUN=true python3 scripts/probe_sites.pyExit codes: 0 all up · 1 something is down · 2 the probe itself couldn't
run (missing or malformed sites.json).
For questions or contributions, feel free to open an issue in the relevant repository.