Root Cause
Mastra’s deployer pre-bundles every dependency discovered during analyzeBundle, even if the dependency is declared external. The createVirtualDependencies helper always generates a mini entry file that re-exports each symbol from the original module (export { … } from 'zod/v3'), and the alias-optimized-deps plugin later rewrites every import 'zod/v3' to point back at that generated file. When the generated file is instructed to import from zod/v3, the alias kicks in again and resolves the import back to the same file, so Rollup detects a self-referencing export (.mastra/.build/zod‑v3.mjs -> .mastra/.build/zod‑v3.mjs) and aborts the build.
bundleExternals.tsLines 33-80
  for (const [dep, { exports }] of depsToOptimize.entries()) {    …    if (exportStringBuilder.length) {      virtualFile.push(`export ${chunks.join(', ')} from '${dep}';`);    }    …    optimizedDependencyEntries.set(dep, {      name: entryName,      virtual: virtualFile.join('\n'),    });  }
The alias plugin shows why the re-export points back to the same file: anything in analyzedBundleInfo.dependencies (such as zod/v3 or zod/v4) is replaced with the absolute path of the generated chunk. Once this occurs inside the generated chunk itself, Rollup encounters the “export references itself” error reported in Mastra Cloud.
bundler.tsLines 63-90
plugins: [  {    name: 'alias-optimized-deps',    resolveId(id: string) {      if (!analyzedBundleInfo.dependencies.has(id)) {        return null;      }      const filename = analyzedBundleInfo.dependencies.get(id)!;      const absolutePath = join(workspaceRoot || projectRoot, filename);      …      return {        id: absolutePath,        external: false,      };    },  },
Because bundleExternals never removes externals from depsToOptimize, zod/v3 and zod/v4 are still pre-bundled even though you marked zod as an external.
bundleExternals.tsLines 398-444
const allExternals = […GLOBAL_EXTERNALS, …DEPRECATED_EXTERNALS, …customExternals];…const { optimizedDependencyEntries } = createVirtualDependencies(depsToOptimize, …);const output = await buildExternalDependencies(optimizedDependencyEntries, {  externals: allExternals,  …});
The debug build log shows Mastra detecting both zod/v3 and zod/v4 during dependency analysis, so they are fed into this flow and end up as .mastra/.build/zod-v3.mjs / .mastra/.build/zod-v4.mjs.
mastra-debug.logLines 190-206
"zod/v4" is imported by "../../node_modules/@mastra/server/dist/chunk-OQPXME7E.js", …"zod/v3" is imported by "../../node_modules/@mastra/server/dist/chunk-OQPXME7E.js", …
Proof the result is self-referential
The generated chunk clearly contains the Zod implementation, and Rollup’s error complains specifically about ZodFirstPartyTypeKind being re-exported from that same chunk—confirming that the alias loop occurred at bundle time rather than in your application code.
zod-v3.mjsLines 1-40
var util;(function (util) {  …})(util || (util = {}));
Path to Resolution
Fix the bundler once: Before calling createVirtualDependencies, drop any dependency whose id or package root matches an entry in allExternals. In practice:
Normalize allExternals to include both the exact specifier and the bare package name (e.g., add zod, zod/v3, zod/v4, and their /* aliases).
Loop through depsToOptimize and delete any entries whose specifier matches that normalized set (or whose getPackageName(dep) matches).
After this change, zod/v3 and zod/v4 are never pre-bundled, so the alias plugin no longer rewrites them to .mastra/.build/*, eliminating the self-import cycle.
Short-term mitigation (if Mastra Cloud uses the published bundler): vendor the patched @mastra/deployer in your repo (e.g., install from a Git tag or npm alias) or run mastra build locally with the patched package and deploy the output artifact manually.
Verification: Once the patch is in place, remove the zod-v3/zod-v4 entries you added to externals. Re-run bun run build with MASTRA_BUNDLER_DEBUG=true to confirm that:
zod/v3 and zod/v4 no longer appear in the “Optimizing dependencies” list.
.mastra/.build/ no longer contains the zod-v3.mjs / zod-v4.mjs files.
The Mastra Cloud deployment succeeds without the circular export warnings.
This is a bundler defect, not a configuration mistake in your app. The durable fix is to teach bundleExternals to respect externals earlier in the pipeline so self-referencing virtual modules are never created.