Core concepts
Eight terms carry most of the product. They are worth five minutes now.
Organisation
Section titled “Organisation”Your company in Seylo. Internally this is called a tenant, and you will see that word in API responses and audit exports. One organisation owns its own clusters, users, agents, schedules, approvals and audit trail, and has no knowledge that any other organisation exists.
An organisation is created either by the first person to sign up with a company email domain, or by us during onboarding. See create your organisation.
User and role
Section titled “User and role”A person who can sign in. Every user holds zero or more of four roles:
| Role | Can do |
|---|---|
viewer |
Read: the dashboard and matrix, history, requests, resources |
releaser |
Submit releases, create namespaces, add components |
approver |
Approve or reject pending requests; view the audit log |
admin |
Everything above, plus clusters, agents and SSO configuration |
They rank viewer < releaser < approver, with admin implying all three.
Zero roles is a legitimate state. A user who authenticated successfully but whose identity provider granted no mapped role is signed in and authorised for nothing; every action returns 403. This is deliberate — it is what a correctly configured provider does for someone who has not been granted access yet. See roles and permissions.
Cluster
Section titled “Cluster”A Kubernetes cluster you have registered. Each one records its provider, its
connection method, its namespace allow/deny policy, and where its metrics
come from. Adding and editing clusters is admin only.
The Seylo component that runs inside your cluster and dials out to us. It holds your cluster’s access; we hold none. It is a single Deployment with one replica, no Service, no Ingress and no inbound port.
An agent enrols once with a single-use token, then holds its own long-lived credential. Both are stored by us only as hashes. See install the agent.
Namespace
Section titled “Namespace”The Kubernetes namespace, used as Seylo’s unit of scoping. Two separate controls narrow what is reachable:
- Cluster policy — an allow or deny list on the cluster, applying to everyone equally.
- Agent RBAC scope — cluster-wide, or a
Rolein each of a named set of namespaces, enforced by Kubernetes itself. See choose an RBAC posture.
Request
Section titled “Request”A proposed mutating action: a release, a namespace creation, a component
addition, a manifest edit. When approvals are enabled, a releaser submitting
one creates a request in pending — nothing has touched the cluster yet.
Approval
Section titled “Approval”An approver or admin acting on a pending request. On approval the same
engine code runs, with the original requester preserved as the initiator, and
the request becomes applied or failed.
One approval is sufficient, and self-approval is permitted. A user who holds
approver may approve their own request. This is deliberately not two-person
control; the requirement is that whoever approves holds the role. A
releaser-only user cannot approve, so their request waits.
Audit trail
Section titled “Audit trail”Every action — applied or refused, by a human or by an agent — writes a row. The manifest history is hash-chained per resource, so a modified or removed entry is detectable rather than merely unlikely.
The words we avoid
Section titled “The words we avoid”Two initialisms appear a page apart and differ by one letter’s case. Seylo documentation always spells them out where the sentence could take either:
- IdP — Identity Provider: Entra, Okta, Google, your OIDC endpoint.
- IDP — Internal Developer Platform: the product category.