Skip to main content

​
How Nelkap works

No. Your workflows run in your own app, next to your database and your other code. Nelkap keeps each run’s state, decides when it goes on, and calls your app’s endpoint when there’s work to do. See How Nelkap works.
No. Nelkap keeps the runs, the schedule, and the saved steps. Your app needs the SDK and one route.
The SDK is written in TypeScript, and works in JavaScript too. It needs Node.js 22 or later. See Installation.
Any framework where a route can hand the SDK a standard web Request, on any host that serves it over public HTTPS: a server, a container, or a serverless function. The framework guides cover Next.js, React Router, SvelteKit, Nuxt, Astro, Hono, and Express.
Nelkap calls your app over the internet, so it can’t reach localhost. Deploy to a staging environment, with its own project, and test there. See Environments.

​
Writing workflows

Your workflow decides. A failed step is saved like a result, so every later call sees the same failure, and your code chooses what comes next: take another path, or try again with a new step after a sleep. See Error handling.
A saved step never runs again. A step cut off before its result was saved, by a crash or a deploy, runs again from its start. See Idempotency.
As long as it needs. Nelkap puts no limit on a run or a step. A run can sleep or wait for up to a year at a time, as many times as its 100 steps allow. Your host may limit how long a single call lasts. See Time limits.
Yes. Call nelkap.run inside a step, so the new run starts only once, even if the first one picks up again. See Fan-out.
Yes. Runs in progress go on with your new code, from their last saved step. Some changes need care, like renaming a step that runs have already passed. See Versioning.
Nelkap records each run and each step, with what it returned or the error it threw. What your code writes with console.log goes to your host’s logs, as usual. Code outside steps runs again on every call of the run, so a line logged there can show up more than once. Log inside a step to write it once.

​
Running in production

Runs that are sleeping or waiting aren’t affected. A run due while your app is down is tried three times, over about three minutes, then fails with deliveryFailed: replay it once your app is back. A run cut off in the middle picks up about five minutes later. See Deployment.
Nothing is lost. A run cut off by the deploy picks up from its last saved step, on your new version. See Runs during a deploy.
Cancel one run from its page. To stop a workflow for good, remove it from registerWorkflows: its runs that haven’t started, and those sleeping or waiting, are canceled. See Runs.
Up to your plan’s limit for the workspace: 50, 100, or 500 runs. Sleeping and waiting runs don’t count. Runs over the limit wait their turn, and none is lost. See Limits.
1, 7, or 15 days after a run ends, depending on your plan. Runs still going are kept for as long as they last. To keep them longer, export them.