> This page is for Webflow Cloud.

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://developers.webflow.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://developers.webflow.com/_mcp/server.

# Configuration

> Configure your app for deployment on Webflow Cloud.

Webflow Cloud is designed to handle most of your deployment configuration, so you can focus on building your app. This page explains what's configured automatically  and what you need to know if you want to understand or troubleshoot the process.

For step-by-step setup use the following guides:

#### [Getting Started](/webflow-cloud/getting-started)

Get started with Webflow Cloud by following our step-by-step guide.

#### [Bring your own app](/webflow-cloud/bring-your-own-app)

Migrate an existing app to Webflow Cloud.

## Deployment details

Webflow Cloud hosts your app on [Cloudflare Workers](https://developers.cloudflare.com/workers/), running it at a base path within your Webflow Cloud [environment](/webflow-cloud/environments) (for example, `/app`). This base path serves as the mount point for your application.

## Platform-provided configuration

The Webflow Cloud builder detects your framework from your project files and generates the necessary platform configuration on your behalf. These settings are fixed — you can't override them, and you don't need to commit them. The generated configuration covers:

* The framework adapter that compiles your app for the Workers runtime
* Your app's base path and asset prefix, taken from your environment's [mount path](#mount-path-configuration)
* Asset handling and image optimization
* Node.js API compatibility
* Observability (for example, logging and metrics)

Anything you commit for these settings is replaced at build time, so leave them out of your own config.

### Storage resources

If you're using Webflow Cloud storage on a framework app, create and commit a `wrangler.json` that defines your [storage bindings](/webflow-cloud/storing-data/overview). Declare a `kv_namespaces`, `d1_databases`, or `r2_buckets` entry, and Webflow Cloud reads it during deployment and provisions the resource for you, assigning the resulting ID at deploy time.

> **Static apps ignore bindings and worker config**
>
> No-framework static apps are assets-only deployments.
> Webflow Cloud accepts `wrangler.json` in the repo, but ignores bindings and worker-specific configuration for that path.

**`wrangler.json`**

```json title="wrangler.json"
{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "my-app",
  "compatibility_date": "2025-04-15",
  "kv_namespaces": [
    { "binding": "SESSIONS", "id": "local" }
  ],
  "d1_databases": [
    {
      "binding": "DB",
      "database_name": "db",
      "database_id": "0",
      "migrations_dir": "drizzle"
    }
  ],
  "r2_buckets": [
    { "binding": "MEDIA", "bucket_name": "media" }
  ]
}
```

> **Why the IDs are placeholders**
>
> `id` on a KV namespace and `database_id` on a D1 database are required fields, so they have to be present for local commands like `wrangler types` and `wrangler d1 migrations apply --local` to work.
>
> The values are never used in production. Webflow Cloud provisions a separate resource per environment and substitutes the real IDs at deploy time, so any placeholder is fine. The **binding name** is the part that matters — that's what your code reads, and it's preserved exactly as you wrote it.

### Required fields

Webflow Cloud validates your `wrangler.json` before reading your bindings from it. Your file needs `name` and `compatibility_date` at the top level, plus these fields on each binding:

| Binding         | Required fields                           |
| :-------------- | :---------------------------------------- |
| `kv_namespaces` | `binding`, `id`                           |
| `d1_databases`  | `binding`, `database_name`, `database_id` |
| `r2_buckets`    | `binding`, `bucket_name`                  |

> **Validation failures are silent**
>
> If validation fails, the build doesn't stop. Webflow Cloud logs the error to your [build logs](/webflow-cloud/deployments#build-logs) and deploys your app **without any of your bindings** — so the failure shows up at runtime as missing storage, not as a failed build.
>
> If your bindings appear to be missing in a deployed environment, check the build log for a validation error before looking anywhere else.

Any other fields you include are passed through and ignored — the framework-level settings come from the [platform-provided configuration](#platform-provided-configuration) above.

Learn more about [storage in Webflow Cloud](/webflow-cloud/storing-data/overview).

## Framework configuration

Your framework config file is yours. Webflow Cloud merges its own platform settings over it at build time, so you only need to declare the options your app actually cares about — feature flags, plugins, integrations, and so on.

You don't need to add an adapter, a base path, or an output mode. If you leave your framework config out entirely, Webflow Cloud still builds your app.

#### Next.js

**`next.config.ts`**

```ts title="next.config.ts"
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  // Declare only your app's own options. For example:
  typedRoutes: true,
};

export default nextConfig;
```

> **\`open-next.config.ts\` is optional**
>
> If you don't commit one, Webflow Cloud generates a basic default configuration and uses it during deployment. Commit your own only if you need to customize OpenNext behavior.

#### Astro

**`astro.config.mjs`**

```js title="astro.config.mjs"
import { defineConfig } from "astro/config";

export default defineConfig({
  // Declare only your app's own options. For example:
  devToolbar: { enabled: false },
});
```

Webflow Cloud adds the `@astrojs/cloudflare` adapter, the React integration, your base path, and the server output mode when it builds. Don't set them yourself.

## Mount path configuration

When you create an [environment](/webflow-cloud/environments), you set a mount path, which is the subpath where your app will be accessible.
For example, with a mount path of `/app`, your app lives at:

```
your-webflow-cloud-domain.com/app
```

Webflow Cloud applies this mount path as your app's base path and asset prefix when it builds. You don't set it yourself — read it at runtime and construct paths from it instead of hard-coding them.

### When you need to prefix a path yourself

Your framework handles most of this automatically. You only need the prefix in the cases below.

| Case                                                              | Prefix needed?                     |
| ----------------------------------------------------------------- | ---------------------------------- |
| Next.js `<Link>`, `useRouter()`, `redirect()`, `next/image`       | No — Next.js applies the base path |
| Astro `<a>` to a page route, `astro:assets` images                | No — Astro applies the base path   |
| Plain `<img>`, `<link>`, or `<script>` tags pointing at `/public` | Yes                                |
| Client-side `fetch()` to your own API routes                      | Yes                                |

### `BASE_URL`

The `BASE_URL` variable represents the mount path of your environment. Combine this with your Webflow Cloud domain to create the URL where your application is accessible to users.

Use for:

* Navigation links and client-side routing
* Form actions and redirects

#### Next.js

```ts
// Next.js applies the base path to Link automatically
<Link href="/">
  <button>Back to Home</button>
</Link>

// Manual fetch calls need the prefix.
// Set NEXT_PUBLIC_BASE_PATH in your environment variables to your mount path.
const baseUrl = process.env.NEXT_PUBLIC_BASE_PATH ?? '';
const response = await fetch(`${baseUrl}/api/users`);
```

#### Astro

```ts
// Access BASE_URL in Astro
const baseUrl = import.meta.env.BASE_URL;

// Navigation button
<a href={`${baseUrl}/`}>
  <button>Back to Home</button>
</a>

// API fetch
const response = await fetch(`${baseUrl}/api/users`);
```

### `ASSETS_PREFIX`

`ASSETS_PREFIX` is the URL for static assets and some direct API calls. The `ASSETS_PREFIX` URL points directly to the Worker handling your app.

Use for:

* Referencing static assets (images, CSS, JavaScript files)
* Uploading large files to your app

#### Next.js

```ts
// Set NEXT_PUBLIC_BASE_PATH in your environment variables to your mount path
const assetsPrefix = process.env.NEXT_PUBLIC_BASE_PATH ?? '';

// Reference an image asset from /public with a plain img tag
<img src={`${assetsPrefix}/images/logo.png`} alt="Logo" />

// next/image needs no prefix — Next.js and Webflow Cloud handle it
```

#### Astro

```ts
// Access ASSETS_PREFIX in Astro
const assetsPrefix = import.meta.env.ASSETS_PREFIX;

// Reference an image asset
<img src={`${assetsPrefix}/images/logo.png`} alt="Logo" />
```

## Troubleshooting and common questions

#### How do I migrate an existing app?

If you're migrating an existing app, follow the steps in the [Bring your own app guide](/webflow-cloud/bring-your-own-app).