Core Concepts

At its core, orbits enfore the SAGA principle, ensuring that your applications are crash-proof. Orbits introduces three main primitives:

• Actions are used to represents a mutating process
• Workflow allow you to compose actions using expressive syntax. Thanks to built-in syntactic sugar, you can model complex business logic without having to alter your typescript way of thinking.
• Resources orchestrate and model the lifecycle of real-world resources. They offer a stateful abstraction over systems such as environments, deployments

Once you're familiar with Actions, it's important to understand two supporting concepts:

• Executors enable actions to run in specific execution environments — for example, inside a different Kubernetes cluster or via a serverless function like AWS Lambda.
• Runtime defines the default configuration and behavior of the Orbits framework, such as database connections, logging, and execution constraints.

Once you understand these core concepts, head over to the "Pilot your infra" section to learn how to apply them in practice — from designing workflows to actively operating and observing your infrastructure.

📄️ Action

Actions are the finest granular level of Orbits.

📄️ Action lifecycle

An action has a lifecycle that starts when the action is saved in the database. Then, Orbits takes care of the different states and calls the appropriate function when needed, with correct locks and timeouts.

📄️ Workflow

A Workflow is a way to chain Actions. The syntax is similar to how async/await syntax works.

📄️ Resource

A Resource is a specialized type of Workflow designed to orchestrate the lifecycle of real-world entities, such as cloud accounts, services, or data systems. Resources provide a declarative and persistent way to manage these entities through versioning, reconciliation, shared state, and scheduled verification.

📄️ Environment variables and runtime

Advanced Feature

📄️ Executor

Executors allow Actions to be run in specific contexts. For example, assume you want to build an app that requires external dependencies, like grunt, java, composer... You can specify that the deploy Action runs in a normal context and that the builder Action runs in a docker or in a lambda or in any other context managed by an executor.