Welcome to The Weekly Five - your curated list of 5
exceptional open source projects I discovered this week.

The Weekly Five

From code to clarity: tools that help teams define, enforce, and visualize the rules of their systems

Every growing team eventually hits the same wall: the rules that govern your system (who can access what, how data flows, where VMs run, how services communicate) live scattered across wikis, tribal knowledge, and half-documented configs. This week's picks focus on tools that bring those invisible rules into the light. Whether you need to lock down permissions in JavaScript, unify 100+ LLM providers behind one API, run virtual machines alongside containers, speed up connections with modern protocols, or turn text into architecture diagrams, these five projects help teams define, enforce, and visualize the logic that holds their systems together.

Top takeaways

  • Authorization and access control can be incrementally adopted without rewriting your entire stack, and CASL proves it with its isomorphic, scalable approach to permissions

  • The LLM provider landscape is fragmented, but LiteLLM proves you can call 100+ models through a single OpenAI-compatible interface with production-grade spend tracking and load balancing

  • Modern infrastructure challenges (running VMs in Kubernetes, adopting HTTP/3) now have production-ready open source solutions that teams can deploy today

Who this issue is for

Backend engineers, platform teams, and technical leads who want practical tools to make their system rules explicit, enforceable, and visible to the whole team.

casl

🔗 View on GitHub | GitHub stars: 6,986

Why this made the cut: CASL brings battle-tested, CanCan-style authorization to the JavaScript ecosystem with an isomorphic design that works identically on client and server.

Why it matters

Authorization logic is one of the most critical yet frequently scattered parts of any application. CASL provides a single, declarative way to define what users can and cannot do, and those rules can run anywhere JavaScript runs. This means your frontend can hide UI elements using the exact same permission logic your API uses to block requests, eliminating the drift that causes security holes.

Key features

  • Isomorphic design: define abilities once, enforce them in Node.js, React, Vue, Angular, or any JavaScript environment

  • Incremental adoption: start with simple role checks and scale to attribute-based access control as your needs grow

  • Framework integrations: first-class support for popular frameworks including React (with hooks), Vue, and Angular

  • Condition-based rules: restrict access based on resource attributes (e.g., users can only edit their own posts)

  • TypeScript support: full type safety for ability definitions and checks

How to use

Installation:

npm install @casl/ability

Define abilities:

import { AbilityBuilder, createMongoAbility } from '@casl/ability';

const { can, cannot, build } = new AbilityBuilder(createMongoAbility);

can('read', 'Article');

can('update', 'Article', { authorId: user.id });

cannot('delete', 'Article');

const ability = build();

Check permissions:

ability.can('read', 'Article'); // true

ability.can('update', article); // true if article.authorId === user.id

React integration tip (from community guides): Use the @casl/react package with the Can component to conditionally render UI elements based on abilities, keeping your permission logic consistent across your entire stack.

Project ideas

  1. Multi-tenant SaaS permission layer: Build a shared permission module using CASL that defines tenant-scoped abilities (e.g., can('manage', 'Invoice', { tenantId })) and wire it into both your Express API middleware and your React dashboard so role changes take effect everywhere instantly.

  2. Content moderation dashboard: Create a moderation tool where admins, moderators, and reviewers each see different actions (approve, flag, delete) on user-submitted content, with CASL abilities driving both the API guards and the UI button visibility.

  1. CASL Introduction - Official Guide - Walks through defining abilities, checking permissions, using conditions, and field-level restrictions with clear code examples.

  2. Roles with Predefined Permissions - CASL Cookbook - Shows how to map traditional roles (admin, editor, viewer) to CASL ability definitions, bridging the gap between role-based and attribute-based access control.

litellm

🔗 View on GitHub | GitHub stars: 52,830

Why this made the cut: LiteLLM gives teams a single, OpenAI-compatible interface to call 100+ LLM providers, with built-in spend tracking, virtual keys, guardrails, and load balancing, so you can swap models without rewriting a line of code.

Why it matters

Every LLM provider has its own SDK, auth pattern, and request format. When your team uses OpenAI today but needs to add Anthropic, Bedrock, or a self-hosted model tomorrow, you face a mountain of integration work. LiteLLM eliminates this by proxying all calls through one unified API. Your application code stays the same while you route requests to whichever provider makes sense for cost, latency, or capability. Used in production by Stripe, Netflix, and the OpenAI Agents SDK.

Key features

  • Unified API: one interface for 100+ LLMs (OpenAI, Anthropic, Gemini, Bedrock, Azure, Cohere, and more) using the OpenAI format

  • AI Gateway (Proxy Server): deploy as a centralized service with virtual keys, spend tracking per project/user, guardrails, and an admin dashboard

  • Load balancing and fallbacks: route across multiple deployments with automatic retry and failover logic

  • MCP Gateway: connect MCP tool servers to any LLM through the proxy

  • A2A Protocol support: invoke agents built with LangGraph, Pydantic AI, or cloud agent services through a unified agent gateway

  • Production performance: 8ms P95 latency at 1,000 requests per second

How to use

Python SDK:

uv add litellm
from litellm import completion
import os

os.environ["OPENAI_API_KEY"] = "your-openai-key"

os.environ["ANTHROPIC_API_KEY"] = "your-anthropic-key"

# OpenAI

response = completion(model="openai/gpt-4o", messages=[{"role": "user", "content": "Hello!"}])

# Anthropic - same interface, just change the model string

response = completion(model="anthropic/claude-sonnet-4-20250514", messages=[{"role": "user", "content": "Hello!"}])

AI Gateway (Proxy Server):

uv tool install 'litellm[proxy]'

litellm --model gpt-4o
import openai

client = openai.OpenAI(api_key="anything", base_url="http://0.0.0.0:4000")

response = client.chat.completions.create(

    model="gpt-4o",

    messages=[{"role": "user", "content": "Hello!"}]

)

Production deployment: LiteLLM provides Terraform modules for both AWS (ECS Fargate + Aurora + ElastiCache) and GCP (Cloud Run + Cloud SQL + Memorystore) with managed Postgres, Redis, and auto-generated secrets out of the box.

Project ideas

  1. Multi-provider AI gateway for your team: Deploy the LiteLLM proxy as your organization's central AI gateway, issue virtual keys per team/project, set per-key spend limits, and use the admin dashboard to track which teams are spending what across OpenAI, Anthropic, and Bedrock.

  2. Model evaluation pipeline: Build a testing harness that sends the same prompts to multiple models (GPT-4o, Claude, Gemini) through LiteLLM's unified API, then compares response quality, latency, and cost to help your team pick the best model for each use case.

  1. LiteLLM AI Gateway Docs - The official proxy server guide covering setup, virtual keys, spend tracking, guardrails, and deployment options.

  2. LiteLLM Docker Quick Start - End-to-end tutorial to get the AI Gateway running with Docker, set up virtual keys, and make your first request.

kubevirt

🔗 View on GitHub | GitHub stars: 6,938

Why this made the cut: KubeVirt extends Kubernetes to manage virtual machines alongside containers, solving the "we still need VMs" problem without requiring a separate infrastructure stack.

Why it matters

Not everything can run in a container. Legacy applications, specific kernel requirements, Windows workloads, and certain compliance scenarios still need virtual machines. KubeVirt lets platform teams use their existing Kubernetes skills, tooling, and infrastructure to manage VMs, eliminating the operational overhead of maintaining two separate platforms. Your VMs become just another Kubernetes resource.

Key features

  • Native Kubernetes integration: VMs are defined as Custom Resources and managed with kubectl

  • Live migration: move running VMs between nodes without downtime

  • Containerized Data Importer (CDI): import VM images from URLs, registries, or existing PVCs

  • Network integration: VMs participate in Kubernetes networking (pod network, Multus for advanced scenarios)

  • Storage flexibility: use any Kubernetes storage class for VM disks

  • Snapshot and clone: leverage CSI snapshots for VM backup and duplication

How to use

Prerequisites: A Kubernetes cluster with hardware virtualization support (nested virtualization or bare metal).

Installation:

export VERSION=$(curl -s https://api.github.com/repos/kubevirt/kubevirt/releases/latest | grep tag_name | cut -d '"' -f 4)

kubectl create -f https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/kubevirt-operator.yaml

kubectl create -f https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/kubevirt-cr.yaml

Install virtctl CLI:

kubectl krew install virt

Create a VM (from community tutorial):

apiVersion: kubevirt.io/v1

kind: VirtualMachine

metadata:

  name: testvm

spec:

  running: false

  template:

    spec:

      domain:

        devices:

          disks:

            - name: containerdisk

              disk:

                bus: virtio

        resources:

          requests:

            memory: 1Gi

      volumes:

        - name: containerdisk

          containerDisk:

            image: quay.io/kubevirt/cirros-container-disk-demo

Start and access:

kubectl virt start testvm

kubectl virt console testvm

Project ideas

  1. Legacy app migration lab: Set up a KubeVirt environment that runs a legacy Windows or Linux VM workload alongside containerized microservices in the same cluster, using Kubernetes Services to route traffic between them as you incrementally migrate the monolith.

  2. Ephemeral dev environments: Create a Kubernetes operator that spins up on-demand KubeVirt VMs pre-loaded with your full development stack (database, OS-level tools, IDE server) so each developer gets an isolated, reproducible environment that auto-destroys after a configurable idle timeout.

  1. Announcing the Release of KubeVirt v1.8 - The latest release blog covering new features that bring KubeVirt closer to feature parity with traditional virtualization platforms.

  2. KubeVirt User Guide - The official hands-on guide covering installation, VM lifecycle, networking, storage, and live migration for teams getting started with VMs on Kubernetes.

quic-go

🔗 View on GitHub | GitHub stars: 11,687

Why this made the cut: quic-go is a production-ready, pure Go implementation of QUIC and HTTP/3, enabling teams to adopt next-generation transport protocols without leaving the Go ecosystem.

Why it matters

QUIC eliminates head-of-line blocking, reduces connection establishment latency, and handles network changes gracefully (crucial for mobile clients). As HTTP/3 adoption accelerates, having a robust Go implementation means backend teams can offer faster, more reliable connections without rewriting services in another language. The library supports both client and server roles, plus diagnostic tooling via qlog.

Key features

  • Full QUIC implementation: RFC 9000 compliant with 0-RTT support

  • HTTP/3 support: serve and consume HTTP/3 traffic natively

  • Connection migration: seamlessly handle client IP changes (WiFi to cellular transitions)

  • qlog support: structured logging format for debugging and performance analysis

  • Stream multiplexing: multiple independent streams over a single connection without head-of-line blocking

  • TLS 1.3 integration: mandatory encryption with modern cryptography

How to use

Installation:

go get github.com/quic-go/quic-go

HTTP/3 server:

package main

import (

    "net/http"

    "github.com/quic-go/quic-go/http3"

)

func main() {

    handler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {

        w.Write([]byte("Hello HTTP/3!"))

    })

    http3.ListenAndServeTLS(":443", "cert.pem", "key.pem", handler)

}

QUIC client (from community guide):

conn, err := quic.DialAddr(ctx, "server:4242", tlsConfig, nil)

stream, err := conn.OpenStreamSync(ctx)

stream.Write([]byte("hello"))

Tunneling pattern: quic-go supports custom stream handling, making it suitable for building tunnels, proxies, and other transport-layer applications that benefit from QUIC's multiplexing and migration features.

Project ideas

  1. Mobile-friendly API gateway: Build a lightweight HTTP/3 reverse proxy in Go using quic-go that sits in front of your existing REST APIs, giving mobile clients faster connection setup (0-RTT) and seamless WiFi-to-cellular handoffs via connection migration.

  2. Real-time multiplayer game server: Use quic-go's stream multiplexing to build a game server where each player's input, chat, and state sync run on independent QUIC streams, eliminating head-of-line blocking so a dropped chat packet never stalls game state updates.

  1. Serving HTTP/3 - quic-go Docs - Official guide on setting up an HTTP/3 server in Go, including TLS configuration, graceful shutdown, and running HTTP/1.1+HTTP/2+HTTP/3 in parallel.

  2. Running a QUIC Client - quic-go Docs - Covers establishing QUIC connections, working with streams, and leveraging 0-RTT for low-latency client applications.

mermaid

🔗 View on GitHub | GitHub stars: 89,067

Why this made the cut: Mermaid turns plain text into professional diagrams, making documentation that actually stays up to date because updating a diagram is as easy as editing a few lines of code.

Why it matters

Diagrams go stale because updating them requires opening a separate tool, finding the source file, making changes, exporting, and uploading. Mermaid eliminates this friction by embedding diagrams directly in Markdown. When your architecture changes, you update the text and the diagram updates automatically. GitHub, GitLab, Notion, and dozens of other tools render Mermaid natively, meaning your documentation lives where your code lives.

Key features

  • Text-based diagrams: flowcharts, sequence diagrams, class diagrams, state diagrams, ER diagrams, Gantt charts, and more

  • Markdown integration: renders directly in GitHub READMEs, GitLab, Obsidian, Notion, and other Markdown environments

  • Live editor: browser-based editor at mermaid.live for prototyping diagrams

  • Theming: customize colors and styles to match your documentation

  • Mindmaps and timelines: newer diagram types for brainstorming and project planning

  • JavaScript API: programmatic diagram generation for dynamic documentation

How to use

In GitHub Markdown:

flowchart LR

    A[User] --> B[Load Balancer]

    B --> C[API Server]

    C --> D[(Database)]

Common diagram types (from video tutorials):

Sequence diagram:

sequenceDiagram

    Client->>Server: Request

    Server->>Database: Query

    Database-->>Server: Results

    Server-->>Client: Response

Entity relationship:

erDiagram

    USER ||--o{ ORDER : places

    ORDER ||--|{ LINE_ITEM : contains

Setup for custom sites:

<script type="module">

  import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.esm.min.mjs';

  mermaid.initialize({ startOnLoad: true });

</script>

Pro tip: Use the live editor (mermaid.live) to prototype complex diagrams before committing them to your docs.

Project ideas

  1. Auto-generated API docs: Write a script that parses your OpenAPI spec and generates Mermaid sequence diagrams for each endpoint's request flow, then embeds them in your repo's docs folder so architecture diagrams update automatically with every API change.

  2. Interactive onboarding guide: Create a "system map" page in your team wiki using Mermaid diagrams (flowcharts for service dependencies, ER diagrams for the data model, sequence diagrams for key workflows) that new engineers can click through during their first week.

  1. Improve Your Documentation with Mermaid.js Diagrams - Kubernetes Blog - How the Kubernetes project adopted Mermaid for docs, with practical tips on diagram types and workflow integration.

  2. Mermaid Getting Started Guide - The official quickstart covering installation options (CDN, npm, live editor), basic syntax for all diagram types, and configuration.

If you only try one

Start with Mermaid. It has the lowest barrier to entry (just add a code block to any Markdown file) and delivers immediate, visible value. Within five minutes, you can have an architecture diagram in your README that the whole team can understand and update. That quick win often sparks a documentation culture shift: when diagrams are easy to create and maintain, people actually create and maintain them. Once your system rules are visible, you will naturally want to enforce them, and that is when the other tools in this issue become essential.

If you are doing Open Source I have a good news for you, I work at CodeRabbit which is an AI review tool and its free for Open Source, please reach out to me on X or LinkedIn or just send an email on [email protected] if you need help on adopting CodeRabbit.

You can visit our portal below to create a new account and connect your repository and start reviewing your code.

AI Code Reviews | CodeRabbit | Try for Free

AI-first pull request reviewer with context-aware feedback, line-by-line code suggestions, and real-time chat.

www.coderabbit.ai

Keep Reading

© 2026 The Weekly Five by Santosh.
beehiivPowered by beehiiv