Your code, its own kernel.
Ignitify runs code you did not write. Your code gets its own Firecracker MicroVM, with its own kernel. A warm VM can serve your next run.
Isolation you do not have to configure.
Running someone else's code is a containment problem before it is a scheduling problem. The usual answer is a container. A container shares the host kernel with everything else on the machine, so the isolation is only as good as the sandbox around it.
Ignitify gives your code its own kernel, its own root filesystem and its own network path. A VM never serves two tenants. When its work is done, the machine is destroyed. If you ask for it, a VM stays warm for your next run, or pinned until you delete it.
A kernel of your own
Not a process, not a container. A MicroVM with its own kernel, walled off from every other tenant.
Limits that refuse early
What a plan allows is checked when a run is admitted, with a reason. You do not find out halfway through, when something fails.
Bare metal underneath
Firecracker needs /dev/kvm. Nesting it inside another hypervisor costs the thing we are selling, so the fleet runs on real hardware.
Teams that must run code they cannot fully trust.
If your product runs code from your users, from third parties, or from a source you do not control, Ignitify gives your users’ code a hard boundary. You write a task in Node.js, Python, Go or Rust, deploy it once, and run it as often as you need. One command line drives all of it.
- Node.js
- Python
- Go
- Rust
Accounts are not self-serve yet. To get access, or to talk about a plan,write to us.
Nothing here is a number we have not taken.
A figure on this site comes from the source that enforces it, or from a capture taken on a live host. Where we have not measured something, we say so instead of estimating. That is why you will not find an uptime figure, a throughput claim, or a comparison with another product on this site.