Running a helper program inside a LangSmith Deployment graph node

Last updated: September 24, 2026

Overview

A graph node can start another program, such as a Node.js script, and talk to it while the run is in progress. This is fine to do, especially for a proof of concept, as long as you keep a few things in mind.

What to know

The helper program shares the server's resources.
Each server handles several runs at the same time (10 by default, set by N_JOBS_PER_WORKER). Your helper program uses the same memory and CPU as all of those runs. If the server runs out of memory, every run on it can fail.

Long runs are fine, but the connection may drop on Cloud.
A run can last up to 24 hours by default, so a run of a few minutes to an hour is fine. On Cloud, though, the connection between your app and the server closes after 1 hour, and this can't be changed. The run keeps going in the background. Your app just needs to reconnect to get the results.

Runs can be stopped during a deploy or scale-down.
When a server shuts down, it waits 180 seconds by default (up to a maximum of 1 hour) for runs to finish, then stops them. A long-running helper program can be cut off in the middle.

If a run restarts, the step starts over.

Interrupted runs are retried automatically (up to 3 times by default). LangSmith saves your graph's progress, but not the helper program's progress. So the node that started the helper runs again from the beginning, and the helper starts fresh. Make sure the step is safe to run more than once.

Avoid heavy computing inside the node.
The server is built to handle many runs efficiently while they wait on things like AI model responses. Heavy computing in the node slows down every other run on that server. At low traffic this usually isn't a problem, but it matters at high volume.

Recommendations

Include everything the helper needs in your deployment, such as Node.js and the program itself. You can add these through your langgraph.json settings.
Don't run too many at once. Lower N_JOBS_PER_WORKER if the helper uses a lot of memory or CPU, and monitor your deployment for crashes or slowdowns.
Always shut down the helper program when the step finishes, fails, or is cancelled, so leftover programs don't pile up.
On Cloud, reconnect if the connection drops after an hour. It doesn't mean the run failed.

Moving to production

This setup works well for testing. For production, move the helper program into its own separate service so it has its own resources and doesn't affect your agent.