Skip to content
Seylo Docs

What Seylo is

Seylo is a console for deploying to and operating Kubernetes clusters — across clouds, across teams, and specifically across the organisational boundaries that normally stop a central tool from working at all.

Most deployment tools need two things that a real fleet cannot give them:

  1. a network path from the tool to each cluster’s API server, and
  2. credentials for each cluster, held centrally.

Private clusters have no inbound path. And the platform team that owns a production cluster is frequently not willing to hand its cloud credentials to a vendor — reasonably. Seylo is built so that neither is required.

How the connection actually works

Section titled “How the connection actually works”

An agent runs inside your cluster and dials out to Seylo over an outbound WebSocket. Your cluster accepts nothing inbound.

   ┌──────────────────────────────┐             ┌───────────────────────────┐
   │  Seylo                       │             │  YOUR cluster             │
   │                              │             │                           │
   │  API + agent gateway         │ ◀───────────│  agent Deployment         │
   │  one port, one TLS cert      │  outbound   │  ServiceAccount + RBAC    │
   │  wss://.../agent/connect     │     WSS     │  loads in-cluster config  │
   └──────────────────────────────┘             └───────────────────────────┘
     no inbound to your cluster                   no listener, no Service,
     no cloud credentials here                    no Ingress, no NodePort

What follows from that diagram is most of the product:

  • No firewall change. No public API endpoint, no VPN or peering, no authorised-networks entry for our IP. If your cluster can reach the internet on 443 — directly or through your existing forward proxy — it can be managed.
  • No cloud credential on our side. The agent authenticates to Kubernetes with its own ServiceAccount. There is no AKS, EKS, GKE or OKE credential in our possession, so there is nothing for us to lose.
  • No exec, no attach. Those verbs appear in no grant our chart can produce, at any setting. Shell access into your containers is not implemented and is not planned.
  • Provider-agnostic. The Kubernetes API is the same everywhere; only credential acquisition ever differed, and the agent removes that step. AKS, EKS, GKE, OKE and any conformant cluster are the same to us.

What you can do once a cluster is connected

Section titled “What you can do once a cluster is connected”
Deploy Release an image, edit manifests, edit environment and ConfigMaps, restart a rollout, schedule a deployment, roll back
Govern Propose-and-approve on every mutating action, four roles, a hash-chained audit trail, namespace allow/deny policy
Observe Dashboard matrix across clusters and environments, rollout progress with real failure reasons, usage metrics, pod-failure alerts
Operate Browse resources, compare environments for drift, right-sizing recommendations, cost attribution

What Seylo deliberately does not do

Section titled “What Seylo deliberately does not do”

Reading this list is faster than discovering it later.

  • It does not return Secret values. Ever, to anyone, through any surface. See how secrets are handled.
  • It does not give you a shell. No kubectl exec, no attach.
  • It does not silently overwrite Argo, Flux or Helm. A write to a resource owned by a reconciler is refused until you explicitly acknowledge it, and the refusal names the owner.
  • It does not estimate numbers it does not have. An unknown cost or metric is reported as unknown, with the reason. It is never filled in from a similar workload.
  • It does not act on its own outside a signed, bounded, expiring and rate-limited envelope that you grant deliberately.

Where to go next

Section titled “Where to go next”