DEV Community: Xalen Technologies

Compute astrology charts in the browser: no node-gyp, no .se1 files, no AGPL

Xalen Technologies — Thu, 25 Jun 2026 06:59:03 +0000

If you've wired Swiss Ephemeris into a Node astrology app, you know the ritual. You npm install sweph, and now every machine needs Python plus a C/C++ toolchain, because the package compiles Swiss's C code via node-gyp at install time (make/gcc on Linux, Xcode on macOS, Visual C++ Build Tools on Windows).

It works on your laptop. Then it explodes:

Apple Silicon: node-gyp can't find full Xcode behind Command Line Tools.
Slim Docker / CI images: no Python, no build-essential, so the install dies.
Serverless: the .node binary you built locally won't load on Amazon Linux (wrong arch or glibc).

Then there's the data. Neither sweph nor swisseph bundles the .se1 ephemeris files; you download them yourself and point the library at a path. The modern set is 2 MB, the full GitHub set is 100 MB. And since 2.10.1, sweph is AGPL-3.0 (LGPL only under a professional license), a real obligation to weigh for a closed-source SaaS backend.

The pure-Rust alternative

XALEN Ephemeris is an analytical engine written entirely in Rust and licensed Apache-2.0. Three things make it interesting for JS/TS devs:

No node-gyp. The Node addon is napi-rs, which ships prebuilt per-platform binaries via npm. No Python, no C compiler, no compile step.
A real WASM build via wasm-bindgen, so you compute charts client-side in the browser: no server round-trip, no backend copyleft.
Zero data files. The core math (VSOP87A, ELP2000-82, IAU precession/nutation, an 8,870-star catalog) is analytical and compiled into the binary. No .se1 to host.

import init, * as xalen from "xalen-ephemeris"; // WASM build, runs in the browser
await init(); // load the .wasm module
const chart = xalen.computeChart({ datetime: "1990-04-12T08:30:00Z", lat: 28.6, lon: 77.2 });
console.log(chart); // planet longitudes, house cusps, etc.

	Swiss via Node	XALEN (pure Rust)
Build deps	node-gyp + Python + C compiler	none: prebuilt binary / `.wasm`
Runtime data	`.se1` files (2 to 100 MB)	none, compiled in
Browser / WASM	possible via Emscripten	native wasm-bindgen
License	AGPL-3.0 / professional	Apache-2.0

To be fair, Swiss can be compiled to WASM (Emscripten ports exist, and its built-in Moshier mode is file-free). So the honest edge isn't capability, it's delivery: pure Rust straight to WASM, with no Emscripten/MEMFS shim and no data files to bundle.

Honest caveat: XALEN is young and not on npm or PyPI yet (crates.io currently serves an older 0.3.1 line). Today this is a watch-and-prototype story, not a drop-it-into-prod one.

Repo: github.com/vedika-io/xalen-ephemeris. Would you ship ephemeris math to the client, or is server-side non-negotiable for you?

Swiss Ephemeris Returns 6 Floats. Your App Needs a Chart.

Xalen Technologies — Mon, 22 Jun 2026 17:46:49 +0000

Every astrology backend on earth runs on Swiss Ephemeris. It is accurate to the arcsecond and has earned three decades of trust. Now look at what it hands back.

import swisseph as swe
xx, ret = swe.calc_ut(jd, swe.MOON, swe.FLG_SIDEREAL)
moon_lon = xx[0]   # (281.43, -4.21, 0.0026, 13.17, 0.58, -0.00003)

Six floats. Position and speed. That is the entire API for a body, and it is where Swiss stops and your real work begins.

Swiss computes positions, not astrology

There is no nakshatra function. No dasha engine. No panchang, no divisional charts, no shadbala, no KP, no yogas. pyswisseph inherits the same surface,because it is a binding, not a new library. So every team rebuilds the same thousands of lines on top of xx[0]:

# YOU write the nakshatra, the pada, the rashi,
# the Vimshottari dasha balance, the tithi/yoga/karana,
# the shadbala, the D-9, the D-10... none ships with Swiss.

Then you hand-roll it all into JSON, because Swiss returns C double[6] arrays.

What "returns a chart" looks like

XALEN Ephemeris is a pure-Rust,Apache-2.0 ephemeris that treats the interpretive layer as part of the library.
The same Moon longitude is the input to functions that already exist:

let nak      = Nakshatra::from_longitude_deg(moon_sid);
let rashi    = Rashi::from_longitude_deg(moon_sid);
let panchang = compute_panchang(sun_sid, moon_sid, jd.as_f64());
let dashas   = vimshottari_dasha(moon_sid, jd.as_f64(),              DashaLevel::Antardasha);

That is the real API from examples/vedic_chart.rs. And every public type derives serde, so the JSON problem vanishes:

let body = serde_json::to_string(&panchang)?;
It even renders the literal chart. Swiss hands you six floats; XALEN hands you an SVG:

rust
let svg = render_north_indian(&chart);



On top of that: 50 ayanamsa systems, 23 house systems, Western aspects and
dignities, plus BaZi, Saju, Mayan, and I-Ching. None of it present in Swiss.

## And the math holds up

Positions are measured against **JPL Horizons DE440**, the same reference Swiss reads, reproducible from the test suite (`cargo test --workspace`, 2,199 passing):

- Sun: **0.21 arcsec**
- Mercury through Saturn: **under 0.76 arcsec**, zero data files (VSOP87A compiled in)
- Moon: RMS ~2.8 arcsec analytically, sub-arcsecond with the optional DE440 kernel

So you keep JPL-class positions and get the layer Swiss made you build yourself.

## The point

The question was never "is Swiss accurate." It is. The question is how much of your codebase exists only because Swiss stopped at a `double[6]` and left the chart to you. There is now a library that already wrote that part.

> Availability note: XALEN's crates.io, PyPI, and npm packages are not all
> published yet. Today you build from source; the claims above are reproducible
> from the repo right now. Star it to catch the release.

**github.com/vedika-io/xalen-ephemeris**

You're One Audit Away From Open-Sourcing Your Astrology App

Xalen Technologies — Mon, 08 Jun 2026 09:10:13 +0000

"Almost every horoscope app on earth links Swiss Ephemeris. Alm
ost none of them have read its license. Here's the clause that can force you
to open-source your entire backend, and the pure-Rust, Apache-2.0 way out."
tags: opensource, legal, rust, startups

Your Astrology SaaS Is an AGPL Time Bomb

Here's how your astrology app was probably born.

It needed planetary positions. A search for "ephemeris library" led, like every
road does, to Swiss Ephemeris, the C library from Astrodienst that astro.com
itself runs on. So pip install pyswisseph, a call to swe.calc_ut(), the Moon comes back in the right place, and it ships.

Nobody opened the license.

So let's open it, because the clause sitting inside it can legally obligate you to publish the complete source code of your entire backend to every user who hits your API. And a closed-source product running on pyswisseph right now is
already in violation.

The two-line version

Swiss Ephemeris is dual-licensed:

AGPL-3.0, free, but copyleft with a network clause, or
A paid commercial license from Astrodienst.

There is no third door. Without the commercial license, you took the AGPL.Using the software accepted its terms. Most people building on Swiss don't know they made that choice, but they made it.

The clause that eats your business: AGPL Section 13

The regular GPL has a famous loophole for SaaS: copyleft triggers on
distribution, and running software on your own server for users to access over a network is not distribution. That's how Google runs GPL code internally without publishing anything. It's sometimes called the "ASP loophole."

The A in AGPL exists for the sole purpose of slamming that loophole shut.
Here's the actual operative language from Section 13:

"...if you modify the Program, your modified version must prominently offer
all users interacting with it remotely through a computer network ... an
opportunity to receive the Corresponding Source of your version..."

Read that again with your product in mind. "All users interacting with it remotely through a computer network" is a precise description of every web astrology app ever built. Users hit your endpoint. Your endpoint computes a chart using Swiss Ephemeris. Section 13 says those users are entitled to your Corresponding Source, and "Corresponding Source" is defined broadly enough to reach the code wrapped around the library.

This is not a theoretical edge case. It is the designed, intended behavior of the license. The AGPL is working exactly as specified when it does this to you.

"But it's just being called, not modified"

This is the rationalization everyone reaches for, so let's kill it.

pyswisseph is not a separate thing. It's a thin C-extension wrapper that links libswe directly. It inherits Swiss Ephemeris's license wholesale: the pyswisseph project says so itself. import swisseph is import AGPL. There is no Python-shaped escape hatch.
And the "it wasn't modified" defense is thinner than it feels:

The FSF's own position is that linking creates a combined work. Whether your service is a "modified version" or a "work based on the Program" under the AGPL is exactly the kind of question you do not want a lawyer answering for the first time during due diligence on your acquisition.
Even on the most charitable reading, the whole company is now riding on a copyleft-boundary argument. That's not a foundation. That's a fault line.

The honest summary Astrodienst themselves push you toward: a service that isn't open-sourced needs the commercial license. That's the whole reason the commercial license exists. They are not selling it for fun. They are selling it to the exact people reading this post.

When the bomb actually goes off

AGPL violations rarely blow up on day one. They blow up at the worst possible moment, because that's when someone finally reads the dependency manifest:

Fundraising / acquisition due diligence. The acquirer's legal team runs a license scan. AGPL-3.0 lights up red next to your core IP. The deal stalls while you scramble to either rip out the dependency or back-pay a commercial license. This exact scenario has tanked timelines.
An enterprise customer's security review. Big-co procurement runs an SCA(software composition analysis) tool. AGPL is on their banned-license list, and it is on most corporate banned lists, precisely because of Section 13. Your deal is now blocked on a license remediation that can't happen overnight.
A competitor or a disgruntled user files a complaint. Now the choice is between publishing your crown jewels and writing Astrodienst a check sized by someone who knows you have no leverage.

The cost of an AGPL dependency isn't zero just because nobody's invoiced
you yet.It's a contingent liability sitting on your balance sheet, and it comes due exactly when you can least afford it.

The way out: same accuracy, sane license

For thirty years the trade-off was brutal and unspoken: the only JPL-accurate ephemeris was AGPL/commercial C. The permissive alternatives (astro,practical-astronomy-rust on crates.io) are lovely little textbook crates:arcminute-grade, astronomy-only, no astrology layer. So everyone held their nose and took the AGPL, because there was no other accurate option.

There is now. It's called XALEN Ephemeris, and it's Apache-2.0.

Apache-2.0 is the opposite of AGPL in every way that matters here:

	AGPL-3.0 (Swiss)	Apache-2.0 (XALEN)
Use in closed-source SaaS	triggers Section 13	yes
Per-deployment / commercial fee	or open everything	none
Network/copyleft clause	yes	none
Patent grant	no	explicit
Obligation	Publish your source	Keep the attribution notice

Ship it in a closed-source product, keep the source private, and the only duty is to preserve the license notice. That's the entire deal.

And there's no accuracy tax

The catch with "permissive ephemeris" used to be that permissive meant
inaccurate. Not here. XALEN's numbers are reproducible from its own test suite(cargo test --workspace, 2,199 passing), measured against JPL Horizons DE440, the same reference Swiss reads:

Sun: 0.21″
Mercury–Saturn: ≤ 0.76″, with zero data files (VSOP87A compiled in)
Moon: RMS ~2.8″ analytically; sub-arcsecond with the optional DE440 kernel
5,000,000-chart diff vs Swiss Ephemeris: 0 charts off by more than 0.1°

And because it's pure Rust with zero unsafe in the computation core, no process-global state, and a Send + Sync engine, Swiss's other two headaches go away too: the .se1 data files you have to ship and the global swe_set_*state you have to mutex. But honestly? Even if XALEN were only "Swiss accuracy with a license that doesn't threaten your company," that would be enough to switch.

XALEN ships a Swiss-compatible shim specifically to make door #3 cheap: a
swe_calc_ut(jd, SE_SUN, ...) surface with the same xx[0..6] array semantics already in your code, so migration is closer to search-and-replace than rewrite.

The AGPL clause has been sitting in your stack this whole time. It didn't go off because nobody looked, not because it's safe. Look now, while looking is cheap.

→ *github.com/vedika-io/xalen-ephemeris

Stop shipping a 1990s C library to compute planets. Xalen is the pure-Rust, Apache-2.0 replacement for Swiss Ephemeris.

Xalen Technologies — Wed, 03 Jun 2026 12:39:10 +0000

Stop shipping a 1990s C library to compute planets. Xalen is the pure-Rust, Apache-2.0 replacement for Swiss Ephemeris.

If your app does astrology, you already know the dependency. Swiss Ephemeris: a C library from the 1990s, a folder of binary .se1 data files you have to ship and locate at runtime, and a license that is either AGPL or you pay for a commercial seat. For 30 years it was the only serious option, so everyone just swallowed the cost.

That era is over. Xalen Ephemeris is a full planetary engine written in pure Rust, with no unsafe in the core engine (the only unsafe lives in the optional FFI, Node and WASM binding crates), released under Apache-2.0. No C toolchain. No data files to ship. No copyleft clause waiting for the day you try to make money. It is built to replace Swiss Ephemeris in production, not to admire it from a distance.

Python is live on PyPI and the Rust crates are live on crates.io:

# Python
pip install xalen

# Rust
cargo add xalen-ephem xalen-time xalen-ayanamsa xalen-vedic

Node and WASM build straight from the repo. Repo: https://github.com/vedika-io/xalen-ephemeris

Switching takes one line

Xalen ships a pyswisseph-shaped API on purpose. Migrating an existing codebase is a find-and-replace:

# before
import swisseph as swe
# after
import xalen.swe as swe

jd = swe.julday(1990, 6, 15, 10.5)
xx, ok = swe.calc_ut(jd, swe.SUN, swe.FLG_SWIEPH | swe.FLG_SPEED)
# same argument order, same SE_/SEFLG_/SIDM_ constants, same tuple layout

Your function calls do not change. Your data-file directory disappears. Your license problem disappears.

Xalen vs Swiss Ephemeris

Line them up and the gap is hard to miss. Swiss Ephemeris is C from the 1990s, shipped as a native library you compile and link, fed by .se1 data files you have to bundle and locate at runtime, under AGPL or a paid commercial license. Xalen is pure Rust with no unsafe in the core engine, thread-safe, with no native dependency and no data files for the analytical engine (the DE440 kernel is optional), under permissive Apache-2.0. Swiss reaches other languages through third-party wrappers; Xalen targets Rust, Python, C and C++, Node and WASM from one core. On accuracy both track JPL DE, and Xalen matches DE440 to sub-arcsecond on the inner planets with the kernel available for full precision. Swiss gives you positions, houses and ayanamsa and stops there; Xalen ships the entire astrology layer on top, renders charts to SVG, geocodes 130+ cities and localizes into 19 languages. And switching is one line: import xalen.swe as swe.

The part nobody else ships

This is where the comparison stops being close. A raw ephemeris, JPL's or Swiss's, hands you coordinates. Then you spend the next two years building the astrology yourself. Xalen ships that layer, for the whole world, in the box:

India / Vedic (Jyotish). Vimshottari and other dashas, 16 divisional charts (vargas), full panchang with tithi, nakshatra, yoga and karana transition times, shadbala, KP, Jaimini, Tajaka annual charts, yogas, doshas, and compatibility. Plus Lal Kitab remedial astrology.

Western. Aspects, essential and accidental dignities, 97 Arabic Lots, Hellenistic and Uranian techniques, Cosmobiology, secondary progressions, exact solar and lunar returns by iterative refinement, declination aspects and antiscia, harmonics, and horary.

China. BaZi Four Pillars, Zi Wei Dou Shu, Feng Shui Flying Stars, and Qi Men Dun Jia (experimental).

The rest of the world. Korean Saju, Japanese Nine Star Ki, Burmese Mahabote, Mayan and Aztec calendars, Tibetan, Persian/Zoroastrian, Egyptian, and Celtic systems. I Ching with all 64 hexagrams and the full 384 line texts. Pythagorean and Chaldean numerology (Life Path, Expression, Soul Urge).

And the astronomy a serious engine needs. 50 ayanamsa systems and 23 house systems. A rigorous solar and lunar eclipse engine with Besselian elements and per-observer local circumstances, validated against NASA for 2017 and 2024. 506 built-in fixed stars plus 8,870 compiled-in Hipparcos stars and the full 118,218-star catalog loadable at runtime. Black Moon Lilith (mean and true), Chiron, nodes, and 15 asteroids and TNOs. Velocity and retrograde flags, topocentric positions, and RA/Dec, heliocentric and rectangular output. Real time systems: UT1/TT/TDB, the full leap-second table, and a Stephenson-Morrison-Hohenkerk delta-T spline. SVG chart rendering (North Indian, South Indian, Western wheel) with zero dependencies, 130+ city geocoding, and names in 19 languages.

Swiss Ephemeris gives you the math and stops. JPL gives you the coordinates and stops. Xalen gives you all of it, from one Apache-2.0 engine, with Rust, Python, Node, WASM and C bindings. A few of these are flagged experimental in the docs, and they are labelled honestly rather than hidden.

The accuracy is not a vibe, it is a number

Most libraries ask you to trust them. Xalen hands you the receipts, in two layers. The first is a reproducible 5,000,000-chart consistency sweep: random (date, lat, lon) charts spanning the years 1500 to 2400, every one diffed against a Swiss Ephemeris (pyswisseph) oracle for every body, the house cusps, and four ayanamsas. The harness is in the repo and it is deterministic, so you can reproduce the entire run yourself:

python3 validation/oracle_pyswisseph.py --n 5000000 --seed 42 \
  | cargo run -p xalen-validation --release -- -

One honest note on that sweep: the oracle is pyswisseph, and without Swiss or JPL data files (.se1 / .bsp) it falls back to the analytic Moshier theory, so by default it measures analytic-against-analytic agreement. The harness prints exactly which backend it used; point it at the data files for a true Swiss-backed comparison.

The headline accuracy comes from the second layer: a committed cross-validation against JPL Horizons vectors, run with cargo test. Against DE440, the Sun lands at 0.21 arcsec and Mercury through Saturn stay under 0.76 arcsec. Uranus and Neptune sit at 1.8 to 2.5 arcsec. The analytical Moon holds an RMS near 2.8 arcsec, and loading the optional DE440 kernel takes the Sun, planets and Moon sub-arcsecond with full-range Pluto. Every figure is per-body and reproducible. The full breakdown is in docs/ACCURACY.md.

This is the point worth sitting with: a pure-Rust engine with zero data files matches the gold-standard NASA DE440 ephemeris to a fraction of an arcsecond on the inner planets, and backs it with a reproducible five-million-chart consistency sweep on top. You do not have to choose between "clean dependency" and "correct."

A clean-room engine, not a wrapper

Xalen is an independent, clean-room implementation, not affiliated with Astrodienst. It is built directly from the published theories the whole field relies on: VSOP87, ELP-2000/82, IAU 2006 precession with 2000B nutation, and the Stephenson, Morrison and Hohenkerk delta-T model, with JPL DE440 as an optional high-precision kernel. It is cross-checked against Swiss Ephemeris because that is the honest way to prove a replacement, not because a single line of it is borrowed.

Where it stands today

This is a launch, and the engine is ready for real work.

If you have ever fought the Swiss Ephemeris C build, hunted for a missing .se1 file in production, or had a licensing conversation you did not enjoy, Xalen is the exit. Star it, fork it, and put it head to head with whatever you trust:

https://github.com/vedika-io/xalen-ephemeris

Try to break it. Open an issue with a chart Xalen gets wrong against your reference. Out of five million, the next interesting failure is the one you find.

Xalen is a computation engine. Any astrological interpretation built on top of it is for informational and cultural purposes, not professional advice.