Begzar: an Android VPN client that closed its own source code

A consumer VPN app, not a library

Begzar is described as a VPN service built around simplicity, security and reliability, with the Android version currently available to users. The installation section is three steps: download the latest version from the Releases page, install the APK on the device, launch the app and connect. There is no configuration file to author, no server to deploy and no key to import.

The repository itself is a Flutter application, and the top level entries show the shape of a mobile project: lib/ and test/ for Dart code, android/ for the platform shell, assets/, a pubspec.yaml and pubspec.lock, analysis_options.yaml, a privacy.md file and a Persian README alongside the English one. The project topics list Android, Flutter, VPN, v2ray, xray, xray-core and xtls, which names the protocol family the client is built on even though the visible documentation does not describe how those are configured.

The wider service is described as a multi-tier stack: Flutter for the mobile application, Golang for the core services, Vue.js for the website, and Laravel for the backend and API. So the repository you can read is the phone side of a system whose server side, subscription and admin plane are not in this repository at all. That split matters when you try to reason about what the app does with your traffic: the interesting part of the protocol handling lives on the server side of the stack, in code that is not published here.

Version 5.5.0 closed the repository and split the licence

The single most consequential fact about this project is a policy change. From version 5.5.0 onward, the project documentation states that Begzar is developed and distributed as closed source, and gives the reason: some individuals were misusing the open-source code, putting user security and service stability at risk. Older open-source releases remain in the repository, newer versions are published under this policy.

The licence section is equally direct. Earlier open-source releases are licensed under MIT, while versions 5.5.0 and above are proprietary and closed source. The LICENSE file in the repository root and the MIT badge in the README therefore describe the historical releases, not the current ones. Anyone evaluating the project on the strength of an MIT badge is looking at the wrong thing, and the mismatch between the MIT badge and the shipped binary is the kind of thing that has to be checked rather than assumed.

The current release line is v7.0.0, tagged as a stable release on 2026-09-17, with v6.8.0 on 2026-08-16 and v6.7.0 on 2026-07-29. The repository is not archived and the last push was on 2026-09-17, matching the v7.0.0 tag, so the project is being worked on even though you cannot read most of it. The premium tier arrived earlier, at version 6.4.0.

What the free tier actually includes

The feature table lists a fast connection with automatic connect, advanced encryption protocols, a mobile-optimised interface, balanced battery and device resource usage, automatic refresh of the active server list, and free access to the service for all users. The server list refreshing is the mechanism worth noticing: the client updates its own set of servers without the user doing anything, which is the standard approach for clients that rely on a shared infrastructure pool.

The premium documentation is where the business model is spelled out. Starting at version 6.4.0 a Premium plan was added, introduced to raise capital and cover infrastructure and server costs. Two assurances are made explicitly: no user data is collected, and the free servers remain active, with the free tier explicitly not removed and subscribing described as entirely optional.

That is a coherent and unusually transparent position for a project of this kind, and the documentation goes further in listing ways to support it, including starring the repository, subscribing to Premium and recommending the service. Note the tension: the same document that says no user data is collected is the document for a paid tier sold on stability and speed. The privacy claim is worth reading in the app's own privacy.md rather than taking from the marketing table, and the README is not the place where that file's contents are summarised.

Why the source code policy is a security decision, not just a licence one

The stated reason for closing the code is worth taking seriously on its own terms. A VPN client is a privileged program. It sits at the network boundary of the device, it holds the configuration that decides where traffic goes, and it is trusted with every destination your phone contacts. A fork of that client, repackaged under a name nobody audits, can be pointed at a different operator's server while keeping the same icon and the same install prompt, and the user has no way to tell.

That is the abuse the policy describes, and it is a real one. But closing the source does not remove the risk, it moves it. Once the binary is opaque, the user can no longer check what the client does with DNS requests, whether logs exist, how the protocol is negotiated, or whether the advertised encryption is what the code implements. The MIT releases remain available in the repository, which means an auditor can still read the older implementation and reason about the general design, and the topics list shows the client still rides on Xray and V2Ray, both of which are separately inspectable.

The practical consequence is a verification gap rather than a safety guarantee. The honest framing is that the closure reduces one class of risk, the repackaged-fork risk, and increases the other, the unverifiable-binary risk, and a security conscious user has to weigh which of the two they can live with.

Where Begzar is the wrong tool

Several common needs rule this project out. If your requirement is an audited, self-hosted tunnel, the answer is elsewhere: build the client yourself on the published Xray and V2Ray cores, where the protocol handling and the server address both live in configuration you control and can read. The difference in approach is ownership of the trust chain. Begzar hands you a finished client and a shared server pool and asks for trust in return. A self-hosted setup hands you the same protocol family and asks for a server, a domain and the operational work that comes with them.

Second, Android only. The documentation is explicit that the Android version is currently available to users, and the repository layout has android/ with no ios/, no desktop and no browser extension. Anyone who needs the same client on a laptop, a router or an iOS device has to look elsewhere, and the Flutter code in lib/ would be reusable in principle, but nothing in the repository documents a second platform build.

Third, the repository is not the product. The stack description puts the core services in Golang, the website in Vue.js and the backend in Laravel, none of which is here. There is no server component to inspect, no configuration schema to diff and no way to check how the free server list is produced or filtered. And with the client closed, an engineer who wants to contribute a fix has no way to do it, which is the point the project is making.

Finally, the app must be installed as an APK from a releases page, sideloaded rather than installed from an app store. That has consequences for managed devices, for update policy, and for how a security team reasons about where the binary came from.

What to check before you route a phone through it

If you decide to use it, the checks are concrete and mostly about provenance. Download the APK from the Releases page of the repository rather than from a mirror or a link forwarded in a chat, and confirm the version number matches the release notes you read, since a v7.0.0 build and a v6.x build differ in licensing terms as well as features. Read privacy.md in the repository, which exists precisely to state what the application records.

Understand the free tier you are joining. The documentation says free servers remain active and that server lists refresh automatically, which means the endpoints your traffic goes through can change without any action from you. For everyday browsing that is a reasonable convenience. For anything you would not want routed through an unknown exit, it is a design decision, and one you should make knowing that the free list is dynamic.

Finally, know what a premium subscription buys and what it does not. The documentation says premium adds benefits and that subscription is optional, with the free tier kept alive. It does not describe the specific benefits, and that is where the project's own site at begzar.app is the place to read them, along with the pricing and the terms. Support channels are listed in the project documentation: a Telegram channel at @BegzarVPN and a support address, both of which are worth trying before you commit a device to the service.

Editorial conclusion

Begzar is a reasonable pick for a personal Android device where you want a working tunnel with free servers, automatic server list updates and no configuration file to write, and where a closed binary is an acceptable trade for convenience. It is the wrong choice for an organisation that has to audit the client, self-host the service, pin and audit a protocol version, or meet an internal requirement that traffic configuration stay in source control. Before installing anything, read the source code policy note in the project documentation, check privacy.md for what the current build actually does with logs, and verify that the APK you install comes from the releases page rather than a mirror, since the client now carries the authority to route all of your traffic.

Frequently asked questions

Official sources

1. Begzar/BegzarApp on GitHub
2. License: MIT
3. Project website
4. README
5. Releases