Three Days, Full Stack: A First Impression of Cloudflare Workers

As a developer, I've seen a lot of serverless platforms, but a recent three-day hackathon here at Intenics let me take a deep dive into Cloudflare's serverless ecosystem. My goal was simple: build a complete application skeleton using Cloudflare Workers and their related services, focusing on the developer experience and following the platform's intended approach.

Here's my journey along with the pleasant surprises and the unexpected lessons I gained while building a full-stack serverless app on Cloudflare.

The Scope

My application skeleton was a simple, but complete full-stack setup, leveraging multiple serverless primitives from the Cloudflare platform.

The following diagram depicts how the deployed application looks like when deployed to Cloudflare.

The frontend app was not the focus, but the workflow had to include a modern Single Page Application. I chose Angular and my frontend only contains an authentication flow with the forms required.

A Fast, Local and Powerful Developer Experience

The standout feature of the whole experience was the quality of the local development tools. The local environment feels like a first-class citizen and reduced my reliance on frequent deployments.

Miniflare is a Game-Changer

Miniflare, the official local environment simulator for cloudflare, is awesome. It's a full-featured sandbox running the Cloudflare Workers runtime along with simulated D1, R2 and other services.

• Local Debugging: I was able to get full breakpoints working for both my TypeScript backend (Hono) and my Angular frontend code running inside the Worker simulator.
• Full-Featured: Miniflare correctly simulated how the Cloudflare Worker served my static assets. I saw my configuration issues before my first deployment. Along with local debugging, fixing these issues was much easier than I had anticipated.
• Easy access to simulated persistence: Miniflare stores SQLite databases for R2, D1, KV, etc in .wrangler/state , so you can easily inspect and edit your simulated D1 databases or the metadata of your simulated R2 Buckets and items.
• Database Migrations: The Wrangler CLI considers Operations workflows like database migrations (and testing them locally), which is a good sign of intent for me. As migrations via Prisma CLI did not generate any output for me, I had an officially supported fallback (which I configured to work with Prisma).

The Learnings

When learning new technologies, surprises and learnings are a given. If you wish you check out Cloudflare Workers, these are the ones I want you beforehand.

1. D1 Is Cutting-Edge (And Young)

Cloudflare D1, their serverless SQLite database, is really exciting, but it's also very new. Setting up ORM mappers (Prisma) and database migrations was tricky and the documentation felt like a moving target. However, the individual parts were mature enough for me to get it running: Prisma generates the migration scripts and wrangler migrations manages them.

2. Static Assets Are Simpler Than They Look

My first impression, based on some of the React-specific samples, led me to believe I needed a separate Worker for my static frontend.

The Reality is Simpler: You don't need a separate Worker for your static frontend. I simply built my Angular app and configured my main backend Worker to serve its static assets. This simplifies cross-domain scenarios.
You can serve your frontend from a dedicated worker and that may be better for your specific workflow. The great thing here is that we are free to chose.

3. Workers KV Is Not a NoSQL Database

I initially expected Workers KV to be a NoSQL Database alternative to DynamoDB or CosmosDB. That isn't the case. It's closer to Redis—a massive, globally distributed key-value store with eventual consistency. This isn't a problem in any way, as it has its own very interesting use-cases.

4. The IaC Dilemma: Wrangler vs. Pulumi/Terraform ⚠️

My biggest takeaway was a critical constraint on my initial "Infrastructure as Code" approach:

Using Pulumi or Terraform for Cloudflare Workers is a bad idea.

While I successfully used Pulumi (which uses the official Terraform provider) to provision my supporting infrastructure like R2 Buckets and D1 Databases, attempting to manage the Worker's configuration with it was a mistake.

• You work against Wrangler: The Terraform Provider only has "Level 1" constructs in AWS CDK terms, meaning it does not provide helpful abstractions. I could configure a Worker, but features like static asset hosting is "more elaborate" and would require an extra call to Cloudflare's API.
• Wrangler with Terraform: My conclusion is to use a hybrid approach: Wrangler manages all Worker-specific configuration and deployment, and Pulumi/Terraform manages all surrounding resources like R2, D1, Domains and associated configurations. I think Terraform would suffice, as this IaC is not very complex and thus the resulting files remain readable despite yaml limitations.

The Result

After three days, I had a fully working proof of concept, that I could indeed develop and host a SaaS application on cloudflare, consisting of:

• Angular Web Application (on Cloudflare Worker static assets)
• REST-like API (Hono on Cloudflare Worker)
• Database (Cloudflare D1)
• Object Storage (Cloudflare R2)
• Authentication (via BetterAuth)

This includes time spent debugging issues in Pulumi and having misunderstandings with the documentation regarding D1 migrations with Prisma.

This development speed was a surprise to me and I now have a new tool under my belt: I can create small serverless applications on Cloudflare Workers using familiar tools and methods.

A Quick AWS Comparison

The central theme for me was the sheer simplicity of the Cloudflare platform compared to traditional cloud providers like AWS or Azure. This is both a massive advantage and a key limitation.

On one hand, the learning curve is much gentler, and initial setup is really fast. You spend much less time configuring your accounts, permissions and access models.

However, this simplicity comes at the cost of fine-grained control. Cloudflare's permissions system is very coarse compared to AWS's IAM or Azure's RBAC. For enterprises with strict regulatory requirements or those needing complex, multi-layered permission schemes, Cloudflare Workers might not be an option. It's a trade-off: "speed and simplicity" versus "fine-grained control and flexibility".

✅ Final Verdict and Next Steps

If Cloudflare's reduced features and permissions fulfill your needs, their Workers platform is a serious alternative. While D1 and some of the newer services are still maturing in terms of documentation, the core experience and its pricing are great.

The combination of:

1. Amazing Local Dev Experience (Miniflare with Local Debugging).
2. Easy Managed Services (Workers, D1, R2).
3. Attractive Pricing

creates a platform that lets developers build and deploy a full-stack, globe-spanning applications faster than nearly any other platform I've used. Cloudflare offers a fresh and exciting approach to serverless computing.