Quick Start: First Deployment

This quick start is the fastest route to a first successful deployment in ByteOr Cloud.

Goal

Start with a running local control plane and end with an agent targeting a created deployment.

Steps

  1. Start the stack with scripts/dev_up.sh or docker compose up --build.
  2. Open the UI and sign in.
  3. Create or select an organization and project.
  4. Create an environment for the project.
  5. Create or open a pipeline draft.
  6. Choose the explicit execution target in the editor: SingleRing for ordered linear pipelines or LaneGraph for branching, fanout, merge, and richer topology work.
  7. Author against the shared plan document. The canvas projection will switch with the target, but the underlying draft stays one synchronized plan-plus-target envelope.
  8. Save the draft.
  9. Run preview or create a version. Cloud validates and lowers the synchronized plan into the requested canonical target instead of compiling from graph-only UI state.
  10. Create a config bundle for that version.
  11. In the config-bundle composer, start from a guided runtime tuning profile and only drop to raw tuning fields when you need explicit overrides.
  12. Register an agent in the target environment.
  13. Create a deployment.
  14. Verify that the registered agent sees the deployment and begins reporting state.
  15. Open deployment details to confirm the shared effective-tuning record: requested settings, applied settings, degraded settings, failure reasons, and host observations.

What success looks like

  • the saved draft records both the selected execution target and the shared plan backing the editor projection
  • the pipeline version exists as an immutable compiled record
  • the config bundle is readable from the project environment
  • the deployment is persisted and associated with the expected environment
  • the agent receives deployment targeting information
  • the control plane shows heartbeats or snapshots from the agent

If the deployment stalls

Check these first:

  • worker readiness and logs
  • whether the background job is retrying or dead-lettered
  • approval requirements for the target environment
  • whether the agent key is bound to the correct environment and scopes
  • whether requested tuning is blocked or degraded because the agent has not reported memlock, realtime scheduling, or CPU-pinning readiness
  • upload an artifact from the agent path and confirm it appears in the control plane
  • launch a dry-run replay from an incident artifact
  • review the audit record trail for deployment and membership changes
Provenance
Need the canonical source?
Use the public hub to orient yourself, then jump to repo-owned docs or rustdoc when you need contract-level detail.