Start here
Modes
SDK reference
Shared reference
DocsShared referenceManifest format
weev generate scans your code and writes .weev/build/manifest.json — the workflow definition that weev push deploys. Version numbers and the content hash are assigned server-side; the manifest document itself carries neither.
Shape
{
"batches": [
{
"name": "monthlyBillingRun",
"jobs": [
{ "name": "loadActiveSubscriptions", "config": {} },
{ "name": "generateInvoices", "config": {} }
],
"dag": [
{ "from": "loadActiveSubscriptions", "to": "generateInvoices" }
] // omitted entirely when a batch has no edges
}
]
}ManifestContent
{ batches: BatchDefinition[] } — the only top-level field.
BatchDefinition
{ name, description?, jobs: JobDefinition[], dag?: DagEdgeDefinition[] }. The dag key is omitted (not []) when a batch has no edges.
JobDefinition
{ name, description?, config? }. config is currently unconstrained and emitted as {} by the scanner.
DagEdgeDefinition
{ from, to } — from is the predecessor job name, to the dependent job. Both must be jobs in the same batch.
Validation
generate and push run the same validator and collect every error rather than stopping at the first. A manifest is rejected for:Identity
generate records it in .weev/build/manifest.meta.json alongside scan warnings and per-job source locations; the server computes the same hash and assigns the monotonically increasing version on weev push. See the CLI reference for the push and deploy flow.