Skip to content
Kyno Docs

Security model

Kyno treats application source, Dockerfile instructions, dependencies, and application traffic as untrusted.

Kyno is beta infrastructure, not a production security certification. Firecracker is the isolation boundary, but adversarial escape testing, backup drills, and broader operational hardening are still release gates.

Isolation boundary

Section titled “Isolation boundary”

Each running app gets:

  • Its own Firecracker microVM and guest kernel.
  • A separate host UID and GID.
  • A separate network namespace.
  • A separate cgroup with memory, CPU, and process limits.
  • A read-only application root filesystem.
  • A separate writable data disk mounted at /data.

Builds run in disposable Firecracker build microVMs. Builds can download base images and dependencies. The final application runs in a different runtime microVM.

Network access

Section titled “Network access”

Running apps can access internet services. Direct SMTP ports (25, 465, 587, and 2525) and the cloud metadata address are blocked.

Raw guest ports are not exposed publicly. Incoming traffic reaches the authenticated gateway over HTTPS, and the gateway proxies approved requests to the app’s private address.

Do not treat outbound network access as a sandbox. An application can still send data over HTTPS, including to email-provider APIs. Only give an app the secrets and data it needs.

Application access

Section titled “Application access”

Apps use private URLs under apps.kyno.work. The gateway checks a signed session cookie issued to a current workspace member. Removing the member revokes app access for that email.

Owners authenticate to the Kyno console with Google or an email magic link through self-hosted Better Auth. Google requests only openid, email, and profile; Kyno does not retain Google provider tokens or request access to Gmail, Drive, Calendar, Contacts, or the Workspace directory.

Viewers verify an email-bound app grant with a single-use link that expires after 15 minutes. Browser sessions last up to eight hours. The gateway checks the grant on every request, so revoking an address immediately invalidates its existing browser sessions.

Variables and secrets

Section titled “Variables and secrets”

Non-sensitive configuration is stored as variables. Secret values are encrypted at rest with AES-GCM and injected into the runtime environment.

MCP returns secret names, never secret values. Secrets must not be placed in source files, .env uploads, Docker build arguments, logs, or tool responses.

Persistent data

Section titled “Persistent data”

Each app has a separate 1 GB ext4 data disk mounted at /data. The root filesystem is read-only.

Kyno does not currently guarantee backups or recovery. Backup tooling is still being built and is not operated as a supported service. Keep an independent copy of important application data.

Trusted computing base

Section titled “Trusted computing base”

Kyno trusts:

  • The control plane and metadata database
  • The authentication gateway
  • The Linux/KVM host and Firecracker
  • The guest kernel and base images

An escape from one of these trusted layers is outside the protection provided by per-app isolation.

Current limits

Section titled “Current limits”
  • One host and one region
  • No high availability or live migration
  • No uptime guarantee
  • No custom app domains
  • No managed database beyond per-app SQLite
  • No backup or recovery guarantee
  • No claim of suitability for adversarial public workloads

If an app handles regulated, highly sensitive, or business-critical data, review these limits before deploying it.