Why I Now Deploy My Web Projects on Cloudflare Instead of Managing Servers

Sean Tang — Mon, 09 Nov 2026 10:06:36 +0000

Why I Now Deploy My Web Projects on Cloudflare Instead of Managing Servers

Hi DEV, I’m Sean. I’m a full-stack engineer working mainly with TypeScript, Node.js, and React.

Over the past two years, I’ve started using AI to write more of my code. That has gradually changed how I work. I spend more time planning products, designing the architecture, and reviewing implementations. AI agents handle more of the implementation work, while I remain responsible for deciding what should be built and whether it actually works.

For me, writing every line by hand has become a less useful measure of progress. I’d rather use that time to understand a problem, make a better design decision, or get a product into someone’s hands.

Technical knowledge still matters. Reviewing generated code requires understanding what it does, especially around authentication, payments, and data access. But I want to apply that knowledge where my judgment contributes most.

That shift encouraged me to start building more products of my own.

I experimented with iOS apps, Chrome extensions, and websites. Eventually, I decided to make web products my main focus. They fit my existing skills, and sharing a working product can be as simple as sending someone a URL.

Then I had to decide how I wanted to deploy them.

I tried traditional server deployments and platforms such as Vercel and Railway. After exploring several approaches, I settled on Cloudflare for my current web projects.

The biggest reason is how much less infrastructure I need to manage myself.

With a traditional server, deploying the application is only part of the job. There’s also the operating system, runtime installation, process management, reverse proxy configuration, and ongoing maintenance. Each part is manageable, but the work adds up when you’re maintaining several small products.

Cloudflare Workers gives me a managed runtime for application code. I can spend more of my attention on the application and its behavior, with fewer machine-level responsibilities. Cloudflare also handles deploying Workers across its global network. That doesn’t automatically make every database query fast, but it removes another piece of infrastructure I would otherwise need to arrange. Workers documentation

Another reason is that the services I need fit together reasonably well.

My core Cloudflare stack is straightforward:

Workers for server-side application logic and APIs.
D1 for relational data.
R2 for uploaded files and other stored assets.

D1 provides a managed database with SQLite SQL semantics. For the kinds of products I’m currently building, having a relational database available alongside the application is convenient. I still need to design schemas, write migrations, and pay attention to queries, but I don’t need to operate a separate database server. D1 documentation

Workers bindings are another detail I appreciate. They let the application access resources such as D1 and R2 through configured bindings. That reduces some of the connection and credential plumbing involved in combining separate services. Bindings documentation

Cost structure also influences my choice, especially while experimenting with products that haven’t established predictable traffic.

R2 is particularly appealing for projects involving images and downloadable files because it doesn’t charge egress bandwidth fees. Storage and operations still have costs, so I wouldn’t describe it as free hosting. But removing egress charges makes one part of the cost calculation simpler. R2 pricing

The development workflow matters just as much as the hosting.

Cloudflare’s tooling supports local development with the Workers runtime and local versions of services such as D1 and R2. That gives me a useful way to test application changes before deploying them. Local development documentation

This also fits how I work with AI agents. A consistent stack gives the agent a clearer set of constraints: the runtime, database, storage interfaces, and deployment configuration are already decided. I can focus the task on a feature instead of reopening infrastructure decisions for every project.

There’s still a review process. An agent can generate code that looks reasonable while assuming it’s running in a conventional Node.js server. Workers has its own runtime, and Node.js compatibility has boundaries. Dependencies and runtime behavior need checking. Node.js compatibility documentation

Choosing Cloudflare also means accepting some dependence on its APIs and services. A different workload might justify a different platform. For my current projects, I’m comfortable with that tradeoff because having a familiar deployment setup helps me keep moving.

Two products I’m building with this approach are Bikto and AIGifsMaker.

Bikto manages short links, dynamic QR codes, and link-in-bio pages. You can update destinations after sharing a link or printing a QR code, then view click analytics. One product decision I care about is that cancelling a subscription shouldn’t disable the links people have already distributed.

Bikto uses React and TanStack Start, with Cloudflare Workers, D1, and R2 underneath. It’s a practical example of the kind of full-stack web application I want to keep building.

AIGifsMaker creates GIFs from text prompts and photos, and also provides tools for converting videos and image sequences into GIFs. The video converter runs in the browser, which is a useful reminder that some work can happen on the user’s device without a server round trip.

Both products use Cloudflare as their core application infrastructure, and I’m developing them with AI agents. Having a consistent foundation makes it easier to reuse what I’ve learned and spend more time on the parts specific to each product.

You’re welcome to try either one. I’d particularly appreciate feedback on the actual workflows: creating and maintaining a link in Bikto, or making and downloading a GIF in AIGifsMaker.

DEV Community: Sean Tang

Why I Now Deploy My Web Projects on Cloudflare Instead of Managing Servers