legal · privacy

Privacy Policy

Last updated: July 2, 2026

z3.run is a mini-cloud that runs your apps and AI agents in hardware-isolated microVMs. This policy explains what data the platform handles, why, for how long, and what control you have over it. The short version: we store what's needed to run and secure your workloads and bill your usage — and nothing is sold or shared with advertisers.

1. Who this covers

This policy applies to the hosted service at z3.run. z3.run is also available as self-hosted software; when you (or your organisation) run your own instance, the operator of that instance is the data controller for everything on it, and this policy does not apply to their deployment.

2. What we collect

Account data

  • Email address and display name — used to sign in, identify you within teams, and contact you about your account.
  • Sign in with Google (optional) — if you choose to sign in with your Google account, we receive your basic Google profile: your name, email address and profile picture. It is used only to create and sign you in to your z3.run account — never for advertising, and never sold or shared. We request no other Google data. z3.run's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.
  • Password — stored only as a salted hash, never in plaintext.
  • Team and project membership — who belongs to which team, and with which role.

Content you deploy

  • Workloads — container images you reference, applications and files you place in a microVM's persistent root filesystem, storage volumes, and environment variables you configure (environment variables can contain secrets — treat them accordingly).
  • Domains and TLS certificates — hostnames you route, and any certificate/private-key pairs you upload for custom domains. Private keys are stored with restrictive permissions and used only to serve your domain.

Operational data

  • Pod logs — your applications' console output is collected into a per-project journal so you can browse recent history. Retention defaults to 7 days and is configurable per project (1–365 days); older lines are pruned automatically.
  • Audit trail — every action that changes your project (deploys, restarts, credential changes, file access, shell sessions, and similar) is recorded with the acting account, timestamp and IP address. Shell and file-transfer contents are not recorded — only metadata about the action.
  • Metrics and network telemetry — CPU, memory and network throughput of your pods and projects, kept as aggregated time-series for charts and capacity planning.
  • API keys — keys you mint (including for MCP / LLM access) are stored hashed; we record scope, and last-use time.

Billing data

  • Prepaid credits — wallet balances, project pool balances, and a ledger of how credits were added and consumed (metered by CPU, memory and storage). We do not store payment-card numbers.

3. What we don't do

  • We do not sell your data, and we do not share it with advertisers or data brokers.
  • We run no third-party analytics or tracking pixels in the product.
  • We do not read the contents of your workloads, volumes or logs except as needed to operate the service, investigate abuse, or when you ask us to (support).
Cookies: the app uses a single, essential, HttpOnly session cookie to keep you signed in. Your theme preference (light/dark) is kept in your browser's local storage. That's it — there are no advertising or cross-site cookies. The marketing site loads icon fonts from a public CDN, which may see your IP address as part of serving the file.

4. How we use data

  • To run the service — schedule your microVMs, route your domains, serve TLS, attach storage.
  • To secure it — the audit trail, IP records and deny-all network model exist to detect and investigate unauthorised access and abuse, for your benefit and other tenants'.
  • To meter and bill — resource usage drives credit consumption; the ledger shows you exactly what consumed credits and when.
  • To support you — when you contact us, we may look at your account, audit and log data to help.

5. Where your data lives & how it's protected

  • Isolation — every workload runs in its own hardware-isolated Firecracker microVM with jailer sandboxing; networking is deny-all by default, and only the connections and domains you configure are opened.
  • Encryption — traffic to the platform and to your domains is served over TLS; cross-host overlay traffic between your pods is encrypted; platform secrets are sealed with a data key (hardware/TPM-backed where available).
  • Access — authorisation fails closed: project data is reachable only by members of the owning team (and platform administrators for operations and support, whose actions are themselves audited).

6. Retention & deletion

  • Pod logs — pruned automatically after your project's retention window (default 7 days).
  • Audit journal — kept for the life of the project as an append-only record; it is deleted together with the project.
  • Metrics — kept as rolled-up time-series and aged out over time.
  • Projects — deleting a project removes its pods, volumes, domains, journal and routing. Deleting your account removes your personal data; ledger entries needed for accounting may be retained in de-identified form.

7. Your rights & your data, portable

You can access nearly everything the platform holds about a project directly in the product or over the API — including a one-click journal export (SQLite or JSONL) containing your full audit history and stored logs. You may request access, correction, export or deletion of your personal data at any time; depending on where you live (e.g. under GDPR or similar laws) these are legal rights, and we honour them regardless.

8. Changes & contact

If this policy changes materially we'll note it here with a new "last updated" date and, for significant changes, notify account holders. Questions or requests: privacy@z3.run.