managing-stacks

Managing Stacks

A stack is a pointer to your own compute environment where Celigo runs extension code -- the script hooks and connector wrappers that would otherwise run on Celigo's hosted JavaScript runtime. A stack holds the address and credentials of that environment, not the logic. At runtime, when a hook or wrapper is configured to use a stack, Celigo dispatches that function's execution to the stack instead of running it on its own managed runtime.

Concerns when managing stacks:

• Necessity -- most accounts never need a stack; the hosted runtime handles the vast majority of extension logic. A stack is for a real trigger (see the decision matrix).
• Type and config -- server (a self-hosted HTTP endpoint) or lambda (an AWS Lambda function), each with its own config block.
• Credentials -- a server carries an auto-generated systemToken; a lambda carries AWS keys. Both are masked in responses and demand credential discipline.
• References -- a stack does nothing on its own. It matters only once a hook (via _stackId on an export/import) or a wrapper connection (via _stackId) points at it.

Stacks are a resource type in their own right. They are referenced by script hooks and by wrapper connections.

The Stack Is the Runtime, Not the Code

The distinction the whole domain hangs on:

• The code is the logic: a hook (a JavaScript function on an export/import -- preMap, postSubmit, etc.) or a connector wrapper (the server-side JavaScript that implements a custom adaptor). Hook logic is a script resource; wrapper logic belongs to the wrapper connection.
• The stack is where that code runs. A hook or wrapper points at a stack via _stackId. When set, Celigo dispatches that function's execution to the stack instead of its managed runtime.

So "edit what the hook does" is script work; "change where the hook runs" (managed runtime <-> a stack, or one stack <-> another) is what touches _stackId. A stack is bring-your-own-compute: it supplies the environment, not the behavior.