How Cloudflare Workers and Deno Deploy Function as Relay Deployers in OmniRoute

Cloudflare Workers and Deno Deploy act as serverless edge proxies that OmniRoute deploys dynamically to bypass network restrictions, forwarding LLM requests from restricted environments to upstream providers while keeping credentials secure.

OmniRoute centralizes request routing for dozens of LLM providers. When direct outbound access is blocked by corporate firewalls or network policies, Cloudflare Workers and Deno Deploy function as relay deployers by running lightweight proxy scripts on global edge networks. This architecture allows OmniRoute to route traffic through trusted serverless environments rather than exposing API keys to client-side code.

Understanding the Relay-Deployer Architecture

The Proxy Registry and Type Enum

In src/lib/proxyRelay/proxyRegistry.ts, OmniRoute defines a proxy-registry schema that recognizes cloudflare and deno as special relay types. The registry stores the mapping between proxy contexts and their deployed endpoint URLs, enabling the system to resolve the correct relay target at runtime.

The ProxyFetch Dispatcher

The proxyFetch function in src/lib/proxyRelay/proxyFetch.ts serves as the core dispatcher. When a request arrives with type: "cloudflare" or type: "deno", the function short-circuits the generic HTTP proxy logic and routes the request directly to the stored worker or deployment URL.

Deploy API Routes and Script Builders

OmniRoute exposes HTTP endpoints to programmatically create relays. The POST /api/settings/proxy/cloudflare-deploy route (defined in src/app/api/settings/proxy/cloudflare-deploy/route.ts) accepts a script, authentication token, and target host, then invokes cloudflareWorkerScript.ts to generate the worker source. Similarly, denoDeployScript.ts produces Deno-compatible scripts using Deno Deploy's fetch and Headers APIs.

Upload Logic and Authentication

The upload implementations reside in src/lib/proxyRelay/cloudflareDeploy.ts and src/lib/proxyRelay/denoDeploy.ts. These modules call the respective platform APIs—Cloudflare's /accounts/:accountId/workers/scripts/:scriptName endpoint and Deno Deploy's /v1/projects/:projectId/deployments—using tokens supplied through the relayAuth field of the proxy configuration.

Runtime Request Flow

After deployment, the resulting URL (e.g., https://<script>.workers.dev) is persisted in the proxy-registry database (src/lib/db/proxyRegistry.ts). Subsequent requests reuse this endpoint. Both deployers leverage buildRelayHeaders.ts to inject X-OmniRelay-Type, X-OmniRelay-Auth, and tracing IDs into outgoing requests.

Deploying a Cloudflare Worker Relay

To deploy a Cloudflare Worker relay programmatically, use the deployCloudflareRelay function from src/lib/proxyRelay/cloudflareDeploy.ts:

import { deployCloudflareRelay } from '@/lib/proxyRelay/cloudflareDeploy';

const script = `
addEventListener('fetch', event => {
  event.respondWith(fetch(event.request));
});
`;

await deployCloudflareRelay({
  accountId: 'YOUR_CLOUDFLARE_ACCOUNT_ID',
  scriptName: 'omniroute-relay',
  script,
  relayAuth: 'Bearer YOUR_CLOUDFLARE_API_TOKEN',
});

This function builds the final worker script using cloudflareWorkerScript.ts, uploads it via the Cloudflare Workers API, and records the resulting endpoint URL in the proxy registry.

Deploying a Deno Deploy Relay

For Deno Deploy, the deployDenoRelay function in src/lib/proxyRelay/denoDeploy.ts follows a similar pattern:

import { deployDenoRelay } from '@/lib/proxyRelay/denoDeploy';

const denoScript = `
import { serve } from "https://deno.land/std@0.215.0/http/server.ts";

serve(async (req) => {
  const url = new URL(req.url);
  url.hostname = "api.provider.com";
  return fetch(url.toString(), {
    method: req.method,
    headers: req.headers,
    body: req.body,
  });
});
`;

await deployDenoRelay({
  projectId: 'YOUR_DENO_PROJECT_ID',
  script: denoScript,
  relayAuth: 'Bearer YOUR_DENO_DEPLOY_TOKEN',
});

The helper constructs the deployment payload via denoDeployScript.ts, publishes it to Deno's REST API, and stores the returned deployment URL for subsequent routing.

Routing Requests Through the Relay

Once deployed, route LLM requests through the relay by specifying the proxy context in your OmniRoute calls:

import { fetchOmni } from '@/open-sse/handlers/chatCore';

await fetchOmni({
  model: 'cloudflare-ai/@cf/qwen/qwq-32b',
  messages: [{ role: 'user', content: 'Hello' }],
  proxy: {
    type: 'cloudflare',
    host: 'my-relay.workers.dev',
    relayAuth: 'Bearer YOUR_CLOUDFLARE_API_TOKEN',
  },
});

The proxyFetch layer detects the type: 'cloudflare' configuration, resolves the stored worker URL, and forwards the request. The worker executes the actual HTTP call to the provider, streaming the response (including SSE chunks) back through OmniRoute to the client unchanged.

Key Implementation Files

• src/lib/proxyRelay/proxyRegistry.ts – Defines the proxy-registry schema including the cloudflare and deno type enum.
• src/lib/proxyRelay/proxyFetch.ts – Core dispatcher that detects relay types and routes requests to edge endpoints.
• src/app/api/settings/proxy/cloudflare-deploy/route.ts – API endpoint that receives worker scripts and triggers Cloudflare deployment.
• src/lib/proxyRelay/cloudflareWorkerScript.ts – Generates Cloudflare Worker source code with request forwarding and header handling.
• src/lib/proxyRelay/cloudflareDeploy.ts – Implements HTTP calls to Cloudflare's Workers API for script uploads.
• src/lib/proxyRelay/denoDeployScript.ts – Generates minimal Deno Deploy scripts for proxying inbound requests.
• src/lib/proxyRelay/denoDeploy.ts – Calls the Deno Deploy REST API to publish scripts.
• src/lib/proxyRelay/buildRelayHeaders.ts – Shared helper adding X-OmniRelay-Type, X-OmniRelay-Auth, and tracing headers.
• src/lib/db/proxyRegistry.ts – Persists mappings from proxy contexts to deployed worker URLs.

Summary

• Cloudflare Workers and Deno Deploy function as serverless edge proxies that OmniRoute deploys dynamically to circumvent network restrictions.
• The proxy registry (proxyRegistry.ts) tracks relay types and endpoint URLs, while proxyFetch.ts routes requests to the appropriate deployer.
• Script builders generate platform-specific code that forwards requests and handles authentication headers without exposing credentials to clients.
• Upload modules automate deployment via platform APIs, storing the resulting endpoints for persistent routing.
• SSE streaming is preserved through the relay, maintaining real-time response contracts required by LLM chat interfaces.

Frequently Asked Questions

When should I use a relay deployer instead of a direct connection?

Use a relay deployer when operating behind corporate firewalls that block direct outbound access to LLM provider APIs, or when you need to isolate API keys from client environments. According to the OmniRoute source code, the worker runs on Cloudflare's edge network or Deno's global edge, which typically maintains unrestricted outbound connectivity.

How are API credentials secured when using Cloudflare Workers or Deno Deploy relays?

API keys are stored only in the worker's or deployment's environment variables, never exposed to the client. The relayAuth token is used solely for the initial deployment API call and subsequent request authentication via headers like X-OmniRelay-Auth, keeping provider credentials isolated within the edge environment.

Does the relay support streaming responses like SSE?

Yes. Both the Cloudflare Worker script builder (cloudflareWorkerScript.ts) and Deno Deploy script builder (denoDeployScript.ts) forward data chunks unchanged, preserving the response-stream contract required by OmniRoute's SSE engine. This ensures real-time chat completions stream correctly through the relay.

Can I customize the worker or deployment script?

Yes. While OmniRoute provides default implementations in cloudflareWorkerScript.ts and denoDeployScript.ts, you can supply custom script strings to the deployCloudflareRelay or deployDenoRelay functions. The deploy API routes accept arbitrary script content, allowing you to inject custom logic for logging, request transformation, or additional authentication layers.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}