{"id":18150,"date":"2026-07-13T14:18:02","date_gmt":"2026-07-13T07:18:02","guid":{"rendered":"https:\/\/www.cipher.co.th\/blogs\/cloudflare-developer-platform-guide-2\/"},"modified":"2026-07-13T14:18:02","modified_gmt":"2026-07-13T07:18:02","slug":"cloudflare-developer-platform-guide","status":"publish","type":"post","link":"https:\/\/www.cipher.co.th\/en\/blogs\/cloudflare-developer-platform-guide\/","title":{"rendered":"The Cloudflare Developer Platform: A Practical Guide for Thai Businesses"},"content":{"rendered":"

Quick answer:<\/strong> The Cloudflare Developer Platform is a set of services for building and running applications on Cloudflare network, not just a CDN or a WAF. It covers compute (Workers, Containers, Durable Objects, Workflows), storage (R2, D1, KV, Hyperdrive), queues and data pipelines, image, video and WebRTC services, and a full AI stack. Two economics define it: Workers bill CPU time rather than wall-clock, and R2 charges zero egress. It suits teams that need low latency worldwide, predictable bills, and workloads made of many short requests. It suits a legacy monolith with native dependencies and heavy long-running memory needs far less well.<\/p>\n

Most Thai engineering teams first met Cloudflare as DNS, CDN, WAF and DDoS protection. Over the past few years, Cloudflare has quietly turned itself into a platform where you deploy the application itself. Today you can put your API, your files, your database, your queues, your LLM inference, your video calls and your outbound email on it without provisioning a single VM or Kubernetes cluster. What has not changed is the market perception. Many teams still budget Cloudflare as a line item under network security, and never look at the compute bill because they assume there is not one.<\/p>\n

The interesting question is not whether Cloudflare can do a given thing. Cloudflare documentation answers that better than we ever will. The hard part is choosing the right primitive for the problem in front of you<\/em>. Several services overlap on paper. KV, D1 and Durable Objects all store data, and picking wrong costs you a rewrite. Queues, Workflows and Pipelines all move work off the request path, and they solve completely different problems. On a serverless platform those choices are architectural and expensive to reverse once traffic is on them.<\/p>\n

This article is a map, not a manual. We walk the platform in the same groups Cloudflare uses, say what each service is actually good for, and say plainly when not to use it. Then a decision table, then a blunt section on where Cloudflare is still the wrong answer, then what a real migration looks like. Every price quoted here is pricing as of July 2026.<\/p>\n

Compute and Orchestration<\/h2>\n

This is the core of the platform. Almost everything else exists so that compute has something to talk to. Cloudflare gives you several execution models that are not interchangeable, and they differ mostly along two axes: how long the thing runs, and how much state it owns. We compare them side by side in Cloudflare compute services explained<\/a>.<\/p>\n

Workers<\/h3>\n

Workers is the platform primary runtime. Your JavaScript, TypeScript, Python or WebAssembly runs inside a V8 isolate in the Cloudflare data centre closest to the user. There are no containers to warm, so there is effectively no cold start, and no region to choose. The single most important economic fact about the whole platform lives here: Workers bills CPU time, not wall-clock time<\/strong>. The milliseconds your code spends waiting on a database or an upstream API are not billed. Workers Paid is 5 dollars per month including 10 million requests and 30 million CPU-milliseconds, then 0.30 dollars per million requests and 0.02 dollars per million CPU-ms (pricing as of July 2026).<\/p>\n

Reach for Workers for APIs, backend-for-frontend layers, edge middleware, authentication, personalisation, A\/B routing, webhook receivers, and anything that is a short request with modest computation. Do not reach for it when you need more than 128 MB of memory, when you need a filesystem, or when you depend on a library that has to compile to a native binary. We wrote the full list of disqualifying cases in when not to use Cloudflare Workers<\/a>, and the head-to-head economics against Lambda in Cloudflare Workers vs AWS Lambda<\/a>.<\/p>\n

Workers for Platforms<\/h3>\n

If your business is letting your customers write code that runs inside your product, this is the service you want. Think SaaS with a plugin system, e-commerce that lets merchants write custom checkout logic, or a low-code builder. Workers for Platforms lets you deploy tens of thousands of customer Workers into isolated namespaces, with a dispatch Worker of your own sitting in front that decides which tenant script handles a request and applies your limits and policies before the customer code runs. Do not use it simply because you have several Workers of your own. That is just ordinary Workers with more than one script, and the extra complexity buys you nothing.<\/p>\n

Durable Objects<\/h3>\n

Durable Objects is Cloudflare answer to the problem of needing exactly one authoritative thing in a distributed system. Each object has an ID, and globally there is one active instance per ID. That makes counters, locks, rate limiters, chat rooms, game lobbies and collaborative editors straightforward, without a race condition and without standing up Redis. WebSocket hibernation is the feature that changes the economics: an idle connection can be evicted from memory and rehydrated on the next message, so a product with many connected but mostly silent clients is dramatically cheaper than it would be on a long-lived server.<\/p>\n

The limit to design around is the soft ceiling of roughly 1,000 requests per second per object. If your architecture funnels all traffic through one object, you have built a bottleneck. Shard by a key that genuinely partitions the load, such as per room, per user or per order. Our comparison against a conventional Redis deployment is in Durable Objects vs Redis<\/a>.<\/p>\n

Containers<\/h3>\n

Containers is the escape hatch for everything Workers cannot do. You push an image, and a Worker calls into it like a function. Instances spin up on demand and sleep when idle. Sizes range from lite (1\/16 vCPU, 256 MiB, 2 GB disk) to standard-4 (4 vCPU, 12 GiB, 20 GB disk), with a hard maximum of 4 vCPU and 12 GiB memory per instance, and 50 GB of total image storage per account. Use it for ffmpeg, headless tooling, Python libraries that need to compile, anything that needs a real filesystem, or code in a language that will never run on V8. It requires the Workers Paid plan.<\/p>\n

Containers is not a Kubernetes replacement, and pretending otherwise will hurt. It is designed as a sidecar that a Worker orchestrates for heavy or awkward work, not as a home for a fleet of long-lived services with a service mesh running around the clock. If your workload is a set of always-on daemons that talk to each other, this is not that platform.<\/p>\n

Workflows<\/h3>\n

Workflows is a durable execution engine. You write your process as a series of steps, and the result of each step is persisted. If step seven fails, the platform retries step seven, not the whole thing, and a single workflow instance can wait days or weeks between steps without holding a process open. It fits onboarding flows, approval chains, syncing with a flaky third-party system, multi-stage file processing, and AI agents that need to chain many tool calls. Cloudflare has said billing will move to a per-step model no earlier than 10 August 2026, with the Paid plan including 500,000 steps per month and 0.80 dollars per additional 100,000 steps. Do not use Workflows as an ordinary queue for short fire-and-forget jobs; you will pay for orchestration machinery you never needed.<\/p>\n

Browser Run (formerly Browser Rendering)<\/h3>\n

Browser Run gives you headless Chrome on Cloudflare network, driven through Puppeteer, Playwright, the Chrome DevTools Protocol, or Quick Actions, which are ready-made HTTP endpoints for screenshot, PDF, markdown, scrape and crawl that need no code deployment at all. It is the right tool for invoice PDFs, OG image generation, end-to-end tests, pre-rendering pages for crawlers, and pulling data out of JavaScript-rendered sites. It runs on both the Free and Paid plans. Do not use it as a bulk scraper at large scale, because you pay for browser time; anything you can get with a plain HTTP fetch should never open a browser.<\/p>\n

State and Storage<\/h2>\n

This is where teams collide most often, because several of these services technically store data but have very different consistency models and access patterns. We go through each one, with worked examples, in Cloudflare storage services explained<\/a>. The section below should be enough to pick.<\/p>\n

R2<\/h3>\n

R2 is S3-compatible object storage. Storage costs 0.015 dollars per GB per month, and egress is zero, always, no matter how much data you pull out<\/strong> (pricing as of July 2026). The free tier includes 10 GB plus 1 million Class A and 10 million Class B operations per month. This is the service that produces the clearest financial result in any move to Cloudflare, because if your workload serves files, video, images or datasets to the public, the egress line, not the storage line, is what dominates your bill today.<\/p>\n

R2 is the wrong choice if you are deeply wired into the AWS ecosystem in ways that go beyond the object API: fine-grained Glacier tiering, S3 Object Lambda, or an analytics pipeline built tightly around EMR and Athena. The full comparison, including where S3 still wins, is in Cloudflare R2 vs Amazon S3<\/a>.<\/p>\n

D1<\/h3>\n

D1 is a serverless SQL database built on SQLite, bound directly into a Worker. It is fast, cheap, and you can create one in under a minute. The constraint you must design around first is the hard limit of 10 GB per database, which cannot be increased<\/strong>. That is not a bug. D1 is designed to be sharded: a database per tenant, per user, per workspace, rather than one large database for the whole company.<\/p>\n

If you are building multi-tenant SaaS and each customer holds a modest amount of data, D1 is exactly right. If you have a single table that will cross 10 GB, or you need JSONB, PostGIS, materialized views or any Postgres extension, keep PostgreSQL and put Hyperdrive in front of it. The detailed comparison is in Cloudflare D1 vs PostgreSQL<\/a>.<\/p>\n

Workers KV<\/h3>\n

KV is a globally replicated key-value store optimised aggressively for reads. Reads are the fastest thing on the platform. It is eventually consistent, and a write can take up to about a minute to be visible at every edge location. Use it for feature flags, routing tables, configuration, redirect maps, cached tokens with a sane expiry, and anything else that is read constantly and written rarely. Do not use KV for data where a stale read is harmful<\/strong>: inventory counts, account balances, or session state that you may need to revoke. Those belong in Durable Objects or D1.<\/p>\n

Durable Objects storage<\/h3>\n

As well as being a compute primitive, each Durable Object has its own strongly consistent, transactional storage, now backed by SQLite so you can run real SQL queries inside the object. Unlike KV, a value you write is immediately readable, because there is exactly one instance holding the truth. It suits state tied to a specific entity: a chat room, a shopping cart, an order, a single user session. It is a poor fit for queries that must span many objects, because there is no global index and no way to join across them. If you find yourself wanting a report over all objects, that report belongs in D1, in an external database, or in R2 via Pipelines.<\/p>\n

Hyperdrive<\/h3>\n

Hyperdrive solves the problem that stops most teams from adopting Workers at all. A Worker can run in hundreds of places at once; PostgreSQL accepts a bounded number of connections. Hyperdrive pools connections at the edge and caches read query results, so a Worker can use the PostgreSQL or MySQL you already run on AWS, GCP, Neon or a Thai data centre without migrating it anywhere. It is free on Workers Paid.<\/p>\n

There is one thing you must internalise: Hyperdrive does not invalidate its cache on write<\/strong>. The default max_age is 60 seconds, which means that if you point a default-cached configuration at a sessions or permissions table, a user you just banned can keep getting in for another minute. Disable caching for tables that change frequently, and cache only queries that tolerate staleness. Real configurations and the cost model are in connecting PostgreSQL to Workers with Hyperdrive<\/a>.<\/p>\n

Messaging and Data Pipelines<\/h2>\n

These three services all look like background work, and they are not remotely the same. Queues sends jobs to a consumer, Pipelines lands high-volume events in a data lake, and Email Service turns email into an ordinary I\/O channel for your code. We go deeper, with code, in Queues, Pipelines and Email Workers: which one to use<\/a>.<\/p>\n

Queues<\/h3>\n

Queues is a managed message queue where the producer is a Worker and the consumer is a Worker. It costs 0.40 dollars per million operations with 1 million included, and the maximum message size is 128 KB (pricing as of July 2026). It gives you batching, retries and a dead-letter queue. Use it to push heavy work off the request path: sending mail, resizing an image, forwarding a webhook, updating a slow downstream system. Two limits matter. Queue consumers have a 15-minute execution ceiling, and 128 KB is not much, so for anything larger, write the payload to R2 and put the key in the message.<\/p>\n

Pipelines<\/h3>\n

Pipelines ingests high-volume events over an HTTP endpoint or a Worker binding, transforms them with SQL, and writes them to R2 as Apache Iceberg tables or as Parquet and JSON files, with exactly-once delivery. It is for clickstream, application logs, IoT telemetry and anything else whose destination is a data warehouse or lakehouse. It is currently in open beta for Workers Paid customers and, beyond standard R2 storage and operations, is not yet billed. Do not use Pipelines where you meant Queues. It is an ingestion system, not a job runner; nothing on the other end is going to act on a single message.<\/p>\n

Email Service (formerly Email Routing and Email Workers)<\/h3>\n

Email Service makes email another I\/O channel for your code. Inbound mail arrives as an event in a Worker, where you can parse it, reply, open a support ticket or forward it. Inbound is free and unlimited; outbound costs 0.35 dollars per 1,000 emails on the Paid plan (pricing as of July 2026). It suits transactional email, support systems that treat a mailbox as an inbox for automation, and inbound-driven workflows. It is not a marketing platform. Large campaigns need deliverability tooling, IP warm-up and engagement reporting, and that is what a dedicated ESP exists to do.<\/p>\n

Real-Time and Media<\/h2>\n

This is the group Thai teams under-use most, even though video and images are usually the largest line on a cloud bill. All five services below can be used independently of each other, and often are. Our deeper treatment is in Cloudflare real-time and media services<\/a>.<\/p>\n

Images<\/h3>\n

Images does two separate things: it stores images, and it transforms them, either through URL parameters or through a binding inside a Worker. The Free plan includes 5,000 unique transformations per month for images stored anywhere, including R2. On the Paid plan, transformations beyond the included 5,000 cost 0.50 dollars per 1,000 unique transformations, storage is 5 dollars per 100,000 images per month, and delivery is 1 dollar per 100,000 images per month (pricing as of July 2026). It fits e-commerce, CMS and user-generated content where one upload must become many renditions. If you already run a good transformation pipeline and your renditions rarely change, moving is unlikely to pay for itself.<\/p>\n

Stream<\/h3>\n

Stream handles the entire video lifecycle: upload, encode, store and deliver, on-demand and live, through one API. It bills on two dimensions only, 5 dollars per 1,000 minutes of video stored and 1 dollar per 1,000 minutes of video delivered, with ingest and encoding free and no separate egress charge (pricing as of July 2026). File size does not matter, only duration. The thing to model before you commit is viewing behaviour: because delivery is billed per minute delivered, a library that is watched heavily can cost more than serving your own HLS segments from R2 at zero egress. Do the arithmetic with your real numbers, not the marketing ones.<\/p>\n

RealtimeKit<\/h3>\n

RealtimeKit is the highest-level product in the Realtime family: SDKs and pre-built UI components for live video and voice, with primitives such as meetings, participants, presets, stage and waiting room, plus recording, chat, polls, breakout rooms, virtual backgrounds and transcription. It is billed by the minute. It fits telehealth, virtual classrooms, webinars and social video, where you want a working call in days rather than months. Do not pick it if you need to own every track and every signalling decision yourself.<\/p>\n

TURN<\/h3>\n

TURN is a managed relay that lets WebRTC traffic get through restrictive NATs and corporate firewalls. WebRTC libraries use it automatically, so you write no extra code. It is free when used together with the Realtime SFU; used on its own it costs 0.05 dollars per GB with the first 1,000 GB free each month (pricing as of July 2026). This is infrastructure you need if you do WebRTC at all, particularly for users on corporate networks or on Thai mobile carriers with CGNAT. It is not something you opt into or out of on taste.<\/p>\n

Selective Forwarding Unit<\/h3>\n

The Realtime SFU is a low-level media server that routes audio, video and data tracks between participants. It is deliberately unopinionated: there is no concept of a room, only sessions and tracks in a publish-subscribe model, and you handle presence and signalling yourself. It costs 0.05 dollars per GB of egress with the first 1,000 GB free each month (pricing as of July 2026). Choose it when you have real WebRTC expertise and an architecture that does not fit standard patterns. If a conventional room model would have worked, use RealtimeKit and save yourself several months.<\/p>\n

AI<\/h2>\n

Cloudflare AI stack is not trying to beat the frontier labs on model quality. It is trying to be the place where you assemble<\/em> an AI system: inference, a vector store, a control plane in front of whatever models you use, and a managed RAG service. We take the whole stack apart piece by piece in the Cloudflare AI stack explained<\/a>.<\/p>\n

Workers AI<\/h3>\n

Workers AI runs open-source models on GPUs inside Cloudflare network, reachable from a Worker through a single binding. The catalogue covers text generation, embeddings, image models, speech, and classification. The benefits are low latency, because inference happens beside your code, and data residency, because nothing leaves for a third party. The constraint you must accept is that these are smaller models than Claude or GPT at the frontier. Deep reasoning and very long contexts are not what they are for. The task-by-task comparison is in Workers AI vs OpenAI<\/a>.<\/p>\n

Vectorize<\/h3>\n

Vectorize is the vector database for semantic search and RAG, and it plugs straight into Workers AI embeddings. The limits to design around: a vector can carry up to 1,536 dimensions, metadata per vector is capped at 10 KiB, an index holds up to 10 million vectors, and topK is capped at 50 when you ask for values or metadata back. If your corpus is larger than that, or you need sophisticated hybrid search with multi-stage re-ranking, look at a dedicated vector database instead.<\/p>\n

AI Gateway<\/h3>\n

AI Gateway is a proxy you put in front of every LLM you call, whether that is OpenAI, Anthropic, Workers AI or anything else, and it gives you caching, rate limiting, retries, model fallback, full prompt logging and per-request cost tracking. It is free. This is the service to turn on first on any AI project, even if you never use a single Cloudflare model, because not being able to see which prompt is burning your token budget is the fastest way to lose control of the bill.<\/p>\n

AI Search (formerly AutoRAG)<\/h3>\n

AI Search is managed RAG. Point it at your data, such as an R2 bucket, and it handles chunking, embedding, re-indexing when content changes, and natural-language querying. It offers hybrid search that mixes semantic and keyword matching, metadata filtering, and a built-in MCP endpoint so AI agents can use it as a tool. It is available on all plans. It fits knowledge bases, in-product documentation search and agent memory. If you need to control chunking strategy or re-ranking in detail, assemble it yourself from Vectorize and Workers AI instead.<\/p>\n

The Integrated Platform<\/h2>\n

What makes Cloudflare usable in practice is not any single service, but that the tooling around all of them is one thing with one configuration file.<\/p>\n

Wrangler (CLI)<\/h3>\n

Wrangler is the single CLI for the entire project lifecycle: scaffolding, a local dev server, managing bindings, creating a D1 database or an R2 bucket, handling secrets, and deploying. The wrangler.jsonc or wrangler.toml file is the one source of truth for your architecture; anyone who opens it can immediately see what the application is wired to. That is a distinct advantage over a Terraform estate spread across a dozen files.<\/p>\n

CI\/CD and Builds<\/h3>\n

Connect a GitHub or GitLab repository and Cloudflare will build and deploy on every push, with preview URLs per branch and a versions system that lets you roll back to a previous deployment in a single click. If your team already has a CI pipeline, calling wrangler deploy from GitHub Actions works just as well and gives you more control. Either is fine; what matters is that nobody is deploying from a laptop.<\/p>\n

Observability<\/h3>\n

Workers ships logs, metrics and traces natively; you turn it on in configuration and query it from the dashboard, and you can also forward everything to Datadog or Grafana. The thing to be aware of is that platform log retention is bounded, so if you need an audit trail for a long period for regulatory reasons, write the events into Pipelines and keep them in R2 as Iceberg tables. Do not treat the platform log viewer as your system of record.<\/p>\n

Secret Store<\/h3>\n

Secret Store holds secrets at the account level so that many Workers can share one value instead of each project holding its own duplicate copy. Access is auditable, and rotating a value once takes effect everywhere it is used. It is for third-party API keys, database credentials and signing keys, which is exactly the class of secret that quietly undermines an organisation security posture when it is copy-pasted into five projects.<\/p>\n

Decision matrix: if you need X, use Y<\/h2>\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
If you need<\/th>\nUse<\/th>\nWhy<\/th>\n<\/tr>\n<\/thead>\n
Code that runs on every request, close to the user, worldwide<\/td>\nWorkers<\/td>\nNo cold start, billed on CPU time not wall-clock<\/td>\n<\/tr>\n
State that must be exactly right per user, per room, per order<\/td>\nDurable Objects<\/td>\nOne authoritative instance per key, no race conditions<\/td>\n<\/tr>\n
Many WebSocket connections that are mostly idle<\/td>\nDurable Objects with hibernation<\/td>\nIdle connections cost almost nothing<\/td>\n<\/tr>\n
To run an existing binary, ffmpeg, or a non-JavaScript language<\/td>\nContainers<\/td>\nReal filesystem, up to 4 vCPU and 12 GiB<\/td>\n<\/tr>\n
A long multi-step process with per-step retries<\/td>\nWorkflows<\/td>\nDurable execution, state persisted per step<\/td>\n<\/tr>\n
To let your customers deploy their own code inside your product<\/td>\nWorkers for Platforms<\/td>\nIsolated namespace per tenant with a dispatch Worker<\/td>\n<\/tr>\n
Screenshots, PDFs, scraping, end-to-end tests<\/td>\nBrowser Run<\/td>\nHeadless Chrome, plus zero-code Quick Actions<\/td>\n<\/tr>\n
To store files, video or backups that get downloaded a lot<\/td>\nR2<\/td>\nEgress is zero, always<\/td>\n<\/tr>\n
To kill an S3 egress bill without rewriting your code<\/td>\nR2 with Sippy migration<\/td>\nS3-compatible API, migrate objects lazily on read<\/td>\n<\/tr>\n
A small relational database per customer<\/td>\nD1<\/td>\nCheap to shard, but 10 GB hard cap per database<\/td>\n<\/tr>\n
To use the PostgreSQL or MySQL you already have<\/td>\nHyperdrive<\/td>\nPooling and query caching at the edge, free on Workers Paid<\/td>\n<\/tr>\n
Config, feature flags or redirect maps read constantly<\/td>\nWorkers KV<\/td>\nFastest reads on the platform, but eventually consistent<\/td>\n<\/tr>\n
A counter, lock or rate limiter that must never be wrong<\/td>\nDurable Objects<\/td>\nStrongly consistent, transactional storage<\/td>\n<\/tr>\n
To move heavy work off the request path<\/td>\nQueues<\/td>\nBatching, retries and a dead-letter queue<\/td>\n<\/tr>\n
To land high-volume events in a data lake<\/td>\nPipelines<\/td>\nSQL transforms, writes Iceberg or Parquet into R2<\/td>\n<\/tr>\n
To receive or send email from your code<\/td>\nEmail Service<\/td>\nInbound free, outbound 0.35 dollars per 1,000<\/td>\n<\/tr>\n
Many image sizes from a single upload<\/td>\nImages<\/td>\nTransform by URL or through a Worker binding<\/td>\n<\/tr>\n
On-demand or live video<\/td>\nStream<\/td>\nBilled per minute stored and delivered, no egress fee<\/td>\n<\/tr>\n
Video calling that works in days, not months<\/td>\nRealtimeKit<\/td>\nSDKs and prebuilt UI, billed per minute<\/td>\n<\/tr>\n
WebRTC where you control every track<\/td>\nRealtime SFU<\/td>\nLow-level media server, 0.05 dollars per GB<\/td>\n<\/tr>\n
WebRTC to work through NAT and corporate firewalls<\/td>\nTURN<\/td>\nFree when used with the SFU<\/td>\n<\/tr>\n
Cheap inference close to the user, with data staying in network<\/td>\nWorkers AI<\/td>\nOpen models on Cloudflare GPUs, one binding<\/td>\n<\/tr>\n
Semantic search or RAG<\/td>\nVectorize<\/td>\nUp to 1,536 dimensions, 10 million vectors per index<\/td>\n<\/tr>\n
Caching, rate limiting, fallback and logging across all LLM providers<\/td>\nAI Gateway<\/td>\nSits in front of any provider, per-request cost visibility<\/td>\n<\/tr>\n
RAG without assembling it yourself<\/td>\nAI Search<\/td>\nAutomatic indexing, hybrid search, built-in MCP endpoint<\/td>\n<\/tr>\n
Deploy on git push with per-branch previews<\/td>\nWorkers Builds<\/td>\nOne-click rollback to a previous deployment<\/td>\n<\/tr>\n
A secret shared across many Workers<\/td>\nSecret Store<\/td>\nAccount-level, rotate once and it applies everywhere<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

Where Cloudflare is still not the answer<\/h2>\n

If you have read this far and concluded that everything sounds good, then we have written the previous sections badly. The following constraints are real, they are not solved by paying more, and several of them are deliberate consequences of the architecture rather than gaps waiting to be filled.<\/p>\n

128 MB of memory is the ceiling and it cannot be raised.<\/strong> A Worker isolate gets 128 MB, identical on Free and Paid. There is no dial. There is no larger plan. If you need to load a sizeable ML model into memory, process large images at high resolution, or read an entire file into memory before transforming it, you will hit OOM, and the only remedy is to move that job to Containers or leave it on your existing infrastructure.<\/p>\n

There is no filesystem.<\/strong> No \/tmp, no disk, nowhere to write. Many libraries in the Node ecosystem quietly assume a filesystem exists, and a good number of others depend on Node runtime internals that are not available or only partially shimmed. It is not enough for a library to build; if it has a native binding that has to be compiled with node-gyp, it will never run inside a Worker.<\/p>\n

D1 stops at 10 GB per database and cannot be increased.<\/strong> If your data model has one central table that everything joins to and it will cross ten gigabytes, D1 is not a choice you can defer. This is not a case of it being tight but survivable. It is a case of it not working. Keep PostgreSQL and reach it through Hyperdrive.<\/p>\n

Fifteen-minute execution ceilings.<\/strong> Cron Triggers, Queue consumers and Durable Object Alarms all stop at 15 minutes per invocation. A nightly batch job that takes an hour has to be broken into small pieces, moved into Workflows, or moved into Containers. Separately, Worker CPU time itself goes up to 5 minutes on Paid, with a 30-second default, and just 10 ms on Free, which is a different limit that people constantly confuse with the 15-minute one.<\/p>\n

The open AI models are smaller than frontier models.<\/strong> Workers AI is good at classification, embeddings, summarisation and RAG over a bounded context. It is not going to give you the reasoning quality of a frontier model, and if that is what your product needs, you will not get it from Workers AI at any price. The correct answer there is to call an external model through AI Gateway, not to pretend a small model is good enough and ship something mediocre.<\/p>\n

A large legacy monolith with native dependencies is a poor fit.<\/strong> If you have an eight-year-old Java monolith talking to Oracle, with dozens of stored procedures, scheduled jobs that chew CPU for hours, and libraries linked against glibc, Cloudflare is not going to fix that for you. What Cloudflare can genuinely do is sit in front of that monolith as an edge layer. What it cannot do is absorb it into a 128 MB isolate.<\/p>\n

Finally, a set of smaller constraints that trip people up in production: only 6 simultaneous outgoing connections per Worker, which is a real limit when one API endpoint fans out to several backends at once; and a bundle size of 3 MB on Free and 10 MB gzipped on Paid, which an unpruned Node dependency tree can exceed with ease.<\/p>\n

What a migration actually looks like<\/h2>\n

Migrations fail when they begin with the sentence we are moving to Cloudflare. They succeed when they begin with the sentence we are moving this part to Cloudflare. The sequence below is what we use with real clients, and every phase has to produce a measurable result before the next one starts.<\/p>\n

One, assess.<\/strong> Read the current cloud bill line by line and find out where the money actually goes. In our experience, egress, NAT gateways, always-on load balancers and instances sitting idle waiting for traffic add up to a larger share of the bill than the compute anyone talks about. Then sort the workloads into three buckets: what fits Workers as-is, what needs Containers, and what should not move at all.<\/p>\n

Two, move the edge layer first.<\/strong> Routing, authentication, rate limiting, caching, request rewriting, personalisation, A\/B tests and API gateway logic can all move onto Workers while the backend stays exactly where it is and never learns anything changed. It sits in front of the existing system, it improves latency immediately, and it is an honest test of whether your team can work with this platform without betting the data layer on the answer.<\/p>\n

Three, keep the database where it is.<\/strong> This is the advice people most often ignore. Do not migrate the database. Point Hyperdrive at the PostgreSQL or MySQL you already run. The database is the most painful thing to move and the least rewarding. If you eventually decide to move it, move it last, once everything else is stable, and only when there is a concrete reason.<\/p>\n

Four, move storage to R2.<\/strong> This is the phase where the bill visibly changes, because egress goes to zero. It can be done incrementally: read from R2 first and fall back to S3 when the object is not yet copied. The cost and effort model, including where the numbers stop working, is in the real cost of migrating from AWS to Cloudflare<\/a>.<\/p>\n

At each step, measure. If moving the edge layer did not improve p95 latency for users in Bangkok and did not reduce the bill, then you moved the wrong thing, and you should stop and reconsider rather than press on to the next phase out of momentum.<\/p>\n

Cipher designs and implements systems on the Cloudflare Developer Platform for businesses in Thailand, from greenfield architecture through partial migration of an existing system to an assessment of whether your current design would gain anything from moving at all, including the case where the answer is that it would not. If you want a straight opinion on your architecture, that is something we can do.<\/p>\n

Frequently Asked Questions<\/h2>\n

How is Cloudflare Workers different from AWS Lambda?<\/h3>\n

Workers runs in a V8 isolate rather than a container, so there is effectively no cold start, and it bills CPU time rather than the wall-clock time your code spends waiting on I\/O. Lambda gives you several GB of memory, a temporary filesystem, and much better support for code with native dependencies. If your workload is many short requests that need low latency worldwide, Workers is usually cheaper; if it is heavy memory-bound processing, Lambda is still the better fit.<\/p>\n

Can D1 replace PostgreSQL?<\/h3>\n

Only in specific cases. D1 is SQLite with a hard 10 GB limit per database that cannot be raised, and it is designed to be sharded per tenant or per user rather than used as one large central database. If you need JSONB, extensions, Postgres-style full-text search, or a single table that will grow past 10 GB, keep PostgreSQL and connect to it through Hyperdrive instead.<\/p>\n

Is R2 really cheaper than S3?<\/h3>\n

Yes when you have significant outbound traffic, because R2 charges 0.015 dollars per GB per month for storage and zero for egress, while S3 charges egress per GB, which is usually the largest single line in the bill for media and downloads (pricing as of July 2026). If your data is rarely read out of the cloud at all, the gap narrows sharply and the migration may not pay for itself.<\/p>\n

What is the memory ceiling on Workers, and can it be raised?<\/h3>\n

It is 128 MB per isolate, identical on the Free and Paid plans, and it cannot be increased at any price. If your job needs more memory than that, move that specific job to Containers, which can be sized up to 4 vCPU and 12 GiB, or leave it on your existing infrastructure.<\/p>\n

Do we have to migrate everything to Cloudflare at once?<\/h3>\n

No, and you should not. The approach that works is to move the edge layer first, meaning routing, auth, caching and API gateway logic, then keep the database exactly where it is and reach it through Hyperdrive, then move file storage to R2 for the egress saving. Heavy compute can be evaluated last, or left where it is.<\/p>\n

Can Workers AI replace OpenAI?<\/h3>\n

It can for tasks that mid-sized models already handle well, such as classification, embeddings, summarisation and RAG over a bounded context, and it lowers latency because inference happens in the same network as your Worker without sending data to a third party. For frontier-level reasoning or very long contexts, call an external model through AI Gateway instead.<\/p>\n","protected":false},"excerpt":{"rendered":"

Quick answer: The Cloudflare Developer Platform is a set of services for building and running applications on Cloudflare network, not […]<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_angie_page":false,"content-type":"","site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"page_builder":"","footnotes":""},"categories":[152],"tags":[],"class_list":["post-18150","post","type-post","status-publish","format-standard","hentry","category-technology-en"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/posts\/18150","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/comments?post=18150"}],"version-history":[{"count":0,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/posts\/18150\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/media?parent=18150"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/categories?post=18150"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/tags?post=18150"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}