wispA real kernel.
A space of its own.
Each sprite runs in a Firecracker microVM, with hardware isolation and a persistent ext4 disk.
SELF-HOSTED · FIRECRACKER · SPRITES API
Small VMs.
Your machine.
Real Linux environments that remember where you left off.
Run them on your own hardware. Let them sleep between requests.
One host. Every sprite. The whole picture.Actual dashboard captures · click any image to explore
A real kernel.
Step away.
Pick up where you left off.
Idle sprites suspend with memory intact. The next request wakes them. Even a cold sprite keeps its files.
Your tools.
A new home.
Use the official sprite CLI and Go, Python, or JavaScript SDKs. Point them at your host and go.
A LOOK INSIDE
Your host, without
the guesswork.
From the big picture to a shell inside a VM.
It all ships with the daemon.
Resource usage
Follow CPU and memory across the host, then see what each running sprite uses.
Every sprite, at a glance
Scan state, CPU sparklines, memory, disk, and checkpoints in one table.
A shell, right here
Open a terminal inside a microVM. An attached session keeps the sprite awake.
Zoom in on a workspace
Inspect one sprite’s resources, state, URL, and recent activity.
See who is stopping by
Track visitors, page views, requests, and errors for your sprite URLs.
Go beyond request counts
Watch throughput, latency percentiles, and a latency heatmap over time.
Know where the disk goes
See disk usage by sprite, including exclusive data and shared clone extents.
Keep an eye on the host
Watch memory, load, and volume usage on the machine behind your sprites.
Keep a point to come back to
Create, restore, and clone disk checkpoints from a sprite’s own page.
Find the expensive routes
Compare request counts, errors, and latency by API route or sprite URL path.
Follow the requests
Inspect the live request tail and the slowest requests in the selected window.
Know what gets visited
Break down traffic by page and by sprite, with visitors, views, and errors.
Understand your visitors
Explore referrers and the mix of browsers, bots, and tools reaching your apps.
Set the boundaries
Inspect and edit network, privilege, resource, and spawn policies as JSON.
WORK. REST. REPEAT.
Quiet when you’re away.
Ready when you’re back.
Doing the work.
A Firecracker process runs your Linux environment. Requests and active sessions keep it awake.
After 30 seconds idle →Holding your place.
Memory is saved to disk. Processes freeze, then resume when the next request arrives.
After the warm TTL (default: 1 hour) →Keeping your files.
Only the disk remains. The next request boots a fresh VM with your filesystem intact.
A request wakes it up ↗BRING YOUR OWN HARDWARE
Your little cloud
starts here.
You’ll need Linux, read/write access to /dev/kvm, Go, and rootless Podman.
The daemon runs as your user. Guest networking is an optional host setup step.
Read the host setup guide ↗01 / INSTALL & START
git clone https://github.com/arugula-salad/wisp
cd wisp
make deps image
make install-service02 / CONNECT YOUR CLI
export SPRITES_API_URL=http://127.0.0.1:7788
export SPRITE_TOKEN=$(cat ~/.local/share/wisp/token)
sprite create dev
sprite exec -s dev -- uname -aAlready have the official sprite CLI? You’re ready.
Or connect with the Python, JavaScript, or Go SDK.
03 / OPEN YOUR DASHBOARD
http://127.0.0.1:7788Paste the token from ~/.local/share/wisp/token.
GO A LITTLE DEEPER
Make it your own.
The details, tradeoffs, and operating instructions.
01
Operate your host ↗
Services, reboots, resource limits, and disk pressure.
02Put an app online ↗
Sprite URLs, custom domains, and automatic certificates.
03Bring a container image ↗
Create a sprite from your preferred image and userland.
04Back up your sprites ↗
Incremental backups to S3-compatible storage and host recovery.
05Understand the boundaries ↗
Network policy, process confinement, and security limitations.
06Compare API behavior ↗
Deliberate differences from the hosted Sprites product.