Production Browser Connectivity and Relay Deployment Report

Full report

On this page

Document Reference: SEC-NET-RELAY-2026-V1 Target Path: E:\\Source\\Rust\\TinyRustLM.com\\agent-file-handoff\\Improvement\\tinyrustlm-memoryendpoints-production-relay-deployment-report.md Classification: Confidential \- Internal Engineering Deployment Blueprint Status: Released / Approved for Production

Executive Summary and System Context

The TinyRustLM architecture delivers localized, deterministic scalar inference utilizing a browser-native WebAssembly (WASM) runtime combined with custom .slm Small Language Model containers1. To support cross-session conversational consistency and personalized interaction histories, the platform integrates an optional hosted semantic memory interface3. However, the production deployment currently exhibits a critical connectivity gap between the browser-based client application (TinyRustLM.com) and the upstream storage provider (MemoryEndpoints.com). Direct asynchronous JavaScript and XML (AJAX) requests from the browser to the upstream memory service remain persistently unreliable. This unreliability stems from strict browser enforcement of Cross-Origin Resource Sharing (CORS) security policies. Because the upstream MemoryEndpoints.com application programming interface (API) does not natively or consistently emit the necessary CORS preflight OPTIONS responses, modern web browsers proactively terminate direct cross-origin requests that carry custom authentication headers or sensitive access credentials4. To definitively bridge this connectivity gap without requiring modifications to the frozen, user-validated WASM and JavaScript application codebase, this engineering specification mandates the deployment of a same-origin reverse proxy relay at the network edge. By registering the proxy at the path https://tinyrustlm.com/api/memoryendpoints/\*, the browser context perceives all memory synchronization traffic as strictly same-origin. This architectural adjustment inherently bypasses cross-origin preflight restrictions at the client level. The edge relay assumes total responsibility for CORS mediation, payload sanitization, credential injection, request validation, and strict route isolation. This comprehensive report evaluates hosting and Domain Name System (DNS) constraints, formulates the authoritative edge-routing topology, establishes defensive URL pathname normalization mechanisms against WHATWG URL Standard vulnerabilities, dictates Zero-Downtime canary deployment mechanics, and provides the definitive Test-Driven Development (TDD) verification matrix required to gate the live production release.

Dynamic Hosting Provider and DNS Constraints Analysis

The baseline constraint for this deployment is that TinyRustLM.com serves entirely static application files (HTML, CSS, JavaScript, and compiled WASM modules). The underlying infrastructure must therefore support the seamless interception of specific API routes without disrupting the high-performance delivery of these static assets. The analysis evaluates three primary topologies to determine the most secure, performant, and cost-effective deployment strategy.

Recommended Production Architecture: Cloudflare Pages with Workers Routes

The authoritative deployment architecture integrates Cloudflare Pages for static asset hosting with Cloudflare Workers acting as the dynamic edge-compute relay. Both services are bound under a unified Cloudflare DNS zone operating in proxy mode. Cloudflare Pages natively hosts the compiled TinyRustLM user interface. Cloudflare DNS manages the apex domain and the www subdomain, providing Universal SSL/TLS 1.3 termination at the global edge6. The edge-compute interception mechanism relies on Cloudflare Workers, which are explicitly bound to the zone via Route Rules targeting tinyrustlm.com/api/memoryendpoints/\ and www.tinyrustlm.com/api/memoryendpoints/\8. This topology is superior due to Cloudflare's routing precedence mechanisms. In the Cloudflare routing engine, explicit Workers Route Rules possess absolute priority over standard DNS resolution and Cloudflare Pages static routing directives9. When a browser initiates a request matching /api/memoryendpoints/\*, the routing fabric immediately intercepts the request and invokes the Worker. Conversely, requests for static assets, such as /index.html or /models/tiny\_lm\_16M\_f32.slm, fall through the routing table to the Cloudflare Pages origin without ever invoking the Worker compute runtime. This ensures that massive model binary downloads do not consume serverless execution resources or trigger unnecessary billing events1. Furthermore, Cloudflare Workers utilize lightweight V8 isolates rather than traditional containerized micro virtual machines. This architectural distinction eliminates the "cold start" latency penalties inherent to containerized serverless functions, ensuring that the relay initializes in under one millisecond10. For autoregressive language models that frequently synchronize memory states to maintain conversational context, this sub-millisecond initialization latency is a mission-critical requirement. The financial efficiency of this architecture is driven by Cloudflare's CPU-time billing model. The Cloudflare Workers Paid tier bills exclusively on active CPU execution time at a rate of $0.02 per million CPU milliseconds, combined with a flat $0.30 per million requests, completely ignoring idle network wait time12. Consequently, while the edge proxy waits for the upstream MemoryEndpoints.com database to process a transaction and return a payload, zero compute duration is billed.

Feasibility Analysis for Alternative Providers

If the domain were bound to a legacy static hosting provider, such as GitHub Pages, same-origin reverse-proxying would be functionally impossible without routing traffic through an intermediate Content Delivery Network (CDN) or edge-compute layer. The analysis evaluated competing serverless edge platforms and rejected them based on extreme structural and financial risks.

Rejected Alternative 1: AWS Route53, S3, CloudFront, and Lambda@Edge

This topology utilizes Amazon Simple Storage Service (S3) for static hosting, CloudFront for global content delivery, and Lambda@Edge for the proxy function logic. This architecture is rejected primarily due to its wall-clock duration billing model. Unlike Cloudflare's CPU-time billing, AWS Lambda@Edge charges for the entire wall-clock duration of the request lifecycle at a rate of $0.00005001 per GB-second12. A network-bound proxy waiting 500 milliseconds for a remote database response will bill for 500 milliseconds of compute time per request. At the scale required for token-by-token memory synchronization, this generates infrastructure costs up to 90% higher than V8 isolate environments13. Additionally, Lambda@Edge functions initiate inside traditional containers, generating cold start latencies ranging from 100 milliseconds to 1.5 seconds, which severely degrades the responsiveness of real-time conversational interfaces11.

Rejected Alternative 2: Vercel Edge Functions

This architecture deploys the static application via the Vercel platform, utilizing Vercel Edge Functions (typically via a route.ts file) to manage the reverse proxy. This approach is rejected due to extreme egress cost markups and seat-based licensing overhead. Vercel imposes severe penalties on outbound bandwidth; while the Pro plan at $20 per seat per month includes 1 Terabyte of Fast Data Transfer, overages are billed at $0.15 per Gigabyte, equating to $150 per Terabyte16. By contrast, Cloudflare does not charge for egress bandwidth17. For an application synchronizing heavy semantic memory payloads or transmitting detailed diagnostic telemetry, Vercel introduces an unacceptable risk of catastrophic billing spikes18. Furthermore, Vercel enforces strict concurrency limits of approximately 30,000 simultaneous executions on its Pro tier, which threatens to throttle bursty traffic patterns during peak inference usage16.

Browser Request Lifecycle and Relay Flow Sequence

The implementation mandates a highly controlled, multi-stage interaction lifecycle between the browser client, the edge relay, and the upstream origin. This sequence ensures that all security protocols, routing normalizations, and header transformations are executed immutably at the edge. Browser Client TinyRustLM Worker Relay MemoryEndpoints.com (Same-Origin) (Cloudflare Edge) (Upstream Server) | | | |--- 1\. OPTIONS (Preflight Request) \--\>| | | \[Origin: https://tinyrustlm.com\] | | | \[Access-Control-Request-Headers\] | | | | | |\<-- 2\. 204 No Content (Allow CORS) \---| | | \[Headers: Dynamic CORS, Max-Age\] | | | | | |--- 3\. POST (Payload Write Request) \-\>| | | \[Session & Memory State JSON\] |--- 4\. POST (Path Sanitized Fetch) \----\>| | | \[Url: /api/matm/session\] | | | \[Injects Workspace Secrets\] | | | | | |\<-- 5 200 OK (Response Payload) \-------| | | \[Retrieves raw payload stream\] | | | | |\<-- 6\. 200 OK (Clean same-origin) \----| | | \[Injects Cache-Control: no-store\] | | | \[Reflects Dynamic CORS headers\] | | The sequence begins with the CORS preflight phase. Because the browser utilizes custom HTTP headers to transmit session identity and idempotency keys, W3C security protocols force the browser engine to issue an OPTIONS request prior to transmitting the actual payload4. The Worker intercepts this request at the edge, validates the Origin header against an explicit regular expression, and immediately terminates the request with a 204 No Content HTTP response. This fast-path termination prevents the upstream server from being burdened with high-volume preflight traffic. Following the successful preflight, the client initiates the primary POST or GET request. The Worker extracts the URL path suffix, sanitizes it to eliminate duplicate slashes, verifies the path against a strict route isolation blocklist, and dynamically injects the MEMORY\_ENDPOINTS\_API\_KEY. This key is securely retrieved from the Cloudflare Secret Store, ensuring that credentials are never exposed to the client browser or hardcoded into the worker script. Utilizing Cloudflare's internal TCP connection pooling, the Worker dispatches the modified request to the MemoryEndpoints.com upstream server. Upon receiving the response, the Worker strips sensitive internal headers emitted by the upstream server, injects strict cache-prevention policies, applies the required dynamic CORS headers, and streams the unbuffered body back to the browser client.

Strict CORS Preflight and Dynamic Origin Routing

To support secure production environments while simultaneously enabling local developer iteration, the edge relay must compute CORS policies dynamically based on the incoming request context rather than relying on static configuration. The Worker evaluates the incoming Origin HTTP header against a strictly defined Regular Expression. The relay only processes requests originating from the production apex domain (https://tinyrustlm.com), the production WWW subdomain (https://www.tinyrustlm.com), authorized localhost development ports (http://localhost:\[port\]), and authorized loopback development addresses (http://127.0.0.1:\[port\]). Any request originating from an unrecognized domain is implicitly rejected by omitting the CORS reflection headers, causing the browser to abort the cross-origin transaction. Under W3C CORS specifications, wildcard origins (\) are strictly prohibited when a request transmits credentials, cookies, or custom authorization headers4. If the edge relay naively returns Access-Control-Allow-Origin: \, the browser will deliberately trigger a network security error and refuse to pass the response to the application layer. The Worker must explicitly echo the validated origin string back to the client. When responding to valid preflight OPTIONS requests, the Worker injects a specific matrix of access control headers. The Access-Control-Allow-Methods header restricts verbs to GET, POST, OPTIONS. The Access-Control-Allow-Headers directive explicitly permits Authorization, X-MemoryEndpoints-Key, Content-Type, Accept, Idempotency-Key. Crucially, the Access-Control-Max-Age is set to 86400\. Setting the max-age to 86,400 seconds (24 hours) instructs the browser to cache the preflight response4. This configuration eliminates the latency of the OPTIONS network round-trip for all subsequent memory synchronization operations during the user's active session, drastically improving perceived UI responsiveness.

WHATWG URL Pathname Normalization and Double-Slash Vulnerability

A critical security vulnerability arises when extracting path parameters and constructing downstream fetch URLs due to the parsing nuances defined within the WHATWG URL Standard. Consider a malformed or maliciously crafted browser request targeting https://tinyrustlm.com/api/memoryendpoints//api/matm/session. If the edge relay implements naive string replacement to extract the suffix—by slicing the length of /api/memoryendpoints from the pathname—the resulting suffix is //api/matm/session. When this suffix is passed into the standard JavaScript URL constructor alongside the upstream base URL, a severe routing hijacking occurs. Under the WHATWG URL Standard, which governs URL parsing in modern browsers, Node.js, and Cloudflare's V8 workerd runtime, any string prefixed with two forward slashes (//) is parsed as a Protocol-Relative URL22. Because the suffix //api/matm/session is evaluated as a complete URL overriding the base, the URL constructor yields https://api/matm/session, assigning the hostname to api and the protocol to https:. The intended upstream base URL (https://MemoryEndpoints.com) is completely ignored. This behavior introduces two severe exploit vectors. First, it enables DNS and Proxy Hijacking. The edge relay routes the subrequest to an arbitrary, potentially attacker-controlled external host named api rather than the intended target domain. Second, it enables Path Traversal and Security Rule Bypassing. If developers attempt to circumvent the URL constructor by using direct string concatenation (base \+ suffix), the resulting URL resolves to https://MemoryEndpoints.com//api/matm/session. While certain backend web servers, such as NGINX or Apache, typically collapse duplicate slashes during RFC 3986 path normalization, many upstream API gateways treat consecutive slashes literally. This causes the gateway to reject the request with a 404 Not Found or, more dangerously, bypass security rules because the authorization pattern matching fails to recognize the double-slash prefix25. To comprehensively mitigate this risk, the Worker implementation programmatically collapses sequential adjacent slashes utilizing a global regular expression (/\\/+/g), guarantees a single leading slash, and validates the final hostname integrity of the resolved upstream object before initiating any network subrequest. If the resolved hostname does not strictly match the expected upstream origin, the Worker throws a security exception and terminates the request.

Route Isolation Boundaries and Capacity Constraints

To guarantee that the same-origin relay cannot be exploited as an open proxy, manipulated into executing denial-of-service (DoS) attacks, or utilized to illicitly download copyrighted model weights, the architecture enforces strict programmatic containment boundaries. The Worker executes aggressive path evaluation at the network edge. Any unauthorized request paths are terminated immediately with a 403 Forbidden HTTP response prior to fetching external data. The relay establishes an authorized enclave, permitting only paths strictly beginning with /api/matm/, the designated Memory Allocation Tracking Protocol namespace. Conversely, any paths targeting /models/\, file extensions ending in \.bin or .slm, or external Hugging Face repository endpoints are explicitly blocked. Large deterministic model weights, such as the 17-million parameter TinyLM-16M29, must be served directly from the static Pages CDN to prevent edge-compute bandwidth exhaustion and preserve architectural isolation1. Furthermore, the proxy explicitly rejects any occurrences of directory traversal syntax (.. or ../) within the URL schema, insulating the upstream server from local file inclusion (LFI) or path-traversal attacks. Regarding capacity constraints, the Cloudflare Workers Paid plan enforces a maximum HTTP payload body size of 100 Megabytes for both incoming requests and outbound responses30. However, conversational session payloads and memory records should strictly consist of highly compressed JSON metadata. To defend the V8 isolate from malicious memory exhaustion vulnerabilities, the relay implements proactive buffer control. The script parses the Content-Length header on all incoming requests; any request indicating a body exceeding 10 Megabytes is immediately rejected at the edge with a 413 Payload Too Large error, ensuring the relay operates well within safe memory tolerances.

Performance Budgets, Retries, and Degraded UI Workflows

The proxy must be designed to gracefully handle network degradation without causing cascading failures or state corruption within the browser application. The Cloudflare Workers Paid tier permits up to 30 seconds of active CPU execution time per invocation, which can be configured up to 5 minutes for long-running computational tasks30. However, the reverse proxy logic involves minimal computation, typically operating within less than 3 milliseconds of active compute time. Importantly, there is no hard limit on the wall-clock duration while the HTTP stream remains actively connected, allowing for long-running upstream database fetches30. To protect the edge relay from slow-loris attacks or upstream server hangs, the implementation utilizes an AbortController to enforce strict latency boundaries. A 15-second hard timeout is established; if the upstream server fails to resolve the database query within 15 seconds, the edge relay aborts the connection and returns a 504 Gateway Timeout30. Cloudflare Workers natively maintain a pool of warm TCP connections to designated origins via Keep-Alive protocols. This connection pooling bypasses the Transmission Control Protocol (TCP) and Transport Layer Security (TLS) handshake latency on consecutive write operations, guaranteeing that edge-relay processing overhead remains negligible. The implementation differentiates retry policies based on HTTP verb idempotency. For idempotent operations, such as GET or OPTIONS, the Worker relay will automatically retry the operation up to two times in the event of an upstream TCP connection reset or a 503 Service Unavailable response. Conversely, the Worker will never automatically retry a POST transaction. Retrying a state-mutating memory write without confirmation creates a severe risk of database duplication and state corruption. The sole exception is if the client explicitly supplies an Idempotency-Key header, which guarantees the upstream MemoryEndpoints.com service can safely deduplicate the request on the backend. If the edge relay returns a 5xx status code or fails entirely due to network partitioning, the TinyRustLM browser interface is programmed to dynamically handle the outage. The client application initiates a seamless local fallback, redirecting the active memory session writes to the browser's local IndexedDB or localStorage scope. The user interface renders a non-intrusive diagnostic banner indicating that the memory synchronization is offline and that the session has been safely saved locally. Once the edge relay reports consecutive successful GET connection pings, the application prompts the user to synchronize local state diffs back to the hosted workspace, ensuring zero data loss during degraded network conditions.

Telemetry, Cache Bypassing, and Log Redaction

Security and privacy mandates require strict controls over data residency, caching policies, and telemetry logging to ensure that sensitive Large Language Model conversational contexts are protected throughout the proxy lifecycle. All required configuration variables and secrets must be securely provisioned to the Cloudflare Platform environment. Hardcoding credentials in source code or static configuration files is strictly forbidden. The UPSTREAM\_ORIGIN and ENVIRONMENT variables are defined as non-secret configuration parameters within the wrangler.jsonc file. Conversely, the MEMORY\_ENDPOINTS\_API\_KEY, which authenticates the relay against the upstream target, and the MEMORY\_ENDPOINTS\_JWT\_SECRET, utilized for verification signatures, are securely injected as encrypted secrets via the Cloudflare Secrets Store.

To guarantee zero-trust data residency, the relay dynamically injects strict cache destruction directives. This ensures sensitive memory payloads are never inadvertently cached by edge networks, intermediate proxies, or the client browser. The relay appends standard HTTP cache-busting headers, including Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate, Pragma: no-cache, and Expires: 0\. Furthermore, the Worker explicitly overrides the Cloudflare edge cache router, completely bypassing static asset caching mechanisms for all proxied API requests by setting the custom fetch option cf: { cacheTtl: \-1, cacheEverything: false }7. To comply with internal security protocols, Health Insurance Portability and Accountability Act (HIPAA), and General Data Protection Regulation (GDPR) mandates, edge monitoring tools such as Cloudflare Tail or Logpush must be prevented from capturing sensitive data. The Worker script implements active header scrubbing before transmitting request metadata to telemetry analytics. Keys matching Authorization and X-MemoryEndpoints-Key are automatically redacted, with their values replaced by the string \[REDACTED\]. Crucially, the body streams for both the request and response are proxied transparently without being stringified or parsed inside the logging callbacks, guaranteeing that raw conversational memory context remains completely invisible to the edge telemetry plane.

Production Implementation of the Edge Relay Worker

The following defines the exact route tables, header transformations, and operational logic required for the tinyrustlm/deploy/memory-endpoints-relay-worker.js script. The logic initializes by defining the strict ALLOWED\_ORIGIN\_REGEX and the APPROVED\_PATH\_PREFIX to enforce route isolation. During the fetch event invocation, the Worker parses the incoming request URL and Origin. It dynamically computes the corsHeaders dictionary, verifying if the Origin matches the allowed list. If the request is an OPTIONS preflight, it returns a fast-path 204 No Content response populated with the CORS headers. For payload requests, the script slices the /api/memoryendpoints prefix and utilizes the global regular expression /\\/+/g to collapse adjacent slashes, ensuring a single leading slash. It evaluates the sanitized suffix against the APPROVED\_PATH\_PREFIX, returning a 403 Forbidden if the path falls outside the authorized enclave. It subsequently evaluates the Content-Length header, rejecting requests exceeding the 10-Megabyte threshold with a 413 Payload Too Large status. The script then reconstructs the upstream target URL by combining the UPSTREAM\_ORIGIN environment variable with the sanitized path suffix. It rigorously validates that the resulting hostname matches the expected upstream hostname to defeat protocol-relative hijacking attempts. The incoming headers are cloned, the Origin header is deleted to prevent upstream CORS conflicts, and the MEMORY\_ENDPOINTS\_API\_KEY is securely injected. An AbortController is instantiated with a 15-second timeout budget before executing the asynchronous fetch request against the upstream target. If the upstream server times out or the connection fails, the catch block intercepts the AbortError and returns the appropriate 504 Gateway Timeout or 502 Bad Gateway response. Upon a successful upstream response, the Worker strips sensitive internal headers such as Set-Cookie, Server, and X-Powered-By, injects the dynamic CORS and anti-caching headers, and streams the unbuffered body back to the client while enqueuing the asynchronous, redacted telemetry logger via ctx.waitUntil().

Zero-Downtime Canary Deployment and Rollback Mechanics

To transition the relay proxy to production without risking service interruption, the deployment leverages Cloudflare's decoupled versioning mechanics, ensuring safe canary rollouts and session affinity32. The process begins by provisioning secrets securely via the command-line interface. Engineers execute npx wrangler secret put MEMORY\_ENDPOINTS\_API\_KEY within the project workspace, providing the secret values directly to the secure Cloudflare Secret Store without committing them to the repository. The wrangler.jsonc configuration file establishes the routing logic, attaching the Worker to intercept API calls directed at the apex and www endpoints, while permitting the static Pages application to natively manage all other traffic8. The configuration specifies the compatibility\_date, defines the non-secret environment variables, and maps the explicit routes to tinyrustlm.com/api/memoryendpoints/\ and www.tinyrustlm.com/api/memoryendpoints/\. The deployment sequence decouples the upload phase from the traffic-routing phase to prevent version skew anomalies, such as clients attempting to load mismatched HTML or JS asset hashes during transitions.

1. Version Upload: Engineers execute npx wrangler versions upload, which compiles and uploads the Worker code to Cloudflare without routing live traffic to it.
2. Version Discovery: Running npx wrangler versions list retrieves the unique Version ID generated by the upload.
3. Gradual Canary Split: The deployment initiates a gradual rollout using npx wrangler versions deploy \<NEW\_VERSION\_ID\>@10% \<PREVIOUS\_VERSION\_ID\>@90%, routing 10% of traffic to the new proxy logic while retaining 90% on the stable version.
4. Verification and Promotion: After verifying error metrics, the split is promoted to 50%, and ultimately 100%, completing the deployment.

During a split canary rollout, users executing sequential operations risk having their browser requests randomly distributed between Version A and Version B. To mitigate this, client requests must transmit the Cloudflare-Workers-Version-Key HTTP header paired with a hashed session key. The Cloudflare routing fabric hashes this value to deterministically route the user to the exact same deployment version across their session, maintaining strict version affinity35. If metric monitoring tools detect a spike in 5xx network failures or isolate memory exhaustions during the canary promotion, a rollback must be initiated instantaneously. Engineers execute npx wrangler rollback \--version \<PREVIOUS\_VERSION\_ID\>, reverting 100% of traffic instantly to the previously stable version ID. Because the Worker configuration is evaluated directly on Cloudflare's routing fabric, triggering a rollback updates V8 isolate configurations within milliseconds across all global edge nodes. This procedure avoids altering DNS records entirely, thereby circumventing unpredictable DNS propagation delays and immediately stabilizing the application36.

Production Verification and Test-Driven Development Plan

The deployment lifecycle implements a rigorous, multi-stage Test-Driven Development (TDD) process utilizing Vitest and Miniflare, the authoritative Cloudflare environment simulator.

TDD Lifecycle Phases

1. Phase 1: Local Unit Tests (Vitest & Miniflare): The primary objective is to confirm that routing sanitization, CORS allowlists, and route isolation blocklists operate as designed without transmitting real HTTP requests over the internet. Tests simulate requests to forbidden paths (e.g., /models/weights.bin) ensuring they return 403 Forbidden, and test double-slash inputs (//api/matm/ping) ensuring they resolve cleanly without triggering protocol-relative 301 or 302 redirects.
2. Phase 2: Local Integration: Utilizing the wrangler dev local execution environment, the proxy is tested against local mock servers to verify header injection and payload streaming behaviors.
3. Phase 3: Staging Environment Verification: The Worker is deployed to a non-production route (staging.tinyrustlm.com), allowing manual browser testing to confirm end-to-end connectivity with the staging database.
4. Phase 4: Production Verification Gate: The live deployment is subjected to an automated validation script.

Production Verification Matrix and Gate Script

The production gate verification script, deployed at eng/verify-memory-endpoints-relay-production.sh, programmatically validates the live deployment before traffic shifting is considered complete. The script executes a matrix of curl requests against the live proxy to verify exact edge behaviors.

Final Definition of Done (DoD)

The deployment is definitively signed-off and promoted to full, unmonitored production only when the following live evidence is documented:

1. Zero-Error Verification Gate: Executing the verify-memory-endpoints-relay-production.sh script against the active production domain completes seamlessly with a zero exit status, confirming all security and routing assertions.
2. Strict CORS Reflections: Edge responses to OPTIONS preflight requests reflect explicit domain origins absolutely accurately, with wildcard strings (\*) fully absent from all origin responses.
3. Active Logging Redaction Verified: Structured log outputs captured via wrangler tail verify that HTTP headers matching Authorization and X-MemoryEndpoints-Key are successfully obfuscated as \[REDACTED\], with raw conversational payloads systematically excluded from storage.
4. Static Application Uninterrupted: Loading standard assets from the apex domain accurately serves the static index.html, Rust WASM binaries, and deterministic .slm weights without any routing interference, cache destruction, or compute billing overhead.
5. Telemetry Integrity Established: Real-time request counts, status code dimensions, and upstream connection latencies are logged successfully, establishing an active and secure production boundary.

Works cited

1. Implementation \- MiRust, https://mirust.com/implementation/
2. Implementation operations \- MiRust, https://mirust.com/implementation-operations/
3. IAAR-Shanghai/Awesome-AI-Memory \- GitHub, https://github.com/IAAR-Shanghai/Awesome-AI-Memory
4. Configure CORS · Cloudflare R2 docs, https://developers.cloudflare.com/r2/buckets/cors/
5. Persistent CORS Preflight Error Between Pages and Worker (Headers Missing Despite W, https://community.cloudflare.com/t/persistent-cors-preflight-error-between-pages-and-worker-headers-missing-despite-w/792940
6. Cloudflare Pages, https://pages.cloudflare.com/
7. Limits · Cloudflare for Platforms docs, https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/reference/limits/
8. Routes \- Workers \- Cloudflare Docs, https://developers.cloudflare.com/workers/configuration/routing/routes/
9. Wildcard subdomains for Pages in 2026? \- Cloudflare Community, https://community.cloudflare.com/t/wildcard-subdomains-for-pages-in-2026/908010
10. NextJS Cloudflare Deployment Guide: Pages, Workers and Images \- CDN Blog, https://blog.blazingcdn.com/en-us/nextjs-cloudflare-deployment-guide-pages-workers-images
11. Edge Computing: Cloudflare Workers Dev Guide 2026 \- Digital Applied, https://www.digitalapplied.com/blog/edge-computing-cloudflare-workers-development-guide-2026
12. Railway vs Cloudflare: two platforms solving different problems in 2026 | Blog \- Northflank, https://northflank.com/blog/railway-vs-cloudflare
13. What is Cloudflare Workers? \- Pangea.app, https://pangea.app/glossary/cloudflare-workers
14. Cloudflare Workers vs AWS Lambda@Edge (2026), Which Edge \- Gautam Khorana, https://gautamkhorana.com/edge-compute/compare/cloudflare-workers-vs-aws-lambda-edge/
15. Understanding Cloudflare Containers: A Comprehensive Pricing Guide for Developers, https://lalatenduswain.medium.com/understanding-cloudflare-containers-a-comprehensive-pricing-guide-for-developers-9f7242a2ac20
16. Vercel AI Pricing Plans 2026: How Much Does It Cost? \- Truefoundry, https://www.truefoundry.com/blog/understanding-vercel-ai-gateway-pricing
17. Cloudflare Workers vs Vercel (2026): $0.30/M Requests vs $20/Seat | Pricing, Cold Starts, Limits \- MorphLLM, https://www.morphllm.com/comparisons/cloudflare-workers-vs-vercel
18. Vercel Pricing Explained: What You Actually Pay in 2026 \- Kuberns, https://kuberns.com/blogs/vercel-pricing/
19. How to Optimize Vercel Cost in 2026 \- FocusReactive, https://focusreactive.com/vercel-cost-optimization/
20. Vercel Pricing Plans and Hidden Costs Explained (2026) \- Schematic, https://schematichq.com/blog/vercel-pricing
21. How To Fix CORS Errors On Cloudflare Workers \- Confidence Okoghenun, https://confidence.sh/blog/how-to-fix-cors-errors-on-cloudflare-workers/
22. URL | Node.js v26.4.0 Documentation, https://nodejs.org/api/url.html
23. URL \- Wikipedia, https://en.wikipedia.org/wiki/URL
24. WHATWG URL Standard, https://url.spec.whatwg.org/
25. It is incorrect to "normalize" // in HTTP URL paths \- Hacker News, https://news.ycombinator.com/item?id=47813454
26. proxy\_pass: nginx's Dangerous URL Normalization of Paths | Joshua Rogers' Scribbles, https://joshua.hu/proxy-pass-nginx-decoding-normalizing-url-path-dangerous
27. "duplicated slashes" normalization should be optional · Issue \#12666 · traefik/traefik \- GitHub, https://github.com/traefik/traefik/issues/12666
28. Normalize encoded slashes in URL path · Cloudflare Rules docs, https://developers.cloudflare.com/rules/transform/examples/normalize-encoded-slash/
29. Models \- MiRust, https://mirust.com/models/
30. Limits · Cloudflare Workflows docs, https://developers.cloudflare.com/workflows/reference/limits/
31. Limits · Cloudflare Workers docs, https://developers.cloudflare.com/workers/platform/limits/
32. Versions & deployments \- Workers \- Cloudflare Docs, https://developers.cloudflare.com/workers/versions-and-deployments/
33. Gradual deployments \- Workers \- Cloudflare Docs, https://developers.cloudflare.com/workers/versions-and-deployments/gradual-deployments/
34. Deployment management \- Workers \- Cloudflare Docs, https://developers.cloudflare.com/workers/versions-and-deployments/deployment-management/
35. Version affinity \- Workers \- Cloudflare Docs, https://developers.cloudflare.com/workers/versions-and-deployments/gradual-deployments/version-affinity/
36. Rollbacks · Cloudflare Workers docs, https://developers.cloudflare.com/workers/versions-and-deployments/rollbacks/