Orbit OS Architecture

Orbit OS is a secure distributed operating system for embedded Linux devices. It turns devices into managed compute nodes where applications and services are deployed as signed .orb packages and executed by a unified runtime.

🧩 Core Principle: All execution happens through a unified API surface, under different trust and runtime boundaries.

System Overview

Orbit OS Architecture Diagram

⚙️ Gravity RT (Execution Core)

Gravity RT is the execution engine of Orbit OS. It is the heart of the system, responsible for:

  • Running .orb applications and services
  • Enforcing process isolation
  • Managing lifecycle (start, stop, restart, update)
  • Enforcing resource limits (CPU, memory, IO)
  • Controlling hardware access via secure APIs
  • Validating all cryptographic signatures before execution

👉 Nothing executes outside Gravity RT.

📦 .orb Package Model

All software in Orbit OS is distributed as .orb packages. A .orb can represent an application, a service, or a tool.

Package Structure

Each .orb contains:

  • Executable code (Go, Python, Java, C++, etc.)
  • Manifest declaration, limits, permissions
  • Resources databases, docs etc.
  • Signature cryptographic

🔁 Every .orb is signed. Unsigned packages are not valid in Orbit OS.

🔐 Orbit OS Trust Model

Orbit OS uses two types of signed packages:

🏪 Store-Signed Packages

Production

Official apps and services distributed through the Orbit OS Store.

  • Fully trusted execution
  • Automatic updates supported
  • Fleet deployment enabled

🧪 Development-Signed Packages

Development

Built locally using the SDK for development and testing.

  • Valid and verifiable
  • Intended for development use
  • No automatic fleet deployment

All .orb packages are signed and verified before execution. The trust level depends on how the package is signed.

⚙️ Gravity RT Security Enforcement

Before execution, Gravity RT performs several validation steps:

  1. Signature verification
  2. Certificate chain validation
  3. Trust domain classification
  4. Policy enforcement (device settings)
  5. Sandbox assignment if required

🔒 Execution Outcomes

🟢 Production

Store-signed .orb. Full managed lifecycle. Fleet deployable.

🟡 Development

Development-signed .orb. Controlled by developer policies. Debuggable.

❌ Rejected

Invalid signature chain or tampered package.

🏪 Orbit OS Store (Control Plane)

The Store is the central system for managing Orbit OS devices and workloads.

  • Package Management: Install, version control, and 1-click deployment.
  • Device Management: Register devices, monitor status, and track versions.
  • System Updates: OTA updates with controlled rollout strategies.

Next: Developer Mode →

🧪 Developer Mode (Real-Time SDK)

Orbit OS enables real-time development directly against running devices using the SDK, without requiring application packaging or deployment.

  • Execute logic directly on live device runtime via the SDK
  • Interact with device APIs in real time
  • Stream logs, state, and execution results instantly

This mode runs against real devices in real time. Applications behave exactly as they would in production, but without requiring a packaged .orb deployment.

Next: Execution Model →

🔌 Execution Model

All system interactions in Orbit OS go through Gravity RT. The difference lies in where the calls originate.

Channel Call Origin Usage Properties
🌐 External Calls SDK, CLI, mobile apps, external tools Direct interaction with Gravity RT from outside the device Real-time control, remote execution, full API access (subject to auth/policies)
🧩 Internal Calls .orb applications, system services Local execution inside the device Isolated execution, high performance, controlled permissions

🧠 Execution Flow

  • EXTERNAL FLOW: Tool / SDK / App → Gravity RT → Device System
  • INTERNAL FLOW: .orb → Gravity RT → Device System

Gravity RT is the single execution entry point for all operations in Orbit OS. External and internal calls differ only by origin, not by execution model.

🧠 Developer Workflow

  1. Develop using SDK or IDE
  2. Execute directly via SDK (no packaging needed)
  3. Validate behavior on a real device
  4. Package as .orb
  5. Sign via SDK or Store pipeline
  6. Deploy via Store or locally
  7. Gravity RT executes under the trust model

🌍 Mental Model: Orbit OS is a secure distributed operating system where embedded devices execute signed workloads via a unified runtime. Developers interact with the same system API in both development and production.

Next: Communication Model →

🔄 Communication Model

Orbit OS uses a unified system API for all internal and external communication.

  • System API: Unified interface used by runtime components and system services.
  • External Integration: Access via SDK, CLI, and external tools.
  • Messaging Layer: Event-driven communication for system coordination and IoT integration.

🚀 Key Design Principles

  • Everything is a signed .orb
  • Trust is based on Store and SDK signing domains
  • Store is the control plane
  • Gravity RT is the execution engine
  • Devices are managed compute nodes
  • Same system API for dev and production
  • External calls = development tools
  • Internal calls = runtime execution
  • Real-time development is first-class
  • Security enforced at runtime