SpaceX's FCC filing describes datacenter satellites in two kinds of orbit, and you can show either or both here. They are not interchangeable — they trade power against coverage in opposite ways.

Sun-synchronous (the constant-power shell)

"Sun-synchronous" is whatever near-polar, slightly retrograde inclination (about 97.6° at 550 km, rising with altitude) makes the orbit plane precess once per year so it holds a fixed angle to the Sun. Parked along the day/night terminator — the dawn–dusk configuration — such a satellite is sunlit for most of the year, falling into Earth's shadow on each orbit only during a roughly three-month season around the northern-summer (June) solstice. That near-constant power suits steady, around-the-clock compute. From the ground it shows up as a roughly north–south arc, and only during your own dawn and dusk, because that is when its plane is above your horizon while your sky is dark.

30° inclination (the peaking shell)

A 30° orbit stays within ±30° latitude and does not track the Sun, so each satellite passes through Earth's shadow on part of every orbit — its power comes and goes. In exchange it is far cheaper to launch into, can be packed in enormous numbers, and concentrates over the populated low and mid latitudes; the filing frames it as capacity for demand peaks. Crucially, its visibility depends on your latitude: within ±30° (the tropics) the satellites pass directly overhead across the whole sky; toward higher latitudes they sit lower in the equator-facing sky; and a 550 km satellite never rises at all above about 53° latitude (a 2,000 km one, above about 70°).

Try the same date and time from Quito (overhead passes) versus Ithaca (a low southern band) versus Fairbanks (little or nothing) to see the latitude dependence directly.

The display shows the real night sky for your location, date and time — about 8,400 catalogue stars, the visible planets, and the Moon with its correct phase — with the datacenter swarms overlaid. The two shells are tinted differently only so you can tell them apart: warm white for sun-synchronous, cool blue for the 30° shell (the real satellites would all look the same near-white).

• Each shell has its own on/off switch, satellite count, and altitude, so you can compare them or stack them.
• Satellite size (in megawatts of compute) is shared by both shells and drives both brightness and angular size.
• Run in real time or up to 100×; switch between an all-sky fisheye and a horizon panorama; and jump to the next dusk or dawn.

Both shells are propagated as circular orbits at the altitude you set, with a proper cylindrical Earth-shadow test deciding whether each satellite is sunlit, and full topocentric geometry converting positions to your local altitude/azimuth.

Sun-synchronous shell

• Modeled as a real sun-synchronous orbit: a single plane at the fixed sun-synchronous inclination for its altitude (~97.6° at 550 km), with its ascending node held at the dawn–dusk local time and tracking the Sun through the year — the orientation a real spacecraft maintains via J2 nodal precession (~0.99°/day). Because the inclination is fixed rather than pinned to the Sun, the plane aligns most closely with the terminator near the equinoxes (off by ~8°) and deviates most near the solstices (up to ~30°). When that deviation is large enough (beyond ~23° at 550 km), part of the shell passes through Earth's shadow on every orbit. At this altitude that happens only around the June solstice — a season of roughly three months (about early May to early August), during which, at its peak, a satellite spends on the order of 20 minutes of each ~95-minute orbit eclipsed. The northern and southern solstices are not symmetric: the retrograde sun-synchronous inclination tilts the plane ~31° off the terminator at the June solstice but only ~16° at the December solstice, so at 550 km there is no December eclipse season at all. The status readout flags the season while it is active.
• Satellites are spread evenly in phase around that one plane, so they fall on a single arc. A real deployment would use several neighboring planes and read as a narrow band rather than a hairline; the single plane is the simplification here.

30° shell

• This shell genuinely fills space, so it is scattered across its full freedom: satellites are distributed over all orbital-plane orientations (the full 360° of ascending-node longitude) and all phases, using a two-dimensional low-discrepancy (Halton) sequence so the plane and the starting phase stay independent and the coverage is even at any count. Their sub-satellite points therefore sweep the entire 60°-wide band from 30°S to 30°N at every longitude, instead of tracing one circle.
• Because the 30° planes do not track the Sun, these satellites pass in and out of Earth's shadow each orbit — you will see them wink out — exactly the intermittency that makes this shell a "peaking" rather than constant-power layer.

Common simplifications

• No real two-line elements or SGP4 — these are idealized circles, not tracked hardware, and will not tell you where any actual satellite is.
• Orbital-plane precession from Earth's oblateness (J2) is not modeled within a session; over minutes to hours that is negligible, over weeks it is not.
• At very high counts (tens of thousands per shell) the frame rate will drop — the satellite count is honest, the geometry exact, only the rendering is heavy.

Apparent magnitude is anchored to the peer-reviewed estimate by Marcy (MNRAS, 2026): a 5 GW datacenter with a ~4 km × 4 km solar array shines near magnitude −6 (his range, −5 to −7) at ~550 km. From that anchor:

• Power → area: reflecting area scales with compute power, so the array side scales as √P; angular size is √area / range.
• Range: low passes are farther (slant range up to ~2,700 km at the horizon) and fainter, by up to ~3.5 magnitudes versus overhead.
• Phase angle Φ: a diffuse-sphere phase function, normalised to the side-lit (90°) geometry typical at the terminator.

One honest limitation: this diffuse-sphere term is direction-tolerant and ignores that a real array is a flat, strongly directional panel — brightest seen face-on, nearly vanishing edge-on. That smooths over a genuine difference between the shells (the 30° shell exposes observers to bright, near-face-on geometry the dawn–dusk shell mostly avoids). The base brightness here is therefore a fair guide to where and when, and a conservative one for the 30° shell's peak brightness.

A flat array is partly mirror-like, so when its specular reflection of the Sun briefly lines up with you, it can flash far brighter than its steady glow — the old Iridium-flare effect. With the flare toggle on, each satellite is given a specular glint on top of its diffuse brightness.

What is computed, and what is assumed

• The phase angle is computed exactly, but it is used as an alignment proxy: the app treats a small Sun–satellite–observer angle as a stand-in for true specular alignment, rather than solving the real surface-normal-bisector condition (which would depend on panel orientations the filing does not give). The glint peaks near that proxy alignment and falls off smoothly with a fixed angular spread, so you see it rise and fade over a pass.
• The peak brightness is an assumption you set. A real flare's intensity depends on the panel's specular reflectance and how optically flat it is — numbers nobody has published for these satellites, spanning roughly ten magnitudes. So rather than invent them, the "peak flare brightness" slider is that unknown: it fixes the magnitude at perfect alignment, and the geometry scales every flare down from there. Nothing is randomised; identical geometry gives identical brightness.

Why the two shells flare differently

• Because the array points at the Sun, its specular reflection goes back toward the Sun — so it only glints at small phase angle — when you stand nearly in line between the Sun and the satellite, and see it in the anti-sunward part of the sky, just outside Earth's shadow. The dawn–dusk shell sits near 90° phase (side-lit) and therefore rarely flares under this model; the 30° shell, seen across a wide range of phase angles, catches the alignment far more often. That contrast falls out of the geometry on its own.
• Real flares can also come from other flat surfaces (radiators, bus panels, antennas) at fixed off-axis angles, whose orientations the filing does not specify — so treat this layer as a clearly-labeled "what if," not a prediction.

• Stars: real positions and magnitudes from the Yale Bright Star Catalogue (J2000), ~8,400 stars to magnitude 6.5, tinted by stellar temperature, so the familiar patterns appear in their true places.
• Atmospheric extinction: satellites low in the sky are dimmed not only by their greater range but by the long slant of air they shine through — from essentially nothing overhead to several magnitudes near the horizon (airmass via the Kasten–Young formula, with a representative clear-sky coefficient of ~0.25 magnitudes per airmass; hazy or low sites would be worse). Since the app emphasises low twilight and near-horizon passes, this is not a small effect.
• Site time: the date and time are local mean solar time at the observing site, set by its longitude — not the site's civil clock, so they ignore time-zone boundaries and daylight saving and can differ from a wall clock by up to roughly an hour.
• Sun, Moon & planets: standard low-precision formulae (Schlyter), good to roughly an arcminute — fine for a naked-eye view, not ephemeris-grade. The Moon's main perturbations are included; lunar parallax (up to ~1°) is not.
• Twilight: sky-background brightness and the faintest visible star both track the Sun's depression below the horizon, so faint stars wash out near sunset while the far brighter datacenters remain visible.

• Not an observing planner or a tracker of real satellites.
• No atmospheric refraction or light pollution.
• Radiators are not drawn; they sit edge-on to the Sun and reflect little visible light, so the arrays dominate brightness.
• All brightness figures inherit Marcy's reflectivity assumptions. No kilometre-scale array has ever flown — treat magnitudes as a physically-motivated bracket, not a prediction.

The proposal itself

• SpaceX FCC application (SAT-LOA-20260108-00016) — the filing for up to a million orbital-data-center satellites at 500–2,000 km in 30° and sun-synchronous orbits. The primary source this simulator models.

The science of brightness & sky impact

• Marcy (2026), “The impact on astronomy of data centres orbiting Earth,” MNRAS — the open-access paper whose magnitude and angular-size estimates this app is calibrated to.
• Mallama & Cole (2025), measured Starlink brightness (MNRAS Letters) — the empirical satellite photometry Marcy scales up from; the observational basis for the magnitudes.

Overviews & a companion simulation

• Lawler et al., “A million new SpaceX satellites will destroy the night sky” (The Conversation, 2026) — astronomers running their own all-sky simulation of this proposal; a sibling to this tool.
• “What Would SpaceX’s Space Datacenter Plans Look Like?” (video) — a visual walkthrough of the concept and its appearance in the sky.

The engineering case

• Google Research, “Project Suncatcher” — a serious technical proposal for space-based AI compute, arguing the engineering upside; a counterweight to the impact-focused pieces.
• Starcloud — Starcloud-1, the first data-center GPU in orbit — a 60 kg proof-of-concept satellite (launched late 2025) carrying an Nvidia H100, from a company that has since pitched a full 5 GW, ~4 km² array like the one modeled here. The only space-data-center effort to have actually flown hardware.