What is Hyjal?

A breakdown of the first cloud platform operating entirely using WebAssembly.
View as Markdown

Hyjal is not only a deployment platform. At it’s core, it is a fast serving engine that dynamically evaluates, compiles and executes/serves application code at time-of-request. We service 8B+ components and 15M+ executions/s at an average execution time of 700 µs.

You bring source code in the language of your choice, organized into Components; Hyjal builds them, stores them, routes requests to and from them, and serves every request on a fresh, metered instance. This page explains the platform model and the vocabulary used throughout these docs. Read it once before the quickstart.

No containers, no servers to size

With Hyjal you no longer have to size infrastructure primitives and keep a fleet of servers or container clusters warm. There are no Dockerfiles, no container images, no virtual machines, nor operational limitations/barriers that are typically dealt with according to upscaling and downscaling workloads.

You do not have to choose instance counts, measure out idle capacity or have to “work around a platform”. You merely hand off code as Components, with all “infrastructure logic” logic baked in; and the platform builds and serves it as you’ve requested.

Serving/execution is conducted on an instance-per-request basis. For each incoming (or internal Component-to-Component) request, a fresh instance of your Component is created, executed, metered, and then either discarded or cached based on the configuration you have selected in milliseconds (typically micro-seconds when cached). Scaling from zero to high concurrency is entirely automatic: there is no warm pool or cluster workload balancing to manage.

Projects and Resources

A Project groups related Components and is the unit of collaboration
and scoping. A Component is the deployable unit of code (a simpler way of stating it: a Component = an executable .wasm binary).

The recurring example in this documentation is a Project named acme with
two Components: web, a front end, and api, a Go service backed by a Neon
Postgres database. Each Resource serves an HTTPS endpoint at a
predictable URL:

https://web--acme.hyjal.cloud
https://api--acme.hyjal.cloud

The -- separator is reserved. Resource and Project names are lowercase alphanumerics and single dashes, with no leading or trailing dash. See Routing and URLs for the full grammar.

Resources relate to each other. A front-end Resource can mount a path prefix onto an API Resource, forwarding /api/* over in-process dispatch with no CORS configuration. You express those relationships in hyjal.toml or via the platform UI.

Buckets and Objects

Every Project & it’s associated Components exist within a Bucket: S3-compatible object storage in which every Component is backed by a directory. Static sites are served straight from their Bucket directory. Build artifacts live in the Bucket too, addressed by digest and read-only. You can manage Bucket files from the Console, the hyjal files command, or the REST API. See Buckets.

Inter-Component communication is a host-provided capability reachable from inside a running instance of your Component(s). Because instances have no ambient network access, Doors are how your code reaches sanctioned platform services:

DoorWhat it provides
Telemetry DoorIngests OpenTelemetry (OTLP) logs pushed from your Resource; severity renders as badges in the Logs tab
Database DoorHolds pooled, TLS-verified connections to classic TCP databases so instances never open raw sockets
Module-to-module dispatchLets one Resource call another Resource in the platform

Doors keep the instance-per-request model safe against connection storms: pooling and connection management are the platform’s job, not yours. See Data and state.

Artifacts, digests, and rollback

hyjal deploy builds every Resource into an artifact (the compiled WebAssembly component) and stores it in the Project’s Bucket. Each artifact is content-addressed by digest, a sha256: hash of its bytes. Redeploying identical bytes is a no-op. A rollback repoints the endpoint to any previous digest and is effectively instant, because the bytes already exist and only the route changes.

Languages and app types

Hyjal serves whatever compiles to a WebAssembly component or command module. First-class language lanes cover the common cases:

  • Rust: cargo component to a wasip2 component
  • JavaScript and TypeScript: a fetch handler via ComponentizeJS
  • Go: TinyGo wasip2, or standard Go through the CGI lane
  • Python: ASGI apps wrapped by the CLI
  • Any language: the CGI lane serves any WASI 0.1 command module

App-type playbooks cover how to shape a deployment:

How pricing works

Hyjal meters what it serves. Each request is one metered instance, and the
Stats tab shows the same request counts & Atomic Compute Units consumed. You are not charged for idle capacity, because there is none.

The Starter plan is free. Pro, Pro+, and Team plans add capacity and collaboration features. For current pricing, see the plans page or the Console.

Next steps