We built YouBase —a Platform-as-a-Service where AI coding agents can deploy and manage full-stack web applications. Not just call APIs, but actually write code, ship it, test it, iterate, and redeploy. Think Vercel or Heroku, except your "developer" is Claude or GPT.
The technical challenge was obvious from the start: AI agents iterate fast. They deploy code, hit an endpoint, get an error, fix it, redeploy, sometimes dozens of times per hour. Traditional platforms aren't built for that kind of tight feedback loop. We needed deployments that completed in seconds, global distribution by default, and strong multi-tenant isolation, because the code being deployed is untrusted and generated on the fly.
We also didn't want to build an orchestration system, a replication layer, or a multi-tenant isolation framework from scratch.
We chose Cloudflare Workers and shipped to production in about two months.
Two weeks after launch, we needed to update validation logic across all active tenant Workers. On a traditional platform, that would have required coordinated rolling deploys, staged rollouts, and a long tail of stragglers. With our setup, we redeployed a single Service Bindings Worker. About thirty seconds later, every tenant was running the new logic, with no downtime and no tenant redeploys. That was the moment the architecture stopped being theoretical.
Architecture Overview
YouBase runs on a hybrid architecture. The control plane (Go, PostgreSQL, Redis, Lambda etc.) handles project creation, deployments, billing, and management. The data plane runs entirely on Cloudflare Workers.
Each project gets its own Worker with a dedicated D1 database and a dedicated R2 bucket. There's no shared database and no shared storage. Bindings are per-tenant, so if one Worker misbehaves, it can't access another tenant's state.
A dispatcher Worker routes incoming requests to the correct tenant Worker using domain mappings stored in KV. We also run a shared Worker that provides common logic through Service Bindings, including validation, billing rules, framework utilities, and feature flags.
We don't manage regions, replicas, or node pools. Everything runs automatically across 300+ Cloudflare locations.
Workers for Platforms: Multi-Tenancy Without Orchestration
We needed real multi-tenancy. With Kubernetes, that would have meant network policies, per-tenant pods, resource quotas, secrets management, per-tenant databases, and a lot of operational overhead.
Workers for Platforms gives you multi-tenant isolation as a native runtime feature. Each workspace gets a dispatch namespace with its own Workers and bindings. Our dispatcher reads domain mappings from KV and forwards requests to the correct Worker:
Each Worker runs in its own V8 isolate. Tenants can't access each other's bindings or memory. There's no shared file system and no shared environment.
What surprised us wasn't the isolation itself, but how little infrastructure we had to configure. We didn't provision clusters. We didn't configure networks. We didn't choose regions. We created namespaces and deployed Workers.
The main friction here was debugging namespace routing. Failures in the dispatch path often surface as generic fetch errors with limited stack context. We ended up adding correlation headers so we could trace requests from dispatcher, to tenant Worker, to shared Worker.
Even with that rough edge, this approach was dramatically simpler than running Kubernetes for untrusted, generated code.
D1 + Session API: Consistency at the Edge
Edge databases often trade consistency for latency, and that tradeoff wasn't acceptable for our use case.
D1's Session API solves this with bookmarks. After each write, the database returns a bookmark (a transaction log position). If you send that bookmark on the next request, D1 guarantees you'll read your own writes:
We pass bookmarks through request headers. Our framework extracts them, creates D1 sessions, executes queries, and returns the new bookmark.
This gives us strong read-after-write guarantees without coordination servers. All writes go to the primary for consistency. Reads go to the nearest replica for speed. If a replica hasn't caught up to your bookmark yet, it waits.
Operationally, this was far simpler than managing PostgreSQL replicas and debugging replication lag across regions.
Service Bindings: Shared Logic With Instant Updates
The operational problem we worried about most was updating shared logic as the number of Workers grew.
The traditional answer is rolling upgrades across all tenant Workers.
Service Bindings let us run a single shared Worker that tenant Workers call through native RPC. There is no HTTP layer, no token auth, and the overhead is sub-millisecond.
We use this shared Worker for:
SQL validation
Billing calculations
Rate limiting
Feature flags
Framework utilities
Core business rules
Other shared infrastructure concerns
When we update this Worker, every tenant immediately sees the new behavior.
This is the piece that removed most of the operational burden. Today, a large fraction of tenant requests flow through Service Bindings.
Observability: Tail Workers and Analytics Engine
We couldn't ask users to instrument logs. AI agents generate code that can crash, loop, or behave strangely. We needed logs and metrics that work "right out of the box."
Tail Workers capture console output, exceptions, request metadata, and timing information. We built an ingest service that buffers these events and streams them to clients through SSE. Users run edgespark log tail and see live output with sub-second latency.
The Analytics Engine covers the metrics side. We track per-project, per-domain, and per-endpoint dimensions. Traditional systems fall apart at that level of cardinality.
Writes are non-blocking, and results can be queried through SQL without a cardinality explosion.
We use this for dashboards, billing, usage reports, and rate limiting.
Supporting Infrastructure: R2 and KV
R2 provides S3-compatible object storage. Each project gets a dedicated bucket. Presigned URLs, multipart uploads, and streaming all work as expected.
KV stores domain-to-worker routing mappings. The dispatcher queries KV on every request and updates propagate globally within seconds.
Why the Integrated Platform Matters
This integration mattered in practice because we didn't spend weeks wiring together Lambda, RDS, S3, and API Gateway. We didn't write connection pooling logic or configure VPC endpoints. We didn't set up IAM policies between services or run our own time-series database for metrics.
Workers call D1 and R2 through bindings. Service Bindings connect Workers with native RPC. KV handles routing. Tail Workers capture logs. Analytics Engine ingests metrics. The pieces fit together cleanly.
In practice, that meant we spent most of those two months building product instead of infrastructure.
Technical Takeaways
We were skeptical about SQLite at the edge, but D1 with the Session API proved us wrong. It gave us global, consistent data with less operational complexity than PostgreSQL replicas.
Multi-tenancy became a configuration problem instead of an architecture problem. When the runtime supports isolation through V8 isolates and dispatch namespaces, you don't need to build isolation yourself.
Service Bindings solved the operational problem of updating shared logic. One deployment updates security rules, utilities, and core features across all tenants.
Platform constraints actually improved our design. No long-running processes. No filesystem. SQLite instead of Postgres. Those constraints pushed us toward simpler, more reliable patterns.
The hard part wasn't Cloudflare itself — it was committing to it. We spent more time evaluating alternatives than we did debugging production issues.
We also expected observability to take weeks. Tail Workers and Analytics Engine had us up and running in a few days.
Debugging distributed Workers at scale is harder than we expected. The tooling isn't as mature as traditional server environments. But the operational simplicity trade-off is worth it.
Current Limitations
D1 has a 10GB per-database limit. That works well for most production applications, but not for data-heavy workloads.
Workers have a 300-second CPU time limit per HTTP request. Long-running tasks require async patterns or background processing.
WebSockets require Durable Objects for persistent state. The current architecture is request–response only, so realtime features like presence or live cursors need additional infrastructure.
Live tail currently supports staging environments only. Production log retention and querying require separate storage and indexing systems.
These are platform constraints we work within today.
Future Roadmap
We're integrating Cron Triggers for scheduled background jobs like database cleanup, report generation, and notification batching.
For real time collaboration, we're evaluating Durable Objects for WebSocket handling, presence systems, and state synchronization.
To support data-heavy applications, we're adding PostgreSQL and MySQL support, with tenant Workers accessing external databases via secure pooling.
We're also expanding Analytics Engine usage for higher-level business metrics such as API endpoint popularity, feature usage, and error patterns.
The edge data plane already scales globally. These efforts focus on control plane capabilities and the remaining platform gaps as the underlying primitives continue to evolve.
Conclusion
We built YouBase on Cloudflare Workers because we didn't want to spend six months on infrastructure before shipping the product. Two months later, we were in production with millisecond cold starts, consistent reads at the edge, and automatic observability.
There are still rough edges. Debugging distributed Workers is harder than debugging a monolith, and some platform limits require workarounds. We're building hybrid solutions for the areas where Workers don't quite fit yet.
But we haven't had to rebuild core infrastructure since launch. So far, it's handled the workload we designed it for. When we needed to update across all tenants, it took about 30 seconds. That tradeoff is the one that mattered.
Technical Appendix: Cloudflare Technologies Used
Data Plane Stack:
Cloudflare Workers – V8 isolate-based serverless compute at the edge
Workers for Platforms – Multi-tenant worker deployment with dispatch namespaces
Cloudflare D1 – SQLite-based edge database with Session API for consistency
Cloudflare R2 – S3-compatible object storage with global edge access
Cloudflare Service Bindings – Low-latency RPC-style worker-to-worker communication
Cloudflare KV – Key-value storage for domain routing
Tail Workers – Real-time log streaming and observability
Analytics Engine – Unlimited-cardinality metrics with SQL queries
