Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.cyberun.cloud/llms.txt

Use this file to discover all available pages before exploring further.

A container service in Cyberun Cloud is a long-running container that your team’s agents host on your hardware. Where a task is a single run of a workflow, a container service is a process that stays up — useful for inference servers, model proxies, dashboards, or any side-car your workflows depend on. If container services aren’t enabled on this deployment, the Containers entry won’t appear in the sidebar.

​
What a service definition holds

  • Slug — lowercase identifier of 3–100 characters using letters, digits, and hyphens (pattern ^[a-z0-9][a-z0-9-]{1,98}[a-z0-9]$). Used in API paths and URLs. Immutable once created.
  • Display name and description — human-readable labels.
  • Docker image — the image to run, e.g. vllm/vllm-openai:latest or pinned by digest. Must be reachable from the agent’s container runtime; private registries need credentials configured on the agent host.
  • Exposed port — the in-container port (1–65535) the service listens on. Defaults to 8080.
  • Health path — HTTP path Cloud probes. Defaults to /health.
  • Environment variables — key/value pairs passed into the container.
  • Volumes — host-path → container-path mounts. Use to share model directories or persistent state with the host.
  • Required labels — same label model as workflows. Only agents with a superset of these labels are eligible.
  • GPU count — number of GPUs to allocate. 0 for CPU-only (default), a positive integer for a specific count, or -1 to let the container see every GPU on the host.
  • Replica count — how many instances to keep running (1–10).

​
Lifecycle

A service definition moves through these states:
  • created — the definition exists but no replicas have been scheduled. The initial state after Create.
  • deploying — agents are pulling the image and starting containers.
  • running — at least one replica is up.
  • stopping — an Undeploy is in progress.
  • stopped — no replicas; the definition is preserved so you can redeploy.
  • failed — deployment did not succeed and no replica is healthy. Check the replica’s health and logs to diagnose.
Each running replica also carries an instance status (one of pending, pulling, running, stopping, stopped, failed) and an independent health status (unknown, healthy, unhealthy) based on probes against the health path.

​
Actions

From the detail page:
  • Deploy — schedule replicas onto eligible agents.
  • Undeploy — stop replicas. The definition stays so you can redeploy later.
  • Edit — change definition fields. Image, exposed port, and volume changes generally need a redeploy to take effect on running replicas.
  • Delete — remove the definition. Replicas are stopped first.