One Deploy. Two Clouds. Zero Ops.

Hyphen Cloud serves your static sites, WebAssembly handlers, and containers with no cold starts, fully redundant across two different cloud providers and regions with geo load balancing, backed by a 99.95% uptime SLA on every paid plan.

Documentation
Runtimes

One platform, more than one way to run

Static assets, WebAssembly handlers, and containers — side by side in the same app, behind the same deploy.

Static

Sites and SPAs served straight from object storage. SPA fallback, redirects, custom response headers, CORS, and per-path cache-control rules are all app config — no build step of ours to learn.

WebAssembly

Run request handlers at the gateway as standard WASI Preview 2 components targeting wasi:http/proxy. No proprietary SDK — if your toolchain emits a component, Hyphen Cloud runs it. Each request is sandboxed with its own memory, a CPU budget, and no network unless you allow-list the hosts.

Containers

Deploy a container and the control plane provisions it, then the gateway routes matching traffic to it. Long-running workloads get the same revisions, preview URLs, and atomic rollback as everything else on the platform.

Start building for free

The first 5 users are always free and $500 in credits for 12 months. No contracts. No lock-in.

Performance

Fast because of what it is, not how much it costs

Speed here is structural, not a tier you upgrade into. Nothing spins up on demand, so there is no cold start to pay for.

No cold starts

There is no function to spin up. The gateway is already running when your request arrives, so the first request of the day costs the same as the millionth — no warming, no provisioned concurrency to pay for.

Served from memory

The data plane answers from an in-process cache rather than reaching back to object storage on every hit. A cache invalidation reaches the gateway within milliseconds of a deploy, so fresh content does not mean a slow first visit.

Close to your visitors

Geo load balancing routes each visitor to the nearest origin that is passing health checks. Distance is decided per request, so traffic shifts as conditions change instead of waiting on a DNS TTL.

Resilience

Multi-cloud by default, not as an upgrade

Most platforms run your app in one provider's account and call the regions within it "redundancy". Hyphen Cloud runs active-active across two different cloud providers, in two different regions, for every app.

Two providers, two regions, both live

Your app runs on two different cloud providers, in two different regions, at the same time — not a warm standby you hope works. Both serve production traffic today.

Geo load balanced, healed automatically

Every origin is health-checked continuously, and each visitor is routed to the nearest healthy one. If a provider goes dark, traffic moves without anyone paging you.

Storage that fails over too

Assets can be written to a primary and secondary object store across providers, so a storage outage in one cloud isn't an outage for your site.

A 99.95% uptime SLA — on every paid plan

Not an enterprise-tier add-on and not a status-page promise: a contractual monthly uptime commitment backed by service credits, available to every customer with a paid subscription.

Read the SLA
Automation

Your infrastructure, scaled by Agent

Hyphen Cloud runs on the same platform as the rest of Hyphen, which means Agent is the one doing the operations work — the part you hired a DevOps team for.

Scales your infrastructure for you

Agent watches real traffic and moves capacity up and back down on its own. A launch spike doesn't need a war room, and a quiet Tuesday doesn't bill like a busy one.

Cleans up after itself

Stale resources get found and removed instead of quietly accruing cost until someone audits the bill.

Keeps optimizing

Agent watches traffic, usage, and configuration patterns and adjusts continuously — no prompting, no babysitting.

See what Agent does
Comparison

How Hyphen Cloud compares

Vercel and Railway are both good at what they do. Here is where Hyphen Cloud is genuinely different.

Scroll the table sideways to compare →

FeatureHyphen CloudVercelRailway
Static sitesNative, served from object storageNativeRuns inside a container
WebAssemblyWASI components, any languageEdge runtime uses V8 isolates, not WASI componentsNot offered
ContainersProvisioned by the control plane, routed by the gatewayFluid compute for functionsThe core model
CloudsTwo providers and regions, active-active with geo load balancingSingle providerSingle provider
Uptime SLA99.95%, contractual, on every paid planNone on Hobby or Pro — Enterprise agreement onlyNone on Hobby or Pro — Enterprise agreement only
Usage pricing$0.00046 per CPU-minute (≈ $20/vCPU-month), $0.05 per GB egress$0.128 per CPU-hour, $0.15–$0.35 per GB$20 per vCPU-month, $0.05 per GB egress
PortabilityStandard Static, WASI, and Container Components (no lock-in)Platform and framework coupledContainer images are portable

Competitor details verified September 2026 from public documentation: Vercel SLA, Vercel Fluid compute, Vercel regional pricing, Vercel Pro plan, and Railway pricing. Vercel rates vary by region and its Pro plan includes 1 TB of data transfer and 10M edge requests against a $20 monthly platform fee; Railway bills $20 per workspace. These platforms change often — check their current pricing before making a decision.

Frequently Asked Questions

Run static sites, WebAssembly handlers, and containers in the same app, behind the same deploy. Static assets are served straight from object storage, with SPA fallback, redirects, custom headers, CORS, and per-path cache-control available as app configuration.
WebAssembly routes let you handle requests with your own code at the gateway, and containers cover long-running workloads: the control plane provisions the container and the gateway routes matching traffic to it. You pick the model per route, so a single site can serve static pages, run a WASM handler on an API path, and proxy to a container elsewhere.
Hyphen Cloud runs standard WASI Preview 2 components targeting the wasi:http/proxy world. If your toolchain emits a compliant component, the gateway runs it without a Hyphen Cloud-specific SDK.
A handler is just a file in your deployment. Drop the .wasm module in your site directory, deploy as normal, and point a route at it in your app config. Requests matching that route run your handler; everything else falls through to static serving.
Any language whose toolchain emits a WASI Preview 2 component targeting wasi:http/proxy. The four toolchains we build and test against are Rust via cargo component, JavaScript and TypeScript via jco componentize, Python via componentize-py, and Go via TinyGo's wasip2 target.
That list reflects the mature toolchains available today, rather than a platform limit. Because the contract is the WASI standard rather than a runtime of ours, a language becomes supported the moment its toolchain can emit a compliant component, with no change on our side and no wrapper for you to adopt.
Two practical constraints are worth knowing before you pick. Each request runs with a 50 ms CPU budget, a 5 second wall-clock timeout, and 64 MiB of memory. Bodies are buffered rather than streamed, with limits of 1 MiB in and 8 MiB out. The module itself is capped at 32 MiB. Languages that ship a full interpreter inside the component, Python and JavaScript in particular, start much closer to those ceilings than Rust or TinyGo do.
Every execution is sandboxed. A handler gets its own memory with a hard ceiling, a CPU budget, and a wall-clock timeout, and it has no filesystem, no environment variables, and no arguments.
Outbound network access is off by default. You allow-list the hosts a route may reach, and independently of that the platform resolves each outbound target and blocks loopback, private, link-local, and cloud-metadata addresses. This check uses the resolved IP, so a handler cannot reach internal infrastructure by pointing a hostname at it.
It means two different cloud providers, in two different regions, serving production traffic at the same time, with geo load balancing in front. Both origins are health-checked continuously and each visitor is routed to the nearest healthy one, so if a provider degrades, traffic moves automatically.
That is a different guarantee from multi-region within a single provider. A provider-wide incident takes out every region you are running in; it does not take out the other cloud.
A contractual 99.95% monthly uptime commitment, backed by service credits, available on every paid subscription rather than only at the enterprise tier. The full terms, including how uptime is measured and how to claim credits, are on the Hyphen service level agreement page.
Fast in a way that does not depend on a plan tier or a warm-up period. The data plane serves from an in-process cache rather than fetching from object storage on every request, and there is no function to cold-start, so the first request after a quiet hour is served as quickly as one during peak traffic.
Real numbers depend on your assets, your cache hit rate, and how many nodes you run, so we would rather show you yours than quote ours. Traffic and latency are queryable per app from the CLI and the API from your first deploy. If you want a figure before committing, ask us for a benchmark against a workload that looks like yours.
Every deploy creates an immutable revision. Files upload first, and the active revision pointer flips only once they are all in place, so visitors are never served a half-uploaded site. Rolling back is repointing at the previous revision.
Every revision also gets its own stable preview URL, so you can look at a build before it is live, and cache invalidation propagates to the gateway within milliseconds of a change.
Three things. It runs active-active across two different cloud providers and regions rather than inside one, so a provider-wide incident is not your incident. Its 99.95% uptime SLA applies to every paid plan, where neither Vercel nor Railway offers a contractual uptime SLA below their Enterprise tiers. And it covers static, WebAssembly, and containers in one place, with WASM handlers written as standard WASI components rather than against a proprietary edge runtime.
Where they are ahead: Vercel's framework integrations are deeper, particularly for Next.js. Pick based on whether that or multi-cloud resilience matters more to you.
No. Use the CLI to create apps, deploy directories, read and write app config, and query traffic and error metrics. Every command supports JSON output for scripting. Running it bare opens an interactive shell if you prefer that.
There is also a full OpenAPI 3.1 specification and generated API reference, so anything the CLI does you can do directly against the API.
Use the CLI or API to query the gateway’s HTTP and error telemetry by app, domain, method, status range, revision, cache-hit status, and time window. That makes it straightforward to answer questions like which revision started returning 500s, or what your actual cache hit rate is.