Xibo CMS is a full-stack digital signage content management system that enables users to create, schedule, and manage content displayed on screens. The backend is built with PHP (Slim framework, Symfony EventDispatcher, Phinx migrations) and exposes RESTful APIs consumed by a modern React/TypeScript SPA frontend (Vite, TanStack Query, Tailwind CSS). It supports player communication via XMR (message relay) and legacy SOAP-based XMDS. Key features include layout and playlist management, media library, scheduling with dayparting and recurrence, reporting (proof of play, bandwidth, session history), OAuth2 authentication, multi-tenancy via folders and permissions, and a widget/module system with connectors. The codebase is large and actively maintained, with extensive frontend tests (Vitest) and Docker-based development/deployment. However, it carries some technical debt from a legacy jQuery/Bootstrap UI that coexists with the modern React frontend, and a high volume of database migrations indicates long evolution.
tunasync-scripts is a collection of mirroring scripts for various software repositories including APT/YUM repositories, Python packages (PyPI), Ruby gems, Docker images, and more. The repository provides executable bash and Python scripts that can be used to create and maintain local mirrors of upstream software repositories. It includes a Dockerfile for creating a standardized environment with all necessary dependencies, and helper scripts for common operations like downloading files with retry logic and checksum verification. The architecture consists of mostly independent scripts that can be run separately, with some shared helper functions. Key entry points include apt-sync.py, yum-sync.py, pypi.sh, rubygems.sh, and various other mirroring scripts for specific ecosystems.
This repository provides a high-precision IP geolocation HTTP API focused on mainland China, capable of resolving IP addresses to province/city/district level using a custom GeoCN database. The server is written in Go, uses MaxMind GeoLite2 databases for ASN and city-level data, and supplements with a custom MMDB for Chinese administrative divisions. It is deployed as a single binary via Docker, with a CI pipeline that weekly rebuilds the image with updated databases. The codebase is monolithic but well-organized, with environment variable configuration, proper error handling, and clean JSON responses. It is primarily an application, not a data research project, though it ships supporting data files for division codes and ASN metadata.
The opencontainers/runtime-tools repository is a command-line application for working with the OCI (Open Container Initiative) runtime specification. It provides two main functionalities: generating OCI runtime spec configuration files (config.json) via the `oci-runtime-tool generate` command, and validating OCI bundles against the runtime specification via the `oci-runtime-tool validate` command. Additionally, it includes a runtime validation suite (`runtimetest`) to test OCI-compliant runtimes (like runC) for specification compliance. The architecture is modular, with separate packages for generation, validation, cgroups handling, path operations, and spec-specific error handling. Built in Go using urfave/cli for command parsing, it supports multiple operating systems (Linux, Windows, Solaris) via build tags and external dependencies on the OCI runtime-spec and other Go libraries. The tool is actively maintained, with recent commits and ongoing alignment with spec updates.
This repository contains educational materials for learning Docker, specifically designed to prepare for the Docker Certified Associate (DCA) certification. It consists of markdown-formatted chapters covering Docker fundamentals, images, volumes, networking, docker-compose, swarm, monitoring, tools, Kubernetes, and enterprise topics. The repository also includes a lab environment setup using Vagrant to provide hands-on experience with Docker in a multi-node cluster configuration. The primary value of this repository lies in its comprehensive documentation rather than executable code. It serves as a structured learning resource that explains Docker concepts with practical examples and setup instructions. The lab directory contains reusable infrastructure-as-code components for provisioning a Docker swarm cluster using Vagrant and VirtualBox, enabling users to create a consistent learning environment.
Haaukins is a cybersecurity training and Capture The Flag (CTF) platform developed at Aalborg University. It orchestrates isolated lab environments for teams, combining Docker containers and VirtualBox VMs to deliver challenges. The system is built as a set of gRPC microservices: a central daemon manages event lifecycle, team assignments, and challenge verification; a store service provides persistence; and an exercise service defines challenge configurations. Participants access labs via a web frontend (Amigo) using browser-based RDP (Guacamole) or WireGuard VPN. The daemon also handles DNS/DHCP per lab subnet, real-time scoreboards via WebSocket, and keylogging for monitoring. The CLI client (hkn) allows administrators to manage events, teams, and exercises. The architecture is modular with clean interfaces for virtualization (Docker/VirtualBox) and storage (in-memory with hooks or gRPC backend), though some components show tight coupling and aging dependencies.
This repository hosts the documentation and tutorials for Kuboard, a Kubernetes management interface. It is built with VuePress 1.x and serves as a static site via Nginx. The site includes Markdown-based guides covering Kubernetes concepts, Kuboard installation and usage, and practical tutorials for deploying applications. Additionally, it provides version-specific installation scripts for setting up Kubernetes clusters and deploying Kuboard in various configurations (standalone, HA, etc.). The documentation is organized into sections such as Overview, Installation, Learning, Guide, and Support, making it a comprehensive resource for Kubernetes users.
WeWe RSS is a monolithic NestJS application that provides RSS feed generation for WeChat public accounts (微信公众号). It acts as a middleware between the WeRead (微信读书) platform and standard RSS readers. The system allows users to add WeChat public accounts via article links, fetches account metadata and article lists through the WeRead platform API, stores them in a MySQL or SQLite database, and exposes RSS/Atom/JSON feeds. It includes a cron-based scheduler for periodic feed updates, an admin dashboard built with React and NextUI, and supports features like full-text extraction, title filtering, and OPML export. The architecture is typical for a NestJS application: controllers handle HTTP requests, tRPC provides a type-safe API layer for the frontend, Prisma ORM manages database interactions, and the frontend is a separate Vite/React app. The codebase is straightforward and functional, with no standout reusable components that could be easily extracted without modification.
Dejavu is a single-page web application that provides a modern UI for browsing, searching, and managing data in Elasticsearch and OpenSearch clusters. It is built with React 18, Redux, Redux-Saga, and Ant Design, and leverages the ReactiveSearch library for search UI components. The application runs entirely client-side, communicating directly with the Elasticsearch REST API. It supports CRUD operations, data import/export (JSON/CSV), field mapping management, term-based filtering, global search, and a search preview builder. The codebase is organized as a monorepo with two packages: a reusable browser component library (`@appbaseio/dejavu-browser`) and the main application (`dejavu-main`). The architecture follows a standard Redux pattern with sagas for side effects, and uses react-virtualized for high-performance data grids. While the code is well-structured and feature-rich, it relies on several outdated dependencies (Redux 3.x, redux-saga 0.16, react-router-dom 4.x, emotion 9.x) and uses Flow type annotations, which are now deprecated. The project appears to be in a stale maintenance state with no recent commits.
TechEmpower Framework Benchmarks is a large-scale, multi-language benchmark suite for comparing the performance of web application frameworks. The repository contains hundreds of independent framework implementations (e.g., Go, Rust, Java, C#, Python, PHP) each implementing the same standard set of HTTP endpoints: JSON serialization, plaintext, single/multiple database queries, updates, fortunes (HTML), and cached queries. The core benchmark toolset (written in Python) orchestrates Docker-based builds, runs load tests via wrk, and verifies response correctness. The codebase is a federation of many small applications rather than a single system, with each framework's code living in its own directory under `frameworks/<language>/<name>/`. The architecture is highly standardized: every framework exposes the same routes, uses the same database schema (World and Fortune tables), and follows common optimization patterns like connection pooling, prepared statements, batch updates, and template caching. While the repository is actively maintained and the toolset is well-structured, the quality of individual framework implementations varies widely—some are expertly tuned for performance, while others are stubs or use outdated libraries. The primary value of this repository is as a reference for comparative performance numbers and as a collection of idiomatic, performance-focused code examples across many languages and frameworks.
This repository provides the Home Assistant add-on packaging for Zigbee2MQTT, a Zigbee to MQTT bridge. It contains Docker build configurations, entrypoint scripts, and add-on metadata to run Zigbee2MQTT as a managed add-on within Home Assistant OS or Supervised installations. The actual Zigbee2MQTT application is fetched from its upstream repository during Docker build (either a stable release or the dev branch for the edge variant). The add-on supports serial device passthrough, socat for remote serial forwarding, MQTT auto-discovery via Home Assistant services, and an ingress-enabled web frontend. The codebase is primarily configuration and build orchestration; there is no application logic beyond the entrypoint script that translates add-on configuration into environment variables for Zigbee2MQTT. It is a well-structured, actively maintained add-on following Home Assistant best practices, but offers no reusable software components outside the Home Assistant ecosystem.
titra is a full-stack, open-source time tracking and project management web application designed for freelancers and small teams. It is built on Meteor.js 3.x with a monolithic architecture spanning server/client/imports directories, using MongoDB as its primary data store, Blaze templates for the UI, and Rspack for bundling. The application provides core time tracking features (day/week/month calendar views, timeline, timers, bulk entry), project/task management with Gantt charts, dashboards with password-protected sharing and slug URLs, CSV import/export, and rich reporting tables. While primarily an application, it includes significant data-analytics tooling through extensive MongoDB aggregation pipelines (e.g., projectStats, timecard totals) used to power its charts and reporting views, giving it a hybrid nature. The architecture relies heavily on Meteor's reactive publication/subscription model and ValidatedMethod mixins for authenticated, transaction-logged server methods. A standout feature is its integration layer: it supports sandboxed JavaScript execution via Node's VM module for inbound/outbound data interfaces and webhook verification, alongside LDAP, OIDC, Google Workspace (Gmail/Calendar), and OpenAI integrations. The UI is polished with a custom SCSS theming system (dark/light modes) built on Bootstrap, wrapping Frappe charts, datatables, and Gantt charts. External dependencies include MongoDB, Google APIs, LDAP, and multiple third-party SaaS tools (Wekan, Zammad, GitLab). Maintenance is active with a recent commit and zero Dependabot alerts, but technical drift is medium due to reliance on deprecated Blaze templates, a monolithic ~1200-line SCSS file with heavy !important usage, and known minor bugs (e.g., an inverted OpenAI API key guard, an undefined variable in projectlist.js, and duplicated dashboard components). The codebase mixes older callback styles with async/await, indicating ongoing modernization. Despite these issues, the core architecture is solid, well-separated by domain (projects, timecards, users), and offers several genuinely reusable, well-crafted utility components, making it a strong candidate for teams seeking a self-hosted time tracking solution or studying Meteor best practices.
This repository is the source code for the micro-frontends.org website, an educational resource explaining the Micro Frontends architectural pattern. It contains a Jekyll-based static site with detailed tutorials, along with multiple self-contained example applications (plain HTML, client-side composition, universal composition, and data-fetching) that demonstrate key Micro Frontends concepts. The example code is organized by team (red, blue, green) and uses Custom Elements, Server-Side Includes (SSI), Docker Compose, and Nginx to illustrate how to build independent frontend fragments that can be composed into a cohesive application. The repository serves primarily as a learning tool and reference implementation, not a production-ready framework.
This repository provides a Docker image for Apache Superset, a data exploration and visualization platform. It is not an application itself but a containerization layer that packages Superset with its dependencies, including helper scripts for initialization and demo data loading. The Dockerfile is well-structured with proper environment variables, healthcheck, non-root user, and multi-architecture build support via CI/CD. The repository includes example configurations for MySQL, PostgreSQL, SQLite, and Celery backends, along with a Makefile for building and pushing images. The codebase is minimal and focused on the Docker build process; there is no application logic beyond the packaging. The dependencies are pinned and up-to-date, and the repository is actively maintained with recent commits and automated workflows.
This repository contains the Docker packaging and optional Docker Swarm deployment recipes for JumpServer, an open-source bastion host / privileged access management system. It does not contain the JumpServer application source code; instead it composes upstream component images (core, koko, chen, web, kael) into a single all-in-one image and provides the runtime scripts to initialize and supervise them. The all-in-one deployment is explicitly a B/S web-only package and does not support client-related features. The core architecture is the allinone multi-stage Dockerfile, which copies runtime trees from each component image onto the core image, then uses Supervisor to run the Django core service, Koko (SSH/terminal access), guacd, Chen, Kael AI service, and the nginx web frontend. The entrypoint script prepares environment defaults, deterministically derives a service-to-service signing key from BOOTSTRAP_TOKEN when no explicit secret is supplied, migrates per-component data directories into a shared volume via symlinks, waits for database and Redis readiness, and runs the JumpServer schema migration before starting services. The swarm/ directory provides a separate deployment path using Docker Swarm stacks, external MySQL/Redis, healthchecks, and a one-shot init-db job. The code is generally careful within its narrow scope: database initialization is idempotent, local vs external dependency startup is handled cleanly, and the multi-stage image build is a non-trivial composition of separately published images. Maintenance appears active, and the build pipeline watches v5.* tags. Drift is medium: the GitHub Actions workflow uses the deprecated/archived actions/create-release@v1 action, image tags are mutable rather than digest-pinned, and a version string inside allinone/readme.txt lags behind the current default Dockerfile version. There are no tests, but this is deployment glue rather than application logic.
This repository provides a collection of scripts, tools, and binary patch files to remove the simultaneous NVENC encoding session limit and enable NvFBC (NVIDIA Frame Buffer Capture) on consumer-grade NVIDIA GPUs. The core mechanism is binary patching of NVIDIA driver shared objects (Linux) and DLLs (Windows) using version-specific byte replacement strings. On Linux, the main entry points are patch.sh and patch-fbc.sh, which use sed to apply patches to libnvidia-encode.so and libnvidia-fbc.so. The project also includes a Dockerfile and docker-entrypoint.sh for applying patches inside containers without modifying the host, and supports Flatpak installations. On Windows, patches are distributed as .1337 files (a simple text-based patch format) and applied using a third-party tool (Win_1337_Apply_Patch). Additionally, a wrapper DLL (nvfbcwrp) intercepts NvFBC API calls to inject the required private keys, enabling NvFBC on consumer cards. The repository also includes a suite of supporting tools: an automated driver locator (nv-driver-locator) that scrapes NVIDIA websites for new releases, an autopatch system for generating patches from driver installers, a patch tester that verifies the patch by running multiple concurrent NVENC sessions, and a README autogenerator that keeps documentation synchronized with the driver database (drivers.json). The architecture is a hybrid of shell scripts, Python tools, and a small amount of C++/assembly for the Windows wrapper. The project relies on external dependencies such as sed, 7zip, ffmpeg, and the Win_1337_Apply_Patch submodule. The codebase is heavily oriented towards reverse engineering and binary manipulation, with a manually curated database of driver versions and patch offsets.
This repository provides Docker images for Laravel development and CI/CD, with PHP versions 8.3, 8.4, and 8.5. The core artifacts are multi-architecture Dockerfiles that extend official PHP-alpine base images and install a curated set of extensions (Redis, Imagick, Xdebug, etc.) and tools (Composer, Node.js, Yarn, PHP_CodeSniffer, Git, rsync). A GitHub Actions workflow rebuilds images weekly, caching and pushing to DockerHub and GitHub Container Registry. The repo also includes example GitLab CI templates for deploying Laravel applications. It is not a library or framework but a published Docker image build repository, and its main value is providing a standard, pre-configured environment for Laravel projects.
This repository provides documentation and automation scripts for setting up a Kubernetes cluster from scratch using VirtualBox. It includes shell scripts for creating and configuring VM images with cloud-init, configuration files for various Kubernetes components (etcd, control plane, worker nodes, HAProxy load balancers), and detailed documentation explaining the setup process. The repository serves as an educational guide for understanding Kubernetes infrastructure components and how they interact, rather than a deployable application itself. The main value lies in the well-structured automation scripts and comprehensive documentation that walk users through building a complete Kubernetes cluster with high availability features.
This repository provides a Dockerized implementation of RaspAP, a wireless router software for Debian-based devices. The container runs systemd to manage multiple services including hostapd (for Wi-Fi access point), dnsmasq (for DHCP/DNS), and the RaspAP web interface. It uses the host's network stack and requires privileged access to configure network interfaces and firewall rules. The setup process involves installing RaspAP via the official installer script, then applying environment-specific configurations through shell scripts that map environment variables to configuration files. The architecture is a single-container design that leverages systemd for process management inside the container. Key components include an environment setup script (env-setup.sh) that dynamically updates configuration files based on prefixed environment variables, a firewall script (firewall-rules.sh) that configures NAT and forwarding rules, and a simple PHP password generator (password-generator.php) for securely hashing web GUI credentials. The container exposes the RaspAP web interface on port 80 (mapped to 8081 on the host) and relies on the host's wireless and Ethernet interfaces for operation. Notable reusable components demonstrate solid engineering practices: the env-setup.sh script implements a clean pattern for mapping environment variables to configuration file key-value pairs using associative arrays and sed-based updates, which could be adapted to other applications with minimal changes. The password-generator.php correctly uses PHP's password_hash function with BCRYPT, showcasing secure password handling. While the Dockerfile follows common patterns for running systemd in containers and the firewall script contains interface-specific assumptions, the overall maintainability is strong with recent commits, active CI/CD workflows, and no reported dependency issues.
Overseerr is a full-stack self-hosted web application for managing media requests in a Plex ecosystem. Users can search for movies and TV shows via TMDB, submit requests (including 4K variants), and have those requests automatically pushed to Radarr/Sonarr for download. The application also tracks media availability by scanning Plex libraries, syncs Plex watchlists, and provides a comprehensive notification subsystem supporting Discord, Telegram, Slack, email, webhooks, and web push. It includes user management with granular permissions, quota enforcement, issue reporting, and a highly customizable discovery page built from TMDB-driven sliders, genres, networks, and studios. The frontend is Next.js (React) with Tailwind CSS, SWR, Formik, and react-intl i18n; the backend is Express with TypeORM on SQLite. The project is feature-rich and has been widely adopted, but the README states it is superseded by the Seerr community fork, and the codebase relies on several aging dependencies (Next.js 12, React 18, Tailwind 3) and a hardcoded TMDB API key. Despite this, the code is well-organized with clear separation between API clients, entities, routes, and UI components, and many parts are written with solid engineering patterns such as a base external API client with caching/rate limiting, a template-method scanner base class, and a clean notification agent interface.