Skip to content
The agent · trust model

Your credentials never leave your network

ispforge is a hosted control plane — but it never stores router credentials in the cloud. A lightweight agent runs inside your infrastructure, holds the NETCONF / SSH / API secrets, and dials out over mutual TLS. The control plane can render and preview config; it can't reach a router without going through your agent.

Request beta access →
Split trust

The SaaS knows the shape. The agent holds the keys.

A deliberate two-party design. The control plane knows which routers exist, which agent owns them, and whether credentials are set — never the secret material itself. Everything that touches a router goes through the agent on your management network.

  • Credentials live on the agent — in auth.yaml, mode 0600, readable only by the agent process on your host.
  • The cloud never sees secrets — Core learns "configured" or "missing" from a heartbeat, nothing more.
  • Zero inbound — the agent dials out over mutual TLS; nothing connects into your network.
  • A leaked control-plane token can't reach your routers — the blast radius is bounded to whatever one agent manages.
  • Step-up gated writes — entering or rotating a credential requires a fresh re-auth, even on a valid session.
CLOUD · ISPFORGE CONTROL PLANE
Renders, previews, audits
Knows topology & "credentials configured?" — never the secrets.
↕ mutual TLS · agent dials out · zero inbound
YOUR NETWORK
a
ispforge-agent
holds auth.yaml · 0600
↓ netconf / api / vtysh
r1 r2 r3
Live from your network

Real-time device state, full deploy history

The agent reports live device state — model, version, BGP neighbors — and every deploy it runs is recorded, diffed and auditable.

portal.ispforge.com/routers/edge1.nyc
Router detail for edge1.nyc: a Juniper MX204 on Junos 22.4R2-S2.7, agent seen just now, with peer groups, interfaces mapped to Cogent and NTT upstreams and the SFMIX peering LAN, and RPKI route-map matching enabled.
Live device state, reported by the in-network agent — model, version, interfaces, neighbors.
portal.ispforge.com/deployments
Deployment history across edge1.nyc, edge2.nyc, edge1.lon and edge2.lon — deploy_policy jobs with status, duration and change counts, including one failed commit-check caught before it reached the router.
Every deploy recorded and diffed — including the bad commit caught pre-flight.
Smooth, not clunky

On-prem security with SaaS UX

// ENROLL

Two-minute enroll

Run the agent as a container or a .deb; it enrolls with a one-time code and gets its own mutual-TLS cert. Assign routers to it in the portal.

// SSO

Portal-to-agent SSO

Add credentials from the router's page — a deep-link signs you into the agent's local UI with your portal session, so it feels portal-native while the secret is written locally.

// DEPLOY

Commit-confirmed

Every deploy previews a diff, then applies transactionally — commit-confirmed on Junos / IOS-XR, scheduled safety-rollback on MikroTik — with rollback armed.

Why not store creds in the portal? A single control-plane compromise would mean fleet-wide router compromise. Agent-local keeps the blast radius bounded.

Hosted control plane · on-prem trust

The convenience of SaaS. The trust boundary of on-prem.

Enroll an agent against a single router — free — and see the split-trust model for yourself.

Request beta access → All features