Security
Tokay's security model starts with a dedicated virtual machine for each Workspace, then adds Project isolation, explicit Config visibility, encrypted Secrets, scoped access, and recoverable production changes. This page explains the boundaries so a team can judge what Tokay protects and where its own application responsibilities begin.
Last updated
AI agent? Start with llms.txt.
Workspaces are isolated by hardware virtualization
Every Workspace runs on its own KVM virtual machine. KVM is the hardware virtualization boundary used by major cloud providers between customers.
A compromise inside another customer's application is contained inside that customer's virtual machine. It cannot reach your Workspace machine, Services, or data through a shared application runtime.
Inside one Workspace, Projects have private network boundaries. Services in one Project cannot connect directly to another Project's Services or databases.
Config and Secrets have different disclosure boundaries
Project Config is intentionally readable by Project operators and API credentials that can read source or write Config. Store only nonsecret runtime values there.
Project Secrets are encrypted at rest and write only through the product API. Tokay does not write Secret values into source, build output, or platform logs. The running Service receives Config, Secrets, and managed resource credentials only at runtime.
Submitted code is checked for likely hardcoded credentials. Moving a detected value into secure storage and changing the source requires approval. See Config, secrets, and environment variables.
Your application can still print a value it reads, so avoid logging credentials in application code.
Authentication belongs at the platform boundary
Tokay accounts use single use emailed magic links rather than passwords. A human confirmation step prevents email scanners that prefetch links from signing in.
Restricted web apps and functions use the same platform owned access layer. The application does not receive or manage Tokay session secrets, so its code cannot weaken the sign in flow. See Who can open your app for how Project, Service, and audience settings work together.
Authorization follows memberships and credential grants
Workspace, Project, and repository roles define what a Platform identity can reach. Every API, MCP, Git HTTPS, and SSH credential has explicit grants that can only narrow the actions that identity can perform.
Both are checked on each request. Removing a membership immediately narrows every credential that depended on it, including the next Git command from an SSH connection that is already open. Account Git keys never provide shell access to the Workspace VM. See Permissions.
Credential access is checked on every request, so revocation and membership changes take effect without waiting for a credential to expire.
Actions and app access are attributable
Deployments, configuration changes, membership changes, and API actions record their actor and credential. The Workspace audit log, available on paid plans, exposes that history.
Each Project also keeps an access log for its deployed apps, showing who was admitted or denied. Machine calls retain both the stable Machine identity and the exact credential presented. See Who can open your app.
Data safety uses several recovery layers
Database migrations rehearse against a copy, and destructive changes can require confirmation and a snapshot. Deleted Projects, code, Services, and databases can be restored for 30 days. Persistent files are replicated away from the VM disk and receive periodic offsite snapshots.
Data can be exported in standard database formats. See Database migrations, Deleting and restoring, Files and persistent storage, and Databases.
Data location and Tokay access
Tokay infrastructure is hosted in the EU.
Tokay stores and processes the source and data needed to build and run your Services. The privacy policy and terms describe how that access is handled.
Send security questions or reports to hello@tokay.io.