# Xray-core: date-based release tags and an install list that is mostly other people's scripts

> Xray-core is the Go network core behind Project X, published under MPL-2.0 with release tags named after dates. The interesting part of the repository is not the core: it is how much of the installation surface belongs to third parties, and what the dependency manifest says the binary is actually made of.

**XTLS/Xray-core** — GitHub describes it as Xray, Penetrates Everything. Also the best v2ray-core. Where the magic happens. An open platform for various uses.. The repository metadata lists Go as its primary language. The metadata lists the MPL-2.0 license. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/XTLS/Xray-core
- Website: https://t.me/projectXray
- Stars: 41,855 · Forks: 5,934
- Language: Go
- License: MPL-2.0
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/xtls-xray-core

## Release tags are calendar dates, and one day produced two of them

The three most recent tags are v26.9.30, published on 2026-09-30, and then v26.9.9 and v26.9.8, both published on 2026-09-08. Two builds on the same day with adjacent numbers tells you something about how the project ships: a tag is a build moment, not a semantic version carrying a compatibility promise. There is no major, minor and patch structure to reason about, so the question "is this upgrade safe" has to be answered by reading the diff rather than by comparing version numbers. The main branch was pushed on 2026-09-29, a day before the v26.9.30 tag, so the branch and the newest tag are close together. For a component that other people's panels and scripts pin, record the exact tag string you deployed. A date tag is unambiguous once written down and useless if you try to remember it.

## Exactly three install routes are labelled official, and the README offers around twenty more

The installation section is organised by category, and only three entries carry the Official marker: the XTLS/Xray-install Linux script, the ghcr.io/xtls/xray-core container image, and a single copy-paste line for macOS:

```shell
brew install xray
```

Everything else in that section belongs to somebody else. Linux gets a second script, tempest, which supports systemd and OpenRC and is Linux-only. Docker gets teddysun/xray and wulabing/xray_docker alongside the official image. Then there are nine web panels, from Remnawave and 3X-UI through Marzban and Hiddify to CELERITY, and nine one-click scripts including Xray-REALITY, reality-ezpz, Xray_bash_onekey, XTool, VPainLess, v2ray-agent, Xray_onekey and ProxySU, plus two Magisk modules for rooted phones. That is a large amount of code that will run with the privileges needed to bind ports and change routing, none of it covered by the MPL-2.0 licence that governs this repository, and none of it pinned to a version in the list. The count is the point: the core is small and the operational tooling around it is a long tail of unaffiliated projects.

## The web panels are the component that actually holds your credentials

Of the categories listed, web panels are the one with real operational weight. A panel is what gives you user accounts, subscription links and a place where inbound settings are edited, which means it is the process holding the private keys and the client configuration your users import. Nine are listed, all third-party, all with their own release cadence that has nothing to do with Xray-core tags. Upgrading the core does not upgrade a panel, and a panel release does not declare which core version it expects. The practical risk is a version skew you did not choose: you update the binary under a panel, or the panel updates itself, and the mismatch shows up as a failing inbound or an invalidated subscription rather than as a clean error. If you run a panel, pin it as carefully as you pin the core tag, and know which process owns the key material before you need to know.

## The go.mod manifest is an accurate description of what the binary contains

The dependency list is unusually revealing for a project whose README is mostly links. It requires go 1.27, so building from source needs a current toolchain. Several entries explain the transport story directly: apernet/quic-go for QUIC, refraction-networking/utls, and xtls/reality pinned to a pseudo-version dated 2026-09-08, which is the same day as two of the release tags. Networking libraries cover the edges: miekg/dns, pion/stun, gorilla/websocket, pires/go-proxyproto, libp2p/go-nat and gvisor, a userspace network stack. Two WireGuard packages and golang.zx2c4.com/wintun mean a TUN-based path is compiled in, including on Windows. There is also blake3 for hashing, cloudflare/circl for cryptography, klauspost/cpuid for CPU feature detection, robfig/cron for scheduling, gRPC and protobuf, and gofumpt and testify on the tooling side. The practical consequence is a single static binary that does a great deal, which is convenient to ship and harder to audit than a small program.

## There is no app directory, no sample config and no run command in the repository

The top level of the tree is app/, common/, core/, features/, infra/, main/, proxy/, testing/ and transport/, plus go.mod, go.sum, SECURITY.md, CODE_OF_CONDUCT.md and LICENSE. The module path is github.com/xtls/xray-core. This is a library-shaped repository, not an application with a main package and a config file at the root, and the README reflects that: it contains no configuration sample, no command line invocation and no explanation of a single field. The usage section points outward instead, to an example configuration for VLESS-XTLS-uTLS-REALITY, one for VLESS-TCP-XTLS-Vision, one called All-in-One-fallbacks-Nginx, and to three separate example repositories including XTLS/Xray-examples and an integrated-examples collection. So the artifact you need in order to actually run the core lives outside this repository, maintained separately, and nothing in the release tag tells you which example set matches it.

## Support runs through Telegram channels split by language, with docs on a Pages site

There is no forum, no chat room and no mailing list in the README. What there is: the official website at xtls.github.io, the Project X channel at t.me/projectXray, a second Project X channel, a Russian-language channel for Project VLESS, and a Persian-language channel for Project XHTTP. That last pair is a useful signal, since it shows where the contributors of those two pieces of work actually are. Sponsorship runs through an issue, number 3668, alongside two sponsor links. Code of conduct and security files exist, and the README states plainly that it is open and invites pull requests against the Xray-core repository. The practical consequence is that configuration help, which is the question almost every new user has, is answered in chat channels rather than in a searchable archive, and the searchable archive is the docs site, which is maintained apart from the code.

## Funding is routed to token addresses and NFT collections, which is a choice with consequences

The donation section is unusual enough to read carefully. Besides conventional sponsor links, it lists addresses across TRX and USDT and USDC on Tron, TON, BTC, XMR, SOL and ETH, and then three OpenSea collections: a Project X NFT, a VLESS NFT and a REALITY NFT. The stated framing is that collecting a Project X NFT supports the development of Project X. Two things follow for a user. The first is that supporting this project can mean buying a token-bound collectible, which is a different act from a recurring donation and carries market and custody risk that a donation does not. The second is that the listed work is spread across active threads, including a pull request for VLESS post-quantum encryption, number 5067, and a discussion titled XHTTP: Beyond REALITY, number 4113. Pick a tool on its configuration and its release history, not on its funding model.

## What the core does not give you, and who fills each gap

Several things a new user looks for are simply not here, and each one has to be sourced elsewhere. There is no default configuration in the repository, so a first run has nothing to load. There is no client GUI from this project, which is why the README spends a long section listing clients for OpenWrt with PassWall and PassWall 2, Asuswrt-Merlin, Windows with v2rayN and Furious, Android with v2rayNG and X-flutter, and Apple platforms with Happ, Streisand and INCY. There is no documented migration path, even though the repository description positions the project as a v2ray-core, so a v2ray user has no compatibility statement to read and no config translation to rely on. And no support matrix exists, so which operating systems and architectures are exercised is inferred from the install list rather than stated. The gap is consistent: the core is well defined, and everything around it is somebody else's release to maintain.

## Conclusion

Xray-core suits someone who already knows the protocol family and wants the core specifically, with a Homebrew formula, an official container image or the project's own Linux script as the shortest path. It does not suit someone arriving from v2ray expecting a drop-in, because the README carries no compatibility or config migration statement, and it does not suit anyone who wants the operational tooling to come from the same project, since the panels and one-click installers are all third-party. Before you install, decide which of those scripts you are willing to run as root on the machine, read the go.mod requirements for a Go 1.27 toolchain, and pin a date tag rather than tracking the main branch, which was pushed on 2026-09-29.

## FAQ

### What is Xray-core?

A Go network core written by Project X, which originated from the XTLS protocol and also produces REALITY. The repository is licensed under MPL-2.0, its module path is github.com/xtls/xray-core, and it is released with date-based tags such as v26.9.30.

### How do you install Xray-core?

The three routes marked official are the XTLS/Xray-install Linux script, the ghcr.io/xtls/xray-core container image, and Homebrew on macOS with brew install xray. The README also lists a second Linux script, two further Docker images, nine web panels and nine one-click installers, all maintained by other projects.

### How do you install Xray-core on Ubuntu?

No Ubuntu-specific command appears in the README. It names a Linux script maintained by the project and an alternative script called tempest that supports systemd and OpenRC and is Linux-only, and it also offers the official container image, which is the route with the fewest distribution-specific assumptions.

### Is Xray-core better than v2ray-core?

The repository description calls Xray the best v2ray-core, but the README contains no compatibility statement, no config migration guide and no side-by-side comparison. Anyone switching has to verify that their existing configuration fields are still accepted, because nothing in this repository promises they are.

### What are the alternatives to Xray-core?

The README does not name a drop-in alternative core. The closest it comes is WireGuard: there is a tutorial on running Xray with a WireGuard inbound, and the core's own go.mod requires the WireGuard and wintun packages, so a WireGuard path is compiled in rather than bolted on by a third party.

## Sources

- [Official documentation](https://t.me/projectXray)
- [Official README](https://github.com/XTLS/Xray-core#readme)
- [Project repository](https://github.com/XTLS/Xray-core)
- [Release notes](https://github.com/XTLS/Xray-core/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xtls-xray-core