Managing On Premise Agents

<!-- TIER:1 -->

Managing On-Premise Agents

An on-premise agent is a secure tunnel between your own network and integrator.io. You install a small piece of Celigo software on a Windows or Linux host inside your network; it dials outbound to integrator.io and holds the connection open so the platform can send work back through it. Because the agent reaches out to Celigo, you do not open inbound firewall ports or whitelist Celigo IP addresses to let the cloud reach private systems behind your firewall.

There are two things sharing the name -- keep them apart:

• The installed software -- the agent daemon running on a host inside your network. It maintains the tunnel and does the reaching.
• The `/agents` resource -- the registration of that daemon in integrator.io: a name, description, and pairing/health metadata. This is what you manage via the API and CLI.

Concerns when managing an on-premise agent:

• Reachability -- giving Celigo a path to systems that have no public endpoint (private DBs, file shares, internal apps)
• Pairing -- installing the software and configuring it with the agent's accessToken to bring the tunnel up
• Health -- heartbeats determine offline; a stopped host or service breaks every connection routed through the agent
• Token lifecycle -- rotating the sensitive accessToken (which authorizes a tunnel into your network) on exposure or on schedule

Referenced by connections via _agentId.

On-Premise Agent vs Stack vs AI Agent

The word "agent" is overloaded in Celigo. An on-premise agent is none of the others:

Smell test: if it is about reaching a system on a private network, it is an on-premise agent. If it is about running your custom code, that is a stack. If it is about an LLM doing work on records, that is an AI agent. A single flow can use both an agent (to reach a private database) and a stack (to run a custom hook). When a request just says "the agent," confirm which one is meant before acting.

Quick Reference

Do You Need an On-Premise Agent?

The deciding question: is the system reachable from the public internet, or only from inside your network?

Minimum Required Fields

Creating an agent resource needs at minimum: name.

Optional but common: description.

Connections That Route Through an Agent

A connection that needs private-network or filesystem access sets _agentId on the connection object. The agent supplies reachability; the connection supplies the target system's credentials and config.

Wiring _agentId onto a connection is a connection-configuration task -- see configuring-connections.

Health & Metadata Fields

These are server-managed (read-only) on the response -- you do not set them:

Related Skills

• configuring-connections > How to Build a Connection -- setting _agentId on filesystem, JDBC, Oracle, and on-prem MongoDB connections
• managing-stacks -- the compute counterpart; use a stack to run custom code, an agent to reach private systems
• configuring-ai-agents -- the AI agent (LLM processor), a different resource despite the shared name
• troubleshooting-flows > Diagnostic Workflow -- diagnosing flow failures caused by an offline agent
• getting-started > Which Skill to Use -- orientation across resource types

<!-- TIER:2 -->

How to Set Up an On-Premise Agent

1. Confirm you actually need one

Only when the target system is not reachable from the public internet (see Do You Need an On-Premise Agent?). Public SaaS APIs and cloud databases with public endpoints need no agent.

2. Check for an existing agent

A single agent can back many connections -- every flow that reaches systems on that network can route through it. Reuse before creating:

# List all on-premise agents
celigo agents list

# Search the account
celigo account search "agent"
celigo account search "<network location or data center name>"

3. Create the agent resource

Create the registration first. The response includes a sensitive accessToken used to pair the installed software -- capture it now.

# Create a new agent registration
echo '{"name":"On-Prem DC1 - Oracle & File Share","description":"Tunnel for the datacenter-1 private network"}' | celigo agents create

4. Install the agent software on a host inside the network

Download and install the Celigo agent software on a Windows or Linux host that can reach the private systems. This step happens on the host and through the integrator.io UI (which provides the installer download) -- not via the CLI.

5. Pair the installed agent with the access token

Configure the installed agent with the accessToken from step 3. This pairs the daemon to the /agents resource and brings the outbound tunnel up. Heartbeats begin flowing once it connects.

6. Verify the agent is online

# Confirm the resource shows heartbeats and is not offline
celigo agents get <id>

Check that offline is false and lastHeartbeatAt is recent. version and clientDetails confirm what is running on the host.

7. Reference the agent from connections

On each connection that needs private-network access, set _agentId to this agent's _id. This applies to filesystem (required), jdbc agent/activedirectory, Oracle rdbms, and on-premise mongodb connections. See configuring-connections. For Oracle, install and pair the agent before creating the connection -- Oracle rejects even a placeholder connection without a real _agentId.

Rotating the Access Token