> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.hyjal.cloud/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.hyjal.cloud/_mcp/server.

# From other platforms

> Map concepts from serverless and VM platforms onto Hyjal, and migrate an existing system to Hyjal service by service with the strangler pattern.

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](/platform/projects-and-resources) with a served [endpoint](/platform/routing-and-urls) |
| 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](/app-types/jobs-and-crons)                         |
| A KV, blob, or object store               | The Project [Bucket](/data/buckets)                                                                 |
| A managed relational database             | An [HTTP-native database](/data/http-databases) or the [Database Door](/data/database-door)         |
| Built-in app tables or a small managed DB | [Hyjal Tables](/data/hyjal-tables)                                                                  |
| A log drain or log-shipping integration   | The [Logs tab](/observability/logs) plus the OTLP [telemetry Door](/observability/telemetry)        |
| Environment variables and secrets         | Per-Resource [environment variables](/deploy/environment-variables) and Project secrets             |
| A custom domain with managed TLS          | [Custom domains](/deploy/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](/platform/architecture): 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:

```js
export default {
  async fetch(request) {
    const url = new URL(request.url);
    return new Response(`Hello from ${url.pathname}`, {
      headers: { "content-type": "text/plain" },
    });
  },
};
```

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](/languages/javascript-typescript).

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

## 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](/deploy/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:

```toml
[resource.web.egress]
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:

```toml
[resource.web]
lane = "static"
mounts = { "/api/*" = "api" }

[resource.api]
lane = "go"
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](/deploy/rollbacks)
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](/languages/overview)
* Wire a front end and API together: [Full-stack apps](/app-types/full-stack-apps)
* Understand the serving model in depth: [Architecture](/platform/architecture)