Connecting on-premise infrastructure to a cloud service usually sets off a security review, because the naive design requires opening an inbound port so the cloud can reach in. That’s a standing invitation on your network perimeter. KeplerAI avoids it entirely by borrowing a pattern proven at massive scale: the self-hosted CI runner.
Pull, don’t push
A GitHub Actions runner doesn’t wait for GitHub to connect to it. It opens an outbound connection and pulls jobs. The KeplerAI data plane Runner works the same way:
- It opens a connection out to the control plane and long-polls for jobs.
- It claims a job, executes it near the data, and posts back aggregated results.
- It sends a heartbeat so the SaaS knows it’s alive.
At no point does anything connect into your network. Your firewall stays closed.
Why this is safer
- No inbound port means no new attack surface on your perimeter.
- The SaaS is stateless about connections — nothing to maintain, and recovery is trivial.
- Network loss is a non-event. Jobs wait in the queue; the Runner resumes polling when it reconnects. Leases and idempotency by
job_idmean a restarted Runner never double-runs a completed job.
Security on top
Every job is protected by mutual TLS and a revocable, per-tenant token. A token only grants access to its own Runner’s jobs, so there’s no cross-tenant reach even in theory. Database credentials never travel — they stay in the Runner.
The takeaway
The safest integration is the one that never asks you to open a door. Outbound-only polling gives you real-time orchestration with a closed perimeter — which is exactly why security teams sign off on it quickly. See the job protocol on the Platform page.