Cloudflare Dev: The Developer Platform Explained and When It Fits

Cloudflare dev usually means building applications on Cloudflare’s developer platform, where code runs as Workers across a global network and talks to storage products built for that model, and it fits best when your app is request-driven, stateless and happy with those constraints.

It is a genuinely different way to run code than a server or a container, and the differences are the whole decision.

Table of contents

• What the platform is
• Local development with Wrangler
• What the runtime is and is not
• Data: the part that shapes your architecture
• Testing, debugging and deploying
• When a conventional service is the better fit
• A migration path that limits risk
• How this fits the rest of the stack
• FAQ

What the platform is

The developer platform is a set of products for running code and storing data on Cloudflare’s network instead of in a single data centre. The headline product is Workers, small pieces of JavaScript, TypeScript or WebAssembly that run in response to requests at locations near the caller. Around them sit products for key-value storage, object storage, relational data, queues, coordination between requests and, more recently, running containers.

The pitch in the documentation is deploying with one command and not managing servers or regions. You write a function, publish it, and it is reachable at a URL worldwide within seconds. There is no machine to patch and no capacity to provision in advance, and the platform scales the function with demand.

The programming model matters more than the product list. A Worker is built around the web standard Request and Response objects and the fetch API. It starts quickly, runs briefly, and is not a long-lived process. Anything that expects a persistent server, a writable local disk or a particular Node library may behave differently or not work.

That is not a flaw. It is the trade. You get global distribution and no operations in exchange for fitting your application into the platform’s shape. Developers who like the trade love it, and developers who discover the constraint late are the ones who write angry forum posts.

The existing posts on Cloudflare hosting and Cloudflare databases cover specific pieces in more depth.

Local development with Wrangler

The command line tool for the platform is Wrangler. It scaffolds projects, runs them locally, manages configuration and publishes. A new project starts from a template command:

npm create cloudflare@latest my-app
cd my-app
npx wrangler dev

The wrangler dev command runs your Worker locally with a close imitation of the production runtime, including simulated bindings to storage products, so you can iterate without deploying. Output appears in your terminal and changes reload automatically.

Configuration lives in a Wrangler file at the project root, in JSON or TOML. It names the Worker, sets a compatibility date that pins runtime behaviour, and declares bindings. A binding is how code reaches a resource: instead of a connection string, you reference a named object in the environment.

name = "my-app"
main = "src/index.ts"
compatibility_date = "2026-09-01"

[[kv_namespaces]]
binding = "CACHE"
id = "replace-with-your-namespace-id"

Keep the compatibility date current but not casually moving, because it determines which platform behaviours your code gets. Pin it, test, and update deliberately. For secrets, use the secrets command rather than the config file, so credentials never enter the repository.

What the runtime is and is not

A Worker runs in a lightweight isolate, not a full Node server. Many Node APIs are available through compatibility layers, but not all, and anything relying on native modules or the file system is a risk. Check dependencies before you commit to the platform, especially database drivers and libraries that assume sockets and processes.

Limits are a design input. Platform plans cap CPU time per request, memory per isolate, subrequests per invocation and bundle size. The exact numbers change, so read the current limits page instead of trusting a blog post, including this one. What matters is the pattern: short, bounded work per request.

Typical good fits:

• API endpoints and request routing. Small handlers that read input, call something, return output.
• Redirects, header manipulation and authentication checks in front of another origin.
• Static sites with a sprinkle of dynamic behaviour.
• Webhook receivers that validate and enqueue work.

Typical poor fits are long-running jobs, heavy CPU work such as image processing at scale, applications that depend on a traditional relational database over a TCP connection, and anything that wants a persistent process holding state in memory. For some of those the platform now offers containers, which relaxes the constraints at the cost of different pricing and behaviour.

Data: the part that shapes your architecture

Where the data lives decides whether the global distribution helps. The platform provides several storage models, and each has different consistency properties.

Key-value storage is eventually consistent. Writes propagate across locations over time, which is fine for configuration, caches and feature flags and wrong for anything where two users must see the same value instantly. Object storage suits files and uploads. A SQL database product gives you relational queries, typically with a primary location and replicas for reads. Coordination primitives exist for cases that need strong consistency for one entity at a time, such as a chat room or a counter.

The design rule from earlier posts applies: code that runs everywhere but reads one database in one place gains little speed on dynamic pages. Choose storage that matches the access pattern, and expect to restructure data to fit.

If your application already uses PostgreSQL or MySQL heavily, moving to a different storage model is a rewrite of the data layer, not a deployment change. Some teams connect Workers to an external database through a proxy or an HTTP-based driver. That works, but you pay a round trip per query, and the latency advantage of running at the edge mostly disappears.

Testing, debugging and deploying

Treat Workers like any other code. Unit test the pure logic. Use the local runtime for integration tests with simulated bindings. Keep a staging environment, which the platform supports through named environments in configuration, and deploy there first.

Logging works through the wrangler tail command, which streams logs from a deployed Worker in real time, and through the dashboard. For production you will want structured logs and some form of external aggregation, since ad hoc tailing does not give you history.

Deployment is one command, wrangler deploy, and rollback means deploying a previous version. Many teams wire this into continuous integration so merges to the main branch publish automatically. Store the API token as a secret in the CI system, scoped to the narrowest permission that can deploy the project.

Review costs by usage dimension rather than by headline. Requests, CPU time, storage operations and bandwidth each have their own meters. Estimate your real traffic against the current published pricing yourself, because pricing changes and a blog post is never the authority.

When a conventional service is the better fit

The platform is excellent at what it does and not universal. Choose a conventional web service when you need a long-running process, a standard framework with full Node or Python library support, a relational database reachable over a normal connection, background workers, or WebSockets with state held in memory.

A traditional service also keeps the mental model simple. You run the same code locally and in production, debug with ordinary tools and move providers without rewriting the app. Portability is a real feature, and it is the one people undervalue until they need to leave.

On RunxBuild, web services run Node, Next.js, Python, Go, Ruby, Java, .NET or Docker from a GitHub repository, with managed MySQL or Postgres beside them, runtime logs, autoscaling and rollback. It does not run code at the edge or provide key-value stores, so the two approaches suit different applications. A reasonable pattern is to use an edge platform for a thin routing or caching layer and a conventional service for the application behind it. The services introduction lists what a service includes.

A migration path that limits risk

If you are considering the platform for an existing application, do not rewrite the whole thing. Put a Worker in front of the current origin and route a single path through it. Redirects, caching rules and header changes are low-risk first uses, and they teach you the deployment and logging workflow with real traffic.

Move one small, stateless endpoint next, such as a webhook receiver or a lightweight API route, and watch error rates and latency for a week. Only then consider moving data. The pain in these migrations is almost always the data layer, so leave it for last and migrate it only if the access pattern clearly benefits.

Keep a way back. If the original service stays available, a routing change can send traffic to it again in minutes.

How this fits the rest of the stack

Whichever model you choose, an application ends up with line items for compute, data and traffic, and they are easier to compare side by side. Put the service and database version of your project into the RunxBuild hosting calculator and see what the conventional route costs. When the app needs a long-running service and a managed database, the RunxBuild dashboard is where you create them.

Useful related references:

• Git Codespace: A Cloud Dev Environment, Not a Host
• npm run dev —host: Why the Flag Gets Swallowed, and the Fix
• GitHub Browser Editor: What github.dev Can Do, What It Cannot, and When You Need Codespaces Instead
• Services on RunxBuild

FAQ

What does Cloudflare dev mean?

It refers to developing on Cloudflare’s developer platform, mainly Workers for running code near users plus storage products such as key-value, object and relational databases, managed with the Wrangler command line tool.

How do I run a Worker locally?

Use npx wrangler dev inside the project. It runs your code in a local runtime that imitates production, with simulated bindings, and reloads on changes.

Can I run a normal Node app on Workers?

Only if its dependencies work in the Workers runtime. Many Node APIs are supported through compatibility layers, but native modules and the file system are not. Check your libraries first.

What is a binding?

A binding connects a Worker to a resource such as a storage namespace or database through a named object in its environment, instead of a connection string in code.

When should I avoid this platform?

For long-running processes, heavy CPU work, apps tied to a traditional database over TCP, or anything that needs a persistent in-memory process. A conventional web service is usually simpler there.