Overview

This reference is for a developer whose code runs on VantaCloud. It states how to deploy a workload, how your code reaches the platform’s resources, and how your workload is observed. VantaCloud is owned by STaRQ Industries and operated by The Clockwyrks.

A workload is the unit you deploy: one or more containers, the resources they need, the probes that tell the platform it is up, and the capabilities it uses. You declare it in a workload spec and the platform runs it on the compute target you name. Your code never holds a credential. Beside every workload runs the capability sidecar, a local service on the loopback interface, and your code asks it for what it needs: a secret’s upstream, a database connection, an object’s upload URL, a model call or an export of its telemetry.

Page	What it states
The Capability Sidecar	The loopback interface, the environment variables your code reads, the discovery document and each capability as your code calls it
The Workload Spec	Every field of the spec you write, its probes and its observability block among them
Observability	What the platform reports for you, what your code reports, your workload’s probes and uptime, and the alerts and dashboards you are given
Telemetry Conventions	Every metric and attribute name, its unit and its labels, the cardinality rule and the conventions version
Error Logging	The shape every error log record takes
The Telemetry Package	vantacloud-telemetry, the thin package per language that writes the conventions for you
Reading Your Telemetry	Where your logs, traces, metrics, uptime and alerts are read
The VantaCloud Protocol	The client-facing API of the open protocol
The Shared Crate	What the closed crate the components share exposes, and how it is versioned
Platform Types	The types the platform’s components share
Service APIs	The internal and admin APIs of the services

Getting started

1. Write a workload spec naming your image, its port, one probe, its observability block and the capabilities it uses, on the terms The Workload Spec states.
2. In your code, read the sidecar’s URLs from the environment and call each capability through them, on the terms The Capability Sidecar states.
3. Point your OpenTelemetry SDK at the sidecar, which the platform does for you by OTEL_EXPORTER_OTLP_ENDPOINT, and name your operations through the telemetry package or through the conventions with the plain SDK.
4. Apply the spec through the platform API. The workload is admitted once its spec declares at least one probe and its observability block, and its uptime, its default alerts and its dashboard follow without a step of yours.