This repository is a comprehensive library of Kyverno policies for Kubernetes, providing a curated collection of Validating, Mutating, Generating, and Cleanup policies. It covers Pod Security Standards (baseline and restricted), best practices, RBAC restrictions, image registry controls, and integrations with ecosystem tools like Istio, Linkerd, Karpenter, and ArgoCD. The policies are written as YAML manifests using Kyverno's CEL-based API (policies.kyverno.io/v1) and are accompanied by extensive test suites using both Chainsaw and Kyverno CLI frameworks. The repository serves as a reference implementation and distribution channel for Kyverno users, with standardized metadata (ArtifactHub), CI/CD pipelines, and contribution guidelines. While not a traditional application, it functions as a policy-as-code library with a strong emphasis on security and operational best practices.
This repository provides a Helm chart for deploying Uptime-Kuma, a self-hosted uptime monitoring tool, on Kubernetes. The chart is well-structured with support for Deployment or StatefulSet, persistent storage, ingress, external database (MariaDB/MySQL), Prometheus ServiceMonitor, and network policies. It includes comprehensive helm-unittest tests, CI/CD pipelines for linting, testing, and releasing, and automated dependency updates via Renovate. The chart is actively maintained and follows Helm best practices.
Ansible Development Tools (ADT) is an installable Python package and CLI wrapper that bundles the official Ansible content-creation toolchain—ansible-builder, ansible-core, ansible-creator, ansible-dev-environment, ansible-lint, ansible-navigator, ansible-sign, molecule, pytest-ansible, and tox-ansible—behind a single `adt` command. The package's own Python code is deliberately small: `adt --version` enumerates versions of the bundled tools via importlib.metadata, and `adt server` starts an embedded Django WSGI application served by Gunicorn. The repository also contains build definitions for the `community-ansible-dev-tools` execution environment and an OpenShift Dev Spaces image, including podman-in-container support. The production behavior of the original code is a machine-facing REST API, not a user interface. Endpoints under `/v1/creator` and `/v2/creator` invoke ansible-creator's Python API to scaffold playbook, collection, devfile, and execution-environment projects and return them as tar archives. The server additionally exposes `/metadata`, `/v2/creator/capabilities`, `/v2/creator/schema`, and `/v2/creator/scaffold` for backend discovery and dynamic command execution. Every request and response is validated against a bundled OpenAPI 3.1 schema using openapi-core, with validation failures returned as HTTP 400 responses. Outside the Python package, the repo contains substantial container engineering: multi-architecture image builds with buildx, GHCR manifest publishing, rootless podman setup, and an entrypoint that dynamically allocates subuid/subgid ranges for OpenShift's random-UID model. CI is comprehensive, with tox-based linting, unit/integration/container tests, CodeQL, nightly devel image builds, and automated dependency updates. Minor blemishes exist—duplication between the v1/v2 creator handlers, a deprecated `MIDDLEWARE_CLASSES` Django setting, and docs that still mention Python 3.10 while the package requires 3.11+—but the codebase is current, well-tested, and actively maintained.
This is a GitHub Action that parses JaCoCo XML coverage reports and posts a formatted coverage summary as a comment on pull requests. It supports single and multi-module projects, aggregate reports, multiple counter types (INSTRUCTION, BRANCH, LINE, COMPLEXITY, METHOD), custom emojis, and comment update strategies. The action fetches the list of changed files from the PR via the GitHub API, computes overall and per-file coverage percentages, and renders a markdown table with pass/fail indicators based on configurable thresholds. The codebase is written in TypeScript, well-structured with clear separation of concerns (action orchestration, XML parsing, coverage computation, markdown rendering), and includes a comprehensive test suite with fixtures covering various report structures and edge cases.
Sentry is a full-stack application for error monitoring, performance tracing, session replay, and observability. In production, it ingests events (errors, transactions, logs, replays, profiles) from SDKs via a Relay proxy, processes them through Kafka streams, and stores data in ClickHouse (Snuba) and PostgreSQL. It exposes a REST API (Django REST Framework) and a React frontend for dashboards, issue management, alerts, and AI-powered features (Seer). The architecture is a monolith with hybrid-cloud services: a control silo for global state, cell silos for regional data, and an API gateway. Key entry points include the Relay ingestion endpoint, the Django WSGI/ASGI server, and Celery task workers. External dependencies include PostgreSQL, ClickHouse, Kafka, Redis, and cloud providers (GCP, AWS). The codebase also includes a billing/subscription layer (getsentry) and extensive third-party integrations (Slack, GitHub, Jira, etc.).
Portainer Community Edition is a full-stack container management platform providing a unified web UI and REST API for Docker, Docker Swarm, Podman, Kubernetes, Azure Container Instances, and edge computing environments. The backend is written in Go, using BoltDB for storage, gorilla/mux for routing, and includes proxy layers for Docker/Kubernetes/Azure APIs, Helm chart management, GitOps workflows, LDAP/OAuth authentication, RBAC, and backup/restore functionality. The frontend is a hybrid of legacy AngularJS (1.8) and modern React with TypeScript, using React Query, Zustand, Formik, Yup, and a custom UI component library with Storybook. Key entry points are the Go main command (api/cmd/portainer/main.go) and the webpack-compiled React/AngularJS app (app/app.js). The system manages endpoints, stacks, services, containers, volumes, networks, images, registries, edge devices, user teams, and access controls through a layered architecture of HTTP handlers, data services, and middleware. External dependencies include Docker SDK, Kubernetes client libraries, Helm SDK, and various third-party registries.
m-cli is a macOS command-line utility that provides a unified interface for managing system settings, preferences, and services. It consists of a main dispatcher script (`m`) and over 40 plugin scripts, each handling a specific macOS subsystem (e.g., Wi-Fi, Bluetooth, display, dock, permissions). The architecture is a simple plugin-based monolith: the main script resolves the plugin path and delegates execution. Plugins follow a consistent pattern with `--help` output that is parsed by shell completion scripts to dynamically generate completions for bash, zsh, and fish. The codebase is entirely written in Bash (with one Python plugin for screen lock) and relies on macOS native commands (`defaults`, `osascript`, `systemsetup`, `diskutil`, etc.). It is well-structured, with clear separation of concerns, standardized option parsing, and a small test suite using Bats. While the plugins are tightly coupled to macOS, the overall architecture and the dynamic completion generation pattern are reusable concepts.
xyOps is a self-hosted, multi-server job scheduler and monitoring platform written in Node.js (CommonJS) with a browser-based single-page application. It is the successor to Cronicle and provides cron-like event scheduling, distributed job execution via WebSocket satellite agents, visual workflow orchestration, real-time server monitoring, alerting, ticketing, secrets management, and a plugin marketplace. The backend is organized around a central engine class (`lib/engine.js`) that mixes in modules for scheduling, job lifecycle, monitoring, alerts, maintenance, SSO, and API handling; the frontend uses a custom page framework with jQuery, CodeMirror, and WebSocket-driven live updates. In production, events are defined with triggers (schedule, interval, single, catchup, range, blackout), jobs are launched locally or on remote satellites, and job output is streamed via SSE/WebSocket. Monitoring data (CPU, memory, disk, processes) flows from satellites to the master, where JEXL expressions evaluate alert conditions and store multi-resolution timelines. The system persists to SQLite/Postgres/Redis via a custom storage abstraction (unbase) and supports import/export, snapshots, activity logging, and a plugin marketplace. Maintenance is active: frequent releases, CI workflows, security patching, and a comprehensive integration test suite are present. The codebase shows some technical debt—large monolithic files, duplicated CRUD patterns, callback-heavy async, and a custom UI framework—but the core architecture is modular, well-documented, and backed by a real test suite.
Zinit is a Zsh plugin manager that provides fast, asynchronous (turbo) loading of plugins and snippets with a unique ice modifier system for declarative configuration. The architecture is a monolithic shell-script library with the primary entry point `zinit.zsh` sourced from `.zshrc`. Key subcommands include `load`, `light`, `snippet`, `update`, `delete`, `compile`, and `unload`. The ice modifiers allow transient options like `wait`, `atclone`, `atpull`, `make`, and `extract` to control how plugins are fetched, compiled, and sourced. The project uses an annex system for extensibility and includes comprehensive completion management, reporting, and diff tracking. The codebase is written entirely in Zsh and relies on common Unix tools (git, curl, tar, etc.). While not a general-purpose application, it is a well-crafted tool for Zsh users, with reusable standalone utilities like `share/git-process-output.zsh` and `share/rpm2cpio.zsh`. The test infrastructure (`tests/_support/bootstrap`) provides a sandbox pattern for integration testing Zsh plugins.
This repository provides a comprehensive Nginx security configuration package to block malicious bots, spam referrers, bad IPs, and vulnerability scanners. It includes curated blocklists (bad user agents, referrers, IPs, fake Googlebots), rate limiting/DDoS protection, and optional fail2ban integration. The core deliverable is a set of modular Nginx include files (bots.d/, conf.d/) and shell scripts (install-ngxblocker, setup-ngxblocker, update-ngxblocker) for automated deployment and daily updates. It also generates Google Analytics ghost spam exclusion lists and a Google Search Console disavow file. The architecture is a collection of configuration templates and deployment tooling, not a standalone application; it is designed to be included into existing Nginx server blocks. The repository is actively maintained with frequent updates to blocklists and CI testing across multiple Linux distributions.
This repository is a curated awesome-list of open-source operations and DevOps tools, organized into 82 categories with 653 entries. It is not a software application; it is a structured dataset of YAML metadata files that are transformed into bilingual README tables via a GitHub Action using Go templates. The data lineage is: contributors add YAML files under items/<category>/<tool>.yaml with fields kind, owner, repo, desc, and desc_en; on push to main, the generator workflow runs the eryajf/yaml-readme action to fetch live GitHub metadata (license, stars, creation/update dates) and render README.md and resources/README-en.md from the provided templates. The repository serves as a discovery resource for engineers evaluating ops tools, answering questions like 'what are the best open-source tools for a given ops category?' and 'what is the license, star count, and last update of a tool?'. It is actively maintained with recent commits, a YAML linting CI, and a clear contribution guide. The reusable assets are the templating pattern and CI workflows, which can be adapted to any curated list or structured-data-to-document pipeline.
Nitric is a multi-cloud framework that enables developers to define cloud infrastructure and application logic in code, then deploy to AWS, Azure, or GCP. The framework provides infrastructure-as-code capabilities for cloud resources (APIs, storage, queues, topics, secrets, etc.) with runtime implementations for handling cloud service events. It features a modular architecture with core framework logic, cloud provider implementations, and a documentation site. The system uses a plugin-based worker system for handling cloud events and provides consistent abstractions across cloud providers through well-defined interfaces.
dotdrop is a command-line tool for managing dotfiles across multiple hosts using profiles, Jinja2 templating, actions, and transformations. It stores dotfiles in a Git repository and deploys them to target systems, allowing different configurations per host or environment. The architecture is modular: separate Python modules handle each operation (install, compare, update, import, remove, uninstall), with a central dispatcher in `dotdrop.py`. Configuration is defined in YAML (or optionally TOML) files that specify dotfiles, profiles, variables, actions, and transformations. Key entry points are the CLI subcommands invoked via `dotdrop <command>`. Data flows involve parsing the config, aggregating imported configs and variables, then executing file operations (copy, symlink, diff) with optional template rendering and shell commands. External dependencies include Jinja2, docopt, PyYAML, and optional libraries for TOML support and system detection. The codebase is well-tested with both Python unit tests and a large suite of Bash integration tests, and it is distributed via PyPI, Homebrew, AUR, Snap, and other channels.
This is a mature Maven plugin (io.fabric8:docker-maven-plugin) that integrates Docker container lifecycle management into Maven builds. It enables building Docker images from Dockerfiles, Maven assemblies, or Jib; pushing images to registries; running containers for integration tests; and managing volumes, networks, and logs. The plugin is widely used in Java/Spring Boot projects for containerized testing and deployment. Architecturally, the plugin follows a layered design: Maven Mojo classes (e.g., BuildMojo, StartMojo, StopMojo) serve as entry points, delegating to a service layer (ServiceHub, BuildService, RunService, RegistryService) that orchestrates Docker operations. The access layer (DockerAccess interface, implemented by DockerAccessWithHcClient) communicates with the Docker daemon via HTTP over Unix sockets, Windows named pipes, or TCP. Configuration is resolved from Maven POM XML, Maven properties, Docker Compose files, or external handlers, with a flexible property merging system. Key data flows include: (1) image build: resolve configuration → create build context (assembly or Dockerfile) → send to Docker daemon → tag and optionally push; (2) container lifecycle: resolve run config → create container → start with wait conditions → track for shutdown; (3) authentication: chain of providers (system properties, Maven settings, Docker config.json, credential helpers, AWS ECR, OpenShift) to obtain registry credentials. The plugin also supports BuildX for multi-architecture images and a watch mode for live-reload during development. External dependencies include the Docker Engine API, Apache HttpClient 4.x, Google Gson, SnakeYAML, Jib Core, and jnr-unixsocket. The codebase is well-tested with over 200 unit tests and integration tests running against multiple Docker versions on Linux, macOS, and Windows.
The conda/constructor repository is a CLI tool for building cross-platform installers from conda packages. It reads a `construct.yaml` configuration file, solves package specifications via conda's API, fetches packages, and generates installer artifacts: shell archives (`.sh`) for Linux/macOS, macOS `.pkg`, Windows `.exe` via NSIS, experimental Windows `.msi` via Briefcase, and Docker images. The architecture is modular with dedicated modules for each installer type, configuration validation (Pydantic + JSON Schema), signing abstraction, and utility functions. Production data flows: construct.yaml → validation → spec solving → package download → payload staging → installer generation + signing + hash outputs. External dependencies include conda, NSIS, Apple pkgbuild, signtool/AzureSignTool/codesign, and Docker. The codebase shows clear separation of concerns, automated CI/CD across platforms, and comprehensive example recipes, though it exhibits moderate coupling to conda internals and some deprecated configuration options.
This repository implements the Ghost CLI, a command-line tool for installing, configuring, updating, and managing Ghost CMS instances on Linux servers (Ubuntu). The system is a monolithic Node.js application with a plugin architecture. Its core responsibilities include: (1) resolving and downloading Ghost versions from the npm registry, (2) setting up required infrastructure (MySQL, nginx, systemd), (3) managing instance lifecycle (start/stop/restart), (4) handling content migration and import/export via the Ghost Admin API, (5) running health checks via the doctor command, and (6) handling major version upgrades with rollback support. Architecturally, the CLI is composed of a Command base class with yargs integration, a layered task system using listr2 for sequential/parallel operations, and an extension system that allows built-in plugins (nginx, systemd, MySQL) to inject commands, setup steps, doctor checks, and custom process managers. Configuration is managed via JSON files, and dependencies are installed using either yarn or pnpm. The codebase is well-structured with clear separation of concerns: commands in lib/commands/, tasks in lib/tasks/, utilities in lib/utils/, and extensions in extensions/. The tool depends on external services: npm registry for version resolution, Ghost Admin API for import/export, system tools (nginx, systemd, MySQL) for production setups, and acme.sh for SSL certificate management. It supports local development (direct node process) and production (systemd service). The codebase is actively maintained, with support for Ghost versions 1.x through 6.x, Node.js 22/24, and MySQL 5.6 through 9.4. While there is some legacy code for older Ghost versions, the overall architecture is modern, testable, and modular.
Vackup is a standalone bash script CLI tool for backing up and restoring Docker volumes. It provides four core commands: export (volume to tarball), import (tarball to volume), save (volume to Docker image), and load (Docker image to volume). The tool runs temporary busybox containers to perform file operations, ensuring compatibility across Linux and macOS. It features robust error handling with user-definable failure hooks, cross-platform path resolution, and a comprehensive Bats test suite. The tool is designed to be run from any host with Docker CLI access, with optional Docker image distribution via the provided Dockerfile.
This repository provides reproducible Nix packaging for a collection of CLI tools (summarize, discrawl, wacrawl, gogcli, goplaces, camsnap, sonoscli, peekaboo, poltergeist, sag, imsg, qmd) used in the OpenClaw ecosystem. It includes per-tool OpenClaw plugin metadata (skills) that teach AI agents how to use each tool. The repo features automated update workflows: a Go-based tool updater (`cmd/update-tools`) that fetches latest GitHub releases and updates Nix expressions with new versions and hashes, and a skill syncer (`cmd/sync-skills`) that pulls the latest skill definitions from upstream OpenClaw repositories. The Go code demonstrates solid engineering with proper timeout handling, process group management, atomic file updates, and comprehensive tests. The Nix expressions are well-structured, supporting multiple platforms (aarch64-darwin, x86_64-linux, aarch64-linux) and using pinned nixpkgs inputs for reproducibility. CI runs formatting checks, vetting, tests with race detector, and builds all packages on supported systems. The repository is actively maintained with frequent commits and automated CI runs.
Gogs is a self-hosted Git service written in Go, providing a full-featured platform for hosting Git repositories with issue tracking, pull requests, wiki, webhooks, and Git LFS support. The backend is a monolithic Go application using a dual web framework (Macaron and Flamego) and dual ORM (XORM and GORM) during an ongoing migration. The frontend is a hybrid of legacy server-rendered templates and a modern React SPA built with TanStack Router, Radix UI, and Tailwind CSS. The system supports multiple authentication backends (LDAP, SMTP, PAM, GitHub OAuth), SSH and HTTP Git protocols, and extensive REST API. It is deployed via Docker with s6 supervisor and backup rotation scripts. The codebase demonstrates strong engineering practices with well-structured utility packages, security-conscious input validation, and comprehensive test coverage using golden files and mock stores. However, it carries technical debt from the framework migration, vendored outdated frontend plugins (CodeMirror 5.17.0), and a monolithic legacy JavaScript file.
Khue's Homelab is a GitOps-driven infrastructure-as-code framework that automates a complete self-hosted Kubernetes platform from bare metal to user-facing applications. The codebase is organized into five layers: metal (Ansible roles that PXE-boot Fedora Server, bootstrap a k3s cluster with kube-vip HA, and install Cilium for networking/load balancing), system (bootstrap Helm charts for ArgoCD, cert-manager, ingress-nginx, Rook Ceph, and monitoring), platform (Gitea, Woodpecker CI, Grafana, Kanidm identity, Dex SSO, zot container registry), apps (Jellyfin + the *arr stack, Matrix, Paperless, Ollama, and more), and external (Terraform-managed Cloudflare DNS, tunnel, and ntfy alerting). ArgoCD ApplicationSets watch the git repository and deploy every Helm chart, making the repo itself the source of truth; a single top-level `make` drives the entire pipeline. The project demonstrates strong IaC craftsmanship: idempotent Ansible roles with checksum-verified downloads and run_once state handling (k3s token genesis, kubeconfig extraction), an ephemeral PXE server with per-MAC kickstart files and DHCP-proxy mode, declarative random secret generation via a small Go tool combined with the External Secrets Operator for cross-namespace secret sync, and a Terraform module that creates least-privilege Cloudflare API tokens injected directly into the cluster. It also includes a Nix dev shell for reproducible tooling, pre-commit hooks, Woodpecker CI that renders Helm diffs on pull requests, and Terratest-based smoke/integration/version tests. The author explicitly labels the project ALPHA and recommends forking for personal use. It is best treated as a reference architecture and a collection of reusable provisioning patterns rather than a turnkey product; some portions (scripts/hacks, take-screenshots, the gitea config job) are acknowledged work-in-progress, and a few pinned versions lag the ecosystem (Go 1.19 in-cluster compile jobs, k3s 1.30, several stale container image tags).