Data Hub offers more than custom code. Some teams need a narrower tool.
HubSpot brings a lot of capabilities together. Data Hub, for example, includes tools for connecting data, improving its quality and putting it to use across the business. For a team that needs those capabilities together, the broader product can be the right investment. What Data Hub includes.
HubSpot’s native custom-code action requires Data Hub Professional or Enterprise. Those subscriptions serve a broader set of needs than running a single piece of code. HubSpot’s requirements.
A smaller team may already have the workflow tools it needs, but not the budget or an immediate use for that broader subscription. Its next requirement might simply be to generate a document, use a particular library or apply its own business rules. That is a different purchasing decision, not a judgment about the value of Data Hub.
Turbyn is our focused answer to that situation: an execution environment for custom code, connected to HubSpot workflows. It complements HubSpot; it is not a replacement for Data Hub’s data-management capabilities. A team can also use both when a particular job needs a different execution environment.
You still need a HubSpot plan with access to the workflows and downstream actions you use. Turbyn doesn’t unlock unrelated HubSpot features.
Different jobs need different execution environments.
The native custom-code runtime is limited to 20 seconds and 128 MB of memory. That can be enough for a small calculation, but constraining for a larger document or a sequence of API calls. Execution limits.
A managed runtime has defined boundaries. Time and memory are different constraints: waiting for a remote API consumes time; parsing a file or building a document consumes memory. The useful question is whether the environment fits the job, rather than whether one runtime is right for every workflow.
Our approach is to separate execution from the workflow editor: give the code its own execution environment, with capacity appropriate to the job, and return the result to HubSpot. Longer runtime should make the complete operation possible, not encourage inefficient code.
Some jobs call for a particular library.
HubSpot documents a predefined set of supported libraries. A PDF generator, a specialist parser or a vendor SDK can sit outside that set. Supported libraries.
A maintained library often represents years of work on the edge cases. Rewriting it inside a workflow, or copying its source into an editor, gives the team another thing to maintain.
Turbyn is built around bringing compatible npm and Python packages into the project. Dependencies belong alongside the code, not in a separate workaround that only its author understands.
Changing code is a release, not just an edit.
Once a workflow depends on code, someone needs to know which code ran, which dependencies it used and whether a new draft has reached production. An editor history alone is not the entire release process.
Our principle is a clear boundary between a draft and a published build. Test the draft, publish code and dependencies together, and deliberately choose what the live action runs. This is about making change understandable, not adding ceremony.
Draft
Test
Published build
Live action
A successful test is not the same as a busy workflow.
One enrollment might work perfectly. Many enrollments can compete for the same API quota. Retrying a request can also repeat a side effect unless the operation is designed for that.
HubSpot offers action-level rate limiting and retry behavior. External APIs still impose their own quotas. Native rate-limit controls.
We think a good execution layer must make pacing, backoff and failures understandable. That is the reliability problem we want to solve. Moving code into Turbyn does not remove an API limit or make every operation safe to retry; the code and the execution policy need to work together.
The infrastructure should not become your next project.
The alternative to a constrained runtime is often “build an endpoint.” Then come deployments, credentials, logs and the connection back to the workflow. That is a lot of setup for one useful action.
You write and test the business logic. Turbyn handles the execution environment and the connection back to your workflow.
1. Connect HubSpot and choose a recipe.
Start from a pattern for your task, or bring code you already have.
2. Add your inputs, libraries and rules.
Keep what works in the recipe. Change the parts that are specific to your business.
3. Test, publish and use the action.
Inspect the result before putting it in a live workflow. Map the outputs to the next step.
When to use Turbyn.
Use native workflow actions when they do the job. Use Turbyn when the work needs custom code and a more suitable execution environment. You keep ownership of the logic, the permissions you grant and the result you publish.
It does not mean unlimited runtime, unlimited memory or an exemption from other platforms’ limits. Check your plan’s capacity and the API limits of each service your code calls.
Platform references checked against HubSpot’s documentation on September 13, 2026. See pricing and documentation for Turbyn’s current setup and allowances.