Get running in your own environment
Set up development, staging, and production with dual execution
- When everyone develops against production because there is no separate environment to test in.
- When a fixture that passes locally has never been checked against the platform it actually ships to.
Set up local DuckDB for development, and Microsoft Fabric or MotherDuck for staging and production, behind one dbt project with CI promotion and no shared credentials. Covers the environment wiring and the fixture proof that a model builds identically in both; it does not cover moving an existing production estate onto this structure.
Sample This Recipe has not been materialized in the Cookbook repository yet. Its trigger, description, prompt, agent guidance and acceptance conditions are prototype drafts. Its name, job, area and readiness come from the reconciled Cookbook seed snapshot. Readiness is a separate question from this one: it says whether the capability exists, not whether the writing has been reviewed.
Review planned Recipe
At least one capability or object type this Recipe needs is not supported yet.
Read the VibeData Recipe `environment-dual-execution` at https://getvibedata.ai/cookbook/environment-dual-execution At least one capability or object type this Recipe needs is not supported yet. Treat it as a reference, not as work to execute.
Recipe id environment-dual-execution · Not yet materialized in the Cookbook repository, so the pointer addresses this page.
Verified by
What has to be observably true before this Recipe is finished.
- the same model produces matching output when built in local DuckDB and in the production target on a fixture
- staging and production each resolve their own credentials with no secret shared between environments
- a change promoted through CI reaches production only after the staging build succeeds
- a developer can run the full project locally in DuckDB without touching production credentials
Recipe promptThe task specification the agent reads. Reference only — it is not what you copy.
Deliver: Set up development, staging, and production with dual execution. Set up local DuckDB for development, and Microsoft Fabric or MotherDuck for staging and production, behind one dbt project with CI promotion and no shared credentials. Covers the environment wiring and the fixture proof that a model builds identically in both; it does not cover moving an existing production estate onto this structure. Execute inside the current Intent. Its Domain, repository, platform, environment and attached sources are the context for this work — read them rather than asking for them. The work is done when: - the same model produces matching output when built in local DuckDB and in the production target on a fixture - staging and production each resolve their own credentials with no secret shared between environments - a change promoted through CI reaches production only after the staging build succeeds - a developer can run the full project locally in DuckDB without touching production credentials Report the evidence for each condition above with the result. A condition you cannot meet is something to say, not something to work around.
Agent guidanceHow the agent approaches the work, and what it will not do.
Read the estate before changing any part of it, and say what you found. Propose the wiring for review before creating anything, then build in an isolated copy so a wrong turn costs a rebuild rather than an environment.
Composes
- environment and credential wiring
- dbt in the project
- GitHub Actions in the project
- isolated-copy execution and gate verification
Asks first
Semantic decisions the Intent cannot supply. Never context Studio already holds.
- which Fabric target this work lands on, when the Domain carries both a Lakehouse and a Warehouse
Guardrails
- Build in an isolated copy. Production is read, never written.
- At least one capability this Recipe needs is not supported yet. Say so and stop rather than substituting a different approach.
I want three environments that are one project — a local loop where a run takes seconds and costs nothing, a staging estate that looks like production, and a production run that behaves the way the local one did.
Iterating against a metered warehouse is slow in two directions. Each run costs capacity you share with everyone else, and each run takes long enough that you stop making small changes and start making big ones — which is how a twelve-line diff becomes a two-hundred-line diff nobody can review. Iterating locally is fast, and it is only useful if the local result predicts the remote one.
Today the two halves drift. The local project accumulates DuckDB-flavoured SQL, the deployment fails on a type or a function that does not exist on the target, and after the third such failure the team quietly gives up on local development and goes back to the queue.
Here the project stays one project. Your data engineering agent develops against a local DuckDB estate, promotes the same code to staging, and runs it on production — and the platform-specific work, the SQL dialect, the type mapping, the isolation mechanism that gives each run its own copy, is handled per environment rather than written into your models.
What you need
- DuckDB locally, and the platform the project ships to — Microsoft Fabric or MotherDuck.
- A dbt project, or the intent to start one. This works from either end.
How it goes
- Point the development profile at the local DuckDB estate. Runs are seconds, so you can afford to be wrong often, which is the whole benefit.
- Declare staging and production as targets of the same project, not as copies of it. One set of models, three places they run.
- Build and iterate locally. Models, tests, and documentation land the way they would anywhere else.
- Ask for the target check before you promote. It reports what in the project is platform-specific and what will need to differ — while the change is still small enough to fix cheaply.
- Run against staging in an isolated copy. Production tables are untouched; you are proving the project runs on the target, not deploying it.
- Reconcile the two runs. Local output against staging output, row by row. A dialect difference that quietly rounds differently shows up here as a number, which is the only form in which anyone notices it.
- Promote. What ships is the project you developed, not a version of it rewritten for the target.
What you end up with
One project that runs in three places, and evidence that it produces the same numbers in each. You also get your iteration loop back: developing against a four-second local run changes how small a change you are willing to make.
When this is not the Recipe you want
If your sources only exist in the remote platform and cannot be sampled locally, develop against an isolated copy in that workspace instead. The isolation still holds; the four-second loop does not.