The dev server AWS Lambda never had. Your whole app — API, queues, workers, tables — running natively on your laptop in 99 milliseconds.
No containers to build, no orchestration to debug. Just your app, running.
You never call a worker yourself. pulse watches the queue and delivers.
Save a file. The next request runs the new code. Restarts don't exist here.
pulse.yaml edits apply live tooReplay yesterday's crash against today's fix — byte for byte.
Real wire protocols throughout — the AWS SDK can't tell the difference.
Run any command bare and it asks instead of erroring. Errors ship their fix.
One native process, one SQLite file. Four steps from empty folder to replayable request.
Working handlers, a pulse.yaml, dependencies installed. Then the API, queues and tables all come online together.
$ pulse init shop -t api-and-worker && pulse startYour route becomes a real API Gateway event — path params, query strings, body, exactly like production.
$ curl -X POST localhost:3000/orders -d '{"sku":"A1"}'Your handler queues a message and replies immediately; pulse delivers it, retries failures and dead-letters repeat offenders.
$ pulse send order-events '{"id":"e9b4"}'Every payload is recorded. Fix the handler, re-fire the actual event against your current code, watch it pass.
$ pulse events replay 8931cf5bLogs are where debugging starts, not where it ends. Four ways to see what actually happened.
One id, the whole story: the exact payload that arrived, everything the function printed, how it ended — and the command to re-run it.
LocalStack tests your infra. SAM deploys. pulse owns the five hundred iterations before staging.
| Feature | pulse | sam local | LocalStack |
|---|---|---|---|
| Cold start to working | ~100 ms | container per invoke | 10–30 s container |
| Code change | save → done | mostly re-invoke | redeploy / config |
| Queue → worker → DLQ locally | ✓ out of the box | ✗not available | via deploy cycle |
| Event replay & request stories | ✓ built in | ✗ | ✗ |
| Requirements | one 20 MB binary | Docker | Docker, GB-scale image |
| Typical memory while developing | ~50 MB | 100s of MB (containers) | GBs (Docker image) |
| Data persists across restarts | ✓ free, default | ✗n/a | paid tier |
swipe the table to compare →
Honesty by design. pulse does one workflow completely — CRUD APIs with background jobs. Anything outside that subset fails loudly with a message saying so, never silently wrong. S3, SNS, EventBridge and Step Functions are on the roadmap, not pretended.
Every piece — a function, a route, a queue, a table — is one command. Run it bare and it asks instead of demanding flags; each edits pulse.yaml for you and applies live.
$ pulse add function notifierWrites services/notifier/handler.py — a working, commented Lambda handler — and registers it.
$ pulse add route POST /notify --function notifierFunctions and routes stay separate on purpose — exactly how real AWS models them.
$ pulse add queue emails --worker send-email --dlqQueue, worker function, wiring and dead-letter queue in one line. Then pulse send emails '{…}'.
$ pulse add table customers --pk emailA table's whole schema is its key — every other field is just code. No migrations, ever.
pulse remove is the exact inverse — it unwires the piece and never deletes your code or data.
Four starters, each adding exactly one concept. All ship in Python and Node, use the plain AWS SDK, and run unchanged in real AWS.
$ pulse init --listhelloOne function behind GET /hello — the smallest possible start.
your first function
todo-apiReal CRUD on one DynamoDB table: create, list, complete, delete.
+ a real table
webhook-relayAck-fast webhook handling with retries and a dead-letter queue.
+ a queue & DLQ
api-and-worker ★The full loop: API + queue + worker + table, wired and narrated.
everything together
Yes. pulse runs your functions natively against the real Lambda Runtime API — the same contract AWS uses in production. Node.js and Python, no Docker, ready in about 100 milliseconds.
No. pulse is one ~20 MB binary that runs your functions as native processes — no images to pull, no containers to boot, no daemon idling in the background. A complete app with an API, a queue, a worker and a table sits around 50 MB of memory, which is why it starts in milliseconds instead of tens of seconds.
Node.js and Python today. Every template ships in both, and handlers are plain AWS SDK code with no pulse imports to remove later. The other Lambda runtimes — Java, Go, .NET, Ruby — are not supported yet, and pulse says so plainly rather than half-running them.
For the inner development loop, yes. LocalStack emulates ~100 AWS services inside Docker and shines at testing infrastructure code. pulse does one workflow completely — Lambda, HTTP, SQS, DynamoDB — natively, with dev-server ergonomics: hot reload, event replay, a live monitor.
They do different jobs. sam local starts a container per invocation and cannot run the queue → worker → dead-letter-queue loop continuously; pulse runs your whole app as a long-lived local cloud with hot reload. Your deploy pipeline keeps using SAM or CDK — pulse is development-time only and never touches it.
Yes — plain boto3 in Python, AWS SDK for JavaScript v3 in Node. pulse sets AWS_ENDPOINT_URL for your functions automatically, so the same code talks to pulse locally and to real AWS in production.
Yes. DynamoDB items, queued messages and event history persist in .pulse/data (SQLite). Stop the engine, restart tomorrow — everything is still there, free, by default.
With whatever you already use — SAM, CDK or the Serverless Framework. pulse is development-time only and your code is vanilla AWS SDK throughout, so there is nothing to strip out.
Install pulse with one command and boot your first Lambda in under 100 milliseconds.
brew install --cask geetnsh2k1/pulse/pulsethen run pulse tour — five minutes, hands-on, nothing simulated