Cloudflare Developers•3w ago

👋 We're migrating our Next.js app from

👋 We're migrating our Next.js app from Pages to Workers through OpenNext, and we're trying to set up preview URLs / non-production brunch deploys. In Pages, there's an option to set different variables for production and non-production deploys, but I don't see such an option in Workers. As far as I understand, we can have two environments in Wrangler, but that only allows us to set per-env runtime variables, not build variables. Has anyone figured out how to set it up?

9 Replies

texan•3w ago

Heyo! So workers doesn’t really have the concept of environments. Wrangler does though! So what I would suggest is having wrangler environments with all their different variables/bindings, and those will deploy to separate workers. Then you can configure each worker with its own build variables. It’s a little clunky, but yeah just because there’s not a direct 1:1 right now. It also means you have to set up each build separately in Workers CI, but it’s not too hard. I can certainly help you set something up though!

wojtodzioOP•3w ago

Hey, thanks a lot for the reply! If I understand correctly, based on what you said, I should: 1. Create 2 separate applications on Cloudflare ("production" and "staging") and connect both to the same repo. 2. Configure each application with its own build and runtime variables. 3. On "staging" I should enable preview URLs and non-production branch deploys. 4. In my wrangler.jsonc, I should add "staging" and "production" as 2 separate envs, each with its own name and bindings. Is that correct? This will cause our production branch to also deploy to "staging", but I think we can live with that. I'll test that setup now and report back 😉

texan•3w ago

Actually for 3) I would do it slight different. I’m assuming you want to auto deploy to staging, and have previews for all other branches? In that case you will enable non production builds, but your deploy command (and version upload command) need to be something like “npx wrangler deploy|versions upload -e staging. That way you just have one repo with the same wrangler file. Each worker is just looking to deploy the environment it cares about Everything else is correct 🙂 Production need not deploy to staging, actually! You can set your main branch to “staging” (or whatever your pre prod branch is), and only your deploy command will be executed against that branch. Everything else will get a special preview url In that case, you’ll get a version upload for prod, but you can ignore 🤓

wojtodzioOP•3w ago

Yes, exactly: I want to auto-deploy to staging and have previews for all other branches. I'm trying to recreate our setup from Pages, and previews were extremely helpful there. I actually have some issues with previews right now. My deploy command for the main branch is pnpm opennextjs-cloudflare deploy -- --env=staging, and it appears to work correctly: I can see my staging at web-staging.<SUBDOMAIN>.workers.dev, and it's correctly using my build and runtime variables defined in the workers dashboard. The issue starts when I try to deploy a preview. I initially tried with this non-production branch deploy command: pnpm opennextjs-cloudflare upload -- --env=staging. It creates a new preview with the correct build variables, but it also removes all runtime variables from the dashboard (even though I have "keep_vars": true in my Wrangler config), and then it can't access them at runtime. What's also confusing is that if I then add those variables back in the dashboard, clicking on the "deploy" button overrides my main branch deploy with the build from my last preview branch deploy. Then I tested changing my non-production branch deploy command to pnpm wrangler versions upload -- --env=staging and pnpm wrangler versions upload --env=staging. Those commands also create a new preview with the correct build variables. Unlike pennextjs-cloudflare upload, they respect "keep_vars": true and don't remove runtime variables; however, those runtime variables are also not available to my preview worker. I eventually set up all my runtime variables as secrets instead of variables, and this appears to work correctly: preview uploads don't remove them, and both my main and preview deploys can access them. I'll now run a few more tests and try to set up a production worker. For referrence, this is my current wrangler.jsonc:

{
  "name": "web",
  "$schema": "../../node_modules/wrangler/config-schema.json",
  "main": ".open-next/worker.js",
  "compatibility_date": "2025-10-02",
  "compatibility_flags": ["nodejs_compat", "global_fetch_strictly_public"],
  "assets": {
    "directory": ".open-next/assets",
    "binding": "ASSETS",
  },
  "placement": { "mode": "smart" },
  "observability": { "logs": { "enabled": true } },
  "limits": { "cpu_ms": 5000 },
  "keep_vars": true,
  "upload_source_maps": true,
  "env": {
    "staging": {
      "name": "web-staging",
      "services": [{ "binding": "WORKER_SELF_REFERENCE", "service": "web-staging" }],
      "r2_buckets": [
        { "binding": "NEXT_INC_CACHE_R2_BUCKET", "bucket_name": "next-incremental-cache-staging" },
      ],
      "preview_urls": true,
    },
    "production": {
      "name": "web-production",
      "services": [{ "binding": "WORKER_SELF_REFERENCE", "service": "web-production" }],
      "r2_buckets": [
        {
          "binding": "NEXT_INC_CACHE_R2_BUCKET",
          "bucket_name": "next-incremental-cache-production",
        },
      ],
    },
  },
}

{
  "name": "web",
  "$schema": "../../node_modules/wrangler/config-schema.json",
  "main": ".open-next/worker.js",
  "compatibility_date": "2025-10-02",
  "compatibility_flags": ["nodejs_compat", "global_fetch_strictly_public"],
  "assets": {
    "directory": ".open-next/assets",
    "binding": "ASSETS",
  },
  "placement": { "mode": "smart" },
  "observability": { "logs": { "enabled": true } },
  "limits": { "cpu_ms": 5000 },
  "keep_vars": true,
  "upload_source_maps": true,
  "env": {
    "staging": {
      "name": "web-staging",
      "services": [{ "binding": "WORKER_SELF_REFERENCE", "service": "web-staging" }],
      "r2_buckets": [
        { "binding": "NEXT_INC_CACHE_R2_BUCKET", "bucket_name": "next-incremental-cache-staging" },
      ],
      "preview_urls": true,
    },
    "production": {
      "name": "web-production",
      "services": [{ "binding": "WORKER_SELF_REFERENCE", "service": "web-production" }],
      "r2_buckets": [
        {
          "binding": "NEXT_INC_CACHE_R2_BUCKET",
          "bucket_name": "next-incremental-cache-production",
        },
      ],
    },
  },
}

texan•3w ago

Hmm, that sounds like like you might be hitting this? https://github.com/cloudflare/workers-sdk/issues/8871#issuecomment-3340611729 It looks like wrangler versions upload doesnt respect keep_vars. If we could address this to operate based on the value in the wrangler config, would that resolve things for you? (though might not be released until next week)

GitHub

Prevent secrets/env vars from being deleted when deploying via GitH...

Which Cloudflare product(s) does this pertain to? Workers Runtime What versions & operating system are you using? No local wrangler Please provide a link to a minimal reproduction No response D...

wojtodzioOP•3w ago

Yeah, this is it! And yeah, if it operated based on the value in the Wrangler config, that would resolve things for me. For now, we just changed all of our runtime variables to secrets, and that works fine, since secrets aren't affected by this. I see that https://github.com/cloudflare/workers-sdk/blob/main/packages/wrangler/src/versions/upload.ts#L704 mentions that wrangler's config should be the source-of-truth for vars, and I suppose we could also just put our variables there instead of setting them through the dashboard, but we want both our build and runtime variables to be the same, and since afaik there's no way to put build variables in the wrangler's config, this means wrangler's config can't be a single source-of-truth of this for us anyway 😉 Thanks a lot for the help! BTW., I think we're also getting hit by this: https://discord.com/channels/595317990191398933/1379873017651269723/1379873017651269723 i.e., we're getting "Failed to restore dependencies from build cache. Skipping.". It's not critical, we can live with it, but I thought I'd mention it in case there's anything I could do to help pinpoint the issue

GitHub

workers-sdk/packages/wrangler/src/versions/upload.ts at main · clo...

⛅️ Home to Wrangler, the CLI for Cloudflare Workers® - cloudflare/workers-sdk

texan•3w ago

Yup not a problem! I'll get a PR out to fix the keep_vars in wrangler (cross team collab). The pnpm cache I'm not as familiar with, and is probably with another team 🙁 I'll see if I can flag someome to look

johtso•3w ago

Also getting the same cache restoration error here and would love to know how to get it working!

texan•3w ago

Wrangler fix for respecting keep_vars: https://github.com/cloudflare/workers-sdk/pull/10865 Hoping to get this out for next week's release

Gaming

Programming

👋 We're migrating our Next.js app from

Did you find this page helpful?