What is the proper way to use environments with generated wrangler config?

[mohamnag]

Environment

node v22.16.0
wrangler 4.22.0
nitropack 2.11.13

Reproduction

check this code: https://github.com/mohamnag/nitro-wrangler-bug
run: npm run build && npx wrangler dev

see the error

Describe the bug

I have been using wrangler configured with a standalone wrangler.jsonc file to manage deployments to different environments where I just discovered the new cloudflare config for cloudflare_module preset. this would simplify life a bit for me as some things like the compatibility date does not need to be set in many places and things that can be configured by nitro itself can be taken care of too. however it looks like the wrangler does not like the generated file having different environments in it. I'm getting the following error trying to deploy the results or even run it in preview mode:

 ⛅️ wrangler 4.22.0
───────────────────
Using redirected Wrangler configuration.
 - Configuration being used: ".output/server/wrangler.json"
 - Original user's configuration: "wrangler.jsonc"
 - Deploy configuration file: ".wrangler/deploy/config.json"

✘ [ERROR] Processing .output/server/wrangler.json configuration:

    - Redirected configurations cannot include environments but the following have been found:
      	- production


      Such configurations are generated by tools, meaning that one of the tools
      your application is using is generating the incorrect configuration.
      Report this issue to the tool's author so that this can be fixed there.

I can workaround this by giving wrangler the generated config file directly (i.e. -c .output/server/wrangler.json) but that is a bit shaky to me (as the file can be renamed, ...). Is there a solid concept on how one is supposed to still use the wrangler's feature for managing different environments without this workaround and without hitting that error?

Additional context

No response

Logs

[MarioAda]

Same issue here.

Cloudflare wants the generated wrangler.json to contain only a default environment, not multiple.

In Vite you can set CLOUDFLARE_ENV to production or staging, and a flattened wrangler.json is generated on build: https://developers.cloudflare.com/workers/vite-plugin/reference/cloudflare-environments/

Not sure how to do that in Nitro....

[Perdolique]

It's actually a good question, especially when Cloudflare encourages users to migrate from Pages to Workers + Assets, and Nitro has a new default preset cloudflare-module.

This documentation explains how the new build system works with a good example. But Nitro can't handle it by adding the --env flag during deployment of built code.

[sumerokr]

Facing the same issue and can't figure out how it can be solved.
Update: solved this challenge for my needs. See below.

[chz]

@pi0 +

[sumerokr]

I've managed to solve it for my needs.
I have one project on GitHub.
It is connected to two workers on CF.
Whenever I push to master branch, the production worker gets updated.
Whenever I push to staging branch, the staging worker gets updated.
I leverage this Nuxt Environment Overrides functionality to make everything work nice. It seems to be a right solution without dirty tricks.

My nuxt.config.ts looks like this. It can give you an idea of how to setup two different ENVs for one codebase.
You can ignore the storage configuration, it is not that relevant, but can give you an idea of how to use it.

export default defineNuxtConfig({
  $env: {
    development: {
      nitro: {
        storage: {
          kv: {
            driver: 'fs',
            base: './.tmp',
          },
        },
      },
    },
    production: {
      nitro: {
        cloudflare: {
          wrangler: {
            name: 'NAME_OF_MY_PRODUCTION_WORKER',
            routes: [
              {
                pattern: 'MY_PRODUCTION_DOMAIN',
                custom_domain: true,
              },
            ],
            kv_namespaces: [
              {
                binding: 'KV',
                id: 'MY_PRODUCTION_KV_ID',
              },
            ],
          },
        },
      },
    },
    staging: {
      nitro: {
        cloudflare: {
          wrangler: {
            name: 'NAME_OF_MY_STAGING_WORKER',
            routes: [
              {
                pattern: 'staging.MY_PRODUCTION_DOMAIN',
                custom_domain: true,
              },
            ],
            kv_namespaces: [
              {
                binding: 'KV',
                id: 'MY_STAGING_KV_ID',
              },
            ],
          },
        },
      },
    },
  },
  nitro: {
    preset: 'cloudflare_module',
    cloudflare: {
      deployConfig: true,
      nodeCompat: true,
    },

    storage: {
      kv: {
        driver: 'cloudflare-kv-binding',
        binding: 'KV',
      },
    },
  },
});

Here is how it looks like in CF. There are two Workers, one for each environment.

Here is my scripts section from the package.json file

"build": "nuxt build",
"build-staging": "nuxt build --envName=staging",

In my NAME_OF_MY_STAGING_WORKER project, I adjusted Settings / Build / Build configuration to
Build command: npm run build-staging
Deploy command: npx wrangler deploy

The NAME_OF_MY_PRODUCTION_WORKER has default settings.
Preview URLs are disabled on CF, I find them useless, since you cannot set different ENV variables for preview env.
Instead I have the same set of variable names in both workers, but with different values accordingly.

[chz]

Nice but i actually use wrangler environments but there are issue where if wrangler config autogenerated its not working with multiple env.

{
  "compatibility_date": "2025-07-15",
  "name": "xxxx",
  "env": {
    "dev": {
      "vars": {
      }
    },
    "prod": {
      "vars": {
      }
    }
  },
  "placement": {
    "mode": "smart"
  },
  "observability": {
    "logs": {
      "enabled": true
    }
  },
  "main": ".output/server/index.mjs",
  "assets": {
    "binding": "ASSETS",
    "directory": ".output/public"
  },
  "compatibility_flags": [
    "nodejs_compat",
    "no_nodejs_compat_v2"
  ]
}

then

"scripts": {
    "build": "nuxt build",
    "dev": "nuxt dev -p 3000 --host 0.0.0.0 --dotenv .dev.vars.dev",
    "dev:prod": "nuxt dev -p 3000 --host 0.0.0.0 --dotenv .dev.vars.prod",
    "preview:dev": "nuxt build && wrangler versions upload --env dev --message \"$(git log -1 --pretty=%s)\"",
    "preview:prod": "nuxt build && wrangler versions upload --env prod --message \"$(git log -1 --pretty=%s)\"",
    "workers:dev": "nuxt build && wrangler dev --cwd .output --env dev",
    "workers:prod": "nuxt build && wrangler dev --cwd .output --env prod",
    "deploy:dev": "npx wrangler deploy --env dev --keep-vars --minify",
    "deploy:prod": "npx wrangler deploy --env prod --keep-vars --minify",
    "postinstall": "nuxt prepare",
    "lint": "eslint .",
    "lint:fix": "eslint . --fix",
    "cf-typegen": "wrangler types --include-env=false"
  }

But i dont know is it ideal version ? or your version.

[chz]

Then dashboard will show this.

[chz]

@pi0, @danielroe what do you think? which variant is better?

[chz]

Also i think it must be documented with multiple environments with passing variable examples.

[mohamnag]

I'm just calling wrangler with the option that sets configuration file directly to the generate file (something like wrangler -c .output/server/wrangler.json ...). generally my POV is that:

1. what wrangler does alone should be possible to be used from it directly. this includes configuring all the environments and setting variables along other config per env. I don't want to put it inside nuxt config file or even pass it through it.
2. it is a very easy to spot bug for nuxt guys if they look at it, so will just wait for it to be fixed.

[MarioAda]

Our solution:

1. Create a separate worker for each environment.
2. Create configuration files such as wrangler.staging.json, wrangler.production.json, etc.
3. In each worker’s build command, copy the appropriate config file to wrangler.json before building. For example: cp wrangler.staging.json wrangler.json && build

[sumerokr]

@MarioAda this is actually simple and elegant, I like your idea!

[mohamnag]

wrangler itself creates different workers per env. Also I personally see a value in having all the config in a single file. but yes there are multiple solutions to this buggy behaviour.

[chz]

wrangler itself creates different workers per env. Also I personally see a value in having all the config in a single file. but yes there are multiple solutions to this buggy behaviour.

Exactly autocreated wrangler dont work properly thats why i'm created manual wrangler.json file