What is Hyjal?

View as Markdown

Hyjal is a deployment platform that runs your applications as WebAssembly. You bring source code in the language of your choice; Hyjal builds it into a WebAssembly component, stores it, routes it, 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 do not pick a unit of infrastructure and keep it warm. There are no Dockerfiles, no container images, and no servers to size. You do not choose instance counts, autoscaling thresholds, or idle capacity. You deploy a component; the platform serves it.

The runtime is Hyjal Afterburner™. Afterburner serves requests instance-per-request: for each incoming request, it creates a fresh instance of your component, runs it, meters the work, and discards it. No state survives an instance, and no memory is shared between requests. Scaling from zero and to high concurrency is automatic: there is no warm pool to manage.

The guest contract is a standard WebAssembly component that exports the wasi:http handler world (WASI 0.3). Command modules built for WASI 0.1 are also served, through the platform’s CGI lane. You write ordinary request-handling code; the toolchain produces the component.

Projects and Resources

A Project groups related Resources and is the unit of collaboration and scoping. A Resource is the deployable or storable unit: a service, a static site, or a data directory. Everything you ship is a Resource, and every Resource carries a capital R throughout these docs.

The recurring example in this documentation is a Project named acme with two Resources: 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 by drawing an edge on the Board, the visual canvas that shows a Project’s Resources and how they connect.

Buckets and Doors

Every Project has a Bucket: S3-compatible object storage in which every Resource 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 manage Bucket files from the Console, the hyjal files command, or the REST API. See Buckets.

A Door is a host-provided capability reachable from inside a running instance. 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, compute milliseconds, and peak memory that billing uses. 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