Frequently Asked Questions

Most pilot customers reach their first running job in about 15 minutes. You install a small agent on each PC — a Windows MSI, macOS .pkg, or pushed via Group Policy, Intune, or Jamf — and the device registers itself with your Zyra organization automatically. No reboot is required. A Linux server agent is available; mobile is planned for Phase 2.

In normal use, no. The agent caps CPU and RAM usage (administrator-configurable, default around 50% of available cores) and automatically pauses workloads the moment interactive use is detected (keyboard, mouse, foreground application). Admins can also restrict Zyra to after-hours only. Compute Node operators can opt out of any individual job from the tray icon.

Yes. Every Compute Node has a "pause" button in the system-tray agent that immediately drains in-flight tasks to other nodes. Administrators decide whether opt-out is permanent, time-boxed, or one-shot. Compute Nodes that are paused remain registered but do not receive new work; they resume on the user's signal.

Yes. Each device has a schedule policy you control — always available, business hours only, after hours only, weekends only, or a custom cron schedule. Policies apply per device or per device group. Users can also pause their device manually from the agent tray icon at any time.

The agent checks for updates on every heartbeat (every 30 seconds) and applies them during idle windows so users are not interrupted. Enterprise customers can pin a specific version and stage updates through canary, beta, and stable channels. All update bundles are signed and verified against a pinned public key before install.

Devices over your plan limit register as "pending capacity" and do not execute jobs until you upgrade the plan or remove other devices. We never auto-bill for overages without your written consent. You can preview the next-tier cost in the admin billing page before deciding to upgrade.

Yes. Upgrades take effect immediately and are prorated for the rest of the billing period. Downgrades take effect at the start of the next billing cycle so you keep the capacity you already paid for. There are no penalties or migration fees for switching plans in either direction.

Yes, for NVIDIA GPUs with CUDA 11+ on Linux and Windows hosts. The scheduler detects GPU capability automatically and routes GPU-tagged jobs to capable nodes. AMD ROCm and Apple Metal support are on the roadmap. GPU compute is billed at a separate per-device-hour rate, detailed in your contract.

Zyra targets batch and asynchronous workloads — CI/CD, data processing, model training, simulation, rendering. We do not market sub-millisecond latency. Typical job-start latency is a few seconds, and node-to-node communication depends on your own network. Hard-realtime or trading-grade workloads should stay on dedicated infrastructure.

Workload inputs and outputs live in object storage (MinIO/S3) that you control, hosted in the region you select. Zyra's control-plane metadata is hosted on Hetzner in Germany and Finland, with strict B2B residency pinning to eu, us, apac, me, af, or sa. Container execution itself happens on your own Compute Nodes.

An administrator removes the device from the dashboard, which immediately revokes its credentials, drains in-flight tasks to other nodes, and purges cached task data on the next agent heartbeat. The PC's local files are never touched — Zyra only manages its own container state, not the user's documents.

No. Tenants are logically isolated at the database, object-storage, and scheduler layers. A Compute Node only ever receives jobs belonging to its own organization. Cross-tenant scheduling is rejected at the policy layer; we publish penetration-test summaries on /security.html as they are completed.

Containers run with no-new-privileges, all Linux capabilities dropped, read-only root filesystem, no host network, strict CPU/RAM/PID quotas, and execution as a non-root user. Image pulls are restricted to allow-listed registries. A compromised workload cannot escape the sandbox or pivot to the host system.

Yes. Every privileged action — Virtual Server deploys, device adds and removes, role changes, API-key usage — is recorded in an append-only audit log retained for two years on Professional and Enterprise tiers. Logs are exportable as JSON or streamed in real time to your SIEM via webhook.

Yes, by an internal continuous security review process. We publish self-attestations for PCI SAQ A (89%), OWASP ASVS Level 1 (91%), and NIST CSF 2.0 (tier 2.7) on /security.html. An independent third-party penetration test is scheduled as part of the SOC 2 Type II audit window, with a target completion of Q4 2026.

Workload inputs and outputs are retained according to your object-storage configuration; Zyra defaults to 30 days for task artifacts. Admin audit logs: 2 years. Billing records: 7 years (statutory). Account data: deleted 30 days after closure. The full retention table is published in Privacy Policy §7.

Yes. We offer a standard GDPR-compliant DPA with EU Standard Contractual Clauses (2021/914) and the UK IDTA for international transfers, available on request for any paid plan. Custom DPAs and security questionnaires are reviewed by our Privacy team within five business days. Email privacy@getzyra.io to start.

A short, disclosed list: Hetzner (EU hosting), Stripe (payments), AWS SES (transactional email), Cloudflare (edge and DDoS), and Plausible (privacy-friendly analytics, no cookies). We do not sell personal information, do not run third-party ad networks, and do not use workload contents for AI training, benchmarking, or marketing. Full list and DPAs in Privacy Policy §5.

Each Virtual Server has a managed object-storage bucket mounted at /input (read-only) and /output (write-only). You upload inputs via the dashboard, CLI, or any S3-compatible API; results land in /output and stream back to the same store. Direct registry pulls and HTTPS callouts can be enabled per Virtual Server when needed.

By default, no. Containers run with --network=none so workloads cannot exfiltrate data or pull arbitrary code at runtime. Outbound access can be granted per Virtual Server with an allow-list of destinations and ports. All allowed traffic is logged in the audit trail and visible in the dashboard.

Yes — through an outbound allow-list scoped per Virtual Server. Typical setups whitelist an internal artifact registry, a database host, or an internal API. We do not require an inbound tunnel into your network; Compute Nodes initiate all connections outbound, which keeps your firewall posture simple.

Most standard Linux Docker images run without modification, including Python, Node.js, Java, .NET, Go, Rust, R, and Julia workloads. Windows containers are on the roadmap. Containers run with no network access by default; outbound access is enabled per Virtual Server. Maximum image size and concurrent containers are governed by your plan.

Yes — all three. The REST API at api.getzyra.io covers every action available in the dashboard. The CLI ships as a single binary for Windows, macOS, and Linux and uses the same API. Official SDKs are available for Python and TypeScript, with Go on the roadmap. OpenAPI specs are published for any other language.

We publish example workflows for GitHub Actions, GitLab CI, CircleCI, and Jenkins. A typical pattern: your CI job pushes the build container to your registry, calls the Zyra CLI to deploy a Virtual Server with that image, waits for completion, and pulls results from object storage. End-to-end pipeline examples are linked from /docs.html.

Yes. SAML 2.0 and OIDC are available on Professional and Enterprise tiers, with tested integrations for Okta, Azure AD/Entra, Google Workspace, and JumpCloud. SCIM 2.0 user provisioning is on the roadmap; multi-factor authentication is enforceable per role today. Setup typically takes under an hour with your IdP admin.

Once a Virtual Server is deployed, the scheduler picks an available Compute Node within seconds, and the container starts as soon as the image is pulled. Cold-start (uncached image) typically takes 20-60 seconds depending on image size; cached images start in 1-3 seconds. Job-throughput depends entirely on your fleet size.

The Professional tier targets 99.5% control-plane uptime; the Enterprise tier targets 99.9% with service credits if missed (exact terms vary by contract). Jobs already running on your Compute Nodes continue executing during a control-plane outage; only new scheduling pauses. Live status is published at status.getzyra.io.

Yes. All workload artifacts live in your own object storage and remain yours unconditionally. Account metadata (devices, jobs, audit logs, billing) can be exported as JSON or CSV from the dashboard at any time, and we provide a full final export at account closure. There is no exit fee and no lock-in.

We follow a documented incident-response runbook: detect, contain, eradicate, recover, post-mortem. Customers affected by a confirmed personal-data breach are notified within 72 hours per GDPR Art. 33, and our supervisory authority is notified in the same window. Post-mortems are published on the status page within 14 days of resolution.