XPipe

XPipe is a desktop connection hub that gives system administrators, DevOps engineers, and developers a single interface to access their entire server infrastructure. Instead of juggling separate tools for SSH, Docker CLI, kubectl, RDP, and VNC, XPipe integrates them all through a unified, locally-running application that requires no configuration changes or agent installation on remote systems.

The application works entirely on top of your existing command-line tooling — it delegates to your installed SSH client, Docker daemon, kubectl binary, and other CLIs rather than reimplementing protocols. This means zero remote footprint: your servers stay exactly as they are, and XPipe manages the orchestration from your local machine. Connection configurations are stored in a cryptographically secured local vault, with optional Git-based synchronization for sharing access across team members or multiple workstations.

XPipe supports an unusually broad set of connection types out of the box: SSH with full config file and agent support, Docker and Podman containers, Kubernetes clusters and pods, Proxmox PVE and KVM virtual machines, Hyper-V and VMware environments, LXD and incus containers, Tailscale and Netbird mesh networks, AWS and Hetzner Cloud servers, RDP and VNC remote desktops, and Windows Subsystem for Linux environments. The extensible plugin architecture via Java’s ServiceLoader mechanism means additional integrations can be added without modifying the core application.

Built in Java 25 with JavaFX for the desktop UI, XPipe ships as native installers for Windows, macOS, and Linux with support for package managers like apt, brew, winget, scoop, and Chocolatey. It includes an integrated MCP server for AI agent integration, a rich scripting system for automating tasks across remote connections, and a file browser designed for professional workflows with sudo elevation, tabbed multitasking, and direct integration with local editors.

What You Get

• Unified Connection Hub - Organize and access SSH servers, Docker/Podman/LXD/Incus containers, Kubernetes pods, Proxmox/Hyper-V/KVM/VMware VMs, AWS and Hetzner Cloud instances, and VPN-connected hosts (Tailscale, Netbird, Teleport) in a single hierarchical tree with one-click launch.
• Remote File Browser - Browse, upload, download, and edit files on any connected system using your locally installed editors (VS Code, Sublime, etc.), with dynamic sudo elevation, tabbed multi-host sessions, and drag-and-drop transfers.
• Terminal Launcher - Open an authenticated shell session in your preferred terminal emulator (iTerm2, Windows Terminal, Alacritty, WezTerm, Ghostty, Kitty, and many others) with auto-filled credentials, tmux/zellij multiplexer integration, and starship/oh-my-zsh environment support.
• Versatile Scripting System - Create reusable shell scripts and init templates that are automatically deployed to the PATH on any remote system, letting you standardize shell environments and automate routine tasks without manual setup.
• SSH Ecosystem Integration - Automatically import existing SSH config files, SSH agents (Pageant, KeeAgent, custom sockets), jump host chains, X11 forwarding settings, and smartcard keys without recreating any configuration.
• Container and VM Management - Start, stop, inspect, and shell into Docker, Podman, LXD, Incus containers and Kubernetes pods directly from the connection hub, with automatic scanning to detect containers on connected hosts.
• Remote Desktop and X11 - Launch RDP, VNC, SPICE, and X11 application sessions via automatic SSH tunneling, treating remote GUI sessions as first-class desktop applications integrated into the XPipe workspace.
• Automatic Service Tunneling - Detect services running on remote systems and tunnel them to localhost with one click, enabling local browser or tool access to remote web UIs, databases, and APIs without manual port forwarding.
• Git-Synced Encrypted Vault - Store all connection configs in a locally encrypted vault that syncs across devices and team members via your own self-hosted Git repository, with secrets fetched from local password managers rather than stored in the vault.
• Integrated MCP Server - Expose all XPipe capabilities (file operations, command execution, terminal launching, system listing) to AI agents via an embedded Model Context Protocol server that integrates with Claude, Cursor, and other LLM clients.

Common Use Cases

• Managing hundreds of cloud and on-prem servers - A DevOps engineer groups 200+ SSH hosts across AWS regions and on-prem data centers into a hierarchical tree and launches authenticated terminal sessions or file browser tabs in seconds without copying credentials.
• Developing against containerized environments - A developer execs into running Docker or Kubernetes pods, browses container filesystems with a local VS Code editor, and tunnels a remote PostgreSQL instance to their local machine — all without remembering port numbers or exec commands.
• Standardizing team infrastructure access - A platform team shares a connection vault via a private Git repo so that new team members get a fully configured connection hub on day one, with consistent SSH configs, scripts, and environment setups.
• Automating repetitive server administration tasks - A sysadmin writes a shell script in XPipe’s scripting system to restart Nginx across a group of web servers, assigns it a desktop shortcut, and triggers it with one click from the taskbar without opening a terminal.
• Using AI agents to operate remote systems - An engineer enables XPipe’s MCP server and connects their AI coding assistant, allowing the agent to list systems, read remote files, run commands, and execute scripts across the entire infrastructure through natural language.

Under The Hood

Architecture XPipe is structured as a modular Java desktop application using the Java Platform Module System, with four main layers — core, beacon, app, and named extensions (base, proc, system, uacc) — each enforcing explicit dependency boundaries via module-info declarations. The app layer follows a layered architecture where the JavaFX UI, business logic, and remote protocol handling are cleanly separated: UI components are built with a reactive JavaFX binding model, business logic resides in store and provider abstractions, and remote communication is handled by the beacon subsystem. A ServiceLoader-based extension mechanism allows connection types, action providers, and scan providers to be registered dynamically without modifying the core — new integrations slot in as separate modules. The Gradle build orchestrates a multi-module project with jpackage-based native installers for Windows, macOS, and Linux, and the operation mode system (background, tray, GUI) sequences startup of the beacon HTTP server, data storage layer, and JavaFX platform in a controlled order.

Tech Stack The backend is written in Java 25 with JavaFX for the desktop UI, using JPMS for module isolation and Lombok to reduce boilerplate throughout. Jackson with Jacksonized builders handles JSON serialization for vault storage and beacon API payloads. The HTTP-based beacon server uses JDK’s built-in com.sun.net.httpserver for zero-dependency local IPC between the desktop UI and external CLI clients. MCP protocol support is provided by the io.modelcontextprotocol Java SDK embedded directly into the running application. Gradle with spotless (Palantir Java Format) enforces code style, and jpackage generates platform-native installers with a bundled JDK. Tests use JUnit 5.

Code Quality The codebase demonstrates strong structural discipline: package hierarchies map cleanly to functional domains (process, storage, browser, hub, beacon, terminal, ext), naming is consistently descriptive, and interfaces like DataStore, DataStoreProvider, and ActionProvider enforce clean contracts between layers. Lombok reduces boilerplate across data classes and structured error propagation flows through a custom ErrorEventFactory and TrackEvent logging system. Spotless enforces consistent formatting across all modules. Test coverage is limited in the open-source repository — a handful of unit tests exist in the core module for path parsing, and the app module contains a placeholder test; the localTest directories are scaffolding rather than substantive test suites. Public CI is limited to Dependabot dependency updates, suggesting testing occurs primarily within the closed release pipeline.

What Makes It Unique XPipe’s defining engineering choice is its zero-footprint remote access model: instead of deploying agents, it leverages shell dialects and command-line programs already present on remote systems — making it work with embedded Linux systems, network switches, WSL environments, and anything that exposes a shell. The embedded MCP server turns the entire infrastructure graph into an AI-accessible tool surface, enabling language models to read files, run commands, and manage connections across all connected systems through a standardized protocol. The beacon HTTP server pattern exposes local desktop state over HTTP secured by a local auth secret, allowing the CLI tool, REST API consumers, and AI agents to share one canonical view of the connection hub without any cloud intermediary. The breadth of remote desktop protocol support (RDP, VNC, SPICE, X11 forwarding) within a single agentless desktop application is unusual in the open-source infrastructure tooling landscape.

Self-Hosting

XPipe is released under the Apache License 2.0, one of the most permissive open-source licenses available. This means you can use it freely for any purpose — commercial or otherwise — modify the source code, redistribute it, and build proprietary tools on top of it without any copyleft obligation. The only requirements are preserving copyright notices and the license text. Everything in the public GitHub repository is fully open and free to use; the project does not require purchase or registration to access the source code.

Operationally, XPipe is a desktop application that runs on each engineer’s local workstation — not a server you deploy or a database you maintain. There is no central XPipe infrastructure to keep running; your connection vault is stored locally in an encrypted format and the only shared component you might operate is the Git repository used for optional vault synchronization, which can be any Git hosting solution your team already uses. Updates arrive via the built-in updater or your package manager of choice (apt, brew, winget, choco, scoop, AUR), and applying them is the user’s responsibility. The local nature of XPipe means operational burden is minimal, but it also means each workstation needs the application installed and kept up to date independently.

Because there is no hosted cloud service, there is no XPipe-provided SLA, no managed uptime guarantee, and no cloud backup of your vault — everything depends on your local machine and your chosen Git sync repository. Community support is available through GitHub Issues. Organizations that need centralized policy enforcement, audit logging as a managed service, enterprise SSO integration, or cross-team compliance dashboards would need to build those capabilities on top of XPipe’s open APIs rather than relying on a vendor-managed offering.