1.4 Core Platform Principles (control, traceability, speed)
Orbnetes deployment and release orchestration documentation for operators and platform teams.
4.1 Control
Orbnetes treats delivery as a controlled process, not just command execution.
- Project scoping keeps resources, configuration, and access boundaries explicit.
- Launch modes and permission checks prevent misuse of pipelines in the wrong context.
- Approval flow can gate deployments before execution starts.
- Rollback policy can be pre-configured as part of release behavior, not improvised during failure.
Result: production changes follow a governed path with fewer risky manual shortcuts.
4.2 Traceability
Every meaningful action in the release lifecycle should be explainable after the fact.
- You can trace from release to deployments, pipelines, jobs, and step logs.
- Audit records capture who performed critical actions and when.
- Soft-delete behavior preserves references so historical context does not disappear.
- Release metadata (source/tag/file/inputs) gives reproducible execution context.
Result: faster root-cause analysis, cleaner postmortems, and better compliance posture.
4.3 Speed
Control should not slow teams down; it should remove repeated friction.
- Lightweight agents minimize infrastructure overhead and startup delay.
- Real-time graph and console reduce time-to-diagnosis during active runs.
- Rerun all / rerun failed shortens recovery from transient failures.
- Reusable Blueprints and launch inputs eliminate repeated manual command composition.
Result: teams keep delivery velocity while improving operational reliability.
5. How to Read the Documentation (recommended entry path)
If you are new to Orbnetes, follow this order:
- Quick Start (create project, register agent, run first Blueprint).
- Blueprints (authoring model and execution behavior).
- Releases + Approvals + Rollback (controlled deployment flow).
- Secrets/Variables/Environments (runtime configuration strategy).
- API and Integrations (automation and external system integration).
This sequence matches how teams typically adopt the platform in practice: first prove execution, then add governance, then scale automation.