[PROJECT] VRS X: A modern rewrite of Virtual Radar Server (.NET 10 / React / Cro

[BrejSki]

Hey everyone!

Long-time user of Virtual Radar Server here! Like many of you, I love the original software by Andrew Whewell, but setting it up on modern non-Windows systems (Mono issues, dependencies) has always been a bit of a hassle.

So... I did something slightly crazy. I decided to rewrite the core of VRS, bringing it into 2026.

Introducing: VRS X
VRS X is a modern re-implementation of the Virtual Radar Server core architecture. I took the essential concepts that made VRS legendary and rebuilt the engine from the ground up using the bleeding-edge .NET 10.

The Goal
To bring the beloved VRS logic into the modern era of cross-platform, native computing, while leaving behind the limitations of legacy frameworks.

What does that mean?
Instead of wrapping the old code, I have rewritten the core decoding engine, database layer, and web server to work natively on modern hardware! While it's not yet a 1:1 feature-complete clone of every plugin available for the original, the foundation is much faster, lighter, and future-proof.

True Cross-Platform & Native Performance
To make it clear: VRS X compiles to a single, self-contained executable. No Mono, no Wine, no runtime installation required. Just download and run.

It works natively on:

• macOS (Apple Silicon & Intel)
• Linux (x64, ARM64) - tested on Raspberry Pi 4 and 5 (supports Headless Mode via SSH)
• Windows (x64, ARM64) - works on Windows 10/11 and Server 2022/2025

What is already working?

• Multiple feed support (SBS & Beast data supported) with merging and feeder management
• Modern React Frontend - completely replaced the old web interface
• BaseStation database support - including import from OpenSky-Network CSV datasets
• Map with AircraftList.json and icons
• Unified Admin Panel (Web & Desktop)

What has to be done?
There are still many things to do to reach full feature parity.

Can I see it somewhere?
Not yet - v0.0.2 is technical preview quality and it's not ready for public release just yet. I am preparing a dedicated page for this project. Once it is stable enough, I will spin up a public server hosting this app using my ADS-B.Pro RadarView data.

Resource Usage
I'd call it potato-server friendly.

I have attached some screenshots below. This is a complete rewrite of the UI – I dropped the old WinForms/HTML mix and moved everything to a clean React interface.

Let me know what you think!

[SoCal Mac]

I use VRS 3.0.0 Beta with a few plugins along with SVG graphics for the plane icons. Works good for me but I'm on a very old machine. I do look forward to when you have it up and running live.

I've attached a screenshot of what I have now.


Mac

[jon01]

Looking forward to this, thanks for working on a new version

Could we have Open AIP Airspace layers, custom coloured aircraft labels and an option to download (or manually input into a box) local air pressure readings (QNH) from local METARs for correct altitude display please?

I have attached a screen shot of my current VRS 2.4.4 with my custom labels and AIP overlay from a kml file

[dodsy1]

For anyone following this project, a preview version is now live and is being updated frequently with new additions.

https://x.ads-b.pro/?fbclid=IwY2xjawQx2qRleHRuA2FlbQIxMABicmlkETBtTW9UcHBNS09IZ0ZFZ2o3c3J0YwZhcHBfaWQQMjIyMDM5MTc4ODIwMDg5MgABHpEUEpmOO7Qu1fRhSf2D6-lLEGw3ZYmhVsU-QO5bndojpfz_XJWZ10SRo3XF_aem_RLSByyyxzMmDAtZRRpLY8g

[jon01]

Thanks for the updates, all looking good!

Could you add:
-Text size and aircraft symbol size adjust sliders
-Custom Aircraft List menu (To add/remove columns)
-Aircraft Trails (Custom length/colour/width)
-A box to enter the transition altitude (Mine is 6,000ft)
-Aircraft below transition altitude to show altitude (A) and aircraft above transition altitude to show flight level (F)
F370 = flight level 370 (37,000ft)
A025 = altitude 2,500ft
-Aircraft Labels still need a dark (Transparent maybe?) background as they are not easy to see with street map selected background

[jon01]

I see this is still being developed, the devlog is regularly updated,  despite this thread going quiet!

https://vrsx.app/index.html

Looking forward to downloading once it comes out of closed beta

[Anmer]

It's a pity one has to share data before getting access to the app!  Reminds me of AirNav!

[BrejSki]

It's a pity one has to share data before getting access to the app!  Reminds me of AirNav!

Hi, sorry for late reply: currently VRS X is in closed beta, but I am really close to release it as a public release (planning public release around Christmas 2026). I prefer to have a small group of valuable testers who have time to test the app properly, report any bugs etc. Thanks to such small group of testers, VRS X is very stable, has many edge cases fixed, some strange bugs have been reproduced and fixed.

I see this is still being developed, the devlog is regularly updated,  despite this thread going quiet!

https://vrsx.app/index.html

Looking forward to downloading once it comes out of closed beta

Hi Jon! yes, I was pretty quiet in here, but in the next comment I will post some information about this project. As a sole dev of this whole system I am really busy developing it + sharing updates on Facebook groups + daily job.

[BrejSki]

PART 1/3 - PROJECT CATCH-UP: VRS X FROM EARLY BETA TO v0.7.3

HELLO EVERYONE!

First of all, I would like to apologize for staying so quiet here.

Since my last update in February, VRS X has changed so much that I probably owe you a proper catch-up post rather than another short development update.

The project is very much alive. In fact, development has been moving much faster than I originally expected.

Before I go through what has changed, I would also like to clarify one thing which has caused some questions recently:

Why is VRS X still in Closed Beta, and why is Closed Beta currently available only to ADS-B.Pro feeders?

During this stage of development I deliberately prefer working with a relatively small group of active testers.

The testers I currently have are extremely valuable. They use VRS X regularly, report bugs, test unusual configurations and very often find problems that I would never discover on my own.

I genuinely enjoy working with them, and I really appreciate their patience.

Without them, VRS X would have many, many bugs that I would probably not even know about.

The goal is simple:

when VRS X finally becomes publicly available, I want it to be as stable and polished as reasonably possible.

Hopefully.

The feeder-only requirement is temporary and applies only to the Closed Beta period.

VRS X 1.0.0 is planned to be publicly available without requiring users to feed ADS-B.Pro.


CURRENT STATUS

Current Closed Beta Stable release:

v0.7.3

Current development version:

v0.8.0

A public preview of the current development build is available here:

VRS X Development Radar

Project website:

https://vrsx.app

Documentation:

https://docs.vrsx.app


SO... WHAT HAS ACTUALLY CHANGED?

A lot.

Really, a lot.

The following list is not perfectly chronological because at this point even I would probably need archaeological tools to reconstruct every change in the exact order.

I will focus mostly on larger architectural changes and features rather than every individual bugfix.


FROM AN EXPERIMENTAL REWRITE TO A REAL APPLICATION

The early versions of VRS X were primarily about proving that rewriting Virtual Radar Server concepts on a modern .NET and web stack was actually practical.

Since then, the project has gradually moved away from being an experimental rewrite and toward becoming a complete standalone radar application.

Some of the largest changes include:

• A modern .NET backend and React-based frontend.
• Full cross-platform support for Windows, Linux, macOS and Raspberry Pi-class systems.
• Pre-built releases distributed through GitHub Releases.
• Built-in passive update notifications.
• A completely browser-based interface.
• Removal of the original Photino desktop wrapper after WebKit-related problems on macOS.
• Significant CPU and memory improvements after moving completely to the browser-based UI.
• A much more mature administration interface.
• First-run setup wizard and guided administration experience.
• Expanded documentation and an Operator's Handbook.

THE RADAR ITSELF HAS BEEN REBUILT SEVERAL TIMES

The radar visible today is very different from the one shown in the first development screenshots.

Over several releases I gradually replaced and redesigned large parts of the rendering stack.

• Aircraft markers were completely redesigned with support for SVG and PNG marker libraries.
• More than 100 aircraft silhouettes are available out of the box.
• Custom aircraft markers can be uploaded and mapped to ICAO aircraft types.
• Operator-specific aircraft colours can be configured.
• Custom operator logos are supported.
• Custom aircraft images can be stored locally and preferred over external photo sources.
• Aircraft labels became highly configurable.
• Military-only filtering was added.
• Aircraft can be hidden by HEX code.
• Emergency squawks 7500, 7600 and 7700 receive dedicated priority and visual treatment.
• Aircraft trails were added and later heavily redesigned and optimized.
• Trail retention became configurable.
• Adaptive trail sampling now stores more points while an aircraft is turning and fewer while it is flying straight.
• Plausible reception gaps can be displayed as dashed connectors instead of pretending that missing track data was actually received.
• Aircraft can now be selected simultaneously using Ctrl/Cmd.
• Selected aircraft can be shared using direct URLs based on callsign, registration or ICAO hex.
• Multiple selected aircraft can also be shared in a single link.

MAPLIBRE AND THE NEW RENDERING ENGINE

One of the biggest changes arrived in the 0.7.x generation.

The main radar was rebuilt around MapLibre, replacing the previous Leaflet-based rendering path and removing the old Google Maps integration.

This also allowed me to change the way very large feeds are rendered.

Instead of trying to blindly draw every aircraft at every zoom level, VRS X now uses selective rendering.

When looking at a very large geographic area, the radar chooses a representative set of aircraft based on factors such as:

• selected aircraft,
• emergency squawks,
• airborne traffic,
• aircraft size,
• altitude,
• source quality,
• and data freshness.

As you zoom in, more aircraft are progressively displayed.

The Aircraft List remains independent and can still show the complete traffic dataset.

This became particularly important during development because I now regularly test VRS X with feeds containing several thousand aircraft simultaneously.


PERFORMANCE

Performance has received constant attention since the first builds.

Some examples:

• AircraftList.json was repeatedly optimized.
• Radar rendering became viewport-aware.
• A shared spatial aircraft index was added on the backend.
• Map density budgets now adapt to zoom level and screen size.
• Only changed aircraft need to be updated instead of rebuilding the complete map dataset every refresh.
• Unchanged responses are not retransmitted unnecessarily.
• Frontend code was split into smaller on-demand bundles.
• Response compression and caching were improved.
• Load benchmarks were added using approximately 11,000 continuously updated aircraft and 100 mixed radar clients.
• Aircraft trail storage and cleanup have been repeatedly optimized to control memory usage.

This work is also why I am comfortable throwing rather ridiculous development feeds at VRS X today.


ADS-B, MLAT AND FEED MANAGEMENT

Feed handling has probably caused me the most headaches during the entire project.

Anyone who followed some of the earlier development updates probably remembers my ongoing fight with MLAT.

Eventually it became one of the largest milestones of the project.

VRS X currently supports common ADS-B and MLAT input formats including Beast/Binary and BaseStation/Text.

Feed configuration has gradually become much more advanced:

• Automatic recognition of common ADS-B and MLAT ports.
• Native MLAT support.
• Multiple feeds.
• Merged feeds.
• Nested merged feeds.
• Hidden source feeds.
• Password-protected merged feeds.
• Feed visibility controls.
• Improved handling of overlapping coverage.
• Selection of the freshest or most reliable aircraft position when several feeds see the same aircraft.
• Improved reconnect behaviour and backoff handling.
• Much better diagnostics for broken or incorrectly configured feeds.

There were also several fairly spectacular bugs during the Closed Beta period, including incorrect Beast handling, flickering aircraft and incomplete position information.

This is exactly the kind of reason why I am still keeping the project in Closed Beta rather than calling everything stable too early.


CONTINUED IN PART 2/3

[BrejSki]

PART 2/3 - COVERAGE, DATABASES, SECURITY AND CENTRAL REPOSITORY

COVERAGE

VRS X also gained a dedicated Coverage system.

Coverage can be calculated and visualized for feeds and merged feeds, including archived reception footprints.

The archive has since been optimized so that it does not grow indefinitely and remains usable even after collecting substantial amounts of reception history.

The coverage preview also moved to the same MapLibre foundation as the main radar.


AIRCRAFT DATABASE AND LOCAL DATA

VRS X has gradually gained much stronger aircraft database tooling.

Some examples:

• Built-in AircraftDB editor.
• Aircraft database import and export.
• Database merge and overwrite modes.
• Import of original Virtual Radar Server databases.
• Support for ADS-B Exchange aircraft database files provided by the user.
• Local aircraft overrides.
• Civil/military category overrides.
• Aircraft model mappings.
• Operator aliases.
• Operator data source tracking.
• Improved duplicate Mode-S / ICAO handling.
• Custom aircraft images.
• Custom operator logos.
• Custom aircraft markers.

The general philosophy here is still the same:

Bring Your Own Data.

VRS X provides the tools, but I do not want to silently redistribute third-party databases with incompatible licenses.


METAR

The METAR decoder was also rewritten from scratch.

The original implementation handled the basics but had problems with edge cases and REMARKS.

The new decoder supports standard METAR fields as well as the RMK section and presents the decoded information in a much more structured form.


THEMES AND USER INTERFACE

VRS X now includes several different visual styles.

Some of them are fairly normal.

Some are... less normal.

Available radar/interface styles have included variants such as:

• Modern,
• Light,
• Dark,
• Classic,
• Futuristic,
• Overfuture,
• Retro,
• and Phosphor CRT.

The current Modern interface uses floating translucent panels and was designed around the newer MapLibre radar.

The Phosphor CRT theme exists for people who want their ADS-B radar to look slightly more like something found in an underground military command centre.

Because apparently that was necessary.


SECURITY

Security has also changed significantly since the early builds.

Among other things:

• Default administrator credentials were removed.
• The first administrator account is now created during initial setup.
• User session handling was strengthened.
• Sensitive actions may require re-authentication.
• Password changes and access revocation were improved.
• Protection against request forgery and API abuse was expanded.
• Uploaded resources and imports receive additional validation and sanitization.
• HTTPS can be used either through VRS X itself or through a reverse proxy.
• Reverse proxy configuration can be verified from the Admin Panel.
• Public administration exposure requires explicit security configuration.
• The Admin Panel remains separated from the public radar interface.

CENTRAL DATA REPOSITORY - VRS X 0.7.x

This was probably the most important architectural addition before the upcoming 0.8.0 release.

VRS X now has its own shared Central Data Repository.

The Central Repository stores and distributes approved information about:

• aircraft,
• operators,
• and flight routes.

Users can submit reports when aircraft, operator or route information is incorrect or missing.

Reports are reviewed before becoming canonical data.

Approved changes are then synchronized back to VRS X installations.

The important part is that VRS X itself does not become dependent on Central to function.

Each installation still keeps its own local data and can continue operating if Central is temporarily unavailable.


CURRENT CENTRAL DATABASE SIZE

At the time of writing this post, Central contains approximately:

• 447,000+ aircraft
• 6,300+ operators
• almost 8,000 discovered and approved routes

And the route number is currently growing very quickly.

Why?

That brings us to the fun part.


VRS X 0.8.0 - AIR TRAFFIC RECORDER

Version 0.8.0 started as a relatively simple idea:

"Let's add flight recording and playback."

Naturally, it got completely out of control.

The upcoming Air Traffic Recorder is an optional component.

It is disabled by default and does not replace the normal VRS X database.

The regular radar still uses its existing lightweight local database.

Recorder data is stored separately using:

PostgreSQL 16+ with TimescaleDB

The database can run:

• locally using Docker,
• on another machine,
• or on a remote PostgreSQL/TimescaleDB server.

If the Recorder database is unavailable, the normal live radar continues working.

Recorder failure should not take the radar down with it.


WHAT DOES THE RECORDER STORE?

The Recorder periodically samples aircraft telemetry.

The sampling interval is configurable, with approximately 15 seconds currently being a typical default.

Users can configure retention limits, including:

• time-based retention,
• and a hard maximum storage size.

Whichever limit is reached first wins.

TimescaleDB compression is also used for older chunks to reduce long-term storage requirements.


RECORDED FLIGHTS

The Recorder does not simply present millions of raw points.

Recorded observations are grouped into aircraft sessions and flights.

Users will be able to search historical flights by:

• callsign,
• registration,
• or ICAO hex.

Selecting a recorded flight opens a playback view including:

• historical track playback,
• altitude profile,
• ground speed profile,
• origin and destination information where available,
• and additional recorded telemetry.

Reception gaps can also be shown, but VRS X deliberately does not fabricate aircraft positions.

Estimated or unobserved sections are visually distinguished from actually recorded ADS-B data.


AND THEN I MADE THE MISTAKE OF ASKING A QUESTION

While building the Recorder I thought:

"If VRS X can see where an aircraft starts and where it finishes... why not let it recognize routes automatically?"

Well.

That question has consumed a significant amount of my free time since then.


AUTOMATIC ROUTE INFERENCE

VRS X 0.8.0 can analyze locally recorded traffic and automatically infer flight routes.

This does not simply mean:

Callsign = airport A -> airport B

The system gathers evidence from multiple independent recorded flights and calculates confidence for:

• origin airport,
• destination airport,
• the complete route,
• terminal proximity,
• surface observations,
• track-based observations,
• alternative airport candidates,
• and competing route observations.

A route is not submitted after seeing one aircraft once.

VRS X looks for repeated observations and builds a confidence model from them.


SURFACE-BACKED AND TRACK-BACKED EVIDENCE

Whenever possible, VRS X tries to confirm an airport using aircraft seen on or extremely close to the airport surface.

That is considered strong endpoint evidence.

But this is not always available.

Sometimes reception starts shortly after departure or disappears shortly before landing.

In those cases VRS X can also use track-based endpoint evidence, considering things such as:

• distance from the airport,
• aircraft altitude,
• radial movement,
• heading changes,
• and repeated observations across independent flights.

MULTIPLE ROUTES UNDER THE SAME CALLSIGN

This became more interesting very quickly.

A callsign does not necessarily correspond to one permanent route.

Some callsigns:

• operate different routes on different days,
• change routes when airline schedules change,
• or legitimately represent multiple route variants at the same time.

VRS X therefore needs to understand:

Callsign -> Route Variants

rather than assuming:

Callsign -> One Eternal Route

When several legitimate routes exist, VRS X can use the observed departure airport to select the appropriate route variant.

More complex ambiguity remains deliberately conservative and may require additional observations or manual review.


CONTINUED IN PART 3/3

[BrejSki]

PART 3/3 - MULTI-STOP, AUTO-APPROVAL, ACCURACY, PRIVACY AND ROADMAP

MULTI-STOP ROUTES

The route model also supports intermediate airports.

So instead of only storing:

A -> C

VRS X can represent:

A -> B -> C

This has already exposed some entertaining edge cases during testing.

For example, some cargo flights use the same callsign across several consecutive legs.

The system must distinguish a complete journey from its individual flight segments.

There is still work being done in this area, but that is exactly why 0.8.0 is still a development version.


ROUTE CHANGES OVER TIME

Routes are also not assumed to be permanent.

A callsign may operate one route today and something completely different next month.

VRS X therefore keeps track of recent observations and can identify situations where the currently observed traffic no longer matches an older approved route.

Those cases are deliberately treated more carefully and are not blindly allowed to overwrite existing route data.


CENTRAL ROUTE INFERENCE

Local VRS X installations perform the actual analysis of their Recorder data.

When a route reaches the required confidence level, VRS X can send a structured report to Central.

Importantly:

raw Recorder tracks are not uploaded with the route report.

Central receives the inferred result and supporting statistics rather than the complete recorded flight history.

Reports can include information such as:

• route candidate,
• independent observation count,
• local confidence,
• dominant support,
• alternative observations,
• surface-backed evidence,
• track-backed evidence,
• airport distance,
• runner-up airport confidence,
• and other inference diagnostics.

THE PROBLEM: IT WORKED BETTER THAN I EXPECTED

This is probably the funniest development problem I have had so far.

I originally expected automatic route recognition to need quite a lot of manual moderation.

Instead, it started producing thousands of very high-quality route candidates.

At one point I ended up with almost:

3,000 routes waiting for manual review.

That is not sustainable unless I suddenly hire a small army of moderators.

So Central now also has an automatic route approval policy.


AUTOMATIC APPROVAL

Clean route candidates can be automatically accepted when they satisfy strict consistency and conflict checks.

The current policy looks at things such as:

• minimum number of independent observations,
• high local route confidence,
• dominant weighted support,
• lack of alternative route evidence,
• lack of conflicts with approved route variants,
• airport endpoint sanity,
• route topology,
• temporal route changes,
• and ambiguity between competing variants.

Central confidence is still calculated and displayed for diagnostics, but it is no longer treated as a simple "probability that the route is correct".

During testing it became clear that low Central confidence often simply means that the supporting evidence is weaker, not that the route itself is wrong.


RANDOM AUDIT

Approximately 2% of otherwise automatically accepted routes are deliberately held back for random manual audit.

This gives me a continuous sample of routes that the automatic policy believes are safe.

It is essentially quality control for the quality control.


HOW ACCURATE IS IT?

This is where the results genuinely surprised me.

At the time of writing, the Central route database contains almost 8,000 unique routes.

Only around two dozen problematic records have been identified during development.

Even more importantly, most of those were not random route-inference failures.

They came from a few very specific bugs or reference-data issues.


EXAMPLE 1 - KPBI -> KDJT

Palm Beach International changed its ICAO identifier from KPBI to KDJT.

VRS X still had an older airport database, so some routes appeared to use the old identifier.

The route inference itself was correct.

The reference airport database simply needed to be updated.


EXAMPLE 2 - LFPG

Some flights involving Paris Charles de Gaulle were incorrectly associated with another Paris airport.

The cause turned out to be a CSV parsing bug.

An airport record containing commas inside a field caused columns to shift during import.

That parser has been corrected for 0.8.0.


EXAMPLE 3 - DUBLIN

Some Dublin traffic was being associated with EIAH instead of EIDW.

EIAH is a heliport located very close to Dublin Airport.

The inference engine was doing exactly what its candidate selection logic allowed it to do, but heliports should never have been considered valid candidates for scheduled airline route inference.

Airport candidate filtering has since been corrected.


EXAMPLE 4 - MULTI-LEG CALLSIGNS

Some apparent route errors turned out to be valid multi-leg flights.

For example, a callsign may operate:

A -> B

and then:

B -> C

using the same callsign.

If the intermediate stop is missed, the system may correctly identify the complete journey as:

A -> C

while still missing the intermediate leg.

That is not a wrong origin or destination, but it is an incomplete route topology, and 0.8.0 is being improved to recognize those cases correctly.


MANUAL VALIDATION

During development I have manually cross-checked hundreds of inferred routes against several external aviation data sources and against my own Recorder history.

The accuracy has been significantly better than I expected when I first designed the feature.

Even some candidates with relatively weak-looking evidence have turned out to be completely correct.

This is why the review system has gradually moved from:

"manually approve most things"

toward:

"automatically approve clean consensus, manually inspect exceptions".


MEDIUM AND LONGER ROUTES

Another surprise is that the same mechanism is starting to work well for longer flights.

Recent inferred routes have included traffic between Europe and Dubai, Iceland, Israel and other medium/long-haul destinations.

Long distance itself is not the primary problem.

The real problem is gaps in coverage.

This is why I am also experimenting with logical continuation detection between Recorder sessions.


LONG-GAP SESSION BRIDGING - EXPERIMENTAL

This feature is still experimental.

The idea is to identify situations where one aircraft disappears from coverage for several hours and later reappears somewhere else.

VRS X does not create synthetic positions inside the missing area.

Instead, it may create a logical relationship between two recorded sessions when the continuation is physically plausible.

The algorithm considers things such as:

• the same ICAO hex,
• stable callsign,
• airborne state,
• altitude,
• ground speed,
• great-circle distance,
• implied average speed during the gap,
• heading consistency,
• possible intermediate recorded sessions,
• and competing continuation candidates.

If several plausible continuations exist, the system refuses to guess.

Again:

no aircraft positions are invented inside the gap.


WHERE IS THIS GOING?

The most important long-term goal is reducing VRS X dependence on external route and aircraft data providers.

The Central Repository already distributes aircraft and route information back to VRS X installations.

Recorder-based route inference now allows the network to gradually build route knowledge from actual ADS-B observations.

This opens the door to much more interesting things later.


FUTURE IDEAS ENABLED BY THE RECORDER

These are not promises for 0.8.0, but the data now makes several ideas realistically possible.

For example:

• Airport connection-network visualization.
• Click an airport and display all observed destinations.
• Observed route frequency.
• Estimated weekly schedules based on repeated ADS-B observations.
• Typical departure and arrival time windows.
• Estimated aircraft type normally used on a specific route.
• Aircraft-type substitutions.
• Seasonal route detection.
• New route detection.
• Routes which have disappeared from the observed network.

The important word here is observed.

VRS X does not need to claim to know an airline's official schedule.

It can simply say:

"This is what the radar actually observed."

Statistics, heuristics and a slightly unreasonable amount of free time can apparently get surprisingly far.


PARTICIPATING IN FUTURE ROUTE CALCULATIONS

The long-term model is still being designed, but I want contribution and privacy to remain separate concepts.

A feeder should be able to contribute ADS-B observations to route calculations without being forced to expose their receiver publicly.

In other words, contributing traffic observations and publicly publishing a receiver feed do not have to be the same thing.

More details will come later when this mechanism is finalized.


WHAT COMES NEXT - VRS X 0.9.0

After 0.8.0 stabilizes, the current roadmap for 0.9.0 focuses mainly on personalized alerting.

Planned areas include:

• personalized aircraft alerts,
• flight alerts,
• SMTP notifications,
• and potentially additional notification channels such as Telegram.

The exact scope may still change depending on how much additional work 0.8.0 creates.

And considering the history of this project, that sentence is probably important.


VRS X 1.0.0 - PUBLIC RELEASE

VRS X 1.0.0 is planned to be the first fully public release.

My current target is still:

before the end of 2026.

I am deliberately calling this a target rather than a promise.

I would rather delay the public release than knowingly publish something unstable.

The important difference compared with the current Closed Beta is:

you will not need to be an ADS-B.Pro feeder simply to install and use VRS X 1.0.0.

The feeder requirement exists for the current testing stage, not as a permanent requirement for the software.


FREEWARE

VRS X is planned to remain freeware.

Commercial use of the application itself is allowed under the VRS X license, although the software itself may not simply be resold as somebody else's product.

The project still preserves the appropriate notices and licensing obligations inherited from the original Virtual Radar Server components where applicable.


AND FINALLY...

If you read all three parts:

Congratulations.

You now know why I did not want to write this update for several months.

VRS X has grown far beyond what I expected when I started the rewrite.

What began as:

"Let's modernize Virtual Radar Server a little."

has gradually turned into:

• a modern live radar,
• multi-feed and MLAT processing,
• coverage analysis,
• a community aircraft/operator/route database,
• historical traffic recording,
• flight playback,
• automatic route inference,
• route variants,
• multi-stop route analysis,
• and increasingly, an air traffic analytics platform.

There is still a lot of work ahead.

But the project is alive, development is active, the Closed Beta testers are keeping me busy, and 0.8.0 is becoming much larger than originally planned.

Thank you to everyone who has been testing VRS X, reporting bugs, feeding ADS-B.Pro, sending suggestions or simply following the project.

I really appreciate it.

More updates will follow.

Hopefully this time before another six months pass.


LINKS

• Project: https://vrsx.app
• Documentation: https://docs.vrsx.app
• Development radar: https://radar.vrsx.app
• ADS-B.Pro: https://ads-b.pro

[jon01]

Thank you for the updates

Looking forward to the full public release!

[BrejSki]

PROJECT INFRASTRUCTURE UPDATE — ADS-B.Pro, VRS X AND DOCUMENTATION


Hi everyone!

Another fairly large update, although this time it is not focused on a single VRS X release.

Over the last few weeks I have been rebuilding quite a lot of the infrastructure around the project itself.

The biggest change is that VRS X is no longer maintained as a separate standalone website. The old project website has effectively been absorbed into the main ADS-B.Pro website:

NEW WEBSITE

The idea is to keep the whole ecosystem in one place instead of maintaining several separate websites and documentation systems.

This now includes:

• VRS X project information
• Operator's Handbook
• installation and configuration documentation
• Closed Beta information
• development logs and release notes
• roadmap
• feeder documentation
• FAQ and general ADS-B.Pro documentation
• links to both live radars

The two separate BookStack documentation instances I was previously maintaining have also been retired and their content has been moved into the main website.

So instead of having project information spread across vrsx.app, separate documentation sites and ADS-B.Pro, the main entry point is now simply:

https://ads-b.pro

VRS X itself is still a self-hosted application and remains in Closed Beta for ADS-B.Pro feeders. RadarView remains the hosted/classic radar, while VRS X is the modern self-hosted side of the project.

There has also been a lot of work behind the scenes on the VRS X Central Repository. It now contains more than 448,000 aircraft, over 22,000 known routes and more than 6,000 operators, with route data being continuously learned from observed traffic rather than simply relying on a static timetable database.

I am also gradually expanding ADS-B.Pro beyond just ADS-B reception. I am currently experimenting with VDL2/ACARS and HFDL data, with the longer-term goal of correlating multiple aviation data sources with the existing route-recognition and traffic-recording systems.

This part is still very experimental, but the general direction is becoming much clearer: VRS X is slowly evolving from a modern Virtual Radar Server replacement into a wider aircraft-data and traffic-analysis platform.

Development logs are now available here:

https://ads-b.pro/devlogs/

And the current VRS X information/documentation can be reached directly from the main ADS-B.Pro website.

As usual, development is moving faster than I am writing forum posts about it.

Bruno