Turborepo validates the workspace, Devflare deploys the target package
Turbo owns task orchestration and caching. still runs from the package that owns the Worker or app.
Turbo at the root, local to each deployable package. Turbo decides what to build; deploy commands run in the package that owns the config.
- Best for
- Bun + Turborepo monorepos with multiple Devflare packages
- Turbo role
- Validation, caching, filters, orchestration
- Deploy rule
- Run from the package that owns the config
Keep the workspace boundary clear
In a monorepo, Turbo and Devflare solve different problems. Turbo owns the workspace graph: cached builds, targeted checks, and “what changed?” filters. Devflare owns package-local Cloudflare behavior: config resolution, generated Wrangler output, preview logic, and production deploys.
That means every deployable package should still keep its own , package scripts, and package-specific runtime assumptions. Turbo should orchestrate those packages, not erase their boundaries.
- Keep one per deployable package or worker family member.
- Use repo-root Turbo scripts for validation lanes and targeted build/check work.
- Use package-local commands for actual build or deploy intent.
- Use GitHub workflow path filters or Turbo filters to decide whether a deploy job should run at all.
Know which layer owns what
| Layer | Owns |
|---|---|
| Turborepo | Task graph, caching, filters, workspace validation lanes, and targeted build/check/test/type flows. |
| Devflare | Config resolution, type generation, worker bundling, preview deploys, production deploys, and preview lifecycle commands. |
| GitHub Actions | Triggers, permissions, branch/PR policy, feedback, and the working directory that selects the target package. |
Good default review question
Ask two separate questions: “Which packages should Turbo run?” and “Which package is actually deploying?” Conflating those is how monorepo deploy flows get muddy.
Repo-root Turbo scripts for contributors and CI
The repo exposes root scripts for the core Devflare workflow so contributors and CI can validate without guessing at filters.
These are validation and orchestration tools, not a replacement for package-local deploy commands.
Root scripts keep Turbo orchestration separate from package deploys
Use root scripts for workspace validation and keep each app package responsible for the Devflare command that resolves its own config.
Repo-root validation lane
Targeted Turbo work from the repo root
Deploy from the package that owns the config
- 1
Use Turbo or path-aware workflow logic to decide whether a package is affected.
- 2
Optionally run Turbo build/check work for that package from the repo root.
- 3
Run from the package directory that owns the you actually want to resolve.
- 4
Keep preview-vs-production intent explicit in the final package-local deploy command.
Keep package selection explicit
If the deploy is for , make that obvious in the working directory or script name. The package boundary should be visible in logs and workflow steps.
Documentation app from a monorepo
Multi-worker previews deploy per-package
shows the other half: Turbo orchestrates the workspace, but a branch-scoped preview family still deploys each worker separately with the same preview scope.
The workflows keep consistent and run separate deploys for , , and the main app.
Branch-scoped worker family deployment
Previous
Production deploys
Production uses or , preview uses or . No target means no deploy.
Next
Preview strategies
Same-worker uploads, named preview scopes, and branch-scoped worker families serve different needs.