Skip to content

Architecture

How the product is put together

ASTROLAB is one Digital Mission Engineering product: a shared mission model, the same families of assets and analyses, and the same loop of configure → run → inspect on Desktop and Web.

This page is the map of that product. Flight-dynamics assumptions live in Flight dynamics. ISL dump/command routing assumptions live in Contact Graph Routing. Independent code-to-code checks live in Independent verification. Plan limits live in Plans and entitlements. Binding trial terms live in Legal. Day-to-day clicks live in the User manual.

Open Web App

What you work with

You do not operate a separate engine console. You edit a mission, apply changes, run a study, and read Design plus Dashboard.

flowchart LR
  Assets["Assets"] --> Mission["Mission"]
  Scenario["Scenario"] --> Mission
  Mission --> Analyses["Analyses"]
  Analyses --> Design["Design — 3D / 2D"]
  Analyses --> Dash["Dashboard — plots and reports"]
Piece Role
Scenario Time window, central body, environment (optical / RF)
Assets Spacecraft, facilities, sensors, RF, power, AOIs, vehicles, constellations — the Mission Tree
Analyses Studies you Run (coverage, link, connection network, routing, latency, power, lifetime, station keeping)
Design Live globe and map — geometry, overlays, playback
Dashboard Plots and tables from a completed run (does not recompute physics)

The same ideas exist on both hosts. Layout differs: Web is a three-column Design workspace in the browser; Desktop is native Mission Tree, Properties, and Mission Viewer windows. Side by side: Platforms.

One core, two hosts

ASTROLAB is not “web-only SaaS” with a separate desktop clone. Desktop and Web share the Python mission core (src/astrolab), the .astrolab document, Orekit, and the analysis catalogue. What changes is where the process runs and where the file is stored.

flowchart TB
  Core["Shared core<br/>mission document · assets · analyses · Orekit · 3D / 2D"]
  Core --> Desktop["Desktop<br/>local process · file on disk"]
  Core --> Web["Web<br/>browser UI · cloud API · cloud mission"]
Desktop Web
How you open it Native application Browser — astrolab.stellor.space
Sign-in Local workspace Account (Supabase Auth). Trial or a plan
Where the mission lives .astrolab on disk Cloud library for the signed-in account, plus .astrolab import / export
Where analyses run On your machine STELLOR cloud (api.stellor.space)
Plans Local use; Web quotas apply if you also use the cloud library Trial / Basic / Pro / Enterprise

Move work with Export / Import of .astrolab. Do not copy raw JSON by hand. Feature gaps that remain in Beta: Desktop vs web.

Web topology

The hosted product splits presentation, identity, and compute. The browser never runs Orekit. Static UI is served from the edge; the signed-in session talks to STELLOR’s API; that API loads the mission and runs physics.

flowchart LR
  User["Browser"] --> Edge["Presentation<br/>Vercel · astrolab.stellor.space"]
  Edge --> API["Compute API<br/>Hetzner · api.stellor.space"]
  Edge --> Auth["Identity and account<br/>Supabase Auth"]
  API --> Auth
  API --> Disk["Mission files and results<br/>EU volume, per account"]
  API --> Orekit["Orekit<br/>in the API process"]
Layer What it actually does What it does not do
Presentation (Vercel) Serves the Web app at astrolab.stellor.space. HTTPS to the browser. Does not store missions. Does not run coverage, link, or lifetime.
Identity (Supabase) Sign-up, sign-in, JWT. Account row (profiles: plan, trial window). Clickwrap evidence (legal_acceptances). Does not hold the mission JSON or analysis blobs.
Compute (Hetzner, Germany) FastAPI + the ASTROLAB core. Orbit, access, and every Run Analysis. Nginx terminates TLS for api.stellor.space. Is not a flight operations centre. Is not a separate “Orekit SaaS” with a public dynamics API.

A typical Web study looks like this:

sequenceDiagram
  participant B as Browser
  participant V as Vercel UI
  participant S as Supabase Auth
  participant A as API Germany
  B->>V: Open Design
  V->>S: Session / JWT
  B->>A: Apply Changes / Run Analysis (JWT)
  A->>A: Load mission · Orekit · write results
  A-->>B: Scene / Dashboard payload

You stay in one workspace. Apply Changes updates the mission and the scene. Run Analysis computes on the API. Dashboard only plots what that run already stored.

Where Web data lives

Two stores, on purpose. Mixing them is the usual source of “the database has my ephemeris” claims — it does not.

Data Where Isolation
Email, plan, trial / subscription window Supabase profiles (EU project) Row Level Security: an authenticated user reads their row
Clickwrap (version, UTC time, SHA-256 of the legal pack) Supabase legal_acceptances Same: insert/read own rows; no client update or delete
Mission document, analysis results, trajectory sidecars Disk on the compute host, under the account id Path per user; the API checks the JWT before read or write
Globe tiles used by the scene Compute host (not in git) Shared read-only assets, not customer IP

Customer mission content stays in the EU compute volume. STELLOR does not use that content to train AI models. You keep ownership of designs and reports; STELLOR keeps the software. Binding text: Legal and evaluation terms. Re-read what you accepted in Engineering Portal → Preferences.

The public SaaS is not an ITAR or EAR enclave. Do not upload defence-restricted technical data there. A dedicated server, an on-premises Web deployment, or a Desktop licence is a separate written contract, not a switch in Trial.

Flight dynamics kernel

Orbits, access, atmosphere, and long-horizon decay are physics models inside the same product, not a hidden second application. The kernel is Orekit (baseline 13.1 in this Beta). You pick propagator family, gravity, drag, SRP, and third bodies in the spacecraft editor; you never call an Orekit API as an end user.

Numerical LEO versus GMAT 2026a (gravity, then drag, Sun/Moon, and spherical SRP) is recorded under Independent verification. That page is verification against another implementation — not flight validation, and not a certification.

Plans (Web)

How large a mission may be, which analysis options are on, and how fine a grid you may run are plan limits. When you hit one, the app asks you to upgrade. The published matrix is generated from the same catalogue the product uses: Plans and entitlements.

Trial is fifteen days, no card, one cloud mission, a 24 h scenario maximum, and the Trial column of that matrix. Analyses run one at a time on every plan in this Beta.

Enterprise is contracted separately. Delivery is a Desktop licence (requested apart from Web), the Web workspace on the customer's own servers, or a dedicated server sized for the number of users.

What this is not

ASTROLAB is a system-level design and analysis environment.

  • It is not a flight operations control centre.
  • It is not CAD or mechanical design.
  • Dashboard is not a live digital twin: it plots a finished run.
  • Provider certifications (SOC, ISO on Vercel, Supabase, or Hetzner) are those vendors’ attestations for their infrastructure. They are not an ASTROLAB product certification.