From other platforms | hyjal.cloud

If you already run applications on another platform, most of what you know transfers. This page maps common concepts onto Hyjal vocabulary and shows how to move an existing system across incrementally, without a rewrite or a big-bang cutover.

Concept mapping

Hyjal uses a small, consistent set of nouns. Here is how ideas from other platforms line up with them.

You have	On Hyjal it is
A worker, function, or serverless service	A Resource with a served endpoint
A container or VM running one service	A Resource: you deploy source, not an image
A cron trigger or scheduled task	A `schedule` on a Resource. See Jobs and crons
A KV, blob, or object store	The Project Bucket
A managed relational database	An HTTP-native database or the Database Door
Built-in app tables or a small managed DB	Hyjal Tables
A log drain or log-shipping integration	The Logs tab plus the OTLP telemetry Door
Environment variables and secrets	Per-Resource environment variables and Project secrets
A custom domain with managed TLS	Custom domains: CNAME plus automatic certificates

The organizing difference is the unit of deployment. On Hyjal you deploy a Resource (source that the platform builds into a WebAssembly component), not a pre-built image and not a long-lived process. Requests are served instance-per-request: a fresh instance per request, metered and discarded.

Coming from Cloudflare Workers

If you write Workers, the request shape is the same. Hyjal’s JavaScript and TypeScript lane is a fetch handler:

1 export default {
2   async fetch(request) {
3     const url = new URL(request.url);
4     return new Response(`Hello from ${url.pathname}`, {
5       headers: { "content-type": "text/plain" },
6     });
7   },
8 };

Deploy it as a Resource in the JS lane. Frameworks whose edge adapters emit fetch handlers (Hono, SvelteKit, Astro, Remix) deploy directly; the CLI applies the adapter. See JavaScript and TypeScript.

The differences to plan for: instances have no ambient network access, so outbound calls go to allowlisted hostnames (see environment variables and egress) or to other Resources; and per-request state does not persist, so durable state lives in a database, Tables, or a Bucket.

Migrating a VM or Heroku-style app

For a monolith or a set of services running on VMs, dynos, or long-lived containers, migrate incrementally with the strangler pattern. You front the existing system with a Hyjal Resource and move functionality across one service at a time, keeping the app serving throughout.

1. Front the system with a Resource. Deploy a Hyjal Resource (typically your front end or an API gateway Resource) and put it on your domain with custom domains.

2. Egress-allowlist the legacy host. Add your existing system’s hostname to the Resource’s egress allowlist so the new Resource can forward to it while you migrate:

1 [resource.web.egress]
2 hosts = ["legacy.acme.internal.example"]

Traffic now enters through Hyjal and passes to the legacy host for anything not yet migrated.

3. Migrate service by service. Re-implement one service as its own Resource (say the Go api behind acme) and mount its path prefix on the front end:

1 [resource.web]
2 lane = "static"
3 mounts = { "/api/*" = "api" }
4 
5 [resource.api]
6 lane = "go"
7 public = false

Requests to /api/* are served in-process by the new Resource; everything else still forwards to the legacy host. Repeat until nothing forwards out, then remove the egress entry.

This keeps each step small and reversible. A rollback repoints an endpoint to the previous digest instantly, so a migration step you are unsure about is cheap to undo.

Next steps

Pick your lane: Languages overview
Wire a front end and API together: Full-stack apps
Understand the serving model in depth: Architecture