Repository navigation
Conversation
Workflows became a valid Blueprint service type on 2026-09-16, but the skill still described services as web/worker/cron/pserv/keyvalue/static only. Adds the workflow row and a validated example, a dedicated field-reference section, three common mistakes, the preview-environment skip rule, and the envVars wiring note. Two requirements are recorded that the published JSON schema does not express. Its required array is [type, name, runtime, region, startCommand], but Render's validator also rejects a workflow missing buildCommand or repo. An agent trusting the schema alone emits an invalid Blueprint.
MCP exposes create_web_service and create_static_site, with no create_workflow, so the single-service shortcut cannot deploy an app that defines workflow tasks. Sends those apps down the Blueprint path even when the workflow is the only service, adds workflow to the service-type list and comparison table, and documents required fields plus the never-set-plan rule.
These skills each touch a surface that behaves differently for workflows, and several implied constraints that no longer hold. - cron-jobs, background-workers: cron and workflow compose in one Blueprint; workflows are not a replacement for a healthy queue worker - mcp: no create_workflow tool exists - cli: render workflows init/dev/tasks, and validate accepts type: workflow - env-vars, networking: envVars apply to every task run; workflows are outbound-only and cannot be a fromService host target - scaling, disks, docker: no plan/numInstances/scaling, no disks, and Blueprint runtimes are python and node only - debug: task-run failures surface in run history, not health checks or PORT
ojusave
left a comment
ojusave
left a comment
There was a problem hiding this comment.
Flagging the three hunks most worth a careful read. Each encodes behaviour that contradicts either the published schema or how other service types work, so they are the ones I would most want a second opinion on.
|
|
||
| **Required:** `type`, `name`, `runtime`, `region`, `startCommand`, and in practice `buildCommand` and `repo`. | ||
|
|
||
| The published schema's `required` array lists only the first five, but Render's validator also rejects a workflow missing `buildCommand` (`buildCommand is required for non-docker workflows`) or `repo` (`repo is required for git-based services`). Always emit both. |
There was a problem hiding this comment.
This is the hunk I would most like checked.
The schema's required array for workflowService is [type, name, runtime, region, startCommand], but the validator rejects a workflow missing buildCommand or repo:
buildCommand is required for non-docker workflows
repo is required for git-based services
repo is the genuinely surprising one. It is required even when validating from inside the repository with an origin remote, whereas a web service in the same directory validates fine without it.
If the intent is for the schema to be authoritative, this is arguably a schema bug rather than something to document. Happy to file it separately and soften the wording here if you would prefer that.
|
|
||
| The published schema's `required` array lists only the first five, but Render's validator also rejects a workflow missing `buildCommand` (`buildCommand is required for non-docker workflows`) or `repo` (`repo is required for git-based services`). Always emit both. | ||
|
|
||
| **`runtime`:** `node` or `python` only. This is narrower than `render workflows create --runtime`, which also accepts `go`, `ruby`, and `elixir`. Workflows in those runtimes cannot be declared in a Blueprint. |
There was a problem hiding this comment.
Blueprints accept python and node; render workflows create --runtime also accepts go, ruby, and elixir. Included because the failure is otherwise confusing: you can create a Go workflow with the CLI and then find no way to express it in render.yaml.
Related, and covered in #15: render blueprints validate returns valid: true for runtime: docker on a workflow even though the schema rejects it, so a passing validate is not proof a runtime is supported.
| - Monorepo or multi-env setup that needs consistent configuration | ||
|
|
||
| If unsure, ask a quick clarifying question, but default to Blueprint for safety. For a single service, strongly prefer Direct Creation via MCP and guide MCP setup if needed. | ||
| MCP has `create_web_service` and `create_static_site`, not `create_workflow`. If the app has workflow tasks, use Blueprint even if the workflow is the only service. Detect workflows by Python `@app.task` from `render`, or TypeScript `task()` from `@renderinc/sdk/workflows`. |
There was a problem hiding this comment.
The behavioural change in this PR. Previously a single-service app went to MCP, but MCP has no create_workflow, so an app whose only service is a workflow had no working path.
The detection heuristic is deliberately narrow: Python @app.task imported from render, or TypeScript task() from @renderinc/sdk/workflows. Worth confirming those are the only entry points you want matched.
|
Closing: opened against the wrong repo. Internal development happens in Thanks @ttacon for the pointer. The internal versions also update |
1 participant
Render Workflows became a valid Blueprint service type on 2026-09-16 (changelog). The skills still described Blueprints as web/worker/cron/pserv/keyvalue/static only, so an agent asked to put a workflow in
render.yamlhad nothing to work from and would fall back to the Dashboard.This PR updates the twelve skills that touch a surface where workflows behave differently. It does not touch
render-workflowsitself: that skill sits on top of #13, so its changes are in a separate stacked PR.What changed
render-blueprintsgains theworkflowservice type: a row in the service table, a validated example, a dedicated field-reference section, three entries in common mistakes, the preview-environment skip rule, and a wiring note.render-deploynow routes apps with workflow tasks to the Blueprint path. MCP hascreate_web_serviceandcreate_static_sitebut nocreate_workflow, so the single-service shortcut cannot deploy them, even when the workflow is the only service.Ten platform skills get the constraint that applies to each:
cron-jobsandbackground-workerson composition (cron and workflow pair in one Blueprint, and a workflow is not a drop-in for a healthy queue worker),mcpon the missing tool,clionrender workflows init|dev|tasks,env-varsandnetworkingon outbound-only behaviour and per-task-run env vars,scalinganddisksanddockeron the fields that do not apply, anddebugon where task-run failures actually surface.Two requirements the JSON schema does not express
Worth a close look, since they are the ones most likely to bite an agent.
The published schema's
requiredarray forworkflowServiceis[type, name, runtime, region, startCommand]. Render's validator additionally rejects a workflow that omits either of these:repois the surprising one. It is required even when validating from inside the repository with anoriginremote, which is not howweband other git-based types behave. Awebservice in the same directory validates without it. An agent that trusts the schema'srequiredarray alone will emit a Blueprint that fails on sync, so both are documented as required in practice.Validation
Every
type: workflowsnippet in this PR was checked two ways: againsthttps://render.com/schema/render.yaml.json, and throughrender blueprints validate(CLI v2.28.0), which returns a plan containing aworkflowsentry for each. All pass.I also confirmed the guidance by deploying a workflow built from these docs to a live workspace. It built, registered its tasks, and a chained
ctx.runtask returned the expected result. The test workflow and its repository have been deleted.The negative guidance is verified rather than assumed:
plan,disk, andscheduleon a workflow are each rejected by the validator, which is why those are called out as mistakes.One caveat I could not close:
POST /v1/blueprintsreturns 405, so Blueprint creation is not scriptable. The Blueprint path was verified through the server-side planner and by deploying the identical configuration as a live workflow service, not by clicking through a Dashboard sync.