HTTPS-PORTAL is a Docker image that automates HTTPS setup using Nginx and Let's Encrypt. It provides a fully automated reverse proxy that obtains SSL certificates, configures Nginx, and handles renewal. The container runs multiple supervised processes via s6-overlay: Nginx, docker-gen (for automatic container discovery), cron (for certificate renewal), and a dynamic environment watcher. Configuration is driven by environment variables, primarily the `DOMAINS` variable which supports a rich syntax for specifying upstreams, redirects, basic auth, access restrictions, custom ports, and per-domain stages. The codebase is primarily Ruby scripts that parse domain descriptors, generate Nginx configuration from ERB templates, and orchestrate certificate signing via acme-tiny. The architecture is clean and modular, with clear separation between domain parsing, certificate management, and Nginx configuration generation. The repository includes comprehensive integration tests using Docker Compose and RSpec.
This repository implements a comprehensive Traefik configuration management system, providing a unified UI and REST API to manage middlewares, routers, services, mTLS, security settings, and plugins. The backend is built in Go using the Gin framework with SQLite for persistence, and it supports both Pangolin and direct Traefik API as data sources. The frontend is a React/TypeScript SPA built with Vite, using Zustand for state management and Shadcn UI for components. Key architectural patterns include background watchers that sync Traefik state into the database, a config proxy that merges and serves dynamic Traefik configuration, and a plugin manager that edits static YAML files. The system acts as an HTTP provider for Traefik, generating dynamic configuration on the fly. It is not a data research project; it is a full-stack operational tool for managing Traefik reverse proxy configurations.
FRP Manager is a Windows desktop application that provides a graphical interface for managing FRP (Fast Reverse Proxy) client configurations. It allows users to create, edit, launch, stop, and monitor multiple FRP proxy configurations, supporting both legacy INI and modern TOML formats. The application can run as a standard GUI or as a Windows service, with real-time status updates via IPC between the GUI and the service process. It includes features such as quick-add proxy presets (SSH, RDP, FTP, etc.), import/export via file, URL, or clipboard, NAT type discovery, master password protection, and multi-language support (6 languages). The installer is a native Windows bootstrapper that extracts an MSI and handles service lifecycle during upgrades. The architecture is monolithic: the main entry point in `cmd/frpmgr/main.go` decides whether to launch the GUI or run as a service. The UI layer uses the `lxn/walk` library (a custom fork) for native Win32 controls, organized into pages (configuration, log, preferences, about). The service layer wraps the official `fatedier/frp` client library and manages Windows service installation, start/stop, and configuration reload. IPC is implemented via named pipes for status updates. Configuration parsing and validation are handled in the `pkg/config` package, with conversion between INI and TOML. The project also includes a comprehensive i18n system using `gotext`, a set of reusable validators, and utility functions for file operations, string manipulation, and reflection-based config pruning. External dependencies include the FRP library (`fatedier/frp` v0.71.0), the forked `lxn/walk` GUI library, Windows API bindings (`golang.org/x/sys/windows`, `github.com/Microsoft/go-winio`), and WiX Toolset for the installer. The build process requires Go 1.25, MinGW, Node.js, and Windows SDK. The codebase is well-structured with clear separation of concerns, though it is tightly coupled to Windows and the forked walk library, limiting portability. Test coverage is present for core packages (config, validators, utilities) but sparse for UI and service components.
This is the playit.gg tunnel agent, a production-grade client-side daemon that exposes local servers (e.g., Minecraft, game servers, web services) to the internet through the playit.gg tunnel network. The system is organized as a Rust multi-package workspace comprising five main crates: `agent_core` (tunnel state machine, TCP/UDP proxying, control connection), `playitd` (background daemon with IPC server, stats, log rotation), `playit-cli` (CLI and TUI frontend using ratatui), `playit-ipc` (local IPC protocol with version negotiation), and `playitd-tray` (Windows system tray controller). It supports Linux, Windows, macOS, and FreeBSD, with platform-specific path handling (Unix sockets, named pipes, Windows service management). The architecture centers on a UDP control connection to playit.gg servers: the agent authenticates via HMAC-SHA256, receives tunnel assignments, then proxies TCP and UDP traffic between tunnel ingress points and local origin servers. The daemon runs as a background service (systemd, OpenRC, Windows service) and exposes a local IPC endpoint for the CLI/TUI to monitor logs, stats, and lifecycle status. Key entry points include `packages/playitd/src/bin/playitd.rs` (daemon binary), `packages/playitd/src/bin/playitd-service.rs` (Windows service host), `packages/playit-cli/src/main.rs` (CLI with attach/start/stop/claim commands), and `packages/playitd-tray/src/main.rs` (Windows tray application). External dependencies include tokio (async runtime), ratatui (TUI), crossterm (terminal), serde (serialization), reqwest (REST client), and ring (HMAC). The codebase demonstrates strong craftsmanship in low-level networking (zero-copy UDP packet pools, PROXY protocol, statically-sized control messages) and state machine design (connection recovery, MTU probing, address selection). However, it suffers from some production debt: panics in critical paths (UDP channel shutdown, flow invariants), duplicated code between `playitd-tray` and `playitd-windows-setup` startup shortcuts, and hardcoded configuration values (control port, protocol version). The build and release infrastructure is extensive (nfpm, WiX, Docker, Arch PKGBUILD, code signing) but shows signs of fragility (stale binary name in mac-deploy.sh, sed-based version overrides).
This repository provides a fully automated, one-command deployment of a self-hosted Supabase stack. The setup script (`setup.sh`) orchestrates the entire process: it installs dependencies, clones the repository, generates cryptographic secrets and JWT tokens, configures environment variables, and layers optional docker-compose overrides for Authelia 2FA, Nginx or Caddy reverse proxy, and SSL via Let's Encrypt. The architecture is a Docker Compose multi-service deployment including Supabase Studio, Kong API gateway, GoTrue auth, PostgREST, Realtime, Storage, Edge Functions, and a custom Postgres image. The code is production-grade with robust error handling, CI/CD pipelines (GitHub Actions) that test every configuration matrix (caddy/nginx, basic auth/authelia/redis), and comprehensive integration tests covering CRUD operations, storage, realtime subscriptions, and edge functions. The repository also includes advanced utilities for key management (asymmetric JWTs, opaque API keys) and a sophisticated Postgres 15-to-17 upgrade script (`upgrade-pg17.sh`) that handles binary extraction, pg_upgrade, and post-migration patches. While primarily a deployment tool, the scripts demonstrate high craftsmanship and are safely reusable as templates for similar self-hosting scenarios.
This repository provides a comprehensive, modular set of Bash scripts to automate the installation and configuration of Apache Guacamole—an open-source remote desktop gateway. The primary orchestrator '1-setup.sh' handles interactive prompts and silent install variables to deploy Guacamole server and client from source, integrate MySQL/MariaDB as the backend database, set up Nginx as a reverse proxy, and optionally configure TLS (self-signed or Let's Encrypt), multi-factor authentication (TOTP, Duo, LDAP), and extra UI features like quick-connect and session recording storage. The scripts are well-structured with extensive error checking, logging, distro-specific workarounds, and support for modular post-install add-ons. Though not a library for reuse, the code demonstrates solid shell scripting craftsmanship, security hardening (fail2ban integration, firewall rules), and separation of concerns. The repository serves as a turnkey deployment toolkit for production-grade Guacamole environments.
Watt Toolkit (Steam++) is a cross-platform desktop application that serves as a multi-functional game toolbox primarily for Steam users. The system provides network acceleration via a local reverse proxy (YARP-based) with HTTPS interception, DNS analysis, and multiple proxy modes (Hosts, System, PAC, VPN, DNS intercept). It includes plugins for Steam account switching, two-factor authenticator management (import/export/recovery), game library management, ArchiSteamFarm integration for card farming, and game tools. The architecture is a modular plugin system built with Avalonia UI, .NET, and ReactiveUI, using a multi-process IPC model for privilege separation. External dependencies include WinDivert for Windows packet interception, XunYou SDK for game acceleration, and ArchiSteamFarm for automated Steam actions. The codebase demonstrates a complex but functional architecture with significant platform-specific code and some areas of technical debt.
This repository provides a preconfigured Nginx reverse proxy distribution designed to bypass regional internet censorship (primarily for Pixiv, but also covering GitHub, Steam, Discord, and other services). It includes a portable Nginx binary, self-signed SSL certificate generation scripts, and a set of modular site-specific configuration files that rewrite SNI and proxy requests to real upstream IP addresses. The system requires no VPN; instead, it modifies the user's `hosts` file to redirect target domains to localhost, where Nginx intercepts the traffic. The primary entry points are Windows batch scripts (e.g., `5.调试工具（这个功能全）.bat`) for starting, stopping, and reloading Nginx, while the core configuration is in `conf/nginx.conf` which includes reusable shared proxy parameters and site-specific configs. Certificate generation is handled by a standalone batch script folder (`自签证书傻瓜式批处理包/`) that creates a root CA and signs server certificates for all proxied domains. The repository is not a development framework or data pipeline; it is an end-user tool for circumventing censorship, with a strong emphasis on easy setup and maintenance through regular IP list updates.
This repository provides deployment tooling for frpc, the client component of the frp reverse proxy project (fatedier/frp). It does not contain any original application code; rather, it packages the official frpc binary into installation scripts for Linux servers and Synology NAS, along with a Docker image. The supported deployment methods include a systemd-managed service (Linux), a nohup background process (Synology), and a Docker container with multi-architecture support (amd64, arm64, arm). The core user experience is to download and execute a script, which automatically fetches the frpc binary from GitHub, installs it under /usr/local/frp, generates a default frpc.toml configuration, and sets up automatic startup. The Dockerfile builds a minimal Alpine image containing the frpc binary and expects a mounted configuration file. The repository is a practical convenience wrapper around the upstream frpc project. Its main value is simplifying installation across different environments and providing a CI/CD pipeline to build and publish multi-arch Docker images. The scripts include basic safeguards such as checking for existing installations, killing any running frpc processes, and detecting platform architecture. However, the code quality is average: the scripts are functional but lack robust error handling, use the deprecated md5sum, and pin an outdated Alpine base image (3.8). The repository is maintained but shows some technical drift, particularly in the old base image and reliance on deprecated commands. There are no highly reusable, isolated software components that demonstrate exceptional craftsmanship beyond the straightforward installation pattern. The repository fulfills its purpose for users who need a quick, largely hands-off setup of frpc, but it does not offer novel architectural insights or independently extractable modules for other projects.
This repository implements a Minecraft reverse proxy server in C++ using the Asio asynchronous networking library. It intercepts Minecraft client connections, forwards them to a remote server, and provides features such as whitelist/blacklist access control, customizable MOTD (server list ping), per-user proxy routing, traffic monitoring, and a web-based control API. The architecture is event-driven with callbacks for login/logout events. The codebase includes a vendored copy of Asio (standalone) and a custom utility library (rbslib) providing buffer management, stream abstractions, varint encoding, command-line parsing, and file I/O. The proxy handles Minecraft protocol packets (handshake, status, login, ping) and supports both synchronous and asynchronous I/O via C++20 coroutines. While functional and reasonably well-structured, the project lacks automated tests, has some incomplete features, and uses Chinese comments which may hinder international maintenance. The vendored Asio library is large and may become outdated, but the core proxy logic is solid.
Mantrae is a self-hosted web UI for managing Traefik dynamic configuration, including routers, services, middlewares, entry points, and server transports. The backend is written in Go using ConnectRPC/protobuf for the API layer, sqlc-generated code for SQLite persistence, and a Svelte frontend for the user interface. It provides CRUD and operational workflows for Traefik resources, DNS providers, users, agents, backups, and profiles. The README explicitly states that development has moved to Tether, making this project superseded. The codebase is a monorepo with large amounts of generated protobuf and sqlc code committed alongside hand-written service logic. It uses modern tooling such as buf, sqlc, goreleaser, and ko, but has no visible tests, some incomplete documentation, and a minimal OpenAPI spec. The UI includes generic data table components with sorting, filtering, pagination, and bulk actions. Overall, it is a functional but unremarkable application with moderate maintainability and limited reuse potential outside its own architecture.