VedAstro: A C# Vedic Astrology Engine You Can Self-Host
A non-profit, open source project to make Vedic Astrology easily available to all.
At a glance
- What is it?
- VedAstro packages Swiss Ephemeris calculations behind a .NET library, a REST API, an MCP server and a Python wrapper, all under MIT. The hard part is not the math, it is deciding whether you want the prediction layer that ships with it.
- Who is it for?
- VedAstro fits teams that want Vedic astrology calculations inside software: the MIT licence, the NuGet and PyPI packages, and the documented Docker image give you a self-hosted path without writing ephemeris code. It does not fit anyone who needs a guaranteed accuracy figure or a maintained release cadence, because no releases were retrieved and the README argues accuracy through chart screenshots rather than error measurements.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 33 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What VedAstro Actually Computes, and for Whom
VedAstro is a C# project that turns Swiss Ephemeris planetary positions into Vedic astrology output. The README frames the audience in two halves. The first half is end users, who get hosted pages: Horoscope, Match Checker, Match Finder, Horary, Numerology, Birth Time Finder, Life Predictor and a daily Panchang page. The second half is developers, who get the same engine as a .NET library on NuGet, a Python package on PyPI, a REST API, a Docker image and an MCP server.
That split matters when you evaluate it. If you are building software, the interesting artifact is not the website. It is the calculation layer under Library/Logic/Calculate, which the README points at directly and describes as the place to learn the exact math and logic. The README also offers Library as the import point for building on top of the code. So the project presents itself as a computation engine with a product attached, not the other way round.
The stated motivation is non-profit and explicitly modelled on Parashara teaching astrology without asking money. That is a positioning claim, not a technical one, but it explains why the licence is MIT and why the API is public rather than gated behind a key tier described in the README.
The Data Flow: Swiss Ephemeris In, Named Bala Values Out
The clearest evidence of the architecture is the sample API response in the README, for the Sun on 30/06/2023 at Singapore. It is a flat payload of named fields, and the field names tell you what the engine does between input and output.
At the bottom of the stack sits SwissEphemeris, which the response exposes as a nested object with Longitude, Latitude, DistanceAU and speed components. Above that, the engine derives a large set of classical strength and placement values: ShadbalaPinda, SthanaBala, KalaBala, DigBala, ChestaBala, NaisargikaBala, DrikBala, OchchaBala, AyanaBala, PakshaBala, HoraBala, KendraBala, DrekkanaBala and SaptavargajaBala. Alongside those sit booleans and classifications: Exalted, Debilitated, Moolatrikona, Benefic, Malefic, InKendra, IsPlanetInOwnHouse, Motion, and lists such as TemporaryFriends, PlanetsInConjuction and SignsPlanetIsAspecting.
Divisional chart placements are present too: Navamsa, Drekkana, Dwadasamsa, Saptamsa, Thrimsamsa. Longitude appears in two frames, NirayanaLongitude and SayanaLongitude, each with both a DegreeMinuteSecond string and a TotalDegrees float. That dual representation is a practical detail: the string is for display, the float is for arithmetic, and the sample shows the ayanamsa offset between them (74.938 degrees nirayana against 97.672 sayana for the same body).
The README lists 200+ endpoints of this shape. The APIBuilder page is described as the way to compose calls, which suggests the API is generated from the same calculation catalogue rather than hand-written per endpoint.
Getting It Running: NuGet, pip, Docker and the MCP Endpoint
The README gives four concrete installation paths, and they are worth separating because they do not have the same depth.
The .NET route is a NuGet package named VedAstro.Library. For Python, the command is pip install VedAstro, and the package name on PyPI is also VedAstro. For self-hosting, the Docker image is published as vedastro/api on Docker Hub, and the README describes it as the way to self-host the full API stack. For AI clients, the MCP server lives at https://mcp.vedastro.org/api/mcp, with setup documented in Docs/MCPServer.MD and stated compatibility with Claude, Cursor, VS Code and any MCP client.
There is also a WordPress plugin for embedding widgets, and Android and iOS clients listed as separate clients rather than as libraries.
What the README does not give is a minimal code example for the .NET library, a Docker run command, or a pinned image tag. Anyone planning to depend on this should treat the NuGet package page and the Docker Hub tags as the authoritative source for versions, because the repository material here contains no release list and no version numbers at all. The same applies to the Python package: pip install VedAstro is documented, but the supported Python versions and the shape of the returned objects are not described in the README.
The Prediction Layer Is the Weakest Documented Part
VedAstro does not stop at positions. It ships a Life Predictor described as algorithmic prediction of a human life's past and future, a Match Checker using ten classical Kuta methods, a Horary module, and a Numerology module attributed to Mantra Shastra. The README's evidence for these is a row of chart screenshots under the heading Perfect Predictions, showing named public figures.
That is the section to be sceptical about. A screenshot of a chart rendered for a famous person is not a measurement of accuracy, and the word perfect in a heading is a claim, not a result. The README supplies no confusion matrix, no held-out evaluation, no statement of how many rules fire per prediction or how conflicting rules are resolved. If your use case depends on the prediction output rather than the raw calculations, you are adopting an opaque rule engine whose contents you would need to read in Library/Logic/Calculate to evaluate.
There is a second, subtler risk. The project publishes two Hugging Face datasets of 15,000 famous people, one with birth date, time and location, one with marriage and divorce information. The README does not state where the birth times came from or how uncertain ones were handled. Birth time is the dominant error source in any chart calculation, and a dataset that does not document its time provenance is hard to use for anything that depends on ascendant or house placement. The Birth Time Finder tool exists precisely because birth times are often unknown, which makes the silence on dataset provenance more noticeable, not less.
Where VedAstro Is the Wrong Tool
If you need Western tropical astrology, this is not your library. The engine is built around nirayana (sidereal) longitudes and Vedic strength systems, and the README's entire vocabulary is Vedic: Kuta matching, Panchang, Shadbala, divisional charts. SayanaLongitude is exposed, so the tropical value is available, but the derived layers around it are not neutral between traditions.
If you need a stable, versioned API contract, the absence of any release information in the supplied material is a real problem. There are no retrieved releases, and the README documents endpoints by example rather than by schema. A response field could be renamed between deployments and you would find out from a broken parser.
If you need a language other than C# or Python, you are limited to calling the REST API or the MCP server over the network. There is no documented JavaScript client, Go binding or Java port. The JavaScript demo files referenced in the README are demo files, not a published package.
And if you need the project to justify its predictions to a reviewer, it cannot, on the material available. The accuracy argument is presented visually and anecdotally. That is a legitimate choice for a non-profit devotional project and a disqualifying one for a regulated or audited context.
Alternatives and the Actual Difference in Approach
The obvious comparison is Swiss Ephemeris itself, which VedAstro uses as its planetary calculation backend. Swiss Ephemeris gives you positions, speeds and house cusps across multiple house systems, with a documented accuracy specification and a long version history. What it does not give you is the Vedic interpretive layer: Shadbala, the divisional charts, Kuta matching, Panchang. Choosing between them is choosing between a computation primitive with a specification and an application framework with a tradition baked in.
A second comparison is the Python astrology ecosystem, where libraries wrap the same ephemeris and expose chart objects in Python idioms. Those tend to be tropical-first and Western in their house and aspect conventions. VedAstro's Python package is a wrapper over a C# service, which means the Python side is a client, not a reimplementation. If you want to read and modify the calculation code, you will be reading C# regardless of which language you call it from.
The third comparison is building your own rules on top of a raw ephemeris. That is what VedAstro has already done, and the Library/Logic/Calculate directory is the artifact that decides whether reusing their work saves you time. If your rules differ from theirs, you inherit a large codebase you must edit rather than a small dependency you can replace.
Maintenance, Licence and What to Check Before You Commit
The licence is MIT. That permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. It offers no patent grant and no warranty, and it does not cover the Swiss Ephemeris data files or any third-party assets the project bundles. Whether your use of the ephemeris data triggers separate obligations is a question for your own counsel, not something this review can settle.
The repository is not archived, and the last push recorded is 2026-08-13, so the project is active at the time of writing. But no releases were retrieved, which means there is no published changelog to read and no version tag to pin against in the material available. For a service you self-host, that changes your upgrade process: you cannot diff release notes, so you would track commits or pin a Docker image digest instead.
The maintenance surface is wide. The project ships a website, an API, an MCP server, a WordPress plugin, mobile clients, two NuGet and PyPI packages and two Hugging Face datasets. A non-profit project carrying that many surfaces has many places for a specific tool to fall behind while the rest keeps moving.
So verify three things first. Open Library/Logic/Calculate and confirm the exact calculation you need is implemented, not approximated. Pull the vedastro/api image and check that the tag you intend to pin still exists. And call https://mcp.vedastro.org/api/mcp from your client to confirm the tool list matches what Docs/MCPServer.MD describes. Those three checks answer most of the adoption question without writing any astrology code.
Editorial conclusion
VedAstro fits teams that want Vedic astrology calculations inside software: the MIT licence, the NuGet and PyPI packages, and the documented Docker image give you a self-hosted path without writing ephemeris code. It does not fit anyone who needs a guaranteed accuracy figure or a maintained release cadence, because no releases were retrieved and the README argues accuracy through chart screenshots rather than error measurements. Before adopting, verify three things against the repository: that Library/Logic/Calculate contains the specific calculation you need, that the Docker image tag you plan to pin is still published, and that the MCP server at mcp.vedastro.org/api/mcp returns results for your client. If the prediction layer is what you actually want, check whether the project exposes its rule set as data or only as compiled C#.
Community notes