Use Turborepo to validate the workspace, then deploy the target package with Devflare
In a Bun monorepo, Turborepo should own task orchestration, caching, and impact-aware validation, while still runs from the package that owns the Worker or app you are deploying.
This repository uses Turbo at the root and keeps local to each deployable package. That split is the important pattern: Turbo decides which packages to build, typecheck, test, or check, but actual deploy commands still run in the package that owns the resolved Devflare config.
- Best for
- Bun + Turborepo monorepos with more than one Devflare package
- Turbo role
- Validation, caching, filters, and impacted-package 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.
Use repo-root Turbo scripts for contributor and CI lanes
The repository now exposes explicit root scripts for the core Devflare workflow so contributors and CI can validate the workspace without guessing at filters every time.
Those scripts are validation and orchestration tools; they are not a replacement for the actual package-local deploy commands.
Repo-root validation lane
Targeted Turbo work from the repo root
Deploy one package at a time, 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 preview families still deploy package by package
is the repository example for the other half of the rule: Turbo can orchestrate the workspace, but a branch-scoped preview family still deploys each worker package separately with the same preview scope and naming inputs.
That is why the workflows keep consistent and run separate deploys for , , and the main app instead of pretending one root deploy magically owns the whole family.
Branch-scoped worker family deployment
Previous
Production deploys
Devflare keeps build and deploy flows inspectable, but deploys are intentionally explicit: production uses or , while preview is either a same-worker upload with plain or a named preview scope with .
Next
Preview strategies
Devflare supports both same-worker preview uploads and named preview scopes, but Durable Object-heavy apps often need a branch-scoped worker-family strategy instead of relying on preview URLs alone.