How CubeSats Are Attached to a Launch Vehicle

CubeSats have transformed access to space by standardizing small satellite deployment. But one question that comes up often — especially among university teams, aerospace students, and small satellite developers — is how these tiny spacecraft actually get from Earth to orbit. Specifically: how are they physically attached to the rocket, and how do they separate once they're there?

The answer involves a specific class of deployment hardware, international standards, and a surprising number of variables depending on your mission profile.

What Is a CubeSat Deployer?

CubeSats aren't bolted directly to a launch vehicle the way traditional satellites are. Instead, they ride inside a CubeSat deployer — a standardized mechanical container that interfaces with the rocket on one end and safely houses the CubeSat on the other.

The most widely used deployer standard is the Poly-Picosatellite Orbital Deployer (P-POD), developed at Cal Poly San Luis Obispo. Other deployers include the ISIPOD, NanoRacks CubeSat Deployer (NRCSD), and the ExoPod, among others. Each has its own mechanical interface, but most follow the same basic principle: the CubeSat sits inside a spring-loaded tube and is ejected when a door opens on command.

The deployer itself is what attaches to the launch vehicle or host platform — not the CubeSat directly. This is an important distinction.

The Physical Interface: How the Deployer Connects to the Rocket 🛸

Deployers attach to a launch vehicle through a mechanical interface plate or separation system that's bolted to the rocket's payload adapter or secondary payload rail. On rockets like Rocket Lab's Electron, SpaceX's Falcon 9, or ISRO's PSLV, secondary payload slots accommodate these interfaces alongside a primary payload.

Most deployers use a bolted flange or rail-mounted attachment that interfaces with the rocket's secondary payload structure. The exact fastener patterns, load ratings, and alignment requirements are defined in the launch vehicle's payload user's guide — a document that serves as the technical contract between the satellite team and the launch provider.

Key elements of the physical attachment include:

  • Mechanical fasteners — typically bolts torqued to precise specifications to handle launch vibration loads
  • Separation connectors — electrical connectors that can be cleanly disconnected at separation
  • Grounding straps — to prevent electrostatic discharge between the deployer and vehicle structure
  • Shock isolation — some deployers or adapters include damping materials to protect the CubeSat from pyrotechnic shocks during primary payload separation

How CubeSats Are Held Inside the Deployer

Inside the deployer, the CubeSat is held in place by spring-loaded rails that apply a light preload force against the satellite's body. The CubeSat standard defines a rail width of 8.5mm and specific surface finish requirements so the satellite can slide freely but doesn't rattle during launch.

A door restraint mechanism — often a nichrome wire burn wire, a shape memory alloy actuator, or a simple pin-puller — keeps the deployer door closed until the correct command is sent on orbit. Once released, the door opens and the internal spring ejects the CubeSat at a low velocity (typically under 2 m/s).

Kill switches (remove-before-flight pins) physically prevent the CubeSat from powering on while inside the deployer. These are removed during final integration, and the spring mechanism holds the switch open until deployment.

Variables That Affect Integration and Attachment

Not every CubeSat mission uses the same attachment path. Several factors shape the actual hardware configuration:

VariableHow It Affects Attachment
CubeSat size (1U, 3U, 6U, 12U)Determines deployer size and structural load requirements
Launch vehicleDictates mechanical interface standards, vibration environments, and documentation requirements
Rideshare vs. dedicated launchRideshare often means the deployer is managed by a third-party integrator, not the satellite team directly
ISS deploymentCubeSats launched to the ISS use the JAXA JEM airlock and the NRCSD system — a completely different integration path
Host spacecraftSome CubeSats deploy from larger satellites, requiring custom mechanical interfaces

ISS Deployment: A Different Path

CubeSats delivered to the International Space Station follow a distinct process. They're launched in a pressurized cargo vehicle, transferred inside the station, loaded into the NanoRacks deployer or JAXA's JEM Small Satellite Orbital Deployer (J-SSOD), and ejected through the JEM airlock using a robotic arm. The CubeSat never attaches to a rocket directly — it rides as internal cargo and deploys from orbit.

This path removes launch vibration concerns but introduces handling, safety, and crew interface requirements that don't apply to direct-to-orbit rideshares.

Structural and Vibrational Qualification 🔩

Before any deployer is accepted onto a launch vehicle, the fully loaded deployer must pass environmental qualification testing — including random vibration, sine vibration, shock, thermal vacuum, and acoustic testing. These tests simulate the worst-case conditions during ascent.

The CubeSat itself must also meet structural requirements defined in the CubeSat Design Specification (CDS), maintained by Cal Poly. This ensures that the satellite won't damage the deployer rails, jam the ejection mechanism, or compromise the primary payload.

Where Individual Missions Diverge

The standards exist precisely because the variables are so numerous. A 1U CubeSat on a PSLV rideshare uses different hardware, documentation, and integration timelines than a 6U CubeSat deploying from the ISS or flying as a secondary payload on a commercial smallsat launcher. The deployer vendor, launch provider, and mission orbit all pull the integration path in different directions.

What holds across every mission is the layered logic: a standardized container manages the satellite, a mechanical interface manages the container, and the launch vehicle manages everything above it. Understanding which layer you're working at — and who owns each interface — is usually where the real complexity lives for any specific mission.