serveroshq/panel

This page introduces an external open-source repository. It is not an HDATF product.

What it does

ServerOS panel is a web control panel for operating Linux servers you already own. Operators supply machine enrollment details, Git repositories or deployment templates and workflow settings to manage deployments, monitoring and backups. Each managed machine needs a separately connected serverosd daemon; installing the panel does not automatically enroll servers. It covers CPU, memory and disk status, service logs, scheduled workflows and team activity. The inspected API routes expose tool calls behind API-key authentication, and the project documents MCP and API connections for external tools. Self-hosting requires a Docker-capable Linux server, a domain and, in the standard setup, ports 80, 443 and 8443 plus wildcard DNS. Email delivery and private GitHub repositories require separate SMTP and GitHub App configuration. The community edition built from this repository differs from the official image that includes commercial extension code. Panel code is AGPL-3.0, while paid extensions and trademarks have separate terms, and default anonymous installation telemetry should be reviewed.

License

AGPL-3.0 Network copyleft. Offering a modified version as a service also requires releasing the source. Review before any product use.

More in this category

• JenkinWoo/sheeridVerify
  sheeridVerify is a Node.js workbench for learning and authorized testing of SheerID verification workflows. Its intended users are educators, researchers, and testers with permission to handle the submitted information. A job takes a verification link, a name, a birth date, and configured school and document sources, then produces queue progress, logs, and a result reflecting the remote state. It queries the current verification step before choosing browser form interaction or document upload. Documents are read as original PNG, JPEG, or PDF bytes rather than generated or altered, and interactive human challenges remain with the user. The web workbench controls concurrency and allows cancellation, resumption, and deletion, but its queue and history are held in memory and disappear on service restart. When a submission response is uncertain, the workflow queries the remote state instead of immediately repeating the write. It requires Node.js 22.15 or newer, Camoufox for the browser branch, and access to SheerID and any configured document or proxy service. Real personal information can reach those services, and deleting a local task does not revoke a remote submission or erase disk logs. Constructing an email string does not prove ownership or student status, and the project disclaims affiliation with SheerID and any guarantee of successful verification.
• render-oss/render-mcp-server
  Render MCP Server is Render's official bridge between an AI application and resources hosted on Render. It uses MCP, a protocol through which an AI application discovers tools and passes structured parameters to them. Inputs include workspace and resource identifiers, log filters, service settings or SQL, and outputs include resource details, operational records and query results. Tools cover service and database creation, deployment history and triggering, logs, metrics and environment-variable replacement. The Postgres query tool wraps queries in a read-only transaction, but other tools can change infrastructure or initiate deployments. Clients can connect to the hosted endpoint or run a local executable or container with appropriate credentials. Database queries use the external database connection and remain subject to its IP allowlist. This is not complete Render administration, and sensitive information can still reach the AI context even though the server attempts to reduce exposure.
• render-oss/cli
  Render CLI is Render's official command-line client for developers and operators managing Render resources. It accepts commands, resource identifiers and options, and returns interactive menus or structured JSON, YAML and text output. It supports service and datastore inspection, deployments, restarts, one-off jobs and live log filtering. It also provides SSH and Postgres sessions and validation of Blueprint configuration files. Non-interactive operation is intended for scripts and CI/CD, with deployment waiting and failure exit status available for automation. It needs a local executable, Render access and authentication, using browser-authorized CLI tokens or an API key for automated environments. Commands operate on the active workspace, and write operations can affect live resources rather than merely generate suggestions. Current documentation states that usage telemetry is enabled by default, and sensitive credentials, confirmation policy and command-specific external dependencies still require operational care.
• KKKKhazix/agent-autoloop
  This automation layer lets terminal agents react to events and ask a person only when a decision is needed. It calls already installed and authenticated executors such as Claude Code and Codex rather than supplying its own model. Schedules, GitHub events and external HTTP events are assigned to agents and workspaces by rules. Final replies and structured receipts become completion records, question cards, notices or deferred follow-ups. While awaiting an answer, the agent process exits and can resume the existing session after a response. It requires macOS or Linux, Node 24, Git, curl and an authenticated agent; the README currently states Windows is unsupported. Event sources, notification channels, agents and delivery pipelines are plugins requiring configuration. Some channels and business recipes have only simulated validation, and the generic command adapter does not enforce every executor's permissions. Model usage belongs to the connected account, while hostile input and file access under the same system account require separate controls.
• thtbee/nectarlink
  NectarLink is a device companion for people who move between an Android phone and a Windows PC. With permission, phone notifications, messages, clipboard content, files, photos and screen content become available on the paired PC, and selected controls work in the other direction. A shared Rust core handles device identity and pairing, while the desktop and Android applications provide their respective interfaces. Devices normally communicate directly over the local network or USB using encrypted connections, and mobile-data relay is optional. Setup involves installing both applications, confirming pairing and enabling only the features the user wants; some advanced Android features require separately authorized debugging access. An optional local HTTP and JSON automation API supports actions such as sending files, notifications and camera requests, requires a Bearer token and is disabled by default. The documented v0.1.4 packages cover Windows x64 and Android, while Linux and Windows ARM64 packages are described as forthcoming and macOS remains a preview. This is not a cloud collaboration service, third-party chat history is limited by notification access, and call audio still stays on the phone even when calls are controlled from the PC.

Only repositories in the ranked Trendshift lists are included, and the lists are used only to find candidates. We do not copy their ranks. Descriptions, licenses and star counts come from each GitHub repository. The notes are our own reading. We have not tested these projects, and a place on a trending list does not prove quality.