Local Development

wisp dev

wisp dev

Deploys a small, permanent bridge stack to your AWS account once, then opens a WebSocket connection from your local machine to it. Real requests to your API are relayed over that connection to your local handler code — rebundled whenever you save, so an edit is live on the next request. There's no redeploy step in this loop.

This is the adoption gate for actually iterating on a wisp app: without it, every change would mean a full wisp deploy cycle before you could see it work.

Startup cost

The bridge is deliberately independent of your route table: one catch-all handler fronts the whole API, and wisp matches the method and path locally. Adding, renaming, or deleting a route therefore never changes the bridge stack, so only the very first wisp dev pays a CloudFormation deploy. Later runs compare a hash against the deployed stack and reconnect in a second or two.

One session per stage

A stage relays to one wisp dev session at a time. If a teammate starts wisp dev against the same stage, they take over the relay and your session prints a notice telling you so — use a separate stage (wisp dev --stage alice) when two people need to work at once.

wisp invoke

Sometimes you just want to run one function once, without the bridge running — a quick check, or a case where the WebSocket bridge isn't available:

wisp invoke <exportName> [--event <file.json>] [--stage <name>]

<exportName> is the name your handler is exported as (export const createOrder = api.post(...) → createOrder), not the route path. --event points at a JSON file to use as the invocation payload; omitted, the handler runs with an empty event.

This runs your real handler locally, but resolves any Store/Queue/Bucket it touches against your actual deployed stack for that stage — so a Store.get() call reads real data, not a mock.

wisp invoke createOrder --event ./fixtures/create-order.json

Choosing between them

Use wisp dev for anything you're actively iterating on — routes, consumers, anything driven by real traffic. Reach for wisp invoke when you want a single, scriptable run of one function, or as a fallback when you're working offline from a file-based event instead of live traffic.