autoXRAY: a one-command Xray setup for a personal server

What the script actually installs

The project describes itself in one line as a bash script for automatic configuration of the Xray core, and the description adds that it configures a personal VPN server and hands out ready made current configurations of the VLESS protocol over the XHTTP and RAW transports with TLS.

The system requirements are stated bluntly: a clean Debian 12 machine with root rights. Nothing else.

The recommended flow is a domain, a server, and one command. You rent a virtual server, you get a domain name, and then you run the script with the domain as an argument.

bash -c "$(curl -L https://raw.githubusercontent.com/xVRVx/autoXRAY/main/autoXRAY2.sh)"

What you get back is a list of four working configurations. A VLESS connection over the RAW transport with TLS and the VISION flow control on port 443. A VLESS connection over the XHTTP transport with TLS and the EXTRA flow control, also on 443. A Hysteria2 connection on 443. And a web proxy for the messaging service on 443.

Everything is on 443, which is the port that matters for a server that has to look ordinary to a network middlebox, and the use of two different transports and two different flow control variants is the script answering the question of which one will work from your network today.

There is also a second script in the repository, one that builds a bridge between a Russian and a European server, and the readme explains that the main script redirects the traffic from Russia directly.

Credentials are regenerated on every run

There is a line in the explanation section that is easy to skim and is actually the security model of the tool.

Every time autoXRAY runs it generates new identifiers, keys and passwords, to protect the users.

So the script is not a one-time installer but a credential generator that you re-run when you want to invalidate the old set. That has an obvious consequence for operations, and the readme covers it: if you are using the subscription link, you have to remember the link, reinstall the script, and then point the application at the new path before updating the subscription in the client. If you are using the keys directly, the readme says that option is not available, because a new run produces a different set of keys, and it suggests using a QR code to move the configuration to a phone instead.

That last suggestion is worth noting as a design decision. The two ways of distributing a configuration, a subscription URL and a key pair, have different update semantics, and the script only supports reissuing the first.

There is also a section on creating configurations for several users, and its answer is that you do not need to, because one configuration can be used by several people at once, and if you want to manage users and watch their traffic you need a control panel anyway.

The selfsteal idea, and why a domain is required

The core concept is the mask, and the readme calls it selfsteal. You run a website of your own on the same server, and the VPN traffic is disguised as traffic to that site.

The advantages listed are specific rather than vague. The site always works on your server, which removes a point of failure. The ping is lower and the connection is faster. No content delivery network is used, unlike on many popular sites. And the disguise is better, because the site is in the same network as the server.

That last point is the reason a domain is a hard requirement rather than an optional extra, and the readme spends a section on getting one. The free option is a subdomain, and the walkthrough is a registration at a free DNS provider, then creating a zone and entering a random name for the subdomain, then creating an A record pointing at the address of the server. Two other free services are listed as alternatives, and there is a paid option that combines a domain with DNS hosting and server rental.

One practical warning is worth noting. DNS records do not update immediately, and the readme says it can take fifteen minutes or sometimes an hour or more, with a tool given for checking the propagation. So a first run of the script may appear to fail for reasons that have nothing to do with the script.

Choosing a server, and the subnets that will not work

The server selection section is the most unusual part of the readme, because it is a list of hosting providers with prices, and the list is chosen on a specific criterion: strictly without identity verification.

The readme explains the choice in a heading, with the reasoning that a knowledge requirement, meaning mandatory identity verification with a passport, a phone number or a card, is what they are avoiding. The European entries are grouped by location, with the note that German locations are the most stable, and each entry has a price and a set of countries where the provider operates.

The Russian entries are for the bridge scenario, and they are priced in roubles.

Then the warning, which is the most useful paragraph in the section. The subnets of popular hosting providers are blocked by many network operators, and for some of them it is not even possible to connect over SSH without a VPN already working. The advice is not to use those providers, or not to complain that the main script does not work.

That is a hard constraint on the tool, and it is the kind of thing that a reader outside the region would not anticipate. The script is not just a configuration generator, it is a configuration generator for a network environment where certain hosting providers are unreachable, which means the choice of server is part of the installation and not a detail to sort out afterwards.

The promotional tariffs mentioned are also flagged as usually ending and usually being heavily reduced, which is a useful warning for anyone budgeting around a price.

Why there is no control panel

The explanation section is the argument for the whole design, and it is the part to read before you install.

The argument is that there are many instructions on the web for installing a graphical panel, naming several popular ones. But they are all excessive for home use, because they are designed for large projects and have a high configuration complexity, and they also run the Xray core themselves.

The cost of the manual route is then quantified, and the number is what makes the script worth having. The manual that you have to work through before you get your first working configuration runs to more than ten pages. On top of that, you also have to find a suitable configuration for Xray and set it up correctly, which is the thing the script does well.

The resource argument closes it. Without a graphical interface and a database, Xray consumes fewer server resources, and it suits running on a weak virtual server configuration.

So the trade is explicit. You give up the ability to manage users through a web interface, and you get a server that fits on a cheap machine and a setup that takes one command. For a family or a single person, that is a reasonable trade. For a service with paying customers, the readme itself points you at a panel.

The client side is documented per platform, with a list of applications for each of iOS and macOS, Android, Windows and Linux, and a note that some of the listed applications do not support the subscription configuration and only accept the single key format, which is the router configuration.

Updating and removing, which the readme is specific about

There are three separate procedures in the readme, one for the whole script, one for the core alone, and one for the web proxy component, and each is a single command.

The core alone is the one that most people who already have a setup will need.

bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install

Removal is the reverse, and the readme is careful to cover each component separately. The web server and the certificate tooling go first.

systemctl disable nginx; systemctl stop nginx; apt remove nginx -y; ~/.acme.sh/acme.sh --uninstall 2>/dev/null

Then the proxy core itself, with a purge flag.

bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ remove --purge

And then the web proxy component, which has its own uninstall script.

bash -c "$(curl -L https://raw.githubusercontent.com/xVRVx/autoXRAY/refs/heads/main/test/telegram/web-proxy-uninstal.sh)"

The order is not arbitrary. The certificate tooling has to go before the proxy core, because the certificates were issued for a hostname the core is serving, and removing them out of order leaves a half configured machine.

The manual removal of the web server is the one step here that is not delegated to a script, and the readme is explicit that it is the one thing to run by hand.

The repository, and who it is written for

The repository is small, and the file names describe the structure.

There is the main script, a second script for building the bridge between the Russian and European servers, an old directory holding the earlier versions of the scripts with their documentation moved out of the readme, and a test directory. The readme's update notes point at that old directory for the description of the scripts that are no longer current, which is a sensible way of keeping a readme about the present rather than a history.

The licence is GPL-3.0, the primary language is shell, the default branch is main, and there are no tagged releases, so the script is fetched by branch rather than by version. The last push was on 2026-10-12 and the repository is not archived, so the work is ongoing.

The documentation is entirely in Russian, and the context explains itself. The script exists to give people in Russia a personal VPN, the server list is chosen for that market, the bridge script handles a specific traffic path, and the blocked subnets warning only makes sense inside a network environment where those providers are unreachable. That is not a defect in the project, it is the project.

For an English reader, the practical translation is that this is a single-purpose installer for one network situation, maintained by its author for that situation, and the parts of the readme that generalise are the parts about not using a control panel, about regenerating credentials on each run, and about the order in which to uninstall things.

Editorial conclusion

autoXRAY suits a single person or a family who want a personal VPN on a cheap server and do not want to run a control panel, because the script does the whole setup in one command and regenerates credentials on every run. It is a poor fit for managing many users, which the readme says needs a panel, and a poor fit if you cannot accept running a shell script fetched over the network as root, which is what the install command does. Before you run it, read the script rather than the readme, check that your provider is not one of the blocked subnets the author warns about, and note that the certificates are issued for a selfsteal site you host yourself.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. xVRVx/autoXRAY on GitHub