Orbit OS Platform

Orbit OS is an operating system for embedded Linux and IoT devices. It provides a complete runtime platform — from hardware access to application lifecycle, remote control, OTA updates, and Edge AI — out of the box.

Applications are packaged as signed .orb files and executed by Gravity RT, the unified runtime at the heart of Orbit OS. The same API works for local development and production deployments.

System Overview

The diagram below shows the full Orbit OS stack — from hardware up through Gravity RT, the application layer, and the remote management plane.

⚙️ Gravity RT

Gravity RT is the execution core of Orbit OS — the single layer through which all applications and system services run. It is always active, extremely lightweight, and acts as the supervisor for everything on the device.

• Application lifecycle: start, stop, restart, and update every .orb app
• Automatic recovery: crashed apps are restarted automatically
• Hardware access: all device capabilities exposed as a unified, secure API
• Resource control: CPU, memory, and I/O limits enforced per application
• Security enforcement: every package verified before execution
• Edge AI: TFLite runtime included by default — no add-on required

Next: .orb Package Model →

📦 .orb Package Model

All software on Orbit OS is distributed as .orb packages — the equivalent of an APK on Android. A .orb can be an application, a background service, or a system tool.

What's inside a .orb

• Executable code — Go, Python, Java, or C++ binary
• Manifest — declares the app's runtime, permissions, and resource limits
• Resources — data files, AI models, configuration, assets
• Cryptographic signature — required for execution

Self-contained and efficient

A .orb bundles everything the app needs. As an example, a full Edge AI face recognition app — including three TFLite models for detection, landmarks, and identification — weighs only 6 MB. The TFLite runtime lives in the OS, not in each package, keeping sizes small.

Persistent data

Each app has its own isolated data directory that survives restarts and OTA updates. One app cannot access another app's data. Developers have full control — the runtime never deletes app data automatically.

Next: Permissions →

🔑 Permissions

Every .orb declares the hardware and system capabilities it needs in its manifest. Gravity RT reads this list at launch and exposes only those APIs to the app — nothing more. This is the principle of least privilege, applied natively.

Examples of available permissions:

• GPIO, PWM, I²C, SPI, UART
• WiFi, Ethernet, Bluetooth (BLE)
• Camera
• AI Service (TFLite inference)
• Network access
• Package Manager
• Firewall

An app that only declares CameraService and AiService has no access to GPIO, networking, or any other capability — by design, not by configuration.

Next: Trust Model →

🔐 Trust Model

Every .orb belongs to one of two signing domains. The signing domain determines how the package is treated at runtime.

The trust level is determined by the signature, not by configuration. There is no way to promote a dev-signed package to production — it must go through the Store pipeline.

Next: Security →

🔒 Security

Security in Orbit OS is not a layer added on top — it is built into the execution model. Every connection is authenticated, every package is verified, and every app runs with only the permissions it declared.

Before any app runs

Gravity RT always performs these steps before execution:

1. Verify the cryptographic signature
2. Validate the certificate chain
3. Classify the trust domain (Store or Dev)
4. Apply device policies
5. Enforce declared permissions

Remote connections

All remote access — from the SDK, CLI, or mobile app — requires mutual authentication. There are no open ports and no implicit trust. In production, both a valid certificate and credentials are required. In Developer Mode, credentials are not required, but the cryptographic certificate still is.

Developer Mode security

Developer Mode is enabled manually in device Settings — the same model as Android's USB Debugging. The device explicitly informs the user of the security implications when enabling it. In production, Developer Mode is always off.

Execution outcomes

Next: Developer Mode →

🧪 Developer Mode

Developer Mode changes how you interact with your device during development. Instead of the traditional embedded cycle — write, compile, flash, reboot, observe — Orbit OS lets you develop entirely on your laptop against real hardware, in real time.

Traditional embedded workflow

Write code → Compile → Deploy → Reboot → Observe → Repeat

Orbit OS Developer Mode

Write code → Your code connects to device → Call real device APIs → Observe → Repeat

Your code runs on your development machine and connects to the real device over the network. From your laptop, your code calls device APIs — you can remotely activate GPIO pins, run AI inference, configure networking, access the camera, and use any other device capability — all through the same API that production apps use. No packaging, no deploying, no rebooting needed.

Only once the behavior is validated do you generate the .orb and install it locally or publish it to the Store.

• Same API in development and production — no surprises when shipping
• Logs stream in real time, with filtering by tag and level (similar to Android logcat)
• No SSH required — all access goes through the Gravity RT API
• Enabled and disabled explicitly in device Settings

Next: SDK & CLI →

🛠️ SDK & CLI

The Orbit OS SDK lets you build applications, connect to devices, and control hardware from your language of choice. All SDKs expose the same API — generated from a shared interface definition — so behavior is consistent across languages.

Apps, tools & CLI

* These languages support both building internal .orb apps that run on the device and CLI/tools that interact with the device remotely.

Mobile tools

* SDKs for building Android and iPhone apps that connect to and control Orbit OS devices remotely.

Development SDK Tool

Included with all SDKs. The Development SDK Tool lets you interact with a device directly:

• Install .orb packages
• Remove packages
• List installed packages
• Interact with device APIs locally for Development

Official Android App

The official Orbit OS Android app provides two capabilities:

• Store access — browse and install apps on your devices from your phone
• Local device control — connect directly to a device on your local network and manage it: install, remove, monitor, control

The SDK's shared interface definition also allows any developer to build their own Android or iOS app to interact with Orbit OS devices — for custom dashboards, industrial control panels, or smart home interfaces.

Next: Developer Workflow →

🧠 Developer Workflow

The full lifecycle from development to production deployment:

1. Enable Developer Mode on the device (Settings → System → Security)
2. Write and run your code from your PC against the device — no packaging needed
3. Iterate in real time — logs and results stream back instantly
4. Package as .orb once behavior is validated
5. Submit to the Store and deploy to your devices

Next: Orbit OS Store →

🏪 Orbit OS Store

The Store is the central control plane for distributing and managing applications across Orbit OS devices. It handles the full application lifecycle — from first install to updates and OTA system upgrades.

The Store is live at store.orbit-os.org.

For developers

The Store includes a developer portal where you can submit your own .orb apps, manage versions, and distribute to users.

Next: Fleet Management →

🖥️ Fleet Management

The Store provides fleet-level control over all your devices from a single interface. Deploy an app to one device or to your entire fleet with a single action.

How fleet deployment works

When installing an app from the Store, a device selector shows all devices in your account. Devices that already have the current version are shown as up to date — preventing unnecessary reinstalls. You can deploy to individual devices or select all eligible devices at once.

• Deploy to any subset of your registered devices
• Version tracking per device — always know what's running where
• Automatic app updates when new versions are published
• OTA system updates managed centrally — enable or disable per device

Next: OTA Updates →

🔄 OTA Updates

Orbit OS supports two types of over-the-air updates, both managed through the Store.

Atomic and safe

Runtime updates are atomic — they either apply completely or not at all. If anything goes wrong, the previous version is instantly restored. There is no risk of ending up in a broken intermediate state.

Soft restart

A runtime update does not reboot the underlying Linux system — only the Gravity RT process and its apps are restarted. This makes updates significantly faster than a full device reboot.

Auto OTA

Auto OTA can be enabled or disabled per device in the Store. When enabled, the Store delivers runtime updates automatically as they are published. When disabled, updates are applied manually at the operator's discretion.

Next: Execution Model →

🔌 Execution Model

All interactions with Gravity RT — whether from an app running on the device or a tool running on a remote laptop — go through the same system API. The origin differs; the model does not.

Because both paths use the same API, code written and tested via the external SDK in Developer Mode behaves identically when deployed as a .orb and running internally in production.

Next: Footprint →

📊 Footprint

Orbit OS is designed to run on resource-constrained edge devices — not just high-end boards. The runtime is small enough to be viable on devices with as little as 128–256 MB of RAM.

Real-world metrics (Raspberry Pi 4, 1.8 GB RAM)

139 MB includes the Gravity RT Server, all system services, and the full runtime — leaving over 1.6 GB free for applications on the RPi 4.

Installation

A single 25 MB .run file is all you need to install Orbit OS on a supported device. Run it on the device, and the runtime is configured automatically. Dependencies are installed once on first run.

Next: Design Principles →

🚀 Design Principles