Sink Types & Configuration
A Sink Type defines a category of sink agent that runs in your infrastructure. Before you can install any sink, you must first create a Sink Type. It provides the authentication credentials and configuration that agents use to connect to the Hub.
Why Sink Types Are Required
Section titled “Why Sink Types Are Required”Every sink agent connects to the Hub using credentials from a Sink Type. The Sink Type also determines:
- Which Libraries (and their code modules) are available to the agent
- What scopes and permissions the agent has
- Which configuration parameters are injected at runtime
Think of a Sink Type as the agent’s identity and capability profile. A Python agent uses a Python Sink Type; a PowerShell agent uses a PowerShell Sink Type.
Creating a Sink Type
Section titled “Creating a Sink Type”Navigate to the Sink Types tab on the Sinks & Sources screen and click Create. You need the following information:
| Field | Required | Description |
|---|---|---|
| Name | Yes | A descriptive label for this type (e.g. REMOTE:LINUX, LOCAL:PYTHON). Choose a naming convention that distinguishes where and how agents of this type run |
| System | No | When enabled, this Sink Type is available to all tenants. Only SuperAdmins can create or modify system-wide types |
| Description | No | Free-text notes about the purpose of this agent type |
| Requires Authentication | Yes | Defaults to on. When enabled, agents must present valid credentials to connect |
| Default Scopes | No | Comma-separated list of OAuth-style scopes granted to agents (e.g. read,tasks.execute). Defaults to read if left empty |
| Host-bound | No | Defaults to off. When enabled, this type’s sinks run only on the node installed for them — e.g. shell scripts executed from that node’s SCRIPTS_FOLDER. Leave off for library-based types, which can run on any of your tenant’s nodes |
Client Credentials
Section titled “Client Credentials”When you create a Sink Type, the platform automatically generates a Client ID and Client Secret. The Client Secret is displayed only once — copy and store it securely immediately.
These credentials are what you provide to the sink agent during installation:
| Credential | Environment Variable | Purpose |
|---|---|---|
| Client ID | CLIENT_ID | Identifies which Sink Type the agent belongs to |
| Client Secret | CLIENT_SECRET | Authenticates the agent to the Hub |
Regenerating a Secret
Section titled “Regenerating a Secret”If a secret is compromised or lost, open the Sink Type detail panel and click Regenerate Secret. A new secret is generated and the old one is immediately invalidated. All agents using that Sink Type must be updated with the new CLIENT_SECRET.
Config Params
Section titled “Config Params”Config Params are key/value configuration pairs attached to a Sink Type. They are injected into sink agents at runtime and can be used to pass environment-specific settings (file paths, feature flags, timeouts) without hardcoding them.
| Param Type | Behaviour |
|---|---|
STATIC | A fixed value baked into the Sink Type definition |
DATA | A key read from the event payload at runtime |
SECRET | A secret key resolved from the Secrets store at runtime |
Config Params are optional. Use them when you need all agents of a given type to share a configuration value.
System-Wide vs Tenant-Scoped
Section titled “System-Wide vs Tenant-Scoped”| Scope | Creator | Visible To |
|---|---|---|
| Tenant-scoped | Any Admin in the tenant | Only that tenant |
| System-wide | SuperAdmin only | All tenants |
System-wide Sink Types have the System flag enabled. They are ideal for platform operators who want to provide standard agent types to all tenants. Your Sink Types list always shows the platform’s system types plus the types your tenant created — other tenants’ custom types are never visible to you.
Who Runs Your Sinks
Section titled “Who Runs Your Sinks”Sink Types vs. Sinks. A Sink Type is a template; a Sink is your tenant’s instance of it (its own identity, status, and configuration). Creating a type does not create an instance — create a Sink for the type to start running workloads.
Make My Copy
Section titled “Make My Copy”Platform sink templates are copied the same way as source templates: in the
Sinks screen’s Types tab, platform templates show Make my copy. Give the
copy a name — the template’s libraries & modules ride along verbatim (edit them
afterwards on the type edit screen), and the copy inherits the template’s node
coverage. Copies show “based on ” and are self-hosted by
default: they run on your machines (the Instances tab shows the static
Hosted by: Your machine hint).
Sinks are executed by nodes — deployed agents such as the platform’s remote node: The Instances tab derives each Sink’s status chip from node heartbeats, exactly
like Sources: Awaiting node (never picked up), Online (< 2 min since the
last ping), Offline (2+ minutes without a ping). Lifecycle states such as
KILLING keep their own chip. A Sink Type needs Libraries to define what code modules the agent can execute. Libraries are managed on the Libraries screen (sidebar → Automation → Libraries), not in the sink type dialog: Either way, attach the library to your sink type (Attach sink type on the library, or detach via the ✕ on a linked chip) — the flow editor only offers modules that are available on the flow’s sink type. See Actions & Libraries for details. Once your Sink Type is created:
SCRIPTS_FOLDER scripts.Instance health
Section titled “Instance health”
Adding Libraries
Section titled “Adding Libraries”
Next Steps
Section titled “Next Steps”