Code at the edge, bindings for everything else.
Tap a binding to see what it does.
Binding
KV
Key-value store with eventually-consistent global replication. Sub-10ms reads from any PoP.
On this page
Nanosek provides Cloudflare Workers services for organizations building or migrating edge applications, APIs, reverse proxies, middleware, redirects, cache logic, security workflows, automation, and integrations on Cloudflare. The service includes architecture design, Workers development, migration from legacy edge platforms, KV/D1/R2/Queues/Workflows/Durable Objects integration, performance tuning, security review, observability, CI/CD, deployment workflows, and managed Cloudflare operations.
Who this is for
What we build with Cloudflare Workers
Edge applications
Build Cloudflare-native applications that run close to users and integrate with CDN, security, storage, identity, and routing controls.
APIs and API gateways
Create API endpoints, authentication middleware, backend routing, validation, response shaping, and service integrations at the edge.
Reverse proxies
Implement controlled proxy behavior with header handling, origin selection, authentication, redirects, failover behavior, and error handling.
Authentication middleware
Add token validation, signed requests, session checks, service tokens, Access-aware flows, and identity-aware request handling.
Request routing and origin selection
Route requests by hostname, path, headers, tenant, geography, feature flag, origin health, or application-specific logic.
Redirect and rewrite logic
Use native Cloudflare rules for simple behavior and Workers for dynamic redirects, rewrite decisions, or legacy redirect engines.
Cache customization
Customize cache keys, cache reads and writes, bypass decisions, revalidation, and origin fallback while avoiding private-data caching.
Webhook handlers
Receive webhooks, verify HMAC signatures, normalize payloads, enqueue work, and decouple slow downstream processing.
Security decision logic
Support application-specific allow, deny, route, enrich, or challenge decisions alongside WAF, Bot Management, Access, and API Shield.
Bot and fraud control workflows
Use Workers carefully for app-specific risk scoring, partner handling, request enrichment, or routing without replacing built-in bot controls.
SaaS integrations
Connect Cloudflare with CRM, ticketing, analytics, identity, payment, security, and customer-managed systems.
Internal tools and dashboards
Build lightweight operator tools, admin workflows, reporting views, and Cloudflare automation interfaces.
Data pipelines
Use Workers with Queues, R2, D1, KV, Workflows, and external systems for event ingestion, enrichment, and delivery.
Scheduled jobs
Run Cron Triggers for synchronization, audits, cleanup jobs, report generation, and operational automation.
AI and automation workflows
Use Workers AI, AI Gateway, Queues, R2, Vectorize, and workflows with observability, retries, and cost controls.
Multi-tenant platforms
Design tenant-aware routing, configuration, storage, isolation, authentication, and deployment models on Cloudflare primitives.
Why Workers need production architecture
Cloudflare Workers make it easy to deploy logic at the edge, but production workloads still need architecture. Teams need to think about state, storage, secrets, authentication, routing, error handling, observability, rate limits, rollback, testing, CI/CD, data consistency, and operational ownership.
Our Cloudflare Workers approach
Use-case discovery
- Review the business goal, current architecture, traffic flow, application behavior, origin dependencies, security requirements, data needs, latency requirements, and operational expectations.
- Decide whether the use case should be solved with Workers, native Cloudflare Rules, or a combination.
Target architecture
- Design Worker routes, bindings, storage, environment variables, secrets, authentication model, error handling, rate limits, caching strategy, and observability approach.
- Select Cloudflare primitives such as KV, D1, R2, Durable Objects, Queues, Workflows, AI Gateway, Workers AI, or Vectorize where appropriate.
Implementation
- Build Workers using clean routing, typed interfaces, structured configuration, secure secret handling, logging, validation, and testable code.
- Integrate with APIs, origins, Cloudflare services, SaaS platforms, and customer systems.
Testing and validation
- Validate request behavior, response headers, cache interaction, error handling, authentication, origin routing, performance, limits, and failure cases.
- Test staging and production routes separately where possible.
Deployment and CI/CD
- Configure Wrangler, environments, preview deployments, CI/CD workflows, secrets, rollback strategy, and release documentation.
- Support Terraform/API-based configuration where needed.
Observability and operations
- Configure logs, metrics, error reporting, dashboards, alerts, request tracing where applicable, and operational runbooks.
- Document ownership, escalation, and maintenance process.
Optimization and managed operations
- Tune performance, caching, storage usage, cost, error handling, retries, queues, workflows, and security controls over time.
Migrating edge logic to Cloudflare Workers
Cloudflare Workers platform capabilities we use
Cloudflare Workers
Used for edge applications, APIs, middleware, custom routing, integrations, automation, and application-specific edge logic.
Workers Routes
Used to attach Workers to specific hostnames and paths with clear production and staging behavior.
Wrangler
Used for local development, environments, deployments, secrets, bindings, previews, and CI/CD workflows.
Environment bindings
Used to connect Workers to KV, D1, R2, Queues, Durable Objects, services, and environment-specific configuration.
Secrets
Used for tokens, API keys, signing secrets, and credentials that must not be hardcoded or committed.
Workers KV
Used for low-latency global reads of configuration, flags, metadata, redirects, or tenant settings where eventual consistency is acceptable.
D1
Used for relational data, lookup tables, application state, admin data, or structured workflows that need SQL semantics.
R2
Used for object storage, assets, archives, logs, generated files, imports, and large payload workflows.
Durable Objects
Used for stateful coordination, per-tenant state, real-time sessions, counters, locks, and WebSocket coordination.
Queues
Used to decouple request handling from asynchronous processing, retries, enrichment, and downstream delivery.
Workflows
Used for durable multi-step automation, long-running business processes, retryable jobs, and coordinated background tasks.
Cron Triggers
Used for scheduled jobs, periodic sync, audits, cleanup, health checks, and reporting automation.
Service Bindings
Used for typed Worker-to-Worker communication without public network hops.
Hyperdrive
Used when Workers need lower-latency, connection-pooled access to regional databases where appropriate.
Vectorize
Used for semantic search, retrieval, classification, and AI-assisted workflows when vector storage is in scope.
Workers AI
Used for Cloudflare-native inference patterns with clear cost controls, queueing, and observability.
AI Gateway
Used to route, monitor, cache, and control AI provider calls from Workers-based workflows.
Cache API
Used for application-controlled caching when native Cache Rules are insufficient; private data caching is reviewed carefully.
HTMLRewriter
Used for streaming HTML transformations, injection, migration helpers, and controlled response rewriting.
WebSockets
Used with Durable Objects for real-time coordination, connection fanout, collaboration, or event-driven interfaces.
Smart Placement
Used where applicable to place execution closer to backend dependencies instead of only closest to the user.
Logpush and Workers Logs
Used for debugging, operational visibility, incident review, error analysis, and managed operations.
Analytics Engine
Used where applicable for custom event metrics, high-cardinality analytics, product telemetry, and operational reporting.
Terraform/API automation
Used to keep routes, bindings, variables, rules, and deployments repeatable and reviewable.
| Control | When Nanosek uses it |
|---|---|
| Cloudflare Workers | Used for edge applications, APIs, middleware, custom routing, integrations, automation, and application-specific edge logic. |
| Workers Routes | Used to attach Workers to specific hostnames and paths with clear production and staging behavior. |
| Wrangler | Used for local development, environments, deployments, secrets, bindings, previews, and CI/CD workflows. |
| Environment bindings | Used to connect Workers to KV, D1, R2, Queues, Durable Objects, services, and environment-specific configuration. |
| Secrets | Used for tokens, API keys, signing secrets, and credentials that must not be hardcoded or committed. |
| Workers KV | Used for low-latency global reads of configuration, flags, metadata, redirects, or tenant settings where eventual consistency is acceptable. |
| D1 | Used for relational data, lookup tables, application state, admin data, or structured workflows that need SQL semantics. |
| R2 | Used for object storage, assets, archives, logs, generated files, imports, and large payload workflows. |
| Durable Objects | Used for stateful coordination, per-tenant state, real-time sessions, counters, locks, and WebSocket coordination. |
| Queues | Used to decouple request handling from asynchronous processing, retries, enrichment, and downstream delivery. |
| Workflows | Used for durable multi-step automation, long-running business processes, retryable jobs, and coordinated background tasks. |
| Cron Triggers | Used for scheduled jobs, periodic sync, audits, cleanup, health checks, and reporting automation. |
| Service Bindings | Used for typed Worker-to-Worker communication without public network hops. |
| Hyperdrive | Used when Workers need lower-latency, connection-pooled access to regional databases where appropriate. |
| Vectorize | Used for semantic search, retrieval, classification, and AI-assisted workflows when vector storage is in scope. |
| Workers AI | Used for Cloudflare-native inference patterns with clear cost controls, queueing, and observability. |
| AI Gateway | Used to route, monitor, cache, and control AI provider calls from Workers-based workflows. |
| Cache API | Used for application-controlled caching when native Cache Rules are insufficient; private data caching is reviewed carefully. |
| HTMLRewriter | Used for streaming HTML transformations, injection, migration helpers, and controlled response rewriting. |
| WebSockets | Used with Durable Objects for real-time coordination, connection fanout, collaboration, or event-driven interfaces. |
| Smart Placement | Used where applicable to place execution closer to backend dependencies instead of only closest to the user. |
| Logpush and Workers Logs | Used for debugging, operational visibility, incident review, error analysis, and managed operations. |
| Analytics Engine | Used where applicable for custom event metrics, high-cardinality analytics, product telemetry, and operational reporting. |
| Terraform/API automation | Used to keep routes, bindings, variables, rules, and deployments repeatable and reviewable. |
Workers migration patterns
Workers use-case matrix
Reverse proxy
Worker routes, fetch, header handling, origin rules
Validate Host header, SNI, auth, redirects, and error behavior.
API gateway
Worker router, auth middleware, rate limiting, service bindings
Validate authentication, schema, logging, and backend failures.
Edge redirects
Redirect Rules first, Workers for dynamic logic
Use native rules where possible; Workers for complex conditions.
Cache customization
Cache Rules, Cache API, custom cache keys
Avoid accidental private data caching.
Webhook receiver
Worker endpoint, HMAC validation, Queues
Verify signatures and decouple processing.
Scheduled automation
Cron Triggers, Queues, Workflows
Add retries, idempotency, and logging.
Multi-tenant app
Workers, D1, KV, Durable Objects, R2
Design tenant isolation, auth, and data model carefully.
Real-time coordination
Durable Objects, WebSockets
Use for stateful coordination and connection management.
Static site backend
Workers plus Pages or Assets plus APIs
Keep routing and deployment simple.
Security middleware
WAF, Bot Management, Access plus Worker logic
Avoid replacing built-in security controls unnecessarily.
AI workflows
Workers AI, AI Gateway, Queues, R2
Add observability, retries, and cost controls.
Data processing
Queues, R2, D1, Workflows
Design for retries, idempotency, and backpressure.
| Use case | Cloudflare approach | Design notes |
|---|---|---|
| Reverse proxy | Worker routes, fetch, header handling, origin rules | Validate Host header, SNI, auth, redirects, and error behavior. |
| API gateway | Worker router, auth middleware, rate limiting, service bindings | Validate authentication, schema, logging, and backend failures. |
| Edge redirects | Redirect Rules first, Workers for dynamic logic | Use native rules where possible; Workers for complex conditions. |
| Cache customization | Cache Rules, Cache API, custom cache keys | Avoid accidental private data caching. |
| Webhook receiver | Worker endpoint, HMAC validation, Queues | Verify signatures and decouple processing. |
| Scheduled automation | Cron Triggers, Queues, Workflows | Add retries, idempotency, and logging. |
| Multi-tenant app | Workers, D1, KV, Durable Objects, R2 | Design tenant isolation, auth, and data model carefully. |
| Real-time coordination | Durable Objects, WebSockets | Use for stateful coordination and connection management. |
| Static site backend | Workers plus Pages or Assets plus APIs | Keep routing and deployment simple. |
| Security middleware | WAF, Bot Management, Access plus Worker logic | Avoid replacing built-in security controls unnecessarily. |
| AI workflows | Workers AI, AI Gateway, Queues, R2 | Add observability, retries, and cost controls. |
| Data processing | Queues, R2, D1, Workflows | Design for retries, idempotency, and backpressure. |
Migration to Cloudflare Workers
Edge platform to Workers migration sources
AWS Lambda@Edge
Workers, Routes, Cache Rules, Origin Rules
Review code path by path and replace simple cache, origin, and header behavior with native rules where possible.
CloudFront Functions
Redirect Rules, Transform Rules, Workers
Use declarative rules for simple viewer request changes and Workers for dynamic or integration-heavy logic.
Fastly Compute
Workers, Cache API, KV, R2, Queues
Rebuild dynamic edge logic and validate cache behavior, headers, errors, and origin expectations.
Akamai EdgeWorkers
Workers, Rules, Cache API, Logpush
Map edge behavior carefully and validate differences in execution model, cache behavior, and observability.
NGINX/Lua reverse proxy logic
Workers, Origin Rules, Transform Rules, Load Balancing
Move routing and header logic into native controls where possible and reserve Workers for dynamic behavior.
API gateway middleware
Workers, API Shield, WAF, Rate Limiting, Service Bindings
Validate authentication, schema behavior, rate limits, request logging, and backend error handling.
Custom Node.js serverless functions
Workers, D1, KV, R2, Queues, Workflows
Adapt runtime APIs, dependencies, state model, environment bindings, and deployment workflow.
Legacy redirect engines
Bulk Redirects, Redirect Rules, Workers
Keep static redirects declarative and use Workers only for dynamic or data-backed redirect logic.
Custom security middleware
WAF, Bot Management, Access, Workers
Avoid duplicating built-in controls; use Workers for application-specific decisions and enrichment.
Cron jobs and backend automation
Cron Triggers, Queues, Workflows, R2, D1
Design retries, idempotency, failure handling, and visibility before production use.
| Migration source | Cloudflare target | Migration notes |
|---|---|---|
| AWS Lambda@Edge | Workers, Routes, Cache Rules, Origin Rules | Review code path by path and replace simple cache, origin, and header behavior with native rules where possible. |
| CloudFront Functions | Redirect Rules, Transform Rules, Workers | Use declarative rules for simple viewer request changes and Workers for dynamic or integration-heavy logic. |
| Fastly Compute | Workers, Cache API, KV, R2, Queues | Rebuild dynamic edge logic and validate cache behavior, headers, errors, and origin expectations. |
| Akamai EdgeWorkers | Workers, Rules, Cache API, Logpush | Map edge behavior carefully and validate differences in execution model, cache behavior, and observability. |
| NGINX/Lua reverse proxy logic | Workers, Origin Rules, Transform Rules, Load Balancing | Move routing and header logic into native controls where possible and reserve Workers for dynamic behavior. |
| API gateway middleware | Workers, API Shield, WAF, Rate Limiting, Service Bindings | Validate authentication, schema behavior, rate limits, request logging, and backend error handling. |
| Custom Node.js serverless functions | Workers, D1, KV, R2, Queues, Workflows | Adapt runtime APIs, dependencies, state model, environment bindings, and deployment workflow. |
| Legacy redirect engines | Bulk Redirects, Redirect Rules, Workers | Keep static redirects declarative and use Workers only for dynamic or data-backed redirect logic. |
| Custom security middleware | WAF, Bot Management, Access, Workers | Avoid duplicating built-in controls; use Workers for application-specific decisions and enrichment. |
| Cron jobs and backend automation | Cron Triggers, Queues, Workflows, R2, D1 | Design retries, idempotency, failure handling, and visibility before production use. |
Cutover checkpoints
- Decide which legacy behavior becomes native Cloudflare Rules and which behavior remains code.
- Configure staging routes, environment bindings, secrets, and rollback path.
- Validate headers, redirects, cache behavior, authentication, origin routing, and error handling before traffic moves.
- Document deployment ownership, release process, and emergency rollback.
Validation signals
- Expected response status, headers, redirects, and body behavior match the legacy implementation.
- Logs, metrics, alerts, and errors are visible during preview, staging, and production rollout.
- Storage bindings, queues, workflows, and external API integrations behave correctly under retry and failure cases.
- Performance, CPU time, request volume, storage operations, and cost profile are within expected bounds.
Deployment steps
- 01 Validate the use case against native Cloudflare Rules before writing code.
- 02 Design Worker routes, bindings, state, secrets, authentication, cache behavior, and error handling.
- 03 Implement the Worker with structured configuration, typed interfaces, tests, logging, and safe secret handling.
- 04 Validate behavior in preview, staging, or separate routes before production traffic is attached.
- 05 Configure Wrangler, CI/CD, environments, secrets, release notes, and rollback steps.
- 06 Set up logs, metrics, dashboards, alerts, and operational ownership.
- 07 Tune performance, storage usage, queues, workflows, cost, security, and managed operations over time.
Risks and mitigations
Using Workers where native rules are better
Evaluate Rules, Redirects, Transform Rules, Cache Rules, and Origin Rules before writing code.
Secret exposure
Use Wrangler secrets and environment bindings; never hardcode tokens or credentials.
Poor error handling
Add structured errors, fallback behavior, retries, and safe response handling.
Accidental private data caching
Review Cache API usage, cache keys, cookies, authorization headers, and response headers.
Unclear ownership
Document routes, bindings, deployment workflow, contacts, and rollback steps.
State design issues
Choose KV, D1, R2, Queues, Workflows, or Durable Objects based on consistency and workload needs.
No observability
Configure logs, metrics, dashboards, alerts, and request correlation.
Vendor/API failures
Use timeouts, retries, circuit-breaker behavior, and queue-based processing where appropriate.
Cost or limit surprises
Review request volume, CPU time, storage operations, queue volume, and data transfer patterns.
Unsafe deployment
Use environments, preview deployments, CI/CD checks, staged rollout, and rollback.
| Risk | Mitigation |
|---|---|
| Using Workers where native rules are better | Evaluate Rules, Redirects, Transform Rules, Cache Rules, and Origin Rules before writing code. |
| Secret exposure | Use Wrangler secrets and environment bindings; never hardcode tokens or credentials. |
| Poor error handling | Add structured errors, fallback behavior, retries, and safe response handling. |
| Accidental private data caching | Review Cache API usage, cache keys, cookies, authorization headers, and response headers. |
| Unclear ownership | Document routes, bindings, deployment workflow, contacts, and rollback steps. |
| State design issues | Choose KV, D1, R2, Queues, Workflows, or Durable Objects based on consistency and workload needs. |
| No observability | Configure logs, metrics, dashboards, alerts, and request correlation. |
| Vendor/API failures | Use timeouts, retries, circuit-breaker behavior, and queue-based processing where appropriate. |
| Cost or limit surprises | Review request volume, CPU time, storage operations, queue volume, and data transfer patterns. |
| Unsafe deployment | Use environments, preview deployments, CI/CD checks, staged rollout, and rollback. |
Workers production readiness checklist
- Fit assessment completed
- Native Rules vs Workers decision documented
- Use case validated against native Cloudflare Rules
- Worker routes defined
- Environment separation planned
- Secrets configured securely
- Bindings documented
- State primitive selected intentionally
- KV/D1/R2/Queue/Durable Object usage designed
- Backend placement strategy reviewed
- Smart Placement considered where backend-heavy
- Same-zone subrequest security reviewed
- Authentication and authorization reviewed
- Input validation implemented
- Error handling implemented
- Retry and idempotency strategy defined
- Cache behavior reviewed
- Private data caching avoided
- Origin behavior tested
- Host header and SNI behavior validated
- Request ID propagation implemented
- Structured logs implemented
- Workers Logs or Logpush configured
- Logging and metrics configured
- Alerts and dashboards configured
- Error and latency alerting configured
- CI/CD workflow configured
- Gradual deployment plan prepared
- Rollback route prepared
- Rollback process documented
- Old backend retained for rollback window
- Dependency compatibility tested
- Cost and CPU profile reviewed
- Cost and usage limits reviewed
- Security review completed
- Operational owner assigned
Deliverables
- Workers use-case assessment
- Cloudflare-native architecture recommendation
- Worker application design
- Storage and bindings design
- Security and authentication model
- API and integration design
- Migration mapping from existing edge logic
- Worker implementation
- Test and validation matrix
- CI/CD and Wrangler setup
- Observability and alerting setup
- Production deployment runbook
- Rollback runbook
- Documentation and handover
- Managed operations backlog
When not to use Workers
Workers are not ideal for every workload. Nanosek may recommend Containers, Queues, Workflows, Hyperdrive, external compute, or native Cloudflare Rules when the workload does not benefit from the Workers execution model or edge placement.
Workers fit assessment
Nanosek treats Workers as an architecture choice, not a default answer. Before recommending Workers, we test the workload against platform fit, runtime constraints, data model, backend topology, observability needs, and operating model.
Memory requirements
Review heap usage, payload size, buffering, transforms, dependency footprint, and whether streaming or external processing is needed.
CPU time requirements
Estimate parsing, crypto, rendering, validation, compression, AI, and transformation work against request CPU limits and cost profile.
Runtime compatibility
Check Web APIs, Node.js compatibility mode, module format, package behavior, dynamic code assumptions, and framework fit.
Dependency compatibility
Identify native modules, filesystem assumptions, long startup paths, background threads, binary dependencies, and packages that expect a traditional server.
State and consistency needs
Decide whether the workload needs eventually consistent KV, relational D1, object storage, queueing, durable orchestration, or strongly coordinated Durable Objects.
Backend connectivity
Review origin location, database location, SaaS dependencies, latency sensitivity, Hyperdrive fit, service bindings, and failure handling.
Long-running process requirements
Separate request-time work from asynchronous jobs, workflows, queues, containers, or external compute where execution should outlive a request.
Observability requirements
Define request IDs, structured logs, Workers Logs, wrangler tail, Logpush, dashboards, latency views, error reporting, and incident workflows up front.
Cost and traffic profile
Model request volume, CPU time, subrequests, storage operations, queue volume, egress patterns, and expected burst behavior.
Compliance and placement needs
Review data residency, regional routing, Smart Placement, backend affinity, logging retention, access controls, and customer policy requirements.
Workers architecture decision framework
Workers vs Lambda and edge functions
Execution placement
Global-by-default execution on Cloudflare network with optional backend-aware placement patterns.
Design for edge benefit, backend latency, regional requirements, and Smart Placement where backend-heavy.
Runtime model
V8 isolate model rather than a traditional container or VM per invocation.
Cold-start and dependency assumptions differ from Lambda, Vercel Functions, Netlify Functions, or container-based workloads.
Cost model
CPU-time and request-oriented economics are different from wall-time oriented serverless models.
I/O-heavy workloads can fit well, but CPU-heavy work needs assessment.
I/O-heavy workload fit
Workers are strong for routing, API composition, request validation, cache logic, and service orchestration.
Use queues, workflows, retries, and timeouts to keep request paths predictable.
Memory and CPU constraints
Workers favor lightweight per-request execution rather than heavy in-memory processing.
Large transforms, CPU-bound jobs, or memory-heavy dependencies may need Containers or external compute.
Resource access
Bindings connect Workers to KV, D1, R2, Durable Objects, Queues, Workflows, services, and secrets.
Migrations must replace IAM-attached resources and SDK assumptions with explicit bindings and scoped credentials.
Observability model
Workers Logs, wrangler tail, Logpush, dashboards, request IDs, and structured logs need deliberate setup.
Existing Lambda or edge-function logging patterns rarely transfer one-to-one.
Rollback process
Rollback can use route changes, versioned deployments, DNS or rule rollback, and retained backend paths.
Plan cutover and fallback before attaching Workers to production traffic.
| Architecture dimension | Cloudflare Workers model | Migration implication |
|---|---|---|
| Execution placement | Global-by-default execution on Cloudflare network with optional backend-aware placement patterns. | Design for edge benefit, backend latency, regional requirements, and Smart Placement where backend-heavy. |
| Runtime model | V8 isolate model rather than a traditional container or VM per invocation. | Cold-start and dependency assumptions differ from Lambda, Vercel Functions, Netlify Functions, or container-based workloads. |
| Cost model | CPU-time and request-oriented economics are different from wall-time oriented serverless models. | I/O-heavy workloads can fit well, but CPU-heavy work needs assessment. |
| I/O-heavy workload fit | Workers are strong for routing, API composition, request validation, cache logic, and service orchestration. | Use queues, workflows, retries, and timeouts to keep request paths predictable. |
| Memory and CPU constraints | Workers favor lightweight per-request execution rather than heavy in-memory processing. | Large transforms, CPU-bound jobs, or memory-heavy dependencies may need Containers or external compute. |
| Resource access | Bindings connect Workers to KV, D1, R2, Durable Objects, Queues, Workflows, services, and secrets. | Migrations must replace IAM-attached resources and SDK assumptions with explicit bindings and scoped credentials. |
| Observability model | Workers Logs, wrangler tail, Logpush, dashboards, request IDs, and structured logs need deliberate setup. | Existing Lambda or edge-function logging patterns rarely transfer one-to-one. |
| Rollback process | Rollback can use route changes, versioned deployments, DNS or rule rollback, and retained backend paths. | Plan cutover and fallback before attaching Workers to production traffic. |
State and storage selection table
KV
Global configuration, feature flags, redirect maps, tenant metadata, and read-heavy lookups.
Use when eventual consistency is acceptable and writes are not on the critical consistency path.
D1
Relational data, admin workflows, application records, lookup tables, and SQL-backed Workers apps.
Design schema, migrations, regional behavior, backups, and query patterns intentionally.
R2
Object storage, assets, archives, uploads, generated files, logs, and data exchange.
Plan access control, lifecycle, metadata, large object handling, and downstream processing.
Durable Objects
Coordinated state, counters, sessions, locks, WebSockets, tenant-local state, and real-time coordination.
Use when a single coordination point or stateful object model is required.
Queues
Asynchronous processing, webhooks, retries, buffering, downstream delivery, and backpressure.
Design idempotency, dead-letter handling, retry behavior, and operational dashboards.
Workflows
Durable multi-step processes, longer-running automation, approvals, retries, and orchestration.
Use when the business process should survive request failures and continue across steps.
Hyperdrive
Workers connecting to regional databases that need connection pooling and lower database latency.
Review backend placement, connection behavior, security, and query patterns.
Workers AI
Cloudflare-native inference, AI automation, classification, summarization, and edge-adjacent AI workflows.
Add queueing, cost controls, evaluation, and logging around AI calls.
AI Gateway
Controlling, observing, caching, and routing AI provider requests from Workers.
Use for provider visibility, policy, caching, failover, and cost governance.
Vectorize
Semantic search, retrieval, recommendations, classification, and embedding-backed features.
Validate data model, update path, query latency, evaluation, and privacy requirements.
| Primitive | Best for | Architecture notes |
|---|---|---|
| KV | Global configuration, feature flags, redirect maps, tenant metadata, and read-heavy lookups. | Use when eventual consistency is acceptable and writes are not on the critical consistency path. |
| D1 | Relational data, admin workflows, application records, lookup tables, and SQL-backed Workers apps. | Design schema, migrations, regional behavior, backups, and query patterns intentionally. |
| R2 | Object storage, assets, archives, uploads, generated files, logs, and data exchange. | Plan access control, lifecycle, metadata, large object handling, and downstream processing. |
| Durable Objects | Coordinated state, counters, sessions, locks, WebSockets, tenant-local state, and real-time coordination. | Use when a single coordination point or stateful object model is required. |
| Queues | Asynchronous processing, webhooks, retries, buffering, downstream delivery, and backpressure. | Design idempotency, dead-letter handling, retry behavior, and operational dashboards. |
| Workflows | Durable multi-step processes, longer-running automation, approvals, retries, and orchestration. | Use when the business process should survive request failures and continue across steps. |
| Hyperdrive | Workers connecting to regional databases that need connection pooling and lower database latency. | Review backend placement, connection behavior, security, and query patterns. |
| Workers AI | Cloudflare-native inference, AI automation, classification, summarization, and edge-adjacent AI workflows. | Add queueing, cost controls, evaluation, and logging around AI calls. |
| AI Gateway | Controlling, observing, caching, and routing AI provider requests from Workers. | Use for provider visibility, policy, caching, failover, and cost governance. |
| Vectorize | Semantic search, retrieval, recommendations, classification, and embedding-backed features. | Validate data model, update path, query latency, evaluation, and privacy requirements. |
Workers observability and operations
Edge observability must be designed before incidents happen. Nanosek defines what each Worker logs, how requests are correlated, where logs are retained, which dashboards matter, and how incidents are triaged across Workers, service bindings, origins, and Cloudflare controls.
Workers Logs and wrangler tail
Use Workers Logs and wrangler tail for development, validation, debugging, and controlled production troubleshooting.
Logpush to R2 or SIEM
Send operational events, request summaries, or security-relevant logs to R2, object storage, or SIEM workflows where retention and investigation require it.
Request ID propagation
Generate or preserve request IDs across Worker routes, service bindings, backend calls, queues, workflows, and logs.
Structured logs
Log consistent fields such as route, tenant, action, outcome, latency, upstream status, cache decision, and error class.
Regional alerting
Watch failures by route, colo, region, backend, tenant, and integration so localized incidents do not hide inside global aggregates.
Error and latency dashboards
Track Worker exceptions, upstream errors, queue backlog, workflow failures, CPU time, latency, and subrequest behavior.
Tracing across service bindings
Propagate correlation context across Worker-to-Worker calls and backend requests so multi-service failures can be reconstructed.
Incident workflows
Define escalation, owner, rollback trigger, temporary mitigation, customer communication, and post-incident review steps.
Workers security architecture
Workers often sit on critical request paths. Nanosek reviews public exposure, authentication, subrequests, secrets, tenant isolation, origin trust, Cloudflare security controls, and deployment permissions before production rollout.
Public routes
Classify which Worker routes are public, private, admin-only, partner-only, or internal and align controls to each exposure level.
Authentication and authorization
Validate sessions, tokens, service credentials, Access policies, role checks, and tenant permissions before backend or storage access.
Secret handling
Use Wrangler secrets, environment bindings, scoped credentials, rotation practices, and no hardcoded tokens.
Same-zone and cross-zone subrequests
Review subrequest behavior, trust boundaries, Host headers, service binding calls, and access controls between zones and services.
WAF, Bot, Access, and Rate Limiting alignment
Use Cloudflare controls before Worker logic where possible and avoid duplicating security decisions in code unnecessarily.
Origin authentication
Protect backend calls with authenticated origin patterns, signed headers, mTLS where appropriate, service tokens, or allowlisted Cloudflare paths.
Service bindings
Prefer service bindings for Worker-to-Worker communication when it reduces public exposure and simplifies auth boundaries.
Tenant isolation
Design tenant identifiers, storage keys, authorization checks, logs, rate limits, and data boundaries to prevent cross-tenant access.
API token scope
Use least-privilege API tokens for deployment, automation, logging, and administrative workflows.
Abuse protection
Add WAF, Bot Management, Turnstile, API Shield, rate limiting, validation, and quota controls to prevent Workers becoming an abuse amplifier.
When Nanosek should help
Frequently asked questions
What are Cloudflare Workers?
When should we use Workers instead of Cloudflare Rules?
Can Cloudflare Workers replace Lambda@Edge or CloudFront Functions?
Can Workers be used for APIs?
Are Cloudflare Workers safe for production traffic?
What storage options can Workers use?
How do you secure a Worker?
Can Workers integrate with Cloudflare WAF, Access, or Bot Management?
Can Nanosek manage Workers after deployment?
Build production-ready applications on Cloudflare Workers
Nanosek helps you design, migrate, secure, deploy, and operate Cloudflare Workers with the right architecture, observability, rollback, and managed operations model.