Architecture

Deno Deploy Subhosting is a platform for executing JavaScript, TypeScript, and WebAssembly code. Deno Deploy Subhosting is completely stateless - it doesn’t store code or execution results. All processing is done just-in-time through our HTTP API - isolates are spun up lazily, on demand.

The key architectural features of Deno Deploy Subhosting are:

• Deno Deploy handles all scaling, sandboxing and isolate execution. You integrate against a simple HTTP API.
• You implement a relay service that forwards well-formed HTTP traffic or events to Deno Deploy subhosting.
• You implement an origin service that implements a set of RPC endpoints that let Deno Deploy retrieve information required to execute your code, and send events to your system.

The diagram below illustrates what a typical Deno Deploy Subhosting implemementation looks like:

Here is how a typical HTTP request would get processed by your system:

1. The user sends a request to your relay service. The relay service accepts the request and figures out how this request should be served (for example based on the request’s URL).
2. If the request should be processed by Deno Deploy, you forward the request to Deno Deploy. In addition to the original headers, you add additional metadata headers like x-forwarded-host, and x-deno-subhost. The x-deno-subhost header lets Deno Deploy know which code to execute to handle the request.
3. Deno Deploy receives the request, and looks for existing isolates able to handle the request. If none are found:
   1. Deno Deploy makes an RPC request to your origin service to retrieve the source code and configuration for the isolate.
   2. Your origin RPC service retrieves the source code and configuration for the isolate, and returns it.
   3. Deno Deploy spins up the isolate with the given source code and configuration.
4. Deno Deploy forwards the request to the isolate for processing. The response is streamed back to the relay service.
5. The relay service forwards the response to the user.

All requests you send to Deno Deploy must be signed by you with a token provided by us. Our system will reject traffic that is not properly signed by a valid token.

All requests sent from Deno Deploy to your origin service are also signed by a token. You must verify the authenticity of incoming requests before processing them (more on this in a later chapter).

Reference implementation

We provide a reference implementation of the subhosting relay and origin. Reviewing these examples can aid you in building a successful Deno Deploy Subhosting integration.

Note that these example relay and origin services run on Deno Deploy themselves. This is for illustrative purposes only: your relay and origin don’t have to run on Deno Deploy - you can run them anywhere.