Security
The safest place for your workload is the machine you control.
Quayel is built so that the sensitive parts — your code, your data, your users’ traffic — stay on your infrastructure. This page describes how that holds up in practice.
Principles
Four commitments the architecture enforces.
Your data stays on your machines
Workloads, volumes and request traffic run on infrastructure you own or rent. The control plane holds configuration and metadata — it is never in the path of your users' requests.
Agents hold short-lived credentials
Each enrolled server authenticates with a signed token that expires in days, not forever, and renews itself well before it lapses.
Revocation actually revokes
Agent tokens are validated against the server's enrollment secret on every request. Rotate that secret and every outstanding token for the machine stops working immediately.
Actions are attributable
Deploys, restarts and rebuilds record the account that triggered them and the commit they put into production.
Agent trust model
How a server proves it is yours.
Enrollment, issue, verification, revocation — the full lifecycle of the credential a machine uses to talk to the control plane.
Enrollment
A server is created in your org with a long, unique enrollment secret. You supply it to the installer once; it is never returned by the API again.
Token issue
The agent exchanges that secret for a signed token identifying its org and server. The signing key lives only on the control plane — servers hold the public half.
Verification
Every agent request is checked against both the signature and the current enrollment secret on record, so a valid signature alone is not enough.
Renewal & revocation
The agent renews ahead of expiry and on restart. Rotating the enrollment secret invalidates every token that machine holds.
Access control
Two layers: what you are in the org, and what you hold on a resource.
Org role sets the floor. Per-resource grants do the real work — someone can deploy one service without seeing the rest of the fleet.
Organization roles
| Role | Scope |
|---|---|
| Owner | Full control of the organization, including deletion and ownership transfer. |
| Admin | Manage servers, services, members and settings across the org. |
| Billing | Manage the subscription and invoices without operational access. |
| Member | No implicit access to resources — sees only what has been granted. |
Per-resource grants
| Grant | Scope |
|---|---|
| Read | View a service or server, its config, metrics and history. |
| Maintain | Operate it — deploy, restart, change configuration. |
| Admin | Everything above, plus managing who else has access. |
Grants apply to a single service or server and can be issued to an individual or a team. Owners and admins hold implicit admin on everything in the org.
Controls
The rest of the surface.
Grants to people or teams
Access on a service or server can be given to an individual or to a team, so onboarding someone is a matter of adding them to the right group.
Least privilege by default
Org members start with no resource access at all. Owners and admins hold implicit admin; everyone else gets exactly what was granted.
Credentials hashed at rest
Account passwords are stored as salted hashes, never in a recoverable form. Email verification and one-time codes gate sensitive account flows.
Scoped source access
Repository access comes from a GitHub App installation limited to the repos you select, and can be revoked from GitHub without involving us.
The edge is yours
TLS terminates on your server, inside your gateway. Certificates and routing are managed for you, but the traffic never transits our infrastructure.
State reported, not assumed
Runtime status comes from agent heartbeats. The dashboard shows what the machines report rather than what the last click implied.
Responsible disclosure
Found something? Tell us first.
We would much rather hear about a problem from you than read about it somewhere else.
- Report a suspected vulnerability privately before disclosing it publicly.
- We aim to acknowledge security reports within two business days.
- Please include reproduction steps and the affected surface (control plane, dashboard, or agent).
- Do not test against organizations or servers you do not own.
Questions
Need this in a security review?
We're happy to walk your team through the architecture, the agent trust model and how access control maps to your org.