Repository navigation
Conversation
The skill stated that Blueprints were not compatible with Workflows. That stopped being true on 2026-09-16, so an agent reading it would refuse a render.yaml workflow or send the user to the Dashboard unnecessarily. Replaces that guidance with a validated type: workflow example and records four behaviours confirmed against the live API and CLI: - buildCommand and repo are required in practice. The published schema's required array omits both, but the validator rejects a workflow without either. repo is required even when validating from inside the repository, which is not how web and other git-based types behave. - Blueprint runtime is python or node only, narrower than render workflows create, which also takes go, ruby, and elixir. - render blueprints validate accepts runtime: docker on a workflow even though the schema rejects it, so a passing validate does not prove a runtime is supported. - Preview environments skip workflow services. Verified by deploying the documented example to a live workspace: the workflow built, registered its tasks, and a chained ctx.run task returned the expected result.
ojusave
left a comment
ojusave
left a comment
There was a problem hiding this comment.
Notes on the four hunks that encode tested behaviour rather than documented behaviour. Each one is a case where following the published docs or schema alone produces a Blueprint that does not work.
|
|
||
| Do **not** set `plan` on a workflow service. Task compute is configured in code (`plan` on the task), not on the service. MCP cannot create workflow services. | ||
|
|
||
| Blueprint `runtime` is `python` or `node` only, which is narrower than `render workflows create`, whose `--runtime` also accepts `go`, `ruby`, and `elixir`. Create a workflow in one of those runtimes with the CLI or Dashboard, not a Blueprint. Note that `render blueprints validate` currently accepts `runtime: docker` on a workflow even though the published schema rejects it, so a passing validate is not proof that a runtime is supported. |
There was a problem hiding this comment.
Two separate traps in one paragraph.
The runtime sets do not match: render.yaml takes python and node, while render workflows create --runtime also takes go, ruby, and elixir. There is a live workflow running runtime: go that could not be expressed in a Blueprint, which is what prompted the note.
The second half matters more for agents: render blueprints validate returns valid: true for runtime: docker on a workflow even though the schema rejects it. An agent that treats a passing validate as confirmation will ship a broken service.
| sync: false | ||
| ``` | ||
|
|
||
| Keep `repo` on workflow services. Unlike `web` and other Git-based types, `render blueprints validate` reports `repo is required for git-based services` for a workflow even when the file is validated from inside that repository with an `origin` remote. Set `repo` explicitly so validation passes. |
There was a problem hiding this comment.
This corrects something I had initially written the other way round.
I had assumed repo could be omitted when render.yaml lives alongside the workflow, and that validate only needed it when run from outside. Testing disproved it: running validate from inside the repository, with a correct origin remote, still fails with repo is required for git-based services. A web service in the same directory validates without it, so the requirement is specific to workflows.
|
|
||
| Required Blueprint fields: `type`, `name`, `runtime`, `region`, `startCommand`, plus `buildCommand` and `repo` in practice. Optional: `branch`, `rootDir`, `buildFilter`, `autoDeployTrigger`, `envVars` (applied to every task run). | ||
|
|
||
| The published JSON schema lists only `type`, `name`, `runtime`, `region`, and `startCommand` as required, but Render's validator also rejects a workflow that omits `buildCommand` (`buildCommand is required for non-docker workflows`) or `repo` (`repo is required for git-based services`). Always include both. Do not treat the schema's `required` array as the complete set. |
There was a problem hiding this comment.
The schema's required array is [type, name, runtime, region, startCommand], but the validator also rejects a workflow missing buildCommand or repo. Since agents are pointed at the schema URL as the source of truth, the gap is worth stating explicitly.
If you would rather fix the schema than document around it, I am happy to open an issue and reduce this to a short pointer.
| | Symptom | Cause | Fix | | ||
| |---------|-------|-----| | ||
| | Schema / validate error on `plan` | Service-level `plan` is not allowed on workflows | Remove `plan`. Set compute on the task in code. | | ||
| | Workflow deploys but behaves unexpectedly with `runtime: docker` | Workflow runtimes are `python` and `node` only. `render blueprints validate` currently accepts `runtime: docker` on a workflow even though the published schema rejects it, so a passing validate is not proof the runtime is supported | Use `runtime: python` or `runtime: node`. Validate against `https://render.com/schema/render.yaml.json` rather than trusting the CLI result alone | |
There was a problem hiding this comment.
This row previously said runtime: docker produces a schema error from the CLI. It does not: validate returns valid: true. Someone hitting a broken Docker workflow would have gone looking for a validation error that never appears.
Rewritten around the observable symptom, with the fix pointing at the schema rather than the CLI.
|
Closing: opened against the wrong repo. Internal development happens in Thanks @ttacon for the pointer. The internal versions also update |
1 participant
The skill said Blueprints were not compatible with Workflows:
That stopped being true on 2026-09-16 (changelog). An agent reading this would refuse a perfectly valid
render.yamlworkflow or send the user to the Dashboard for no reason. This replaces that guidance with a validated example and makes Blueprint the preferred path when the repo already uses IaC.Behaviours documented here
Each of these came out of testing against the live API and CLI rather than from the docs, and each is something an agent would otherwise get wrong.
buildCommandandrepoare required in practice. The published schema'srequiredarray is[type, name, runtime, region, startCommand], but the validator also rejects a workflow missing either of:repois required even when validating from inside the repository with anoriginremote. Awebservice in the same directory validates without it, so this is workflow-specific and easy to trip over.Blueprint runtimes are narrower than the CLI's.
render.yamlacceptspythonandnode.render workflows create --runtimealso acceptsgo,ruby, andelixir. A workflow in one of those runtimes cannot be declared in a Blueprint at all, so the skill now points those cases at the CLI or Dashboard.A passing
validatedoes not prove a runtime is supported.render blueprints validatereturnsvalid: trueforruntime: dockeron a workflow, while the published schema rejects it. The troubleshooting table previously claimed the CLI raises a schema error there, which would send someone chasing the wrong problem. Corrected to say the CLI is lenient and to check the schema.Preview environments skip workflow services. Other Blueprint resources still replicate, and there is no
previews.generationknob that forces a workflow into a preview stack.Validation
The
type: workflowexample passes both the JSON schema andrender blueprints validate(CLI v2.28.0), which returns a plan with aworkflowsentry.I also deployed the documented example to a live workspace rather than relying on validation alone. Using the exact
main.pypattern this skill teaches (@app.task,TaskContextfirst, chaining viactx.run), the workflow built, registered all three tasks, and the chained task returned{"greet": "hello deployed-world", "ping": "pong"}. The local path inrender workflows devproduced the same result. The test workflow and repository have been deleted.This also confirms two claims the SDK 1.x work in #13 makes:
pip install renderresolves to "Python SDK for Render Workflows" 1.1.0, andTaskContext,Workflows,Render,RenderAsync, andRetryall import fromrender.