Sprites - Stateful sandboxes

# Create a new sprite
curl -X PUT https://api.sprites.dev/v1/sprites/my-sprite \
-H "Authorization: Bearer $SPRITES_TOKEN"

# Execute a command
curl -X POST https://api.sprites.dev/v1/sprites/my-sprite/exec \
-H "Authorization: Bearer $SPRITES_TOKEN" \
-d '{"command": "echo hello"}'

import { SpritesClient } from '@fly/sprites';

const client = new SpritesClient(process.env.SPRITES_TOKEN!);

// Get a Sprite reference
const sprite = client.sprite('my-sprite');

// Run a command!
const { stdout } = await sprite.exec('echo hello');
console.log(stdout);

client := sprites.New("your-auth-token")

// Get a sprite handle
sprite := client.Sprite("my-sprite")

// Run a command - just like exec.Command!
cmd := sprite.Command("echo", "hello", "world")
output, err := cmd.Output()
if err != nil {
log.Fatal(err)
}

fmt.Printf("Output: %s", output)

Stateful environment

Sprites are fully mutable and persistent between runs. Your data lives on a boring, ext4 filesystem. It's available when your Sprite runs.

Persistence

Unlimited checkpoints

Write files, install packages, build sqlite databases. Change whatever you need. When you're happy, checkpoint. When you're not, restore.

Checkpoints

Granular billing

Sprites come up fast, have a bunch of CPU and RAM available, and run as long as they need to. You pay only for the resources you use.

Billing

HTTP Access

Each Sprite has a unique URL. Share what you're building in public, hook up webhooks, serve APIs. If it's HTTP you can do it.

Sprite URLs

Sprites dynamically manage resources; we only bill for actual CPU cycles, resident memory, and consumed storage.

All resources are billed hourly based on actual usage.