High Frontier Logistics: Open Source Orbital Tender Concept

What's in the repository

Open source doesn't mean "here's the renders." It means the actual source files and everything you'd need to pick up where I left off, adapt the design, or build your own argument on top of it. Here's what's in the repository.

📦 Repository contents

✦
Blender source file (.blend) Complete real-world-scale Blender geometry in a single file, exportable to common mesh/scene formats such as STL, OBJ, FBX, glTF, and USD. STEP/CAD reconstruction may require FreeCAD or other CAD conversion work.
✦
Thesis full text The written argument for why orbital logistics is the bottleneck worth designing for, with linked sources.

License: Repository scripts and helper code under MIT. Design files, geometry, renders, animation, and thesis text under CC BY-SA 4.0. Attribution: "High Frontier Logistics / Wesley E. Corp" highfrontierlogistics.com.

Why open source this at all? Because the best outcome isn't that I build this, it's that the idea survives long enough to influence someone who can. Locking geometry behind a personal project doesn't serve that. A public repository does.

The Concept

It's an orbital tender, a vessel that accepts, stores, services, and redeploys Starship-class payloads. Think less "spaceship" and more "container port that happens to be in orbit." Every ton of material that leaves Earth needs somewhere to go before it arrives. The tender is that somewhere.

A payload is a payload. The tender doesn't care what's inside the container. If it fits a standardized cargo envelope, there's a berth for it. Standardized interfaces, agnostic handling. The whole design philosophy is boring on purpose: open architecture, no proprietary couplings, the same design repeated so it scales in 6-bay increments.

Opening the source files is a continuation of that philosophy. The architecture was designed to be extended without a redesign. The repository is the same idea, fork it, add bays, propose a different berthing mount and then discuss, critique, and revise.

Quick answers

Short answers to common questions. The technical claims are grounded in the modeled files, stated assumptions, or linked references.

What is the orbital tender?

The orbital tender is an open-source spacecraft concept for handling payloads in orbit. It is designed around standardized payload bays, a central loader arm, and a repeated coupling interface that lets payloads be captured, stored, serviced, and redeployed.

Is this flight hardware?

No. This is a modeled design concept, not flight-qualified hardware. The geometry, animation, and written design thesis are meant to provide a concrete starting point for review, critique, and improvement.

What problem is it trying to solve?

Most space logistics concepts focus on launch or propulsion. This concept focuses on orbital handling: how payloads are physically received, moved, stored, locked in place, and later redeployed.

What is the key mechanism?

Each payload uses a single standardized fitting that performs two jobs. It gives the loader arm a grasp point, and it also becomes the berth lock once the payload is seated. One fitting, two functions.

Why open source?

The goal is to make the design available for critique, reuse, student projects, mechanism studies, and future improvement. The intent is not to hide the idea, but to publish it clearly enough that others can evaluate and improve it.

What still needs engineering work?

Nearly everything required for flight: structural analysis, docking dynamics, controls, power, thermal design, propulsion, autonomy, orbital safety, materials, manufacturing methods, and full systems engineering.

Could students build part of it?

Yes. The full tender is large, but the coupling and loader interaction could be reduced to a bench-scale prototype using CNC, 3D printing, bearings, sensors, and simple actuation.

Is this a space station?

Not exactly. A station is usually a destination or habitat. This concept is closer to an orbital cargo-handling vessel or logistics node: a machine for receiving, storing, and redeploying payloads.

Is this a tug?

Not exactly. A tug moves payloads from orbit to orbit. The tender concept focuses more on receiving, holding, organizing, and mechanically handling payloads. Propulsion is an important future subsystem, but it is not the main contribution shown here.

What makes the concept different?

The main difference is the repeated handling architecture: standardized bays, a central loader, and a single payload fitting that works as both grasp point and lock. The design treats orbital cargo handling as a mechanical systems problem.

Not seeing what you need? Contact [email protected].

What's designed vs. what's assumed

Honesty is the whole pitch here. The left column is geometry I actually modeled. You can see all of it in the animation, and all of it ships in the repo. The right column is drawn from published physics and launch-economics projections: plausible, but not mine and not yet proven. The same distinction carries into the model itself.

Designed & rendered

In the animation and in the repo

●

18 Starship-class payload bays Modeled geometry, arranged for the central loader's reach.

●

Central robotic loader Articulated arm that moves payloads between bays in the animation.

●

Flat-pack deployment, by design Components nest inside a payload-bay envelope for launch. The actual unfolding mechanism is a design intent, not yet implemented in the model.

●

6-bay modular increments One connector repeated; the architecture grows without a redesign.

●

Berthing mount Dual-function fitting acts as grasp point for the loader arm and berth lock once seated.

Assumed from the literature

Projections, please verify independently

○

Aspirational low-cost launch to LEO Industry targets vary widely; not current demonstrated price. Treat as directional.

○

L4/L5 passive stability Standard three-body result. Real and well-understood, just not something I thought up.

○

Orbit-to-orbit repositioning Depends on a propulsion system I haven't specified. Treat range as open.

○

Lunar-water propellant at ~$50/kg ISRU projection contingent on infrastructure that doesn't exist yet.

○

Standardized cargo envelope compatibility Based on published dimensions; not validated against hardware.

The repo carries the same notation. Files are explicit about which claims are modeled geometry and which are external projections.

🔴 The One Piece Meant to Leave the Tender

Almost everything else in this model is about this specific tender: its bay count, its mobility system, its internal logic. The berthing mount is different. It's the one component whose entire value depends on showing up on hardware this project doesn't control.

Every payload arrives fitted with a standard coupling, visible as the red/orange ringed fitting at each bay boundary in the animation. It does two jobs with one fitting:

●

Grasp point What the mobility system's finger mechanism interfaces with to capture and move a payload.

●

Berth lock The same fitting secures the payload in place once it's seated, no separate hardware needed for handling vs. storage.

This isn't drawn from an existing standard, there isn't one yet. It's a proposal: one fitting, two functions, meant to be copied onto payloads built by people who never look at the rest of this model. If a coupling standard for orbital cargo handling is going to exist, it has to start somewhere. This is a starting point open for discussion, critique, and revision.

Why a Waystation, and Why L5

You don't colonize a continent from the beach, you build a port first, a place to dock, refuel, repair, and redistribute. For expansion off Earth, the natural site for that port is a Lagrange point. The mechanics are real; the infrastructure case is the proposal.

The real advantage of L4/L5 isn't fuel savings, station-keeping at L1/L2 is cheap anyway, a few tens of m/s a year. It's passive stability: lose power or comms at L1 and your facility drifts off. At L4/L5 it remains naturally confined near the stable region instead of quickly departing, though real hardware would still need navigation and occasional correction. For cargo sitting idle between missions, that passive hold is worth more than the trivial fuel difference.

Why L5 specifically? Mostly history. L4 and L5 are physically identical, either works. L5 got its name recognition because Gerard O'Neill used it in The High Frontier (1976) and the L5 Society ran with it. In practice you'd pick whichever fits your traffic pattern, or use both. The point was never which Lagrange point. It's that the port gets built at all.

The Thesis (where this comes from)

The design didn't come out of nowhere. It comes from a pattern that holds across most of economic history: the durable winners aren't the ones who make the goods, they're the ones who move, hold, and hand them off. Venice controlled the routes, not the spices. Containerization reshaped the world with one standardized box. Logistics is the layer everything has to pass through, and space is about to have that problem with almost no one building for it. I'm not claiming certainty on the timeline, I'm claiming the bottleneck is real and worth designing for now.

🚀 Cheap heavy lift

Reusable launch is changing what's physically liftable, not just what's affordable. Once mass to orbit gets cheap enough, the constraint moves from "can we launch it" to "where does it go once it's up there."

⚡ The gap nobody's building

Lots of people build rockets. Lots imagine habitats. Very few are designing the unglamorous middle layer, the thing that catches, holds, and hands off cargo in orbit. That's the tender: a container port that happens to be in orbit.

🧬 A longer-horizon reason (held loosely)

If longevity research delivers even part of what's hoped, and senolytics and reprogramming are in human trials now, people build on longer time horizons, which makes durable orbital infrastructure more valuable. I find this compelling but hold it loosely; the logistics argument above doesn't depend on it.

The short version: cheap heavy lift changes where people build. The constraint becomes orbital handling, receiving, holding, and redeploying cargo, and almost no one is designing for it. That gap is the tender. The full argument, including the longer-horizon case, is in the repository.

About

I designed and created this work, but this didn't happen alone; a lifetime of support from family, friends, and cohorts made it possible.

I'm Wes Corp, an independent designer in Idaho with a hands-on workflow spanning mechanical design, CAD, animation, Linux, local AI, robotics, and web infrastructure. I'd rather produce an animated working model than present slideware about one.

The tender was designed end to end with my CAD workflow, geometry, rigging, and animation, which is why I can show it moving instead of just describing it. And that's why you can open it and change it yourself.

Sources / References

Major background claims and external assumptions are linked below for independent verification.

Longevity: Senolytic trials registered at ClinicalTrials.gov. Epigenetic reprogramming via partial Yamanaka factors - see Ocampo et al., Cell (2016) for foundational work. Human trial pipeline tracked via Lifespan.io Rejuvenation Roadmap.
Launch costs: SpaceX Falcon 9 rideshare pricing at spacex.com/rideshare. Starship aspirational $/kg targets from SpaceX Starship (archived Users Guide PDF) and company public statements. Third-party analysis by Payload and BryceTech.
China space program: Tiangong station operations via China Manned Space Agency (CMSA). Next-generation launch vehicle timelines from CNSA announcements and SpaceNews China coverage.
Lunar resources: LCROSS ejecta plume water detection. Colaprete et al., Science (2010). LRO ongoing polar hydrogen mapping at NASA Moon Water and Ices. ISRU propellant cost modeling from NASA Engineering & Safety Center lunar ISRU feasibility studies.
Asteroid resources: Near-Earth object composition from meteorite analogues, platinum-group metals at 10–30 ppm in CI chondrites (Krot et al., LPSC 2013). Spectral surveys via IAU Minor Planet Center and NASA CNEOS.
Orbital mechanics: Lagrange point stability explained at NASA GSFC: Lagrangian Points L4 and L5. Station-keeping ∆v requirements from NASA Technical Reports Server. ESA Lagrange Points overview.
Space law: Outer Space Treaty (1967) full text via UNOOSA. Artemis Accords (2020) signatory nations and principles via NASA. Bilateral investment treaty precedents in ICSID jurisprudence.

All forward-looking projections are speculative and subject to change. This site does not provide investment advice. For specific data sources or methodology questions, contact [email protected].

Where this is headed

To be clear about what this is and isn't: it's a design and a thesis, now public. There's no fund, no raise, no product. And here's the honest part: making it open source was the only thing on this page I actually controlled. What happens next isn't up to me, and that's the point.

June 2026 - Blend file released

Source model public

The full Blender source file went public, hull, internals, rigging, and animation pipeline. Repository scripts and helper code under MIT, CC BY-SA 4.0 on design files, geometry, renders, and animation. Everything needed to build on it, fork it, or argue with it.

July 2026 - v1.0.0 + thesis published

Release and full argument public

v1.0.0 ships the complete Blender file and the design thesis together, the geometry, the rendered stills, and the written argument for orbital logistics as infrastructure. The thesis makes explicit which claims are modeled and which are external, so the conversation can be about the idea, not about what the idea is.

After that

Out of my hands by design

Maybe the repository sits untouched. Maybe someone forks it and builds something I never imagined. Maybe the idea gets torn apart and something better replaces it. None of that is mine to decide, and an open release means the concept survives, or doesn't, on its own merits, not on whether I personally can carry it. That's a feature, not a risk.

Open Source Orbital Tender