Pages adds monorepo builds, wrangler.toml config, and database integrations

Cloudflare has been gradually merging the feature sets of its two serverless development products, Workers and Pages. The latest batch of Pages announcements continues that convergence, adding several capabilities that previously required choosing Workers: monorepo support in the Git-based CI/CD pipeline, project configuration via wrangler.toml files, and one-click connections to external database providers.

Monorepo support in the CI/CD pipeline

Until now, a Pages project connected to GitHub or GitLab assumed a one-repo-to-one-project relationship. Teams using monorepos had to fall back on direct uploads via the Wrangler CLI, losing automatic builds and preview deployments tied to their Git provider.

The build system now understands repositories with multiple apps in separate subdirectories. You can define include and exclude path rules per project, so a commit touching only one app does not trigger rebuilds of unrelated projects in the same repository.

Configured path controls also help manage dependencies across applications. A monorepo may hold several apps that share internal packages; an update to a shared design library can rebuild every app that depends on it, while excluding an unrelated app down the tree. Existing management tools like Turborepo, NX, and Lerna can be used alongside the built-in path settings.

Configuration in wrangler.toml

Pages projects previously had to be configured from the Cloudflare dashboard, which forced developers to leave their editor for changes like adding environment variables or bindings and kept configuration out of version control. Projects can now be defined with a wrangler.toml file, the same format used for Workers. That puts configuration in the repository, makes it editable in the code editor, and allows a single file to define settings shared across local development, preview, and production environments.

Access control also improves: changing configuration no longer requires granting teammates dashboard access when they already have repository access. For existing projects, Wrangler includes a command that downloads the current dashboard configuration and generates a valid wrangler.toml file to place in the project root. If you already use wrangler.toml strictly for local development, running wrangler pages deploy will flag the additional fields needed before the configuration applies to preview and production.

Database integrations with a few clicks

Pages projects already had direct access to D1, Cloudflare's serverless SQL database, and to existing PostgreSQL databases through Hyperdrive. The new integrations cover external providers: Neon, PlanetScale, Supabase, Turso, Upstash, and Xata. From the Pages project settings, selecting a provider automatically sets the required environment variables and stores the API key as a secret.

Integrations are available in preview deployments as well, so you can pair a staging database with the unique preview URL before shipping to production. Cloudflare says additional database providers are on the way and is planning to extend the integrations platform to other categories such as authentication and observability. Third parties interested in publishing their own integrations can submit them through an intake form.

Next.js support matures

The next-on-pages adapter has gone through multiple minor and patch releases since its version 1.0 launch. Three improvements stand out:

  • ESLint plugin. The new eslint-plugin-next-on-pages package catches common compatibility mistakes while writing code, before the build step.
  • getRequestContext() APIs. These expose Cloudflare-specific resources and metadata about the current request, such as client location or browser preferences, inside your application code.
  • setupDevPlatform() API. The default next dev server now provides instant edit-and-refresh behavior while still giving access to platform resources like D1, R2, and KV. The C3 scaffolding tool creates a new Next.js project configured this way with a single command.

On the roadmap

Cloudflare previewed several milestones planned for later in 2024. Workers will gain Pages-style CI/CD for repository-connected builds, the ability to deploy static assets as part of a Worker, and preview URLs for testing changes. Pages will receive Tail Workers for log capture and forwarding, Workers Trace Events Logpush for long-term log storage, and gradual deployments to roll out new versions of Pages Functions incrementally.

The user interfaces for Pages and Workers in the dashboard are also expected to converge. Behind the scenes, Cloudflare says it is unifying how both project types are composed and deployed, with the goal of new features working across both products from day one.