🐞 Dev mode fails when bindings are defined via `nuxt.config.ts` instead of `wrangler.jsonc`

[mrkaashee]

Hi 👋

I previously opened an issue regarding multi-deployment and dev bindings. The suggested solution (using $production.nitro.preset: 'cloudflare_module') works well and solved that use case — thanks for that.

However, I ran into another issue when trying to configure Cloudflare resources entirely from nuxt.config.ts (it works fine in production but throws an error in development).

---

Environment

• Nuxt: 4.4.2
• @nuxthub/core: 0.10.7
• Nitro: 2.13.1

---

Working setup (with wrangler.jsonc)

When bindings are defined in wrangler.jsonc, everything works correctly in both dev and production.

export default defineNuxtConfig({ 
  nitro: { 
    preset: 'cloudflare_module', 
    cloudflare: { 
      deployConfig: true, 
      nodeCompat: true 
    } 
  }, 
  hub: { 
    db: 'sqlite', 
    blob: true, 
    cache: true, 
    kv: true 
  } 
})

{ 
  "d1_databases": [
    { 
      "binding": "DB",
      "database_name": "...",
      "database_id": "xxxx",
      "migrations_table": "_hub_migrations",
      "migrations_dir": "server/db/migrations/sqlite/" 
    }
  ], 
  "r2_buckets": [
    { 
      "binding": "BLOB", 
      "bucket_name": "..." 
    }
  ], 
  "kv_namespaces": [ 
    { 
      "binding": "CACHE", 
      "id": "xxxx" 
    }, 
    { 
      "binding": "KV", 
      "id": "xxxx" 
    } 
  ] 
}

Dev server starts normally and migrations run correctly.

---

Non-working setup (bindings defined in nuxt.config.ts)

If I try to define the bindings through nitro.cloudflare.wrangler and hub configuration instead of wrangler.jsonc, dev mode fails.

export default defineNuxtConfig({ 
  nitro: { 
    preset: 'cloudflare_module', 
    cloudflare: { 
      deployConfig: true, 
      nodeCompat: true, 
      wrangler: { 
        name: process.env.NAME, 
        observability: { enabled: true },
      } 
    } 
  }, 
  hub: { 
    db: { 
      dialect: 'sqlite', 
      driver: 'd1',
      connection: { databaseId: process.env.DATABASE_ID } 
    }, 
    kv: { 
      driver: 'cloudflare-kv-binding', 
      namespaceId: process.env.KV_ID 
    }, 
    cache: { 
      driver: 'cloudflare-kv-binding', 
      namespaceId: process.env.CACHE_ID 
    }, 
    blob: { 
      driver: 'cloudflare-r2', 
      binding: 'BLOB', 
      bucketName: process.env.BLOB_NAME
    } 
  } 
})

---

Error in dev

Dev server starts but migrations fail:

[nuxt:hub] ERROR Failed to create migrations table
[nuxt-hub] DB binding not found

Interestingly, the logs show that nuxt-hub correctly identifies the desired driver:

hub:db using sqlite database with d1 driver
hub:kv using cloudflare-kv-binding driver
hub:cache using cloudflare-kv-binding driver
hub:blob using cloudflare-r2 driver

However, even though the database is appropriately configured in the hub object, the Cloudflare dev emulator (Miniflare) does not seem to provide the DB binding globally.

Note on drivers: If I use the shorthand db: 'sqlite', it works only because it falls back to the libsql driver locally (creating a file in .data/db), which avoids the binding requirement but diverges from the intended "Cloudflare-emulated" setup. Replacing it with an explicit driver: 'd1' configuration consistently reveals the missing binding.

---

Expected behavior

If bindings are defined via nitro.cloudflare.wrangler / hub configuration, they should also be injected into the local development context by Nitro/Miniflare, without requiring a physical wrangler.jsonc file on disk.

This would allow keeping all infrastructure configuration inside nuxt.config.ts, which is especially useful for:

• Multi-deployment setups (switching IDs via env vars in nuxt.config.ts)
• CI/CD driven configuration
• Avoiding project-specific wrangler.jsonc files

Question

Is this a known limitation where the local emulator specifically requires a physical config file, or should Nitro / NuxtHub be syncing these code-defined bindings to the emulator environment?

Thanks!

[nathanschram]

I dug into both the NuxtHub and Nitro source for this one and I think I found the gap.

The shorthand config (db: 'sqlite') works in dev because NuxtHub falls back to the libsql driver locally - it creates a SQLite file in .data/db and doesn't need any Miniflare bindings. You spotted this already. When you switch to explicit driver: 'd1', you're opting into the Cloudflare D1 path which needs Miniflare to provide the actual bindings.

The core issue is in how Nitro handles dev mode vs deployment. When NuxtHub registers bindings programmatically (via addWranglerBinding() which sets nitro.options.cloudflare.wrangler), that config is used at build/deploy time - Nitro's writeWranglerConfig() merges it with any physical wrangler file. But for dev mode, Nitro's cloudflareDevModule() only looks for a physical wrangler.json/jsonc/toml file on disk and passes that path to Wrangler's getPlatformProxy(). The programmatic config from nuxt.config.ts never reaches Miniflare during dev.

So it's not really an env var issue - even if your process.env.DATABASE_ID is perfectly available, the binding registered via addWranglerBinding() still wouldn't reach Miniflare in dev mode. It's an architectural gap in how Nitro bridges programmatic config to the dev environment.

The workaround is a minimal wrangler.jsonc just for the bindings:

// wrangler.jsonc - bindings for local dev
{
  "d1_databases": [{ "binding": "DB", "database_id": "local-dev" }],
  "kv_namespaces": [
    { "binding": "KV", "id": "local-kv" },
    { "binding": "CACHE", "id": "local-cache" }
  ],
  "r2_buckets": [{ "binding": "BLOB", "bucket_name": "local-blob" }]
}

The IDs here are just local namespacing for Miniflare's persistence - any string works for dev. Your production binding IDs stay in nuxt.config.ts where they belong. It's a bit of a split, but it keeps your multi-deployment config centralised while giving Miniflare what it needs.

This does seem like something that could be improved upstream in Nitro - the dev module could read programmatic bindings the same way the build path does. Might be worth raising as a feature request on the Nitro repo if this pattern matters to you.