Edge Runtime Compatibility Matrix

Edge runtime compatibility matrix

An edge function is not a small virtual machine.

It is a program running inside a deliberately bounded host contract. That boundary is the reason functions can start quickly, move between nodes and share infrastructure safely. It is also the reason a package that works on a laptop may not work unchanged at the edge.

This reference describes BlinkHost's current function-shaped runtime model. It is versioned guidance, not a promise that every package in a language ecosystem can be compiled to WebAssembly.

Lifecycle summary

Runtime	BlinkHost status	Intended use
Rust targeting WASI	Generally available	Performance-sensitive request handlers and bounded services
Go through TinyGo	Generally available	Compact handlers using the documented TinyGo-compatible surface
JavaScript	Public beta	Web-standard request handlers with certified packages and adapters
TypeScript	Public beta	Type-checked source compiled into the same bounded JavaScript runtime
Python	Beta	Standard-library-first bounded handlers using curated pure-Python dependencies

Lifecycle labels matter. “Beta” means the capability is available within a documented contract but retains narrower compatibility and evidence gates than generally available runtimes.

Capability matrix

Capability	Rust	TinyGo	JavaScript / TypeScript	Python
HTTP request and response	GA	GA	Beta	Beta
Structured logging	GA	GA	Beta	Beta
Named database binding	GA	GA	Beta	Beta
Managed secrets	GA	GA	Beta	Beta
Policy-controlled outbound HTTP	GA	GA	Beta	Beta
Hosted object storage operations	GA	GA	Beta	Beta
Password hashing host operation	GA	GA	Beta	Beta
Scheduled, event and background triggers	Opt-in beta	Opt-in beta	Opt-in beta	Opt-in beta
Persistent listening server	Not this runtime	Not this runtime	Not this runtime	Not this runtime
Ambient filesystem	Unavailable	Unavailable	Unavailable	Unavailable
Ambient socket access	Unavailable	Unavailable	Unavailable	Unavailable
Arbitrary native add-ons	Restricted	Restricted	Unsupported	Unsupported

An unavailable ambient capability may still have a safe platform equivalent. For example, an application should use its named object-storage binding rather than expecting a writable disk to persist between invocations.

JavaScript and TypeScript

The JavaScript runtime is based on a managed Javy/QuickJS toolchain. It provides a deliberately limited Fetch-style request-and-response surface and bounded promise-job draining. It is not Node.js running inside a smaller container.

Good fits

• direct Fetch-style handlers;
• JSON APIs and webhooks;
• validation and transformation;
• named database and object-storage operations;
• bounded calls through the platform's outbound HTTP capability;
• packages published as portable JavaScript without native binaries or Node operating-system assumptions.

Certified and developing adapter paths

Hono has production-engine conformance evidence. Adapter foundations also exist for h3, itty-router, GraphQL Yoga and tRPC, but each package and version still needs its own compatibility evidence before it should be described as certified.

Common incompatibilities

• fs, net, tls, child_process, worker threads and native add-ons;
• packages that execute unrestricted install scripts;
• dynamic imports whose target cannot be determined at build time;
• libraries that depend on a long-running event loop, timers or a listening socket;
• code that assumes Node globals are complete.

Compatibility shims can help with harmless differences such as global names. They must not silently turn a security-sensitive capability into a no-op. A filesystem call that appears successful while writing nowhere is worse than a clear build error.

Python

Python uses a managed CPython-WASI runtime and is intentionally function-scoped.

Good fits

• parsing and validation with the supported standard-library subset;
• deterministic business rules;
• JSON APIs;
• named database operations;
• curated pure-Python packages that fit the execution and artifact envelope.

Common incompatibilities

• native wheels containing platform-specific C, C++ or Fortran extensions;
• subprocess, raw sockets and process management;
• packages requiring an unrestricted writable filesystem;
• Django, Flask or FastAPI used as persistent listening servers;
• scientific and media stacks that rely on native libraries unless a specific WASI port is certified;
• background threads or indefinite processes.

Python developers still write ordinary Python handlers. The constraint is architectural: request in, bounded work, response out. A managed function is not pretending to be a permanent Linux server.

Rust

Rust targets wasm32-wasip1 through a pinned toolchain and the versioned BlinkHost SDK.

Good fits

• predictable, low-overhead handlers;
• validation, cryptographic framing and data transformation using compatible crates;
• database and outbound operations exposed by the SDK;
• codebases that benefit from a strict type and ownership model.

Watch for

• crates that bind to operating-system libraries;
• threads or unsupported WebAssembly proposals;
• direct socket and filesystem assumptions;
• build scripts that need network access;
• dependencies not available in the controlled offline build set.

The Rust ecosystem contains many WASI-compatible crates, but language compatibility is not package compatibility.

Go through TinyGo

TinyGo provides a WebAssembly-oriented Go toolchain with a smaller runtime profile than the standard Go compiler for this environment.

Good fits

• straightforward HTTP handlers;
• JSON transformation;
• applications using the supported TinyGo standard-library surface;
• shared logic that can be compiled under TinyGo's documented constraints.

Watch for

• reflection-heavy libraries;
• packages depending on unsupported standard-library behaviour;
• cgo and operating-system bindings;
• goroutine patterns that assume unrestricted threading or a permanent process;
• differences between standard Go and TinyGo semantics or implementation coverage.

Test with the pinned TinyGo version used by the managed build rather than assuming a successful native Go build is equivalent.

Framework decision table

Workload	Recommended direction
React, Vue, Svelte, Solid or Astro static frontend	Build as a frontend target
Hono request handler within the certified version contract	JavaScript or TypeScript function beta
Small Python JSON handler	Python function beta
Rust or TinyGo request handler	GA function runtime
Django, FastAPI, Flask or Express server expecting a listening process	Use an appropriate managed application/container runtime; do not force it into a function
WebSocket server or long-lived connection coordinator	Use a product designed for persistent connections
CPU-heavy media processing	Use a queued, isolated compute workload with explicit resource economics
Scheduled bounded task	Opt-in background function if its limits fit

How package decisions are made

A package can be labelled:

• Certified: continuously tested in the published runtime contract.
• Compatible: passed the compatibility suite but is not part of the core supported matrix.
• Experimental: available behind an explicit gate without a production service commitment.
• Unsupported: rejected before deployment, ideally with a practical alternative.

The evaluation should inspect direct and transitive dependencies, native code, install scripts, dynamic imports, environment expectations, artifact size and real execution semantics. A successful compilation is necessary but not sufficient: a handler returning the framework's 404 page is not a successful compatibility test.

Portability guidance

Keep domain logic separate from platform adapters. A function can expose a small handler that translates the host request into ordinary application input and maps the result back into a response. Database, object storage and secrets should sit behind narrow interfaces.

That structure makes three forms of testing possible:

1. ordinary unit tests outside BlinkHost;
2. local or browser tests using adapter doubles;
3. conformance tests against the real managed runtime.

Portability does not mean the lowest common denominator. It means platform-specific capabilities are visible at the boundary instead of spreading through the application.

Further reading

• WASI
• Rust and WebAssembly
• TinyGo WebAssembly documentation
• Python WebAssembly platforms
• Javy
• WinterTC runtime keys