The Space Hardware Cloud
CubeSTEM is building the Space Hardware Cloud. TwinLink gives engineering teams controlled access to spacecraft hardware owned by laboratories and manufacturers — through one interface, while owners retain access and safety control.
TwinLink — One interface. Many spacecraft systems.
3 min · interactive · hardware execution simulated
Why access breaks
Spacecraft software teams often wait for purchased hardware, custom interfaces, and a complete local bench before meaningful physical validation can begin.
Every device, vendor, and laboratory introduces another integration path before engineering work can start.
Candidate hardware is difficult to evaluate while architecture and software decisions are still flexible.
Laboratories and manufacturers need selective exposure, scoped access, and local authority — not an unrestricted internet connection.
The platform
TwinLink sits between engineering applications and heterogeneous spacecraft resources. It standardizes access while keeping integration and physical authority on the owner's side.
TwinLink is not the Digital Twin, an Edge box, or a remote desktop. A Digital Twin can be one application-side participant in a future engineering workflow.
CONSUME · what a mission team builds on
INTEGRATE · what an owner or vendor maps in
Nothing to install and nothing to open.
The Bridge is software you run beside your hardware, on an ordinary Windows or Linux lab PC. It dials out — no inbound port, no appliance to ship, no equipment leaves your site. A CubeSTEM Edge Node exists as an optional appliance and is not on the required path.
Composed missions
A mission rarely needs an entire bench from one place. You may already own the on-board computer and need someone else's power supply — or a specific attitude-control table, for two weeks in March. A composed mission runs across both at once: your hardware and theirs, through one interface.
YOUR APPLICATION
One Client SDK. One device model. One evidence trail.
TWINLINK
Discovery, leases, authorization, command routing, telemetry, audit
YOUR SITE
For example: your OBC
You contribute it. You keep it. You can withdraw it at any time.
VENDOR OR LABORATORY SITE
For example: their EPS
They expose a capability subset to you under an explicit grant: scoped, time-limited, and revocable at any moment.
OBC and EPS name the real-world shape of this use case, not shipped device classes — the TwinLink device model covers the resource classes it covers today, and this website is pinned to contracts 0.3.0. The cross-organization grant you can exercise in the product experience is an experience-layer capability, not a TwinLink 0.3.0 API.
How a composed mission worksChoose your path
Mission teams use resources. Laboratories and manufacturers own them. Strategic partners inspect how the system can grow.
Trust and safety apply across every path; they are not a separate participant in the network.
Mission and software teams
Discover candidate hardware, begin with simulation, and move toward controlled physical validation through the same engineering interface.
Universities and laboratories
Start privately, define capabilities and safety limits, then grant selected collaborators access only when you choose.
Space hardware manufacturers
Map an approved product surface into TwinLink without replacing the device firmware, board, or commercial relationship.
Investors, agencies, and strategic partners
See how controlled integrations can compound into shared engineering infrastructure — without confusing simulated evidence with traction.
Interactive product experience
The guided journey runs the real product workflow on the server. Hardware execution is simulated today — and the product is built so the same contract can later be implemented against physical hardware without the workflow you see changing.
INTERACTIVE PRODUCT EXPERIENCE · SIMULATED
Physical TwinLink resources are not connected in this website experience.
Owner grants
Scoped telemetry and commands
Mission runs
Valid command at 2500 RPM
Safety proves
4000 RPM blocked by local max
Evidence remains
Attributable result and denial
Owner revokes
Future discovery and access close
Trust model
TwinLink is not an open pipe onto laboratory equipment. Owners define what is remotely exposed. Remote access is designed around explicitly permitted capabilities.
Owners define what is remotely exposed. Capabilities are not public by default.
The architecture keeps safety-critical authority local. Cloud policy may be stricter; it cannot weaken local limits.
Only permitted capabilities leave the site. Hardware does not become an unrestricted Internet device.
Designed on zero-trust principles for secure remote Hardware-as-a-Service.
Architecture and in-development controls — not a production security certification, and not a claim that physical safety hardware is already shipping.
What is real today
The interactive experience on this site runs on simulated hardware, and says so. The engineering underneath it is real, versioned, and checked into a repository. These are separate facts, so they are stated separately.
REAL AND VERSIONED
SIMULATED IN THIS EXPERIENCE
NOT CONNECTED YET
Hardware execution is simulated today. The product is built so a future TwinLink API provider implements the same interface against physical hardware — the same resources, the same leases, the same commands, the same evidence. A conformance stub for that provider already exists in this codebase and deliberately refuses to run, so the boundary cannot be blurred by accident.
This website and the TwinLink repository move at different speeds. Conflating them would overstate what the site actually runs.
Implementation path
The website deliberately separates what you can interact with today from measured results that appear only once a physical resource is connected.
IN DEVELOPMENT
The common device, access, orchestration, and connector layer that the rest of the experience is built around.
INTERACTIVE · SIMULATED
Mission teams, manufacturers, laboratories, and strategic partners can each run the full product workflow end-to-end, with the status of every result labelled.
NEXT PHYSICAL PROOF
A controlled CubeSTEM resource can move the experience from simulated telemetry to measured hardware results through the same TwinLink path.
PARTNER-DEPENDENT
External hardware becomes a real network resource only after technical integration, owner approval, and an agreed access policy.
Founding programme
Hardware owners come from two directions: manufacturers who want their products evaluated before procurement, and laboratories with capable equipment that is idle most of the week. Both keep control of what is exposed, to whom, and for how long.
Founding hardware partner programme
Selected founding spacecraft-hardware manufacturers may receive an initial TwinLink integration at no integration charge, subject to technical fit and mutually agreed scope.
The manufacturer remains in control of what is exposed, who may access it, and what commercial relationship follows an evaluation.
We are looking for
If you build an OBC, EPS, ADCS subsystem, payload, sensor, SDR, actuator, or other spacecraft engineering hardware, we would like to explore a founding integration.
Technical fit + mutually agreed scope
Founding laboratory node
Selected founding laboratories may receive an initial TwinLink integration for one resource at no integration charge, subject to technical fit and mutually agreed scope.
The laboratory decides what is exposed, who may reach it, and when. Private first; shared only if and when you choose. Nothing is installed beyond software you run yourself, and no equipment leaves your site.
We are looking for
If you run a cubesat programme, a FlatSat bench, an ADCS or reaction-wheel table, thermal or vacuum test equipment, a ground station, or comparable laboratory hardware, we would like to explore a founding laboratory node.
No appliance to install · no inbound port
