Features

Each badge reflects what you can use through the velyr binary today, judged from the source and its tests, not from the plans.

• ■Available implemented and reachable from velyr run.
• ▲Experimental implemented in the codebase but not exposed to users, or incomplete.
• □Planned described in the design documents only.

Permissions ■Available#

Filesystem, network, environment, process, native-library and inspector access are denied by default and granted with flags or velyr.json. Deny rules always win, paths are normalized and symlink-checked, and network targets are checked again after DNS resolution. The process, native-library and inspector kinds are parsed but have no API to guard yet, so they are ▲Experimental.

Details: Permissions, Configuration.

Modules ■Available#

ES modules are the native format: static import, dynamic import() and top-level await. Bare specifiers resolve through node_modules using package.json exports and imports. Remote (https:) imports, CommonJS and TypeScript are not available from the CLI yet. The CommonJS loader and the TypeScript transform (built on Oxc) exist as crates, so those are ▲Experimental.

Details: Modules.

Web APIs ■Available#

Implemented and installed in every isolate:

• URL, URLSearchParams, TextEncoder, TextDecoder, atob, btoa
• Event, EventTarget, CustomEvent, AbortController, AbortSignal, DOMException
• setTimeout, setInterval, queueMicrotask, performance, navigator, structuredClone
• Web Streams, including CompressionStream and DecompressionStream
• crypto and SubtleCrypto
• fetch, Headers, Request, Response
• MessageChannel, MessagePort, BroadcastChannel

Not present yet: Blob, File, FormData, WebSocket and URLPattern are □Planned.

Details: Web APIs.

Files, sockets and TLS ■Available#

Runtime-specific APIs live under a Velyr namespace rather than on standard prototypes: Velyr.readFile, readTextFile, writeFile, writeTextFile, stat, env, permissions.query, connect, listen, connectTls, listenTls and startTls. All of them are present in every script and fail with VELYR_PERMISSION_DENIED without a grant.

HTTP server ▲Experimental#

A hyper-based HTTP/1 and HTTP/2 server and client exist as a Rust crate. Its client half powers fetch; the server half is not exposed. There is no JavaScript server API yet. Velyr.serve and velyr serve are □Planned.

Details: Server.

Workers ■Available#

Module workers run on their own thread with their own isolate, and talk to the parent through structured-clone messages. A worker's permissions are the intersection of its parent's and what it asks for. Multicore serving (distributing connections across workers, --workers=auto) is □Planned.

Details: Workers.

Resource quotas ■Available#

The quotas key in velyr.json caps files, sockets, listeners, workers, timers and body bytes. Exceeding a limit raises VELYR_QUOTA_EXCEEDED. See Configuration.

Node compatibility □Planned#

node: modules, Buffer, process and N-API are not implemented. A CommonJS require loader exists as a crate but is not linked into the binary. Node compatibility is designed to be an optional layer, not part of the core.

Details: Node compatibility.

Packages ▲Experimental#

The package.json model, npm semver, registry client, content-addressed cache and lockfile code exist as a crate. No command uses them, so velyr add, velyr install and velyr remove are □Planned.

Plugins □Planned#

WebAssembly Components are the preferred plugin direction. No plugin crate exists yet.

Details: Plugins.

Native JavaScript engine ▲Experimental#

Velyr runs on V8 today. A second engine written in Rust is under development behind the same engine interface. It is selectable with --engine native, an experimental, feature-gated option, and its own source notes that modules and promises are not implemented yet.

Observability ■Available#

Structured logs go to stderr in pretty or json format, filtered by VELYR_LOG. Permission denials produce a structured event. See Command Line Interface.