@supermachine/core 0.4.25
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +202 -0
- package/README.md +407 -0
- package/examples/01-hello.mjs +32 -0
- package/examples/02-pool.mjs +54 -0
- package/examples/03-snapshot-then-restore.mjs +54 -0
- package/examples/04-expose-tcp.mjs +80 -0
- package/examples/05-spawn-streaming.mjs +59 -0
- package/examples/README.md +43 -0
- package/index.d.ts +532 -0
- package/index.js +290 -0
- package/package.json +59 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,202 @@
|
|
|
1
|
+
|
|
2
|
+
Apache License
|
|
3
|
+
Version 2.0, January 2004
|
|
4
|
+
http://www.apache.org/licenses/
|
|
5
|
+
|
|
6
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
7
|
+
|
|
8
|
+
1. Definitions.
|
|
9
|
+
|
|
10
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
11
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
12
|
+
|
|
13
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
14
|
+
the copyright owner that is granting the License.
|
|
15
|
+
|
|
16
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
17
|
+
other entities that control, are controlled by, or are under common
|
|
18
|
+
control with that entity. For the purposes of this definition,
|
|
19
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
20
|
+
direction or management of such entity, whether by contract or
|
|
21
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
22
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
23
|
+
|
|
24
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
25
|
+
exercising permissions granted by this License.
|
|
26
|
+
|
|
27
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
28
|
+
including but not limited to software source code, documentation
|
|
29
|
+
source, and configuration files.
|
|
30
|
+
|
|
31
|
+
"Object" form shall mean any form resulting from mechanical
|
|
32
|
+
transformation or translation of a Source form, including but
|
|
33
|
+
not limited to compiled object code, generated documentation,
|
|
34
|
+
and conversions to other media types.
|
|
35
|
+
|
|
36
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
37
|
+
Object form, made available under the License, as indicated by a
|
|
38
|
+
copyright notice that is included in or attached to the work
|
|
39
|
+
(an example is provided in the Appendix below).
|
|
40
|
+
|
|
41
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
42
|
+
form, that is based on (or derived from) the Work and for which the
|
|
43
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
44
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
45
|
+
of this License, Derivative Works shall not include works that remain
|
|
46
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
47
|
+
the Work and Derivative Works thereof.
|
|
48
|
+
|
|
49
|
+
"Contribution" shall mean any work of authorship, including
|
|
50
|
+
the original version of the Work and any modifications or additions
|
|
51
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
52
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
53
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
54
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
55
|
+
means any form of electronic, verbal, or written communication sent
|
|
56
|
+
to the Licensor or its representatives, including but not limited to
|
|
57
|
+
communication on electronic mailing lists, source code control systems,
|
|
58
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
59
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
60
|
+
excluding communication that is conspicuously marked or otherwise
|
|
61
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
62
|
+
|
|
63
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
64
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
65
|
+
subsequently incorporated within the Work.
|
|
66
|
+
|
|
67
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
68
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
69
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
70
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
71
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
72
|
+
Work and such Derivative Works in Source or Object form.
|
|
73
|
+
|
|
74
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
75
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
76
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
77
|
+
(except as stated in this section) patent license to make, have made,
|
|
78
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
79
|
+
where such license applies only to those patent claims licensable
|
|
80
|
+
by such Contributor that are necessarily infringed by their
|
|
81
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
82
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
83
|
+
institute patent litigation against any entity (including a
|
|
84
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
85
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
86
|
+
or contributory patent infringement, then any patent licenses
|
|
87
|
+
granted to You under this License for that Work shall terminate
|
|
88
|
+
as of the date such litigation is filed.
|
|
89
|
+
|
|
90
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
91
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
92
|
+
modifications, and in Source or Object form, provided that You
|
|
93
|
+
meet the following conditions:
|
|
94
|
+
|
|
95
|
+
(a) You must give any other recipients of the Work or
|
|
96
|
+
Derivative Works a copy of this License; and
|
|
97
|
+
|
|
98
|
+
(b) You must cause any modified files to carry prominent notices
|
|
99
|
+
stating that You changed the files; and
|
|
100
|
+
|
|
101
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
102
|
+
that You distribute, all copyright, patent, trademark, and
|
|
103
|
+
attribution notices from the Source form of the Work,
|
|
104
|
+
excluding those notices that do not pertain to any part of
|
|
105
|
+
the Derivative Works; and
|
|
106
|
+
|
|
107
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
108
|
+
distribution, then any Derivative Works that You distribute must
|
|
109
|
+
include a readable copy of the attribution notices contained
|
|
110
|
+
within such NOTICE file, excluding those notices that do not
|
|
111
|
+
pertain to any part of the Derivative Works, in at least one
|
|
112
|
+
of the following places: within a NOTICE text file distributed
|
|
113
|
+
as part of the Derivative Works; within the Source form or
|
|
114
|
+
documentation, if provided along with the Derivative Works; or,
|
|
115
|
+
within a display generated by the Derivative Works, if and
|
|
116
|
+
wherever such third-party notices normally appear. The contents
|
|
117
|
+
of the NOTICE file are for informational purposes only and
|
|
118
|
+
do not modify the License. You may add Your own attribution
|
|
119
|
+
notices within Derivative Works that You distribute, alongside
|
|
120
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
121
|
+
that such additional attribution notices cannot be construed
|
|
122
|
+
as modifying the License.
|
|
123
|
+
|
|
124
|
+
You may add Your own copyright statement to Your modifications and
|
|
125
|
+
may provide additional or different license terms and conditions
|
|
126
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
127
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
128
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
129
|
+
the conditions stated in this License.
|
|
130
|
+
|
|
131
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
132
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
133
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
134
|
+
this License, without any additional terms or conditions.
|
|
135
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
136
|
+
the terms of any separate license agreement you may have executed
|
|
137
|
+
with Licensor regarding such Contributions.
|
|
138
|
+
|
|
139
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
140
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
141
|
+
except as required for reasonable and customary use in describing the
|
|
142
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
143
|
+
|
|
144
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
145
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
146
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
147
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
148
|
+
implied, including, without limitation, any warranties or conditions
|
|
149
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
150
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
151
|
+
appropriateness of using or redistributing the Work and assume any
|
|
152
|
+
risks associated with Your exercise of permissions under this License.
|
|
153
|
+
|
|
154
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
155
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
156
|
+
unless required by applicable law (such as deliberate and grossly
|
|
157
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
158
|
+
liable to You for damages, including any direct, indirect, special,
|
|
159
|
+
incidental, or consequential damages of any character arising as a
|
|
160
|
+
result of this License or out of the use or inability to use the
|
|
161
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
162
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
163
|
+
other commercial damages or losses), even if such Contributor
|
|
164
|
+
has been advised of the possibility of such damages.
|
|
165
|
+
|
|
166
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
167
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
168
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
169
|
+
or other liability obligations and/or rights consistent with this
|
|
170
|
+
License. However, in accepting such obligations, You may act only
|
|
171
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
172
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
173
|
+
defend, and hold each Contributor harmless for any liability
|
|
174
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
175
|
+
of your accepting any such warranty or additional liability.
|
|
176
|
+
|
|
177
|
+
END OF TERMS AND CONDITIONS
|
|
178
|
+
|
|
179
|
+
APPENDIX: How to apply the Apache License to your work.
|
|
180
|
+
|
|
181
|
+
To apply the Apache License to your work, attach the following
|
|
182
|
+
boilerplate notice, with the fields enclosed by brackets "[]"
|
|
183
|
+
replaced with your own identifying information. (Don't include
|
|
184
|
+
the brackets!) The text should be enclosed in the appropriate
|
|
185
|
+
comment syntax for the file format. We also recommend that a
|
|
186
|
+
file or class name and description of purpose be included on the
|
|
187
|
+
same "printed page" as the copyright notice for easier
|
|
188
|
+
identification within third-party archives.
|
|
189
|
+
|
|
190
|
+
Copyright [yyyy] [name of copyright owner]
|
|
191
|
+
|
|
192
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
193
|
+
you may not use this file except in compliance with the License.
|
|
194
|
+
You may obtain a copy of the License at
|
|
195
|
+
|
|
196
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
197
|
+
|
|
198
|
+
Unless required by applicable law or agreed to in writing, software
|
|
199
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
200
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
201
|
+
See the License for the specific language governing permissions and
|
|
202
|
+
limitations under the License.
|
package/README.md
ADDED
|
@@ -0,0 +1,407 @@
|
|
|
1
|
+
# @supermachine/core
|
|
2
|
+
|
|
3
|
+
> Run any OCI/Docker image as a hardware-isolated microVM, from Node.js / Bun / Deno. Sub-100 ms cold start, ~3 MiB RAM per idle VM, full API parity with the [`supermachine`](https://crates.io/crates/supermachine) Rust crate via napi-rs.
|
|
4
|
+
|
|
5
|
+
```bash
|
|
6
|
+
npm install @supermachine/core
|
|
7
|
+
```
|
|
8
|
+
|
|
9
|
+
**No Rust toolchain required.** The package ships a prebuilt, code-signed native addon via the `@supermachine/core-darwin-arm64` optional dependency — npm's `os` / `cpu` filter installs only on macOS Apple Silicon (the current only supported platform). At runtime you need:
|
|
10
|
+
|
|
11
|
+
- macOS Apple Silicon (`arm64`)
|
|
12
|
+
- Node ≥ 18.17, Bun, or Deno 2+
|
|
13
|
+
- Network access on first `Image.build()` (OCI registry pull via `curl`, no Docker daemon required — same pull model as libkrun / krunvm). After bake, snapshots are local and offline-usable.
|
|
14
|
+
|
|
15
|
+
For private registries, supermachine reads `~/.docker/config.json` (the same auth file Docker writes via `docker login`). You can create that file by hand if you don't have Docker installed. To force the legacy Docker-daemon-based pull path, set `SUPERMACHINE_IMAGE_SOURCE=docker`.
|
|
16
|
+
|
|
17
|
+
```ts
|
|
18
|
+
import { Image } from "@supermachine/core";
|
|
19
|
+
|
|
20
|
+
const image = await Image.build({ ref: "alpine:latest" });
|
|
21
|
+
const pool = await image.pool({ min: 4, max: 16 });
|
|
22
|
+
const vm = await pool.acquire();
|
|
23
|
+
try {
|
|
24
|
+
const { stdout, exitCode } = await vm.exec({
|
|
25
|
+
argv: ["echo", "hello from the VM"],
|
|
26
|
+
timeoutMs: 5_000,
|
|
27
|
+
});
|
|
28
|
+
console.log(stdout.toString()); // "hello from the VM\n"
|
|
29
|
+
} finally {
|
|
30
|
+
await vm.release();
|
|
31
|
+
}
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
---
|
|
35
|
+
|
|
36
|
+
## Why microVMs
|
|
37
|
+
|
|
38
|
+
Same hardware isolation as Firecracker, libkrun, or qemu — but the *acquire latency* you'd expect from a container. Designed for use cases where you'd otherwise pick between containers (fast but shared-kernel) and full VMs (isolated but slow):
|
|
39
|
+
|
|
40
|
+
- **Agent runtimes** — spin up a fresh, hardware-isolated environment per agent task, run untrusted code, throw it away. ~5 ms cycle, no kernel-namespace escapes to worry about.
|
|
41
|
+
- **CI / build verifiers** — compile + run untrusted code (MultiPL-E, Codeforces solutions, student submissions) without trusting the host.
|
|
42
|
+
- **Per-tenant sandboxes** — run customer code per request without a fork+exec security boundary.
|
|
43
|
+
- **Code execution APIs** — same as the OpenAI Code Interpreter pattern, hardware-isolated.
|
|
44
|
+
|
|
45
|
+
If your bar is "fast enough fork" and you trust the workload, use containers. If your bar is "I'm running this code from an LLM and the host needs to survive", use this.
|
|
46
|
+
|
|
47
|
+
---
|
|
48
|
+
|
|
49
|
+
## Status
|
|
50
|
+
|
|
51
|
+
**Currently supported:** macOS on Apple Silicon (`darwin-arm64`, HVF backend).
|
|
52
|
+
**Roadmap:** Linux KVM (`linux-arm64-gnu`, `linux-x64-gnu`), Windows WHP.
|
|
53
|
+
|
|
54
|
+
For platforms not yet supported, the package installs cleanly but emits a clear error on first call. The `optionalDependencies` mechanism means non-supported hosts don't fail `npm install`.
|
|
55
|
+
|
|
56
|
+
---
|
|
57
|
+
|
|
58
|
+
## Performance, measured
|
|
59
|
+
|
|
60
|
+
All numbers are on Apple Silicon (M-series, 24 GiB dev box), `alpine:latest` unless noted. The numbers include the napi-rs binding overhead (~10–20 µs per `await` from libuv worker scheduling). Per-call overhead is 0.3–0.5 % vs. direct Rust embedders — the floor is set by V8 / libuv / HVF, not by the binding.
|
|
61
|
+
|
|
62
|
+
| Operation | Cost | Notes |
|
|
63
|
+
|---|---|---|
|
|
64
|
+
| Cold bake (first run, Docker layer cache warm) | **~400 ms** | Pulls layers → squashfs → boots VM → captures snapshot |
|
|
65
|
+
| Cache-hit bake | **~15 ms** | Re-running `Image.build` for an already-baked image |
|
|
66
|
+
| First `acquire()` after `build()` (warm-handoff) | **~0 ms** | Bake's living worker is stashed for the first acquire |
|
|
67
|
+
| `acquire()` on pre-spawned idle pool entry | **~0 ms** | Just a queue pop |
|
|
68
|
+
| `acquire()` with cycle-restore | **~5 ms** | HVF-bound; restoration from in-memory snapshot |
|
|
69
|
+
| `acquire()` spawn-from-disk (pool growing) | **~22 ms** | Fork + dyld + HVF setup + mmap-restore |
|
|
70
|
+
| `vm.exec(["echo", "hi"])` round-trip | **~0.3 ms** | vsock RPC to the in-guest agent — no host fork |
|
|
71
|
+
|
|
72
|
+
### Memory
|
|
73
|
+
|
|
74
|
+
Each idle VM costs **~3 MiB host `phys_footprint`** (measured). The `memoryMib` build option is a *guest-visible ceiling*, not host commit — pages are committed lazily via CoW page-faults. Read-only state (kernel, init binaries, your image's `rustc`/`python` etc.) is shared across all VMs via the snapshot's mmap, so a pool of 50 VMs uses ~150 MiB total, not 50 × 256 MiB.
|
|
75
|
+
|
|
76
|
+
**The hard limit on parallelism isn't VM count — it's concurrent active workloads.** 50 idle VMs ≈ 150 MiB; 50 simultaneous rustc compiles ≈ 15+ GiB. Size your pool against expected *active concurrency*, not problem count.
|
|
77
|
+
|
|
78
|
+
---
|
|
79
|
+
|
|
80
|
+
## Integration patterns
|
|
81
|
+
|
|
82
|
+
### Pattern 1: One-shot exec (CI / verifier)
|
|
83
|
+
|
|
84
|
+
You have generated code, want to run it in isolation, get the result, throw the VM away.
|
|
85
|
+
|
|
86
|
+
```ts
|
|
87
|
+
import { Image } from "@supermachine/core";
|
|
88
|
+
|
|
89
|
+
const image = await Image.build({
|
|
90
|
+
ref: "python:slim",
|
|
91
|
+
memoryMib: 512,
|
|
92
|
+
});
|
|
93
|
+
|
|
94
|
+
const pool = await image.pool({ min: 0, max: 8, restoreOnRelease: true });
|
|
95
|
+
|
|
96
|
+
async function runCandidate(source: string): Promise<{ ok: boolean; stdout: string }> {
|
|
97
|
+
const vm = await pool.acquire();
|
|
98
|
+
try {
|
|
99
|
+
const out = await vm.exec({
|
|
100
|
+
argv: ["python3", "/tmp/code.py"],
|
|
101
|
+
stageFiles: { "/tmp/code.py": Buffer.from(source) },
|
|
102
|
+
timeoutMs: 10_000,
|
|
103
|
+
});
|
|
104
|
+
return { ok: out.exitCode === 0, stdout: out.stdout.toString() };
|
|
105
|
+
} finally {
|
|
106
|
+
await vm.release();
|
|
107
|
+
}
|
|
108
|
+
}
|
|
109
|
+
|
|
110
|
+
const results = await Promise.all(
|
|
111
|
+
candidates.map(runCandidate), // queues through pool of 8
|
|
112
|
+
);
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
`restoreOnRelease: true` is the right default here — each candidate runs in clean state.
|
|
116
|
+
|
|
117
|
+
### Pattern 2: Agent runtime (per-task isolated sandbox)
|
|
118
|
+
|
|
119
|
+
```ts
|
|
120
|
+
import { Image } from "@supermachine/core";
|
|
121
|
+
|
|
122
|
+
const image = await Image.build({
|
|
123
|
+
ref: "python:slim",
|
|
124
|
+
memoryMib: 512,
|
|
125
|
+
// Pre-warm: import heavy libs once at bake time, snapshot the
|
|
126
|
+
// warm state. Subsequent acquires land on the post-import
|
|
127
|
+
// snapshot — saves ~200 ms of import cost per task.
|
|
128
|
+
warmupTag: "v1", // bump to invalidate cache
|
|
129
|
+
warmup: async (vm) => {
|
|
130
|
+
await vm.exec({
|
|
131
|
+
argv: ["python3", "-c", "import numpy, pandas, requests"],
|
|
132
|
+
timeoutMs: 60_000,
|
|
133
|
+
});
|
|
134
|
+
},
|
|
135
|
+
});
|
|
136
|
+
|
|
137
|
+
const pool = await image.pool({
|
|
138
|
+
min: 4, // warm idle pool
|
|
139
|
+
max: 32, // burst capacity
|
|
140
|
+
restoreOnRelease: true, // isolate per task
|
|
141
|
+
acquireTimeoutMs: 30_000,
|
|
142
|
+
});
|
|
143
|
+
|
|
144
|
+
// In your request handler:
|
|
145
|
+
async function handleAgentTask(taskCode: string) {
|
|
146
|
+
using vm = await pool.acquire(); // Node 20+ disposer
|
|
147
|
+
return await vm.exec({
|
|
148
|
+
argv: ["python3", "/tmp/task.py"],
|
|
149
|
+
stageFiles: { "/tmp/task.py": Buffer.from(taskCode) },
|
|
150
|
+
timeoutMs: 30_000,
|
|
151
|
+
});
|
|
152
|
+
} // auto-released
|
|
153
|
+
```
|
|
154
|
+
|
|
155
|
+
### Pattern 3: Persistent service inside the VM
|
|
156
|
+
|
|
157
|
+
You want to bake an image where the snapshot includes a *running listener* (nginx, redis, your own daemon) so first restore has it serving immediately.
|
|
158
|
+
|
|
159
|
+
```ts
|
|
160
|
+
const image = await Image.build({
|
|
161
|
+
ref: "nginx:alpine",
|
|
162
|
+
listenerRequired: true, // wait for workload to bind before snapshot
|
|
163
|
+
// (no warmup needed — listener-ready trigger fires when nginx is up)
|
|
164
|
+
});
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
Without `listenerRequired`, the default `.build()` uses a *pre-exec* snapshot trigger for ~10× faster bake on slow-starting workloads — but the listener won't be bound at restore time. The right knob depends on whether your code talks to the workload's listener or runs its own `vm.exec` commands.
|
|
168
|
+
|
|
169
|
+
### Pattern 4: Resource files baked into the snapshot
|
|
170
|
+
|
|
171
|
+
Sometimes you need files inside the guest that aren't part of the OCI image — a config, a cert, a binary. `extraFiles` stages them into the snapshot's filesystem layer:
|
|
172
|
+
|
|
173
|
+
```ts
|
|
174
|
+
const image = await Image.build({
|
|
175
|
+
ref: "alpine:latest",
|
|
176
|
+
extraFiles: [
|
|
177
|
+
{ hostPath: "./config/app.toml", guestPath: "/etc/app.toml" },
|
|
178
|
+
{ hostPath: "./certs/server.pem", guestPath: "/etc/server.pem" },
|
|
179
|
+
],
|
|
180
|
+
});
|
|
181
|
+
```
|
|
182
|
+
|
|
183
|
+
Host file contents are folded into the snapshot's input-hash, so editing the host file invalidates the cache and rebakes automatically.
|
|
184
|
+
|
|
185
|
+
---
|
|
186
|
+
|
|
187
|
+
## Full API
|
|
188
|
+
|
|
189
|
+
Auto-generated from the Rust source — see [`index.d.ts`](./index.d.ts) for the typed surface. Highlights below; runnable demos in [`examples/`](./examples/).
|
|
190
|
+
|
|
191
|
+
### `Image`
|
|
192
|
+
|
|
193
|
+
```ts
|
|
194
|
+
class Image {
|
|
195
|
+
static build(options: BuildOptions): Promise<Image>;
|
|
196
|
+
static fromSnapshot(path: string): Promise<Image>;
|
|
197
|
+
pool(options?: PoolOptions): Promise<Pool>;
|
|
198
|
+
|
|
199
|
+
// Sync accessors — read from snapshot metadata, cached.
|
|
200
|
+
readonly snapshotPath: string;
|
|
201
|
+
readonly memoryMib: number;
|
|
202
|
+
readonly vcpus: number;
|
|
203
|
+
}
|
|
204
|
+
```
|
|
205
|
+
|
|
206
|
+
`BuildOptions`:
|
|
207
|
+
|
|
208
|
+
| Field | Type | Default | Notes |
|
|
209
|
+
|---|---|---|---|
|
|
210
|
+
| `ref` | `string` | required | OCI ref: `"alpine:latest"`, `"ghcr.io/owner/img@sha256:..."` |
|
|
211
|
+
| `name` | `string` | sha-derived | Stable snapshot name |
|
|
212
|
+
| `memoryMib` | `number` | 256 | Guest-visible ceiling (lazy-committed) |
|
|
213
|
+
| `vcpus` | `number` | 1 | vCPUs per VM |
|
|
214
|
+
| `pullPolicy` | `"always" \| "missing" \| "never"` | `"missing"` | docker-style pull policy |
|
|
215
|
+
| `cmd` | `string[]` | (image CMD) | Override the image's CMD / ENTRYPOINT |
|
|
216
|
+
| `env` | `Record<string, string>` | `{}` | Extra workload env vars |
|
|
217
|
+
| `guestPort` | `number` | 80 | Listener port (used with `listenerRequired`) |
|
|
218
|
+
| `listenerRequired` | `boolean` | `false` | Wait for workload's listener before snapshotting |
|
|
219
|
+
| `extraFiles` | `ExtraFile[]` | — | Stage host files into guest at fixed paths |
|
|
220
|
+
| `warmupTag` | `string` | `"default"` | Cache key for the warmup; bump to invalidate |
|
|
221
|
+
| `warmup` | `(vm: WarmupVm) => Promise<void>` | — | Post-bake state pre-population |
|
|
222
|
+
| `snapshotsDir` | `string` | `~/.local/supermachine-snapshots` | Where to write the snapshot |
|
|
223
|
+
|
|
224
|
+
### `Pool`
|
|
225
|
+
|
|
226
|
+
```ts
|
|
227
|
+
class Pool {
|
|
228
|
+
acquire(): Promise<Vm>;
|
|
229
|
+
stats(): PoolStats; // sync, ~1 µs — safe to poll
|
|
230
|
+
shutdown(): Promise<void>;
|
|
231
|
+
}
|
|
232
|
+
|
|
233
|
+
interface PoolStats {
|
|
234
|
+
alive: number; // total workers (idle + checked-out)
|
|
235
|
+
inUse: number; // checked out via acquire()
|
|
236
|
+
idle: number;
|
|
237
|
+
waiting: number; // acquire() callers blocked on a free slot
|
|
238
|
+
min: number;
|
|
239
|
+
max: number;
|
|
240
|
+
}
|
|
241
|
+
```
|
|
242
|
+
|
|
243
|
+
`PoolOptions`:
|
|
244
|
+
|
|
245
|
+
| Field | Type | Default | Notes |
|
|
246
|
+
|---|---|---|---|
|
|
247
|
+
| `min` | `number` | 1 | Idle VMs to keep warm |
|
|
248
|
+
| `max` | `number` | 1 | Maximum total VMs |
|
|
249
|
+
| `acquireTimeoutMs` | `number` | 60 000 | Max wait when pool is saturated. **Pass `0` for "block forever" (batch workloads).** |
|
|
250
|
+
| `idleTimeoutMs` | `number` | — | Evict idle VMs above `min` after this |
|
|
251
|
+
| `restoreOnRelease` | `boolean` | `true` | Clean state per acquire (vs. dirty reuse) |
|
|
252
|
+
| `memoryMib` | `number` | (image default) | Runtime memory override (no re-bake) |
|
|
253
|
+
| `vcpus` | `number` | (image default) | Runtime vCPU override (no re-bake) |
|
|
254
|
+
| `restoreTimeoutMs` | `number` | 30 000 | Per-worker snapshot-restore deadline |
|
|
255
|
+
|
|
256
|
+
### `Vm`
|
|
257
|
+
|
|
258
|
+
```ts
|
|
259
|
+
class Vm {
|
|
260
|
+
// Execution
|
|
261
|
+
exec(options: ExecOptions): Promise<ExecOutput>;
|
|
262
|
+
spawn(options: ExecOptions): Promise<ExecChild>; // streaming variant
|
|
263
|
+
|
|
264
|
+
// File I/O (4 MiB cap each direction)
|
|
265
|
+
writeFile(path: string, bytes: Buffer): Promise<void>;
|
|
266
|
+
readFile(path: string): Promise<Buffer>;
|
|
267
|
+
|
|
268
|
+
// Workload control
|
|
269
|
+
workloadSignal(signum: number): Promise<void>; // SIGTERM/SIGHUP/etc. to PID-1
|
|
270
|
+
exposeTcp(hostPort: number, guestPort: number): Promise<TcpForwarder>;
|
|
271
|
+
|
|
272
|
+
// Mid-flight snapshot
|
|
273
|
+
snapshot(destDir: string): Promise<Image>;
|
|
274
|
+
|
|
275
|
+
// Lifecycle
|
|
276
|
+
release(): Promise<void>;
|
|
277
|
+
dispose(): Promise<void>; // alias; Symbol.asyncDispose-friendly
|
|
278
|
+
|
|
279
|
+
// Escape hatches (raw socket paths for bring-your-own-client)
|
|
280
|
+
readonly vsockPath: string;
|
|
281
|
+
readonly execPath: string;
|
|
282
|
+
}
|
|
283
|
+
```
|
|
284
|
+
|
|
285
|
+
`ExecOptions`:
|
|
286
|
+
|
|
287
|
+
| Field | Type | Default | Notes |
|
|
288
|
+
|---|---|---|---|
|
|
289
|
+
| `argv` | `string[]` | required | argv[0] resolved via PATH inside the guest |
|
|
290
|
+
| `stageFiles` | `Record<string, Buffer>` | `{}` | Files to drop into the guest before exec (mode 0o644) |
|
|
291
|
+
| `stageFilesMode` | `StagedFileMode[]` | — | Same as stageFiles but with explicit per-file modes (e.g. 0o755 for scripts) |
|
|
292
|
+
| `timeoutMs` | `number` | 60 000 | Hard wall-clock kill (collect-mode `exec` only) |
|
|
293
|
+
| `env` | `Record<string, string>` | `{}` | Per-exec env (merged with image env) |
|
|
294
|
+
| `cwd` | `string` | `/` | Working directory inside the guest |
|
|
295
|
+
| `chain` | `string[]` | — | Run if first argv exits 0 (saves one round-trip) |
|
|
296
|
+
| `tty` | `boolean` | `false` | Allocate a pty; stdout/stderr merge onto stdout |
|
|
297
|
+
| `winsize` | `{cols, rows}` | — | Initial pty size (tty only). Resize later via `ExecChild.resize()` |
|
|
298
|
+
|
|
299
|
+
`ExecOutput` (collect-mode):
|
|
300
|
+
|
|
301
|
+
```ts
|
|
302
|
+
interface ExecOutput {
|
|
303
|
+
stdout: Buffer;
|
|
304
|
+
stderr: Buffer;
|
|
305
|
+
exitCode: number; // -1 if killed by signal / timeout
|
|
306
|
+
}
|
|
307
|
+
```
|
|
308
|
+
|
|
309
|
+
### `ExecChild` (streaming, returned by `vm.spawn()`)
|
|
310
|
+
|
|
311
|
+
Pull-style bidirectional I/O. Use when you want incremental input/output (LLM-style streaming, interactive REPLs, long-running daemons) instead of waiting for the whole exec to finish.
|
|
312
|
+
|
|
313
|
+
```ts
|
|
314
|
+
class ExecChild {
|
|
315
|
+
writeStdin(bytes: Buffer): Promise<void>;
|
|
316
|
+
closeStdin(): Promise<void>;
|
|
317
|
+
readStdout(maxBytes?: number): Promise<Buffer>; // returns 0-length on EOF
|
|
318
|
+
readStderr(maxBytes?: number): Promise<Buffer>;
|
|
319
|
+
signal(signum: number): Promise<void>; // e.g. 15=SIGTERM, 9=SIGKILL
|
|
320
|
+
resize(cols: number, rows: number): Promise<void>;// tty resize; no-op in pipe mode
|
|
321
|
+
wait(): Promise<ExecWaitResult>;
|
|
322
|
+
}
|
|
323
|
+
|
|
324
|
+
interface ExecWaitResult {
|
|
325
|
+
exitCode: number;
|
|
326
|
+
timedOut: boolean;
|
|
327
|
+
peakRssKib: number | null;
|
|
328
|
+
}
|
|
329
|
+
```
|
|
330
|
+
|
|
331
|
+
### `TcpForwarder` (returned by `vm.exposeTcp()`)
|
|
332
|
+
|
|
333
|
+
Proxies `127.0.0.1:hostPort` into the guest's vsock mux. In-flight connections survive `stop()`.
|
|
334
|
+
|
|
335
|
+
```ts
|
|
336
|
+
class TcpForwarder {
|
|
337
|
+
readonly localAddr: string; // e.g. "127.0.0.1:54321"
|
|
338
|
+
stop(): Promise<void>; // idempotent
|
|
339
|
+
}
|
|
340
|
+
```
|
|
341
|
+
|
|
342
|
+
---
|
|
343
|
+
|
|
344
|
+
## `using` syntax (Node 20+)
|
|
345
|
+
|
|
346
|
+
If you have explicit-resource-management (TC39) enabled:
|
|
347
|
+
|
|
348
|
+
```ts
|
|
349
|
+
{
|
|
350
|
+
using vm = await pool.acquire();
|
|
351
|
+
await vm.exec({ argv: ["echo", "auto-released"] });
|
|
352
|
+
} // vm.release() runs at end of block
|
|
353
|
+
```
|
|
354
|
+
|
|
355
|
+
For older Node / Bun / Deno without `Symbol.asyncDispose`, use `try/finally`:
|
|
356
|
+
|
|
357
|
+
```ts
|
|
358
|
+
const vm = await pool.acquire();
|
|
359
|
+
try {
|
|
360
|
+
await vm.exec({ argv: ["echo", "manual"] });
|
|
361
|
+
} finally {
|
|
362
|
+
await vm.release();
|
|
363
|
+
}
|
|
364
|
+
```
|
|
365
|
+
|
|
366
|
+
---
|
|
367
|
+
|
|
368
|
+
## Compatibility
|
|
369
|
+
|
|
370
|
+
| Runtime | Status |
|
|
371
|
+
|---|---|
|
|
372
|
+
| Node.js ≥ 18.17 | supported (LTS line, N-API 9) |
|
|
373
|
+
| Node.js ≥ 20 | supported + `Symbol.asyncDispose` available |
|
|
374
|
+
| Bun ≥ 1.0 | supported (same .node binary) |
|
|
375
|
+
| Deno ≥ 2 | supported (same .node binary, `--unstable-node-api` for older) |
|
|
376
|
+
| Browsers / Cloudflare Workers / Edge | not supported (no HVF available; see `@supermachine/client` roadmap) |
|
|
377
|
+
|
|
378
|
+
The native binary is a single `.node` file built with napi-rs; the N-API ABI is stable so runtime upgrades don't require rebuilds.
|
|
379
|
+
|
|
380
|
+
---
|
|
381
|
+
|
|
382
|
+
## Troubleshooting
|
|
383
|
+
|
|
384
|
+
**`hv_vm_create: 0xfae94007`** — worker binary lost its HVF entitlement (usually after a manual `cargo build` strip). The published npm binary is pre-signed; if you're running from source, run `npm run build` which re-signs.
|
|
385
|
+
|
|
386
|
+
**`registry unreachable`** — Docker registry DNS failed. Check your network. Pre-pull images you depend on with `docker pull <image>` to surface this earlier.
|
|
387
|
+
|
|
388
|
+
**`snapshot path not found`** — calling `Image.fromSnapshot` immediately after `Image.build` can race the bg disk save. Either wait for the file to exist or just keep the `Image` handle from `build()` instead of reloading.
|
|
389
|
+
|
|
390
|
+
**Pool seems to hang under load** — likely cycle-restore-on-release contention. Set `restoreOnRelease: false` for throughput-style workloads if you don't need state isolation between acquires.
|
|
391
|
+
|
|
392
|
+
**Memory grows over time** — first sample after balloon convergence (~10 s); pre-balloon RSS is misleading. Use macOS `footprint -p <pid>` for accurate per-process memory accounting (RSS double-counts shared snapshot mmap pages).
|
|
393
|
+
|
|
394
|
+
---
|
|
395
|
+
|
|
396
|
+
## Versioning
|
|
397
|
+
|
|
398
|
+
Lockstep with the [`supermachine`](https://crates.io/crates/supermachine) Rust crate. Each release ships a matching `@supermachine/core` and platform binary (e.g. `@supermachine/core-darwin-arm64`) with the same version number. Pin in your `package.json` with an exact match if you bake snapshots and don't want the snapshot format to drift.
|
|
399
|
+
|
|
400
|
+
## License
|
|
401
|
+
|
|
402
|
+
Apache-2.0
|
|
403
|
+
|
|
404
|
+
## Source
|
|
405
|
+
|
|
406
|
+
GitHub: <https://github.com/supercorp/supermachine>
|
|
407
|
+
Rust crate: <https://crates.io/crates/supermachine>
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
// 01-hello.mjs — the minimum @supermachine/core program.
|
|
2
|
+
//
|
|
3
|
+
// Boots an alpine:latest microVM, runs `echo hello`, prints the
|
|
4
|
+
// output. Cold bake ~400 ms; cache-hit ~15 ms + first-acquire
|
|
5
|
+
// near-zero (warm handoff).
|
|
6
|
+
//
|
|
7
|
+
// Run:
|
|
8
|
+
// node examples/01-hello.mjs
|
|
9
|
+
//
|
|
10
|
+
// Requires Docker (for the OCI image pull) and macOS on Apple
|
|
11
|
+
// Silicon (no Linux/Windows backends yet).
|
|
12
|
+
|
|
13
|
+
import { Image } from "@supermachine/core";
|
|
14
|
+
|
|
15
|
+
const img = await Image.build({
|
|
16
|
+
ref: "alpine:latest",
|
|
17
|
+
// Stable name → snapshot cached on disk, so subsequent runs
|
|
18
|
+
// skip the bake. Omit for an auto-derived sha-name.
|
|
19
|
+
name: "hello-alpine",
|
|
20
|
+
});
|
|
21
|
+
|
|
22
|
+
const pool = await img.pool({ min: 1, max: 1 });
|
|
23
|
+
const vm = await pool.acquire();
|
|
24
|
+
|
|
25
|
+
const { stdout, exitCode } = await vm.exec({
|
|
26
|
+
argv: ["echo", "hello from supermachine"],
|
|
27
|
+
timeoutMs: 5_000,
|
|
28
|
+
});
|
|
29
|
+
|
|
30
|
+
console.log(`exit ${exitCode}:`, stdout.toString().trim());
|
|
31
|
+
|
|
32
|
+
await vm.release();
|