💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

1. 2026年のエッジコンピュート地図 — V8 isolate / WASM / Firecracker の3モデル

2026年5月現在、「エッジコンピュート」という言葉はもう一つのカテゴリではありません。同じ「サーバーレス関数」に見えても、内部の実行モデルは明確に3つに分かれています。

| --- | --- | --- | --- |

トレードオフは常に同じです。

- **V8 isolate**: 最速のコールドスタート、最も広いグローバル分散(300+ PoP)、ただし Node.js ネイティブアドオン不可

- **WebAssembly**: 言語の自由度(Rust, Go, Swift, JavaScript すべて WASM にコンパイル可能)、マイクロ秒のコールドスタート、ただしエコシステムは小さい

- **MicroVM**: 完全な Linux、すべての npm パッケージが動く、ただしコールドスタートは重く地理分散は限定的

2026年のトレンドは明確です。**フルスタックエッジプラットフォーム**(Cloudflare)と **ハイブリッドサーバーレス**(Vercel Fluid Compute)が両極を占め、残りは特定ワークロード(Fastly の CDN、Deno の Web 標準、Bun の速度)に居場所を見つけています。

WinterCG から WinterTC へ — 標準の進化

すべての主要エッジランタイムが WinterTC(旧 WinterCG)の [Minimum Common API](https://wintertc.org/) を実装しています。`fetch`、`Request`、`Response`、`URLPattern`、`crypto.subtle`、`TextEncoder`、`ReadableStream`、`Headers`、`FormData`、`AbortController` はどこでも同じ動作をします。**つまり、よく書かれたエッジ関数は Cloudflare Workers、Deno Deploy、Vercel Edge、Netlify Edge で一行も変えずに動きます。**

2. Cloudflare Workers — 最も完成したエッジプラットフォーム

Cloudflare Workers は 2025-2026 年にかけて、単純な「エッジ関数」から完全なフルスタックプラットフォームへと進化しました。主要な構成要素は7つあります。

| サービス | 役割 | 2026年5月の状態 |

| --- | --- | --- |

| Workers | V8 isolate 実行環境 | GA、300+ PoP |

| R2 | S3 互換オブジェクトストレージ | GA、egress 無料 |

| D1 | SQLite ベースのグローバル DB | GA(2024年4月) |

| Durable Objects | ステートフルオブジェクト(SQLite バックエンド) | GA、SQLite バックエンドは2025年 GA |

| Hyperdrive | Postgres / MySQL コネクションプーラー | GA |

| Queues | メッセージキュー | GA |

| Workers AI | GPU 推論 | GA |

最大の変化は **Durable Objects の SQLite バックエンド**です。従来 K/V 形式だった状態保存が、2025年から各 DO インスタンスに組み込み SQLite が付くようになりました。つまり **各 Durable Object はミニデータベース + コンピュート**の組み合わせになったわけです。

// Durable Object with SQLite backend (2025+)

export class ChatRoom extends DurableObject {

sql: SqlStorage

constructor(state: DurableObjectState, env: Env) {

super(state, env)

this.sql = state.storage.sql

this.sql.exec(`

CREATE TABLE IF NOT EXISTS messages (

id INTEGER PRIMARY KEY AUTOINCREMENT,

user TEXT NOT NULL,

body TEXT NOT NULL,

ts INTEGER NOT NULL

)

}

async addMessage(user: string, body: string) {

this.sql.exec(

'INSERT INTO messages (user, body, ts) VALUES (?, ?, ?)',

user,

body,

Date.now()

)

}

async recent(limit = 50) {

return this.sql

.exec('SELECT * FROM messages ORDER BY ts DESC LIMIT ?', limit)

.toArray()

}

Hyperdrive — エッジから Postgres を使う方法

Workers の V8 isolate は TCP ソケットを直接開けないのが長年の制約でした。Hyperdrive がこれを解決します。Postgres / MySQL の接続を Cloudflare のネットワーク内部でプーリングし、Workers は HTTP ライクなインターフェースでクエリを投げます。

// wrangler.toml

// [[hyperdrive]]

// binding = "DB"

// id = "your-hyperdrive-id"

export default {

async fetch(req: Request, env: Env): Promise<Response> {

const client = new Client({ connectionString: env.DB.connectionString })

await client.connect()

const { rows } = await client.query('SELECT NOW()')

return Response.json(rows)

}

Hyperdrive の本当の価値は **グローバルコネクションプーリング + エッジキャッシング**です。東京から来たリクエストがアメリカの RDS まで往復せず、東京 PoP のプール済み接続を再利用し、キャッシュ可能なクエリはキャッシュから返します。

3. Cloudflare Workers AI / Vectorize / AI Gateway

2026年5月時点で、Cloudflare の AI スタックは3本柱です。

- **Workers AI**: Llama 3、Mistral、Stable Diffusion など 50+ モデルを GPU で直接推論。PoP に分散された H100/A100。

- **Vectorize**: ベクトル DB。RAG に必須。メタデータフィルタリング、32K 次元対応。

- **AI Gateway**: OpenAI、Anthropic、Replicate などの外部 LLM API をプロキシ。キャッシング、レート制限、ロギング、トークンコストのトラッキング。

// AI Gateway through Workers

export default {

async fetch(req: Request, env: Env): Promise<Response> {

// 1) Workers AI (Cloudflare's own GPU)

const llmResp = await env.AI.run('@cf/meta/llama-3-8b-instruct', {

messages: [

{ role: 'system', content: 'You are a helpful assistant.' },

{ role: 'user', content: 'Explain edge compute in one sentence.' },

})

// 2) AI Gateway proxy to OpenAI (cached, rate-limited)

const openaiResp = await fetch(

'https://gateway.ai.cloudflare.com/v1/ACCOUNT/my-gw/openai/chat/completions',

{

method: 'POST',

headers: {

Authorization: `Bearer ${env.OPENAI_KEY}`,

'Content-Type': 'application/json',

body: JSON.stringify({

model: 'gpt-4o-mini',

messages: [{ role: 'user', content: 'Hello' }],

}),

}

)

return Response.json({ workers_ai: llmResp, openai: await openaiResp.json() })

}

AI Gateway の本当の怖さは **すべての外部 LLM 呼び出しをキャッシュできる**点です。同じプロンプト + 同じモデルならキャッシュヒットでコストがゼロになります。本番ワークロードでトークン単価が 30-60% 削減される事例が普通に出ています。

4. Cloudflare Containers(2024年発表) — エッジで Linux

2024年9月に発表され、2025年ベータを経て2026年に GA に到達した Cloudflare Containers は、Workers の V8 isolate 制限を正面から突破します。**完全な Linux コンテナを Cloudflare PoP で実行**できるのです。

特徴:

- **リージョン固定が可能**: Workers と違い、コンテナは特定リージョン(例: ソウル)にピン留めできます。

- **Workers との緊密な連携**: Worker コード内で `env.MY_CONTAINER.fetch(req)` でコンテナを起動して呼び出せます。最初の呼び出しはコールドスタート(5-10 秒)ですが、その後は暖かい状態で保たれます。

- **OCI イメージ**: 通常の Dockerfile が使えます。ffmpeg、headless Chrome、Python ML ライブラリなんでも。

- **ユースケース**: 動画トランスコーディング、ヘッドレスブラウザ、AI 推論(GPU 未対応)、レガシーコードのホスティング。

// wrangler.toml

// [[containers]]

// binding = "MY_CONTAINER"

// image = "./Dockerfile"

// max_instances = 5

export default {

async fetch(req: Request, env: Env): Promise<Response> {

// Container is auto-started, kept warm for some time

const container = env.MY_CONTAINER.get(env.MY_CONTAINER.idFromName('worker-1'))

return container.fetch(req)

}

Cloudflare Containers は **Workers + Containers のハイブリッドアーキテクチャ**への道を開きます。通常のリクエストは Workers(0 ms cold)で、重い処理は Containers(Linux full)へルーティングするパターンが標準になりつつあります。

5. Vercel Fluid Compute(2025年4月) — サーバーレス進化の次の段階

2025年4月、Vercel は既存の Serverless Functions を **Fluid Compute** という名前で全面的に再設計しました。コアアイデアはシンプルです。

> 「1 インスタンス = 1 リクエスト」のサーバーレスモデルを捨て、**1つのインスタンスが複数のリクエストを同時に処理**する。

従来の AWS Lambda モデルでは、同時リクエストごとに新しいインスタンスを起動します。Vercel Fluid Compute では1つの Node.js プロセスが複数のリクエストを in-flight で扱い、**I/O 待ち時間を他のリクエストに譲り合います**。結果として:

- **コールドスタート頻度の低下**: 同じインスタンスが長く生き、より多くのリクエストを処理

- **コスト削減**: 同時処理によって同じトラフィックをより少ないインスタンスで処理(Vercel 公式発表で平均 40-90% 削減)

- **AI ワークロードに最適**: LLM レスポンス待ち時間(数秒)に他のリクエストを差し込める

Fluid Compute はすべての Vercel 関数のデフォルトになりました。**Edge Runtime はそのまま V8 isolate 上で動き**、**Node.js Runtime が Fluid に進化**した形です。

// app/api/chat/route.ts (Next.js 15+)

// Runs on Vercel Fluid Compute by default

export async function POST(req: Request) {

const { prompt } = await req.json()

// This await frees the Fluid worker to handle other requests

// while the LLM streams back

const stream = await openai.chat.completions.create({

model: 'gpt-4o',

messages: [{ role: 'user', content: prompt }],

stream: true,

})

return new Response(stream.toReadableStream(), {

headers: { 'Content-Type': 'text/event-stream' },

})

}

Edge Functions の今後は?

Vercel は 2025 年後半から **Edge Functions(Edge Runtime)と Fluid Compute の境界を徐々に曖昧に**しています。Middleware は引き続き Edge で動きますが、route handler は大抵 Fluid のほうが有利です。推奨ルールは:

- **Middleware、ジオロケーション、A/B ルーティング**: Edge Runtime(V8 isolate)

- **API route、LLM 呼び出し、DB クエリ**: Fluid Compute(Node.js)

- **静的ページ**: ISR + CDN(Edge Cache)

6. Deno Deploy + KV + Queues

Deno Deploy は Deno ランタイムをグローバル 35 リージョンの V8 isolate 上で実行します。最大の強みは **Web 標準ファースト**であることです。

- `Deno.serve()` で即座に HTTP サーバー起動

- `Deno.openKv()` — strongly consistent な KV ストア(FoundationDB ベース)

- `Deno.cron()` — コード内で直接 cron を定義

- `Deno.serve()` ハンドラから直接キューに enqueue / dequeue

// main.ts

const kv = await Deno.openKv()

Deno.serve(async (req) => {

const url = new URL(req.url)

if (url.pathname === '/enqueue') {

await kv.enqueue({ task: 'send-email', to: 'user@example.com' })

return new Response('Queued')

}

if (url.pathname === '/count') {

const result = await kv.get<number>(['visits'])

const next = (result.value ?? 0) + 1

await kv.atomic().check(result).set(['visits'], next).commit()

return new Response(`Visits: ${next}`)

}

return new Response('Hello from Deno Deploy')

})

// Queue consumer

kv.listenQueue(async (msg: { task: string; to: string }) => {

console.log('Processing:', msg.task, msg.to)

// send email...

})

// Cron job — runs every hour

Deno.cron('hourly cleanup', '0 * * * *', async () => {

await kv.delete(['expired-cache'])

})

Deno Deploy の魅力は **追加インフラなしで小さなフルスタックアプリが完成する**点です。Deno + Deno KV + Deno Queues + Deno Cron だけでバックエンドが完結します。Fresh フレームワークや Hono と相性抜群です。

2026年現在の Deno Deploy の弱点は **AWS / Cloudflare に比べてリージョン数が少ない**こと(35 vs 300+)と、**コールドスタートが Workers よりやや遅い**ことです。

7. Fastly Compute@Edge — WASM ベース

Fastly は最初から **WebAssembly(Wasmtime ベース)** を選んだ唯一の主要エッジプラットフォームです。名前も 2024 年に単に「Fastly Compute」に短縮されました。WASM の利点:

- **マイクロ秒単位のコールドスタート**: V8 isolate より速い 35 マイクロ秒レベル

- **多言語サポート**: Rust、JavaScript、Go(TinyGo)、AssemblyScript、Swift、C/C++

- **V8 isolate より強いサンドボックス**: WASI による capability ベースの権限モデル

// Rust on Fastly Compute

use fastly::http::{Method, StatusCode};

use fastly::{Error, Request, Response};

#[fastly::main]

fn main(req: Request) -> Result<Response, Error> {

match (req.get_method(), req.get_path()) {

(&Method::GET, "/") => Ok(Response::from_status(StatusCode::OK)

.with_body_text_plain("Hello from Fastly WASM!")),

(&Method::POST, "/api/echo") => {

let body = req.into_body_str();

Ok(Response::from_status(StatusCode::OK).with_body_text_plain(&body))

}

_ => Ok(Response::from_status(StatusCode::NOT_FOUND)),

}

Fastly の強みは **CDN との深い統合**です。元々 CDN 会社なので、キャッシュ無効化、ESI(Edge Side Includes)、VCL との結合が自然です。メディア、ニュース、e コマースの CDN ワークロードに最適。

弱点は **フルスタックビルディングブロックがない**ことです。KV ストアはありますが、DB、キュー、AI は外部依存。Cloudflare のように一か所で全て完結はできません。

8. Bun on Render / Fly.io / Railway / Coolify

Bun はエッジプラットフォームの一級市民ではありません。正確には **ローカル開発 + 通常のコンテナホスティング**の組み合わせで強力です。2026年現在、Bun 1.2 が安定版で、Render / Fly.io / Railway / Coolify が一級 Bun サポートを持っています。

// server.ts — Bun 1.2 native HTTP server

const server = Bun.serve({

port: 3000,

fetch(req) {

const url = new URL(req.url)

if (url.pathname === '/json') {

return Response.json({ hello: 'world', runtime: 'bun' })

}

return new Response('Hello from Bun!')

})

console.log(`Listening on ${server.url}`)

Bun の価値提案:

- **高速な起動時間**: Node.js より 2-3 倍速いコールドスタート

- **バンドラー + トランスパイラー + パッケージマネージャー + テストランナーが統合**: `bun install`、`bun build`、`bun test` を一つのツールで

- **Web 標準 API ファースト**: `fetch`、`Request`、`Response` がネイティブ

- **Node.js 互換性 95%+**: 大抵の npm パッケージが動く

Bun をどこで動かすか?

- **Fly.io**: Firecracker microVM ベース、グローバル 30+ リージョン。Bun コンテナをそのままデプロイ可能。WebSocket、永続ボリュームに対応。

- **Render**: 単一リージョン中心だが最も簡単なデプロイ体験。Bun ビルドパックが一級。

- **Railway**: Render に類似。より強い PaaS の印象。

- **Coolify**: セルフホスト PaaS。自前 VPS で Vercel ライクな体験。

Bun + Fly.io が特に人気の理由は **Cloudflare Workers の制約(50 ms CPU time、128 MB RAM)を避けながらグローバル分散を維持**できる点です。

9. Netlify Edge Functions

Netlify Edge Functions は **Deno ランタイムを Netlify インフラ上で実行**する形態です。つまりコードモデルは Deno Deploy と同じで、違いはインフラ(Netlify の CDN)+ 統合(Netlify Forms、Identity、Blobs)だけです。

// netlify/edge-functions/geo.ts

export default async (req: Request, context: Context) => {

const country = context.geo.country?.code ?? 'unknown'

const city = context.geo.city ?? 'unknown'

return new Response(

JSON.stringify({ country, city, ip: context.ip }),

{ headers: { 'Content-Type': 'application/json' } }

)

}

export const config: Config = {

path: '/api/geo',

}

Netlify は **静的サイトホスティングが本業**で、Edge Functions は補助ツールです。SSG + 一部の動的ルートなら Netlify が最速で展開できますが、フルサーバーサイドアプリなら Vercel か Cloudflare のほうが適しています。

10. AWS Lambda SnapStart — コールドスタート問題の解決

Lambda は長らくコールドスタート問題でエッジに後れを取っていました。Java は数秒、Python でも数百 ms が基本でした。2022 年に Java 向けに始まった **SnapStart** が 2024 年に Python / .NET まで拡張され、2026 年現在はほぼすべてのマネージドランタイムで利用可能になりました。

SnapStart の原理:

1. 関数が初めてデプロイされたときに一度だけ初期化(`Init`)を実行

2. Firecracker microVM のメモリスナップショットを保存(数十 MB)

3. コールドスタート時にスナップショットを復元 — 初期化ステージをスキップ

4. 結果: コールドスタートが 50 ms 以下まで下がる(Java で 90% 削減)

AWS SAM template

Resources:

MyFunction:

Type: AWS::Serverless::Function

Properties:

Runtime: python3.13

Handler: app.handler

CodeUri: ./src

SnapStart:

ApplyOn: PublishedVersions

SnapStart の制限:

- **PublishedVersions にのみ適用**: `$LATEST` エイリアスには適用不可。デプロイワークフローが少し複雑に。

- **VPC + ENI 時間は減らない**: ネットワーク接続時間は別問題。

- **スナップショット時点の可変状態に注意**: 初期化段階で作った DB 接続などはスナップショットに焼き込まれ、復元後は死んだ接続の可能性があります。SDK が提供するフック(`beforeCheckpoint` / `afterRestore`)で対処が必要です。

Lambda は SnapStart でコールドスタートをある程度解決しましたが、**依然としてリージョン数が約 30 で、真のエッジ(300+ PoP)ではありません。** Lambda@Edge がその役割を担っていましたが、CloudFront に縛られ制約が多く、2026 年には事実上 Cloudflare Workers / Vercel Edge に席を譲りました。

11. Supabase Edge Functions

Supabase Edge Functions は **Deno ランタイム + Supabase DB / Auth / Storage の統合**です。コードは Deno Deploy とほぼ同じですが、`import { createClient } from 'jsr:@supabase/supabase-js'` で Supabase リソースに認証付きでアクセスできます。

// supabase/functions/send-welcome/index.ts

Deno.serve(async (req) => {

const { user_id } = await req.json()

const supabase = createClient(

Deno.env.get('SUPABASE_URL')!,

Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!

)

const { data: profile } = await supabase

.from('profiles')

.select('email, name')

.eq('id', user_id)

.single()

// Send email...

return new Response(JSON.stringify({ ok: true, profile }))

})

デプロイは `supabase functions deploy send-welcome` の一行。自動的に `https://PROJECT.supabase.co/functions/v1/send-welcome` エンドポイントができます。

Supabase Edge は **既に Supabase を使っているチーム**に最適です。DB + Auth + Storage + Realtime + Edge Functions が一つのコンソールにあり、RLS と自動連動します。欠点はリージョンが少なく、Cloudflare ほどの分散ではないことです。

12. WinterCG / WinterTC — クロスプラットフォーム標準

WinterCG は 2022 年に W3C コミュニティグループとして始まり、2025 年に **Ecma TC55(WinterTC)** に昇格しました。今や ECMA 公式の標準トラックです。目的はシンプルです。

> **サーバーサイド JavaScript ランタイムが従うべき共通 API サーフェス(Minimum Common API)を定義する。**

2026年5月時点で、以下のランタイムが WinterTC Minimum Common API 互換を宣言しています。

- Cloudflare Workers

- Deno Deploy / Deno

- Vercel Edge Runtime

- Netlify Edge Functions

- Supabase Edge Functions

- Bun

- Fastly Compute(JavaScript SDK)

コア API:

- `fetch`、`Request`、`Response`、`Headers`、`FormData`

- `URL`、`URLPattern`、`URLSearchParams`

- `TextEncoder`、`TextDecoder`、`Blob`、`File`

- `crypto.subtle`、`crypto.getRandomValues`

- `ReadableStream`、`WritableStream`、`TransformStream`

- `AbortController`、`AbortSignal`

- `console`、`setTimeout`、`setInterval`、`queueMicrotask`

- `structuredClone`、`EventTarget`、`Event`、`CustomEvent`

**実用的な意味**: WinterTC API だけを使ったよく書かれたエッジ関数は、5つのプラットフォームで一行も変えずに動きます。フレームワーク(Hono、itty-router、Hattip)はこの標準の上でマルチプラットフォームをサポートします。

// Hono — runs on Cloudflare Workers, Deno Deploy, Vercel Edge, Bun, Node.js

const app = new Hono()

app.get('/', (c) => c.text('Hello from any edge runtime!'))

app.get('/json', (c) => c.json({ runtime: 'wintertc-compatible' }))

app.post('/echo', async (c) => c.json(await c.req.json()))

export default app

// Cloudflare: export default app

// Deno: Deno.serve(app.fetch)

// Bun: Bun.serve({ port: 3000, fetch: app.fetch })

// Node: serve({ fetch: app.fetch, port: 3000 })

13. 誰が何を選ぶべきか — グローバル / 韓国 / 日本トラフィック

グローバルトラフィック(北米 + 欧州 + アジア均等)

- **第1位: Cloudflare Workers + R2 + D1 + Workers AI** — 300+ PoP、最速のグローバルレスポンス、egress 無料

- **第2位: Vercel Fluid Compute(Edge + Fluid ハイブリッド)** — Next.js 優先、AI/RAG ワークロード最適

- **AI ヘビー**: Workers AI + Vectorize + AI Gateway の組み合わせが最も統合度が高い

韓国トラフィック中心

韓国はすべての主要クラウドの KR リージョンがあり選択肢が多いです。

- **フルスタックエッジ**: Cloudflare(ソウル PoP あり)または Vercel(icn1)

- **DB が韓国にある必要がある**: AWS Seoul(Lambda + RDS)または Supabase Tokyo + Cloudflare キャッシュ

- **レガシー互換 / Linux 必須**: AWS Lambda + SnapStart または Fly.io Singapore(韓国から 40-60 ms)

- **迷うなら**: Vercel + Supabase Tokyo が最も手軽なフルスタック

日本トラフィック中心

- **Cloudflare**: 東京 PoP は最大級のノードの一つ、日本トラフィックは非常に高速

- **Vercel**: `nrt1`(東京)リージョンが Edge から即応答

- **AWS**: `ap-northeast-1`(東京)Lambda SnapStart が 50 ms 以下のコールドスタート

- **Deno Deploy**: 東京リージョンあり、日本語 i18n サイトに適合

ワークロード別クイック選択マトリックス

| ワークロード | おすすめ |

| --- | --- |

| グローバル静的サイト + 一部 API | Cloudflare Workers + Pages |

| Next.js フルスタック + AI | Vercel Fluid Compute |

| Postgres ヘビー + エッジ | Cloudflare Workers + Hyperdrive |

| LLM API キャッシング / コスト削減 | Cloudflare AI Gateway |

| Deno ファースト、KV で完結できるバックエンド | Deno Deploy |

| WASM 多言語(Rust 等) | Fastly Compute |

| Linux 必須、npm フル互換 | Bun + Fly.io または Lambda SnapStart |

| Supabase をすでに使用中 | Supabase Edge Functions |

| 動画トランスコーディング / ヘッドレスブラウザ | Cloudflare Containers |

| 単一リージョンで OK、最も簡単なデプロイ | Render または Railway |

14. 参考 / References

- Cloudflare Workers — https://developers.cloudflare.com/workers/

- Cloudflare R2 — https://developers.cloudflare.com/r2/

- Cloudflare D1 — https://developers.cloudflare.com/d1/

- Cloudflare Durable Objects (SQLite backend) — https://developers.cloudflare.com/durable-objects/

- Cloudflare Hyperdrive — https://developers.cloudflare.com/hyperdrive/

- Cloudflare Queues — https://developers.cloudflare.com/queues/

- Cloudflare Workers AI — https://developers.cloudflare.com/workers-ai/

- Cloudflare Vectorize — https://developers.cloudflare.com/vectorize/

- Cloudflare AI Gateway — https://developers.cloudflare.com/ai-gateway/

- Cloudflare Containers — https://developers.cloudflare.com/containers/

- Vercel Fluid Compute (April 2025 announcement) — https://vercel.com/blog/introducing-fluid-compute

- Vercel Edge Functions — https://vercel.com/docs/functions/runtimes/edge

- Deno Deploy — https://docs.deno.com/deploy/

- Deno KV — https://docs.deno.com/deploy/kv/manual/

- Deno Queues — https://docs.deno.com/deploy/kv/manual/queue_overview/

- Fastly Compute — https://www.fastly.com/products/edge-compute

- Fastly Compute Wasmtime — https://docs.fastly.com/products/compute

- Bun — https://bun.sh/

- Fly.io Machines — https://fly.io/docs/machines/

- Render — https://render.com/docs

- Railway — https://docs.railway.app/

- Coolify — https://coolify.io/docs/

- Netlify Edge Functions — https://docs.netlify.com/edge-functions/overview/

- AWS Lambda SnapStart — https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html

- Supabase Edge Functions — https://supabase.com/docs/guides/functions

- WinterTC (Ecma TC55) — https://wintertc.org/

- WinterCG Minimum Common API — https://min-common-api.proposal.wintertc.org/

- Hono framework — https://hono.dev/