Quick Start: First Deployment
Synced from repo docs
This page is synced from docs/guides/quick-start-first-deployment.md via docs/public-docs.json. Edit the owning repo source instead of this generated copy. GitHub source: https://github.com/byteor-systems/byteor-cloud/blob/master/docs/guides/quick-start-first-deployment.md
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
- Start the stack with
scripts/dev_up.shordocker compose up --build. - Open the UI and sign in.
- Create or select an organization and project.
- Create an environment for the project.
- Create or open a pipeline draft.
- Choose the explicit execution target in the editor:
SingleRingfor ordered linear pipelines orLaneGraphfor branching, fanout, merge, and richer topology work. - 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.
- Save the draft.
- 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.
- Create a config bundle for that version.
- In the config-bundle composer, start from a guided runtime tuning profile and only drop to raw tuning fields when you need explicit overrides.
- Register an agent in the target environment.
- Create a deployment.
- Verify that the registered agent sees the deployment and begins reporting state.
- 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
Recommended next steps
- 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