Legal
Privacy Policy
This policy explains what Rustbox collects, why it is needed for a sandbox execution platform, how it is retained, and how you can request access, correction, deletion, or export.
Submitted code
Processed to run jobs and return results
Training use
Not used to train AI models
Advertising
No sale of personal data or ad pixels
Plain-language summary
Rustbox needs submitted code and execution metadata to run jobs. We use that data to operate the service, secure the platform, enforce quotas, provide support, and investigate abuse. Avoid sending secrets or regulated data unless you have a separate agreement that permits it.
On this page
1. Scope and controller
This Privacy Policy explains how Orkait collects, uses, stores, shares, and protects information when you use Rustbox, including the website, documentation, playground, dashboard, API, SDKs, OAuth sign-in, beta access forms, and webhook features.
Rustbox is a developer service for executing code in isolated runtime profiles. Because submitted code and execution metadata can contain sensitive information, you should avoid sending secrets, production credentials, regulated data, or confidential third-party data unless you have a written agreement that permits it.
For privacy questions, deletion requests, or account support, contact [email protected].
2. Information we collect
We collect information you provide directly, information generated when you use the service, information created by sandbox executions, and limited technical metadata needed to operate and protect the service.
The table below describes the main categories. Actual data collected depends on whether you browse the website, sign in, request beta access, use the playground, call the API, create projects, configure webhooks, or contact support.
Account and identity data
Examples
Name, email address, OAuth provider, provider account identifier, avatar URL, session state, and organization or project information you provide.
Purpose
Authentication, account management, support, abuse prevention, and access control.
Retention
For the life of the account, then deleted or archived when no longer needed for legal, security, or operational reasons.
Submission payloads
Examples
Code, language, stdin, execution options, files, request body, and other inputs sent to the playground or API.
Purpose
Sandbox execution, verdict generation, debugging failed jobs, support, and abuse investigation.
Retention
Kept only as long as needed to operate the service, support users, enforce quotas, and investigate abuse. Beta defaults may use a 30-day evidence window unless a plan or agreement says otherwise.
Execution and evidence data
Examples
Verdict, stdout, stderr, exit status, wall time, memory usage, seccomp events, runtime profile, queue timing, language, project, and webhook delivery metadata.
Purpose
Returning results, proving isolation behavior, troubleshooting, quota reconciliation, performance analysis, and security monitoring.
Retention
Typically retained for operational windows such as 30 days during beta, then deleted, aggregated, or de-identified when practical.
API key, project, and webhook data
Examples
API key labels, key creation and revocation timestamps, project names, webhook URLs, signing secret state, delivery attempts, and error status.
Purpose
API access, dashboard management, webhooks, security controls, rate limiting, and support.
Retention
For the life of the key, project, or webhook configuration, plus any audit or security retention period required to protect the service.
Request and device metadata
Examples
IP address, user agent, URL path, timestamp, referrer, approximate region, error logs, rate-limit counters, and security telemetry.
Purpose
Security, fraud prevention, abuse detection, incident response, reliability, diagnostics, and capacity planning.
Retention
Usually short-lived and rotated out when no longer needed. Security logs may be retained longer if they relate to abuse, incidents, or legal obligations.
Preferences and local state
Examples
Playground preferences, dashboard UI state, sidebar state cookies, local storage values, and similar client-side settings.
Purpose
Remembering interface choices and reducing repeated setup work.
Retention
Stored in your browser until cleared by you, expired by the browser, or replaced by the application.
Account and identity data
Name, email address, OAuth provider, provider account identifier, avatar URL, session state, and organization or project information you provide.
Authentication, account management, support, abuse prevention, and access control.
For the life of the account, then deleted or archived when no longer needed for legal, security, or operational reasons.
Submission payloads
Code, language, stdin, execution options, files, request body, and other inputs sent to the playground or API.
Sandbox execution, verdict generation, debugging failed jobs, support, and abuse investigation.
Kept only as long as needed to operate the service, support users, enforce quotas, and investigate abuse. Beta defaults may use a 30-day evidence window unless a plan or agreement says otherwise.
Execution and evidence data
Verdict, stdout, stderr, exit status, wall time, memory usage, seccomp events, runtime profile, queue timing, language, project, and webhook delivery metadata.
Returning results, proving isolation behavior, troubleshooting, quota reconciliation, performance analysis, and security monitoring.
Typically retained for operational windows such as 30 days during beta, then deleted, aggregated, or de-identified when practical.
API key, project, and webhook data
API key labels, key creation and revocation timestamps, project names, webhook URLs, signing secret state, delivery attempts, and error status.
API access, dashboard management, webhooks, security controls, rate limiting, and support.
For the life of the key, project, or webhook configuration, plus any audit or security retention period required to protect the service.
Request and device metadata
IP address, user agent, URL path, timestamp, referrer, approximate region, error logs, rate-limit counters, and security telemetry.
Security, fraud prevention, abuse detection, incident response, reliability, diagnostics, and capacity planning.
Usually short-lived and rotated out when no longer needed. Security logs may be retained longer if they relate to abuse, incidents, or legal obligations.
Preferences and local state
Playground preferences, dashboard UI state, sidebar state cookies, local storage values, and similar client-side settings.
Remembering interface choices and reducing repeated setup work.
Stored in your browser until cleared by you, expired by the browser, or replaced by the application.
3. Sources of information
We receive information from you when you create an account, sign in, request access, submit jobs, configure projects, create API keys, send support messages, or configure webhooks.
We receive information from OAuth providers such as GitHub or Google when you choose to authenticate with them, subject to their own terms and privacy policies.
We automatically generate execution data, request metadata, rate-limit events, security logs, and operational metrics when the website, dashboard, API, or runtime infrastructure is used.
4. How we use information
We use information to authenticate users, run sandbox jobs, return verdicts, deliver webhooks, enforce rate limits, allocate queues, manage projects, provide support, detect abuse, secure infrastructure, debug failures, improve reliability, and communicate service changes.
We may use aggregated or de-identified operational metrics to understand performance, capacity, product usage, language popularity, queue behavior, and infrastructure reliability.
We do not use submitted code, stdin, outputs, or execution payloads to train AI models. We do not sell personal information. We do not share personal information with advertisers.
5. Legal bases where applicable
Where privacy law requires a legal basis, we process information to perform a contract with you, operate the service at your request, pursue legitimate interests such as security and abuse prevention, comply with legal obligations, or act with your consent where consent is required.
You may withdraw consent where processing is based on consent, but withdrawal may not affect processing that already occurred or processing needed for security, legal obligations, or contract performance.
7. Retention and deletion
We retain information only as long as reasonably needed for the purposes described in this policy, including account operation, execution history, quotas, support, security, abuse investigation, legal obligations, and audit needs.
Beta retention periods may change as the product matures. When deletion is requested, we delete or de-identify eligible data unless retention is needed for security, fraud prevention, dispute resolution, legal compliance, backup restoration, or legitimate operational reasons.
Backups and logs may take additional time to expire from all systems. We do not promise that data can be removed instantly from immutable backups or incident archives.
8. Security
Rustbox uses technical and organizational safeguards designed for a developer runtime service, including sandbox isolation, credential controls, rate limiting, logging, access restrictions, and operational monitoring.
No online service can guarantee perfect security. You are responsible for protecting API keys, secrets, OAuth sessions, webhook signing secrets, client-side storage, and any data you submit to the service.
If you believe an account, API key, webhook secret, or submission has been compromised, contact support and rotate affected credentials as soon as possible.
10. Your choices and rights
Depending on your location, you may have rights to access, correct, delete, export, restrict, or object to processing of personal information. You may also have the right to appeal or lodge a complaint with a regulator.
You can revoke API keys, remove webhook endpoints, clear local browser storage, stop using the service, or request account deletion. Some operational records may remain where needed for security, legal, or abuse-prevention reasons.
To exercise a privacy right, email [email protected] from the address associated with your account. We may need to verify your identity before completing the request.
11. Children and student data
Rustbox is intended for developers, organizations, educators, and technical users. It is not directed to children under 13, and we do not knowingly collect personal information from children under 13.
If you use Rustbox in an educational setting, you are responsible for obtaining any required notices, permissions, school approvals, or agreements before submitting student data or student code.
12. International processing
Rustbox may process information in countries where Orkait, hosting providers, infrastructure vendors, or service providers operate. Those countries may have different privacy laws than your location.
Where required, Orkait will use appropriate safeguards for cross-border transfers, such as contractual protections or other recognized transfer mechanisms.
13. Changes to this policy
We may update this Privacy Policy as Rustbox changes, data practices change, legal requirements evolve, or new product features are added.
The last-updated date identifies the current version. Continued use of Rustbox after an update means the updated policy applies to future use.
Last updated: May 12, 2026