Last updated Nov 9, 2026

Effective Nov 9, 2026

Privacy Policy

Clusy runs your code and sends your work to AI models to answer you, so being vague about data would not be much use to you. This policy says what we collect, who receives it, which countries it goes to, how long we keep it, and what you can ask us to do about it.

1.The short version

This summary is not a substitute for the rest of the policy, but these are the things people most want to know.

We do not sell or share your personal data, and we do not use third party advertising networks or advertising pixels.
We do not train AI models on your content. We run no training, fine tuning or distillation pipeline on customer notebooks, prompts, chat or outputs. Section 6 explains what the AI companies we send content to may do with it, which is a separate question.
Your prompts and notebook content are sent to third party AI companies to generate a response, including companies in mainland China and Singapore. Which one depends on the model you pick. Section 6 names every one of them.
Your code runs on third party infrastructure, E2B for CPU and Modal for GPU.
Portal, our second product, runs your Python jobs on machines in cloud accounts you connect, and holds the credentials for those accounts. A Portal account is separate from a Clusy notebook account. Portal has no way yet to delete your account yourself, so email us to delete it. Section 3 says what Portal keeps.
Automated systems scan code before it runs in the Clusy notebook and produce security alerts. Section 7 explains what that means and what we record.
Anything you publish is public, and Hub listings are submitted to search engines and open to AI crawlers. Section 13.
You can access, export, correct and delete your data, and you can object to processing. Section 14.

2.Who we are, and our role

This policy explains how Clusy Inc. handles personal data. Clusy Inc. is a Delaware corporation with its registered address at 2093 Philadelphia Pike, Suite #3740, Claymont, DE 19703, United States. For privacy questions and to exercise your rights, contact privacy@clusy.io.

We act in two different roles, and it matters which one applies:

We are the controller: for your account and profile, billing and usage records, product analytics and service telemetry, security and abuse records, support tickets, marketing and attribution data, and meeting bookings. In Portal, this includes your Portal account and sign in records, the credentials for the cloud accounts you connect and the secrets you store, the descriptions of the machines that run your jobs, cost estimates and the audit log. We decide why and how that data is processed, and this policy is your notice for it.
We act for you: for the content you put into the product: your notebooks, cells, code, uploaded files, prompts, chat, execution outputs and sandbox files, and in Portal the working directories you upload, your jobs’ scripts, arguments and environment variables, and their output streams, checkpoints and outputs. You decide what goes in. If you put other people’s personal data into Clusy, you are the controller of it and we process it on your instructions. We keep two exceptions for our own purposes, and we state them openly: security and abuse prevention (section 7), and operating and maintaining the service.

If you are a business customer and need a written data processing agreement covering the second role, email privacy@clusy.io.

This policy covers the Clusy web application, the clusy.io website, our documentation and blog, the meeting booking flow at clusy.io/meet, and our support and marketing communications. It also covers Portal: its landing pages, sign in, console and documentation at portal.clusy.io; gateway.clusy.io, which its command line tool and coding tools talk to; the portal command line tool and MCP server; and the agent you can install on your own computer to run jobs.

Since November 8, 2026 a Portal account is separate from a Clusy notebook account, and this policy covers both. Where it says “your account” without naming Portal, it means your Clusy notebook account.

3.What we collect

Account and profile

Your email address, and your display name and avatar if you sign in with Google or GitHub or if you set them. Optionally, a headline, a short bio, and website, GitHub and LinkedIn links, which are public if you fill them in. Your plan and onboarding status. Preferences you set, including custom instructions you write for the agent, your theme and interface settings, your default model and runtime choices, your email and notification preferences, and what you told us you signed up to do. We do not ask for your employer, job title or company at signup.

Content you create in the product

Notebook cells, including code and text. Files you upload and files created inside your sandbox. Your chat with the agent, including your prompts, the agent’s replies, tool calls and their results, and the model’s intermediate reasoning. Execution records, including error messages and Python tracebacks from your own code, and execution outputs, including images, tables and charts. Notes the agent extracts and keeps as project memory, stored with a numeric embedding so it can be recalled. Research results, including the question asked and quotations from the sources retrieved.

Credentials we hold for you

Access and refresh tokens for accounts you connect, your own model provider API keys if you use bring your own key, and any headers or environment values you configure for an MCP server. Clusy API keys you create are stored only as a hash, so we cannot recover the key itself. Section 12 explains how these are protected.

Billing

Your Stripe customer and subscription identifiers, your plan and its history, invoices, and metered usage records. We never receive or store your card number. Card details go directly to Stripe.

Device, usage and logs

Product analytics events about what you do in the app, request and access logs from our servers, your IP address, a coarse city and country derived from it, your browser and device type, language and timezone. Application error reports, which include an error message, a stack trace and the identifiers of the account, project and session involved.

Security and abuse records

Signals produced by the automated checks described in section 7, including categorised detection labels and irreversible hashes of the code that triggered them, records of suspensions and appeals, and hashes of IP addresses used to detect linked accounts.

Marketing and attribution

If you arrive from a campaign link, the referring URL, landing page and campaign parameters, held against your account after you sign up. An advertising click identifier from the link you arrived on is stored in a first party cookie and in your browser, but is not sent to your account record. Clicks on our short links are logged without an account identifier, with a hashed IP and a coarse country.

Meeting bookings and support

If you book a meeting with us: your name, email, timezone, any notes you write, and the email addresses of guests you add. If you contact support: your message, your email, and basic diagnostics about the page you were on. If you use the contact form on our website: your name, email, team or company and your message. If you use the Ask feature on our documentation site, your question and the last few turns of that conversation are sent to an AI model to generate an answer, and we do not store the text of your questions.

Your Portal account and sign in

Portal, our second product, has had its own accounts since November 8, 2026, separate from Clusy notebook accounts. You sign in to Portal with a six digit code sent to your email address, or with Google or GitHub. There is no password.

Portal’s account store keeps your email address, whether you have confirmed it, and when you signed up and last signed in. If you sign in with Google, it also keeps the name, profile picture address and account identifier Google gives it. If you sign in with GitHub, it keeps your GitHub username and user identifier, your profile picture address, and your name if your profile has one. It records the IP address and browser of each sign in. Asking for a code creates an account record at once, before you enter the code.

Portal’s own record of you holds an account identifier, your email address and whether it is verified, a display name if Google or GitHub gives one (for GitHub, your username if your profile has no name), your account status, and when you first and last signed in. It holds no IP address and no picture. Your first sign in creates a personal workspace, named after your email address, with you as its Owner.

If you used Portal before November 8, 2026, you signed in to it with your Clusy account. When Portal began signing people in itself, we copied your sign in details from the Clusy notebook’s account store into Portal’s, keeping the same identifier: your email address, when it was confirmed, when the account was created and last used to sign in, the profile details Google or GitHub had given (such as your name and picture address), and your email, Google and GitHub sign in links. No password or second factor was copied. Your Clusy notebook account was not changed and remains a separate account.

When you sign in from the portal command line tool or from a coding tool, Portal stores the name of the tool and your computer’s host name with the access you approve, and stores the access itself only as a hash. Each such sign in, whether back through your browser or with a device code, also records the IP address it came from, in a record deleted within about 25 minutes of the sign in starting.

Your Portal jobs and machines

For your work, Portal keeps:

the credentials for the cloud accounts you connect and the secrets you store for jobs, sealed as section 12 describes, with the names of secrets readable;
records of each job: its name, project, script path, arguments and any environment variables you pass, which are stored readably, its requirements, settings and budget, its status, cost estimate and savings, and, if it fails, the error your program ended with, including its message, up to 500 characters, and where in your code it exited;
each job’s events, and samples of its CPU, memory and GPU use and its progress;
a description of each machine that runs a job: its host name, operating system, processors, memory, GPUs, free disk, Python version and installed Python packages, and its provider, machine type, region and zone;
each job’s output stream, which is everything the job prints, up to its first 256 MiB;
checkpoints of running jobs, which hold the program’s memory and working files, so anything your program has read into memory, including a secret, can be inside one;
the working directory you upload with a job, leaving out version control folders, environments, caches, ignored files, files whose names suggest credentials, JSON files that hold a private key and files over 100 MB, and the job’s outputs, which are its working directory saved when it finishes, fails or is stopped while running;
a cost ledger of every cloud resource Portal creates for you;
what Portal reads from your cloud accounts: prices, machine types and quota limits, and for AWS the daily cost of the resources Portal started, from your Cost Explorer; and
an audit log of every change in your workspace, every sign in and every approval, with the IP address it came from.

If you enrol one of your own computers to run jobs, Portal keeps its host name, a hashed form of its machine identifier, its operating system, architecture and hardware, its GPUs and drivers, its free disk and Python version, the user name and number its jobs run as, whether that user can act as an administrator without a password and which administrator groups it belongs to, the versions of its tools and, optionally, its SSH host key fingerprint. It keeps these after you remove the computer.

Feedback you send from the Portal console carries its type, subject and message, the page you were on, your verified email address (or, without one, your account identifier), your workspace’s identifier and the Portal version, and a contact address if you choose to give one. It goes to Clusy’s own feedback inbox, not into Portal.

Portal also records product analytics, described in section 15, and its server and load balancer keep logs that include IP addresses, described in section 10.

Where it comes from

Mostly from you and from your device. Some comes from your connected accounts at your direction, some from Stripe about your payments, and some from other people: someone who adds you as a guest to a meeting gives us your email address, and a person who shares a project with you creates a record involving you.

For Portal, some comes from Google or GitHub if you sign in with them, from the cloud accounts you connect, which Portal reads to quote prices, check quotas and check its cost estimates, from the machines that run your jobs, and, for people who used Portal before November 8, 2026, from the Clusy notebook’s account store.

4.Sensitive data, and what not to upload

We do not ask you for sensitive personal data, and we have no interest in receiving it. But Clusy is a research tool with a filesystem and an upload button, so what ends up in your notebooks, or in the jobs you run through Portal, is your decision, and we will not pretend otherwise.

Do not upload special category data such as health, genetic, biometric, racial or ethnic origin, political, religious or sexual orientation data; protected health information under HIPAA; payment card data; or export controlled technical data, unless we have signed a separate written agreement covering it. We do not currently sign HIPAA business associate agreements. This is a term of the Terms of Use as well as a request.

Sensitive data we do hold as controller: credentials that grant access to your other accounts. That is the access and refresh tokens for services you connect, your own model provider API keys, and in Portal the credentials for the cloud accounts you connect and the secrets you store for jobs. We use them only to authenticate you and to call those services at your direction, to secure the service and to prevent fraud. In Portal, calling those services includes starting, watching, moving, suspending and stopping your jobs under your workspace’s settings, reading prices and quotas, and checking our cost estimates against your AWS costs. We do not use them for any other purpose and we do not sell or share them, so no separate opt out is required for them under California law.

Besides the service you connected, such a credential goes to only these places. Some publishing operations pass a token into your own sandbox so the upload can run there. Portal uses your cloud credentials only inside Portal’s server and does not give them to the machines it starts, with one exception: for an Azure Container Apps job, Portal stores a registry credential as a secret of that job in your own Azure subscription, and with the client secret method that credential is your connection’s client secret. A secret you name in a Portal job is given to that job’s machine as an environment variable, and once your program has read it, it can be inside the job’s checkpoints.

We also hold records relating to suspected breaches of our terms, including suspension and ban records. Section 7 explains how those are used.

5.Why we use it, and our legal basis

If you are in the EEA, the UK or Switzerland, the right hand column is our legal basis under the GDPR. These apply to you because we offer services to people in those places, not only where some other law requires it.

Running the product: Providing accounts, projects, notebooks, the agent and the app. Necessary to perform our contract with you.
Executing your code: Provisioning and running cloud sandboxes. Necessary to perform our contract.
Running Portal: Providing Portal accounts and workspaces, signing you in and emailing your sign in and verification codes, and starting, watching, moving, checkpointing, suspending and stopping your jobs on machines in the cloud accounts you connect or on computers you enrol, including reading prices, quotas and, for AWS, cost totals from those accounts, and keeping the cost estimates, caps and budgets you rely on. Necessary to perform our contract with you.
Moving existing Portal accounts: When Portal began signing people in itself on November 8, 2026, copying the sign in details of the people who already used Portal from the Clusy notebook’s account store into Portal’s, so that they kept the same Portal account. Our legitimate interest in continuing the service those people had chosen to use.
Sending content to AI providers: Transmitting prompts and notebook context to a model provider so it can generate a response. Necessary to perform our contract. This is not based on consent, and it is not optional if you use the agent.
Billing and metering: Subscriptions, invoices, usage metering, dunning and credits. Necessary to perform our contract, and to comply with tax and accounting obligations.
Security and abuse prevention: Detecting and acting on cryptomining, proxy and tunnelling abuse, malware infrastructure, scanning and other misuse of compute. For Portal, also checking email sign in requests with Cloudflare Turnstile, recording sign ins, approvals and changes in an audit log with the IP address they came from, checking account status, and ending the access of an account we suspend. Our legitimate interest in protecting other users, third parties on the internet, our providers and our business from real and recurring abuse, and in some cases compliance with law.
Service reliability: Logs, error reports, tracing and capacity work, including Portal’s server and load balancer logs. Our legitimate interest in keeping the service working and diagnosing faults.
Product analytics: Understanding which features are used so we can improve them. Our legitimate interest in improving the product. On our website and the Portal landing pages, the analytics behind the cookie banner run only with your consent. The Portal console records analytics on our legitimate interest, including before you sign in, and keeps a device identifier in your browser’s storage without asking for consent first; section 15 says what it stores and sends.
Support: Answering your questions and fixing your problems, including feedback you send from the Portal console. Necessary to perform our contract.
Meeting bookings: Scheduling, confirming, reminding and cancelling. Necessary to take steps at your request before a contract, and our legitimate interest in arranging requested meetings.
Marketing: Product updates and announcements, including emails about Portal sent to Clusy notebook accounts. Your consent, or our legitimate interest in telling existing customers about our own similar services, with an unsubscribe link in every message.
Legal compliance: Responding to lawful requests, keeping required records, enforcing our terms and establishing or defending legal claims. Compliance with a legal obligation, and our legitimate interest in establishing and defending claims.

Where we rely on legitimate interests, we have weighed them against your rights and you can ask us for the reasoning at privacy@clusy.io. You can object: see section 14.

6.AI processing and model providers

This is the section most people should read. To answer you, the agent sends your material to a third party AI company. The model you select decides which company handles your chat turn, but it does not decide every request. Two things also route independently of your choice:

Background work. Session and notebook titles and tags are generated by Anthropic Claude on AWS Bedrock, project memory embeddings are generated on AWS Bedrock, and inline code completion goes to DeepSeek. These run whatever model you have selected.
Fallback. If the provider for your selected model fails part way through a turn, we retry that turn on DeepSeek so your work is not lost. That means content you selected a different model for can reach DeepSeek, in mainland China, without you choosing it. If that is not acceptable for your work, tell us at privacy@clusy.io. Separately, if the safety filter on Claude Opus 5, Claude Opus 5.5 or Claude Fable 5.1 declines a request, we retry that one turn on Claude Opus 4.8 at the same provider; no new company receives your content in that case.

What is sent

Your prompt and the conversation history. Notebook context, including cell code and text. The contents of files the agent reads, and excerpts of files in your project. Tool call arguments and results. Execution output and error traces. Images, but only when you have selected a model that supports vision. The system prompt also includes your timezone, an approximate city and country, your display name, your profile headline and what you told us you signed up to do.

It also includes your IP address. Where your browser connection has a public IP address, we include it in plain text in the system prompt, alongside the approximate location derived from it, so the agent can answer questions about what is local to you. We also send your IP address to ipapi.co, a geolocation service, to derive that location. If you would prefer this not to happen, tell us at privacy@clusy.io.

Who receives it

The first six entries below are the model providers that receive your content through our own provider accounts. The rest are services the agent calls while working on your behalf: they are not model providers, but they receive your content or your IP address, so they belong in the same list. It is current as of the date at the top of this page and changes when we add or retire a model or a tool.

Amazon Web Services: Amazon Bedrock. Serves the Anthropic Claude models we offer, generates session and notebook titles and tags, and produces the embeddings used for project memory. We call it through US cross-region inference profiles, so the inference itself may run in any United States AWS region. One model is treated differently: Claude Fable 5.1 is offered by AWS only on the condition that AWS may retain the prompts and outputs sent to it for up to 30 days and review them, inside AWS, for misuse. That retention applies to every hosted Fable 5.1 request, it is not shared with Anthropic, and it does not apply to the other Claude models we offer on Bedrock. If you would rather your content never be held that way, do not select Fable 5.1, or use it through your own Anthropic key.
Microsoft: Azure AI Foundry (Azure OpenAI). Serves the GPT models we offer. The account resources are in the Azure East US 2 and West US 3 regions, but the deployments use a global standard capacity type, so requests may be served from Microsoft data centres in other regions.
DeepSeek: api.deepseek.com, in mainland China. Serves the DeepSeek models, including the Auto option that accounts use unless you pick a different model, and inline code completion.
Moonshot AI: Serves Kimi models, on endpoints in mainland China and on its global platform.
Alibaba Cloud: Model Studio, through the Singapore (ap-southeast-1) gateway. Serves the Qwen model.
Cloudflare: Workers AI. Hosts models built by other companies, currently a Kimi model from Moonshot AI and GLM 5.2 from Z.ai, on Cloudflare’s own infrastructure.
ipapi.co: Receives your IP address to return a coarse location, as described above.
Exa and Firecrawl: Web search and page extraction. When the agent searches the web or reads a page for you, these services receive the search query or the URL the agent is working with, and return results into your session.
Our own crawler service: A Clusy operated service, hosted on Microsoft Azure Container Apps in the East US 2 region, that fetches and extracts web pages the agent asks for. It stores nothing beyond a short lived cache.

Bring your own key. If you connect your own Anthropic or OpenAI API key, your content goes to that company on your own account and under your own agreement with them. Their retention, human review and training practices apply, and our commitments here do not extend to them. We send the key to the provider once when you add it, to check that it works. We store it encrypted, decrypt it only to make calls on your behalf, and cache it in memory on the agent so background work in the same session can use it. When you remove the key we delete the stored copy, and a cached copy can persist for up to about a day before it expires.

Portal and your coding tools

Portal itself sends nothing to an AI model provider. If you use Portal from a coding tool, such as Claude Code or Codex, whatever that tool reads from Portal, including job details, output streams and the cloud account identities that Portal’s detection step finds on your computer, goes to that tool’s AI provider under your own agreement with it, not through us. A job’s output stream holds whatever your program prints.

Training

Clusy does not train, fine tune or distil models on your content. No pipeline in our systems exports customer notebooks, prompts, chat or outputs into a training or annotation dataset. Our evaluation suites run on synthetic prompts and public benchmarks.
What each provider may do is set by our contract with that provider, and it is not the same everywhere. We do not currently send a no training or zero retention instruction to every provider on every request, and we are not going to claim otherwise. If this matters to your work, use bring your own key with a provider whose terms you control, or ask us at privacy@clusy.io which route a specific model takes.
Published content is different. Anything you publish is public and may be collected by anyone, including AI crawlers. See section 13.

Who at Clusy can read your work

There is no screen in our product that shows staff your notebook cells, chat messages or execution outputs. Staff with database access can technically read stored data, and do so only to investigate abuse, to investigate a fault, or where you ask us to look at something in support. Administrators can see session titles, which are generated from your content, and the text of any appeal or support ticket you submit. Staff actions in our admin tools are logged.

In Portal, people Clusy authorises as Portal operators can open an admin page with platform wide totals and the latest jobs by identifier, workspace identifier, status, exit code, times and cost, and, for a job that failed, where its program exited (file, line and function), the type of error and any child program that failed. It never shows their output streams, the contents of their code or workspace names. People who administer Portal’s AWS account can technically read whatever Portal’s server can read. They can run commands against Portal’s records that list people with their email addresses, read any workspace’s audit log with its IP addresses, export a workspace’s records, add a person to any workspace in any role, including Owner, from their next sign in, approve a computer waiting to join a workspace without its pairing code, freeze a workspace, end and restore a person’s access, and create an agent token for a workspace lasting up to 30 days, which is recorded as approved by that workspace’s first active Owner without any action from them and appears in the workspace’s list of agents, where the Owner can revoke it. Each such command writes an entry to the audit log, and the command itself is logged. They can also open a shell inside Portal’s running server, which holds decrypted credentials in memory while they are in use; those sessions are logged too.

7.Automated checks, suspension and appeals

We have had real abuse to deal with, including sandboxes used as network proxies and accounts used to run malware infrastructure. So we monitor, and you should know how.

What runs, and on what

Your chat messages, and the inputs to tools the agent runs, are checked against a fixed set of pattern rules. The rules look for a small, closed list of categories: cryptomining, proxy and tunnelling setups, attempts to break out of the sandbox, reading credentials, moving credentials off the machine, and scanning or denial of service tooling. Separately, we monitor account, authentication and usage signals, and we record execution activity.

Sandbox network traffic is barely restricted. On CPU sandboxes we block inbound public traffic and deny outbound connections to a small fixed list of addresses. Everything else on the internet stays reachable, GPU sandboxes have no outbound restriction, and we do not inspect the contents of what a sandbox sends.

What the check does, and does not, do

The check is alert only, and it runs alongside your work rather than gating it. It cannot block, cancel or alter a turn. Your work proceeds either way and an alert is recorded for review.

What we store is deliberately not your content. A detection record holds a category label, a severity, a fixed confidence value for the rule that fired, the identifiers of the rules that matched, an irreversible hash of the text that triggered it, and a short canned description of the pattern type. That description is chosen from a fixed list we wrote; it is not an excerpt of what you typed. The database additionally rejects any such record containing an email address, an IP address or an identifier. We do not store your raw prompts, code, commands, hostnames or credentials in these records.

Human decisions and automated ones

Suspensions are made by a person. An alert goes to our team, and a human decides whether to act, gives a reason, and is recorded as having done so. Two narrowly scoped automated rules exist that could suspend an account without a person, both aimed at bulk signup abuse, and both are currently switched off. Our automated containment framework runs in a monitoring mode and cannot suspend an account.

Consequences. A restriction can stop a run, limit a sandbox, or remove published content. A suspension blocks access to your account until it is lifted. It does not delete your work. A termination for a serious breach ends the account.

Your rights here

If we suspend your account we tell you the reason. If you want to know whether an automated rule was involved in your case, ask us and we will tell you. You can put your side of it through the appeal form, which is the one thing a suspended account can still reach, and a person reviews every appeal. You can ask us to reconsider, and if we got it wrong we lift it. We do not publish the internal detail of the detection rules, because that would make them trivial to evade, but you will get enough to understand and contest the decision. You keep your right to access and export your own content while suspended.

Portal

The checks above run on the Clusy notebook. Portal does not scan the code of your jobs, and no automated rule suspends a Portal account: a person at Clusy suspends one, either in Portal’s account store or with an operator command. Portal then ends the account’s sessions, its sign ins from tools and its agent tokens, stops the jobs started by the account or its coding tools, and revokes the computers the account enrolled, which cuts them off from Portal without turning them off. Nothing is deleted at that moment, but the stopped jobs’ checkpoints and outputs then expire on the schedules in section 10, and nothing that was ended comes back if the suspension is lifted. A suspended Portal account is told only that it cannot sign in: Portal’s sign in page shows no reason, Portal has no appeal form, and the notebook’s appeal form does not reach it. We will tell you the reason. To contest it, email support@clusy.io from your Portal account’s address, and a person will review your appeal.

Portal does act on your jobs by itself, under settings an Owner can change. By default it moves a running job to a cheaper machine when that saves at least 20% and at least three times the cost of the move, moves a job off a spot machine to an on demand machine, which costs more, when the job’s state is too large to save within the spot notice, suspends a job that has been idle for 30 minutes, checkpoints and suspends a job on a spot notice, on a recoverable out of memory error or 30 minutes before a provider’s fixed time limit, and ends a job once it has run for 72 hours, or once 72 hours have passed since a suspended job was created or last resumed. It never resumes a suspended job by itself.

9.Where your data goes

We are based in the United States and our infrastructure runs mainly in the United States. If you are in the EEA, the UK or Switzerland, using Clusy involves transferring your data outside your country.

United States: Our own infrastructure and most of our providers, including AWS, Supabase, Stripe, PostHog, Vercel, Resend, Cloudflare, Microsoft, Google, GitHub, E2B and Modal. Where a provider participates in the EU-US Data Privacy Framework we rely on it; otherwise we rely on the European Commission’s Standard Contractual Clauses, with the UK Addendum for UK transfers.
Singapore: Alibaba Cloud Model Studio, for the Qwen model. Standard Contractual Clauses.
Portal’s storage: Portal’s server and database, which hold your Portal account, your sealed credentials and your records, are in the United States. Its main storage bucket, which holds the working directories you upload, your jobs’ output streams and their outputs, has a location hint of eastern North America, a preference Cloudflare follows where it can. A job’s checkpoints go to whichever of our stores Portal expects to be fastest for that transfer: our Cloudflare buckets in North America, Europe, Asia Pacific and Oceania, or a store we create in the AWS, Microsoft Azure or Google Cloud region where the job’s machine runs. So a checkpoint can be stored in any of those Cloudflare locations or in any region where your jobs run. These stores are run for us by Cloudflare, AWS, Microsoft and Google under their data processing terms. Where a store is in a country without an adequacy decision, we rely on the Standard Contractual Clauses in those terms, with the UK Addendum for UK transfers.
Where Portal runs your jobs: On machines in your own cloud accounts, in the region of the offer you or your coding tool choose, or on a computer you enrolled. If Portal moves a running job by itself, to a cheaper machine or off a spot machine, the new machine can be in another region or another of your connected clouds that the job’s requirements allow, unless you started the job on one exact machine. Unless a job names a region, Modal may run it in any of its regions. You can keep a job within chosen providers or regions by naming them when you start it, or turn automatic moves off. These machines are in your own accounts, under your agreement with each provider.
Mainland China: DeepSeek and Moonshot AI. There is no adequacy decision for China. We rely on Standard Contractual Clauses. You should understand that the practical protection those clauses give against access by public authorities in China is limited, and that inference requires your content to be processed in readable form, so encryption is not available as an additional safeguard here.
Other regions: Microsoft Azure AI Foundry serves the GPT models on a global capacity type, so requests may be handled in Microsoft data centres outside the regions where the account resources sit.

If you do not want your content processed in China, choose a model served elsewhere. Auto and inline code completion use DeepSeek, so this is a setting you need to change rather than one you need to leave alone. If you need a written commitment that your account will never route to a particular country, contact privacy@clusy.io, because we cannot currently guarantee it through the product alone.

You can ask us for a copy of the safeguards we rely on for any transfer at privacy@clusy.io.

10.How long we keep things

Content you create is kept until you delete it or delete your account, because it is your working material and deleting it for you would be worse than keeping it. Operational records have defined lives. Where we have not set a period we say so rather than implying one. Portal is different: its checkpoints, outputs and uploads have fixed lives, and its records and output streams are kept while your Portal account or workspace exists, as the Portal rows below set out.

Your account and content: Notebooks, cells, files, chat history, execution records and outputs: kept until you delete them or delete your account.
Sub agent activity logs: 30 days, then deleted automatically. These contain generated text, reasoning and tool results.
IP address hashes: Hashes stored against an account or a sandbox session: 30 days from account creation or session start, then erased automatically. A separate hash used to de-duplicate marketing link clicks is kept with the click record and has no automatic expiry.
Web server access logs: Up to 30 days. These contain raw IP addresses. Portal’s are covered in the Portal rows below.
Application logs: Kept on the server that produced them and rotated by size rather than by age, so roughly 125 MB per service before the oldest is discarded. Outside Portal, we do not operate a central log store; Portal’s logs are covered in the Portal rows below.
Error reports: 30 days for individual reports; 180 days for the grouped summary.
Performance traces: 72 hours in the live store. An archive copy is written to our own object storage and we have not yet set an expiry on it. We are fixing that; ask us if you need the current position.
Security and abuse records: Kept while an account is active and afterwards where we need them to prevent a repeat breach or to defend a claim. We have not set an automatic expiry.
Billing and usage records: Kept for as long as tax and accounting law requires, which is generally seven years, and they survive account deletion.
Support tickets and appeals: Kept with the submitter’s email address after account deletion, so we have a record of what was asked and decided. This includes feedback sent from the Portal console.
Meeting bookings: Kept until no longer needed for the meeting, related communications and our business records. There is no automatic deletion; ask us and we will delete yours.
Marketing and attribution: Click records and attribution data are kept while they remain useful for understanding how people find us. There is no automatic deletion.
Cookie consent record: 180 days, after which we ask you again.
Object storage version history: Previous versions of files are retained for 7 days after they are replaced or deleted, then removed automatically.
Portal account and sign in records: Your account in Portal’s account store, including the IP address and browser of each sign in, and Portal’s own records of you, your workspace, your console sessions, the access you approved for tools and the computers you enrolled: kept while your Portal account or workspace exists, with no automatic expiry, including after you stop using Portal. An account record made when you ask for a code is kept even if you never enter the code. A sign in in progress lasts at most 15 minutes, and its record is deleted within about 25 minutes of it starting. So is the record of a sign in from the command line tool or a coding tool, which holds the IP address it came from.
Portal checkpoints: A suspended job’s checkpoint is kept 3 days from the suspension, a period we set and you cannot change. About 18 hours before it expires, Portal marks the job as expiring, but does not email you; then the job ends as expired and its checkpoints are kept 7 more days. Checkpoints of a job that finished or that a person stopped are deleted when it ends, and those of a job that ended any other way are kept 7 days. A checkpoint is deleted as soon as the move or resume that used it succeeds, normally 1 hour after a move that failed, and 1 day after it fails its arrival check.
Portal outputs and uploads: A job’s outputs: 7 days from when they were saved at the job’s end. A working directory you uploaded that no job took: 1 day. A job’s own copy of its working directory: until the job ends. Copies of working files can remain on Portal’s server file system and in its backups.
Portal job records: Job records, with their events, resource samples, machine descriptions, moves and cost estimates, are kept while your workspace exists. Portal keeps only the newest 20,000 events and 20,000 samples of each job. Removing an ended job from your history, in the console, with portal rm or with the delete_jobs tool, hides it and stops it being continued, but does not erase its records, and its cost still counts in your totals.
Portal output streams: Portal sets no expiry on a job’s output stream: it is kept with the job’s records for as long as your workspace exists, unless a storage rule removes it sooner. Removing the job from your history does not delete it.
Portal connections and secrets: Kept until you remove them. Removing one deletes Portal’s copy at once, but it remains in database backups for about 7 days. They are not deleted when your Portal access ends.
Portal cost ledger: A record of every cloud resource Portal created for you and its estimated cost. Kept while your workspace exists, and it can outlast a deletion request where we need it for accounting.
Portal audit log: Portal’s server can add to it but not change or delete it, and it has no automatic expiry. It records who did what and from where, refuses anything shaped like a secret or a token, and is kept as a security record when other data is deleted.
Portal analytics: Kept in PostHog under the retention that applies to Portal’s project there. On request we delete the events recorded under your Portal account identifier.
Portal server logs: Portal’s server writes its logs to Amazon CloudWatch Logs and keeps them 90 days; some lines carry an IP address. Its load balancer logs every request to portal.clusy.io and gateway.clusy.io, with the IP address, the address requested and the browser, and keeps those logs 90 days. Logs of operator commands run against Portal’s records are kept 400 days, logs of shell sessions inside Portal’s server 30 days, and AWS’s record of actions in Portal’s AWS account 90 days.
Portal backups: Portal’s database is backed up daily and about 7 days of backups are kept, so a deleted record, including a removed connection’s sealed credentials, can remain in a backup for about a week. Portal’s server file system, which holds working files such as job directories and staged uploads, is backed up daily and each backup is kept 35 days.

11.Deleting your account

You can delete your account yourself, in Settings under Account. You will be asked to confirm by typing DELETE. It is not reversible, so export anything you want to keep first.

This deletes your Clusy notebook account. Your Portal account is separate: deleting either one leaves the other, and its data, as it is. How to delete a Portal account is set out at the end of this section.

Deleting your account deletes your profile, your projects and everything in them: notebooks, branches, cells, execution records, outputs, agent chat history and project memory, your share links and their published snapshots, your stored integration credentials, your MCP server entries, and your project workspace files. It cancels any active subscription and shuts down any running or paused sandbox.

Some things are kept, and you should know which:

billing, invoice and usage records, which we are required to keep for tax and accounting;
security and abuse records, and records of any suspension or ban, so that a terminated account cannot simply be recreated. Where these identify you, they do so through an irreversible hash rather than your account details;
support tickets and appeals, including the email address they were submitted with;
operational logs and telemetry, which age out on the schedules in section 10 rather than being deleted immediately; and
copies of published content that other people made before you deleted, including forks in their own projects and files they downloaded. We cannot reach those.

Some uploaded files and agent generated outputs may take longer to clear from object storage than the database records do. If you want confirmation that everything has gone, email privacy@clusy.io and we will check and confirm in writing.

Deleting your account is different from cancelling a subscription. Cancelling leaves your work in place on the free plan.

Deleting your Portal account

Portal has no way yet to delete your account yourself. Email privacy@clusy.io from the address you sign in to Portal with, and we will end your Portal access, delete your Portal account and your workspace’s records and files, including the analytics events recorded under your Portal account identifier, and confirm, within 30 days. Download any outputs you want to keep with portal pull first: they are kept only 7 days.

Some things are kept. We keep what we must for legal, tax, accounting or security reasons, and only while that reason applies: this covers the Portal audit log and the cost ledger. Portal’s logs are not deleted on request either: they age out on the schedules in section 10, 90 days for its server and load balancer logs and up to 400 days for logs of operator commands. Feedback you sent from the Portal console is kept as a support ticket. Deleted records also remain in backups until those expire, about 7 days for the database and 35 days for the server file system. Ending your access does not revoke anything at your cloud providers or remove what Portal created in your cloud accounts; section 16 explains.

Removing a job from your history, in the console, with portal rm or with the delete_jobs tool, hides it and stops it being continued, but does not erase its records, and its cost still counts. If you used Portal before November 8, 2026, you may also have a Clusy notebook account, which you delete as described above.

12.How we protect it

We would rather understate this than overstate it, so here is what is actually true.

Traffic to our services is encrypted in transit with TLS.
Object storage is encrypted at rest, and our database is hosted on a managed platform that encrypts stored data.
Credentials for services you connect are additionally encrypted by us before they are stored, with a key held outside the database. Your Clusy API keys are stored only as a hash. One exception we will name: headers and environment values you configure for a custom MCP server are stored without that additional layer, so avoid putting a high value secret there.
Access to production data is limited to staff who need it, administrative actions are logged, and sensitive internal records are restricted at the database level so that they cannot be read by ordinary accounts.
Sign in to the Clusy notebook is protected by an anti bot check, and sessions use short lived tokens.
We monitor the Clusy notebook for abuse as described in section 7.
Portal seals the credentials for your cloud accounts, your secrets and each job’s key with AES-256-GCM under a data key of your workspace’s own, which is stored only wrapped by AWS KMS, Amazon’s key service. Portal’s server unwraps that key when it needs it and keeps it in memory for up to 5 minutes, or longer while it is running work for your workspace. Portal never displays a stored value. Portal’s server can unwrap every workspace’s key, so this protects against someone who obtains a copy of the stored records or backups, not against a compromise of Portal’s server or against us. Checkpoints are encrypted on the machine with a key made for that job before they reach storage, though Portal holds that key rather than you, and a workspace Owner can turn this encryption off. Uploaded working directories, output streams and outputs have only the storage provider’s own encryption.
Portal has no passwords: you sign in with an emailed code, which has the anti bot check, or with Google or GitHub, and Portal offers no second factor. A console session ends after 12 hours unused and lasts at most 7 days. A sign in from the command line tool or a coding tool lasts until you sign out or it is revoked, and agent tokens last 1, 7 or 30 days. Portal stores its tokens only as hashes, and its server cannot change or delete entries in its audit log. The security page has the detail.

We have a SOC 1 Type II report on our company wide controls, which customers and their auditors can request under a confidentiality agreement at security@clusy.io. A SOC 1 report covers controls relevant to our customers’ financial reporting; it is not a SOC 2 report or a security certification. We do not hold SOC 2, ISO 27001 or any other security certification, and we do not claim to. If you need one before you can use Clusy, tell us so we know it matters.

No system is completely secure. If there is a breach affecting your personal data, we will notify the relevant supervisory authority where required and tell affected users without undue delay. If you are a business customer and we process data for you, we will tell you promptly so that you can meet your own deadlines.

To report a vulnerability, see our security page, and note the security research safe harbour in the Terms of Use.

13.Content you publish

When you publish a notebook, it leaves the private part of the product. Two things follow that people are sometimes surprised by.

Hub listings are submitted to search engines, and our public pages explicitly permit AI crawlers, including crawlers that collect data for model training. A published notebook can therefore be indexed, copied and ingested by third parties we do not control.
Unpublishing does not reach copies. Revoking a share stops new access at once and permanently, but forks other people made, files they downloaded, and search engine or third party caches are outside our control.

A published notebook includes your display name and avatar. Your profile, including any headline, bio and links you add, is publicly readable. Your chat with the agent is not included in a share.

If you publish personal data about other people, you are the controller of it and responsible for having a basis to publish it. To ask for something to be taken down, see the Terms of Use or email privacy@clusy.io.

14.Your rights

We extend these rights to everyone who uses Clusy, wherever you live, whether or not a particular law requires it.

Access. Ask what we hold about you and get a copy.
Portability. Get your content in a portable form. You can export notebooks from the product, and we can provide an export of your account data. In Portal, you can download a job’s outputs with portal pull for 7 days after they are saved and read its output stream, and we can provide an export of your workspace’s records.
Correction. Fix anything inaccurate. Most profile fields you can edit yourself. Portal takes your name from Google or GitHub each time you sign in, so change it there. To correct the email address on your Portal account, ask us: signing in with a different address creates a separate Portal account.
Deletion. Delete your Clusy notebook account in the product, or ask us. Portal has no way yet to delete your account yourself, so for Portal, ask us. Section 11 sets out what we keep and why.
Restriction. Ask us to pause processing while a dispute is resolved.
Rights about automated decisions. Ask for human review of a decision, put your point of view, and contest it. See section 7.
Non discrimination. We will not give you a worse service for exercising a right.
Appeal. If we refuse a request, you can appeal by replying to our decision. We will respond within 45 days with our reasoning, and tell you how to complain to a regulator.

Your right to object

You have the right to object at any time to processing we carry out on the basis of our legitimate interests, including product analytics and reliability work. We will stop unless we have compelling grounds that override your interests, or we need the processing to establish or defend legal claims. Security and abuse prevention is one area where we will usually have those grounds, because it protects other people. If you object to Portal’s analytics, tell us: Portal cannot yet stop recording them for one person, but we will delete the events recorded under your Portal account identifier.

You can object to direct marketing at any time and we will always stop. Use the unsubscribe link in any marketing email or email privacy@clusy.io. Service messages about your account, billing and security are not marketing and continue.

Withdrawing consent

Where we rely on consent, you can withdraw it at any time, as easily as you gave it, using the cookie settings control on our website or the relevant setting in the product. Withdrawing consent does not affect processing done before you withdrew it.

How to exercise a right

Email privacy@clusy.io. You do not need an account to make a request: if you were added as a guest to a meeting, or appear in someone else’s published notebook, write to the same address.

We will acknowledge your request promptly and respond within 45 days, or one month if the GDPR applies to you. If a request is complex we may extend that once, and we will tell you why before we do. If you have a Clusy or Portal account, we will verify you by having you write from that account’s email address or sign in. If you do not, we will ask you to confirm details that match what we hold. We use that verification data only to check your identity.

A request for a copy of your data will not return secrets: we will not send you API keys, connected account tokens, the cloud credentials and secrets Portal holds or authentication credentials, because disclosing them by email would create the very risk the right is meant to prevent.

Complaints

Please raise it with us first at privacy@clusy.io, and we will try to put it right. You can also complain to a regulator. In the UK that is the Information Commissioner’s Office. In the EEA it is the supervisory authority where you live, where you work, or where the problem happened. In the United States you can contact your state attorney general.

15.Cookies, storage and analytics

On our website

Our website shows a cookie banner with three categories: strictly necessary, which is always on; performance and analytics; and personalisation and outreach. The two optional categories are off unless you turn them on, and rejecting is one click, exactly like accepting. Your choice is stored in a first party cookie for 180 days, after which we ask again. You can change it any time using the cookie settings control at the bottom of the site. The Portal landing pages at portal.clusy.io show the same banner. Your choice is stored separately for each site, so a choice made on www.clusy.io does not carry over to portal.clusy.io, and the other way round.

PostHog provides analytics. It starts opted out and only begins capturing if you accept the analytics category. On www.clusy.io its traffic is routed through our own domain. On the Portal landing pages it reports to Portal’s own PostHog project and sends directly to PostHog, which therefore receives your IP address.
Vercel Web Analytics counts page views. It currently loads on the pages of www.clusy.io rather than sitting behind the banner, because it is designed not to identify you or store anything on your device. It does not run on the Portal pages at portal.clusy.io. We are reviewing whether to move it behind the analytics category.
Attribution. If you accept the personalisation category, we store campaign parameters and any advertising click identifier from the link you arrived on, in a cookie that is readable across clusy.io subdomains, so that we can tell which of our own campaigns brought you. This is not advertising targeting and it is not shared with an ad network.
A small amount of storage is always used for things the site cannot work without, such as remembering your light or dark theme and your cookie choice itself.

In the Clusy app

The signed in Clusy app at app.clusy.io does not show a cookie banner. It stores your session token and interface preferences in your browser, which is necessary for it to work, and it runs PostHog analytics on our legitimate interest in understanding and improving the product. In the app, PostHog is configured not to record your screen and not to capture what is on the page: it receives your account identifier, your plan, and named events about which features you use, with a filter that drops anything long enough to be content. It is not sent your email address. If you would rather not be included in product analytics, email privacy@clusy.io and we will exclude your account.

In the Portal console

The Portal console at portal.clusy.io/app does not show a cookie banner, and it does not read the choice you made on the Portal landing pages. It sets three cookies, all strictly necessary and sent only to portal.clusy.io: __Host-portal_session, your signed in session, which ends after 12 hours unused and lasts at most 7 days; __Host-portal_oauth_tx, which holds a sign in in progress for up to 15 minutes; and __Host-portal_oauth_ix, which holds Portal’s sign in request for 15 minutes. In your browser’s storage it keeps your theme and layout choices, whether you were signed in, the analytics identifiers described below, and, during a Google or GitHub sign in, what it needs to finish it. The sign in page connects directly to Portal’s account store at Supabase, and loads Cloudflare Turnstile when you ask for an email code, so Cloudflare receives your IP address and browser details for that check.

The console records product analytics on our legitimate interest, whether or not you are signed in, and without asking for consent. It keeps a random device identifier and session identifiers in your browser’s storage, and sends page views and a fixed list of interface events to Portal’s server, which adds the IP address the request came from and passes them to Portal’s own PostHog project; your browser does not contact PostHog itself. Events carry your browser, operating system, language, timezone, screen and window size, and the page you were on, which can include a job’s identifier. When you sign in, your earlier events from that browser are linked to your Portal account identifier, with your role and how many workspaces you have, and the device identifier is replaced when you sign out. Portal’s server also records an event for each change you or your coding tools make in Portal, from the console, the command line tool or the MCP server, with the kind of action, how it ended, how long it took and the IP address it came from. Events never carry your email address, the contents or names of your jobs, request contents or tokens. If you used Portal before November 8, 2026, your Portal account identifier is the same as your Clusy notebook account identifier, so your Portal and notebook analytics can be linked.

Portal has no setting to turn analytics off for one person. If you object, email privacy@clusy.io and we will delete the events recorded under your Portal account identifier. The portal command line tool and MCP server contain no analytics of their own; the events above are recorded by Portal’s server. Release builds of the command line tool ask our server, without your credential, at most once a day whether a newer version exists, which tells our server your IP address; set PORTAL_NO_UPDATE_CHECK to stop it. Portal’s documentation at portal.clusy.io/docs sets no cookies and loads nothing from other sites.

Do Not Track and Global Privacy Control

We do not currently detect or respond to Do Not Track or Global Privacy Control signals. We are implementing Global Privacy Control support. In the meantime, the cookie banner is the effective control on our website, and the email address above works everywhere. The Portal console has no banner and does not read these signals, so there the email address above is the control.

We do not permit third parties to collect personal information about your activity across other websites through our services.

16.Accounts you connect

When you connect a third party service, we store the credentials needed to use it on your behalf, encrypted, and a small amount of profile information from that service so we can show you which account is connected. We also keep the last four characters of a token in readable form so we can display a masked version to you.

Some specifics worth knowing:

Connecting a GitHub repository means we clone it to our servers, including private repositories, so the agent can work with it.
Publishing to Hugging Face or Kaggle sends your notebook with its execution outputs embedded. We keep a record of what was published, where, and whether it was private.
Connecting a data warehouse lets the agent run queries with your credentials and bring the results into your notebook, where they are stored like any other output.
During some publishing operations, a short lived token is passed into your sandbox so the upload can run there.
Disconnecting removes the credential from Clusy but does not revoke it at the provider. Revoke it in that service’s own settings as well if that matters to you. Deleting your Clusy account likewise removes our copy without revoking anything upstream.

Portal cloud connections. When you connect a cloud account to Portal, Portal stores the credential it needs, sealed: for AWS, a role it may assume with an external ID Portal issued, or access keys; for Microsoft Azure, your tenant, app and subscription identifiers and, if you choose that method, a client secret; for Google Cloud, a service account key; for Modal, a token; for Lambda, an API key. It also records which cloud account the credential belongs to. Connecting from the command line uses your own cloud login to create what Portal needs in your cloud account, such as a role or an access key, a service principal, or a service account and its key, and does so only after you confirm the plan it shows. Portal uses the credential to set up what it needs there, to start, watch and stop the machines it makes, to read prices and quotas, and, for AWS, to read your Cost Explorer totals once a day. Finding which clouds you are signed in to happens on your computer: the account identifiers it finds go to your terminal or coding tool, not to us.

Removing a Portal connection deletes Portal’s copy of the credential at once, but does not revoke it at the provider, and it leaves in place what Portal created in your cloud account, such as roles, keys, service principals, service accounts and resource groups. Remove those there as well if that matters to you. Portal’s copy remains in database backups for about 7 days, and ending your Portal access does not delete your connections.

17.Children

Clusy is for adults. You must be at least 18 to hold an account, which is the same rule as in our Terms of Use. We do not knowingly collect personal data from anyone under 18 and we do not direct the service to children. The same rule applies to Portal accounts.

If you believe someone under 18 has an account, email privacy@clusy.io. We will investigate, close the account and delete the personal data.

18.Regional information

EEA, UK and Switzerland

The GDPR and the UK GDPR apply to our processing of your data because we offer services to people in those places. Our legal bases are in section 5, transfers in section 9, and your rights, including the rights to object and to complain to a supervisory authority, in section 14. Clusy Inc. is the controller for the processing described in section 2.

We have not yet appointed representatives under Article 27 of the GDPR and the UK GDPR. Until we do, please direct all requests and complaints to privacy@clusy.io, which is monitored and is the fastest route to a person.

California

The categories of personal information we collect are set out in section 3, with our purposes in section 5, the recipients in section 8, and how long we keep each category in section 10. In statutory terms we collect identifiers, customer records, commercial information, internet and network activity, coarse geolocation, professional information where you volunteer it, audio and visual information only in the form of files you upload, sensitive personal information in the form of account credentials, and inferences.

We do not sell or share personal information, and we have not in the preceding twelve months. We use sensitive personal information only for the limited purposes the law permits, described in section 4, so we do not offer a separate limitation right for it. You have the rights in section 14, including the right to appeal, and we do not discriminate against you for exercising them. Because we deal with users online, requests should come to privacy@clusy.io. You may use an authorised agent, and we will ask for proof of their authority.

Other US states

If you live in a state with a comprehensive privacy law, you have the rights described in section 14 including the right to appeal a refusal, and, if your appeal is denied, to complain to your state attorney general. We give these rights to everyone rather than only where a statute compels them.

19.Changes to this policy

We review this policy at least once a year, and whenever we change a provider, add a model provider, or change how data flows. When we make a material change to how we handle your data, we will update the effective date at the top and tell you by email or in the product before it takes effect. A change that only describes more fully how we already handle your data takes effect when we publish it.

If we ever want to use your content for a genuinely new purpose, such as training models, we will tell you first and ask for your agreement separately. We will not do it by quietly editing this page, and we will not apply it to content you created before you agreed.

20.Contact

Clusy Inc., 2093 Philadelphia Pike, Suite #3740, Claymont, DE 19703, United States, is the controller for the processing described in section 2.

Privacy questions and requests: privacy@clusy.io
Security reports: security@clusy.io
Legal notices: legal@clusy.io
Everything else: support@clusy.io

Need a signed DPA?

Email privacy@clusy.io with your organisation name, the processing roles involved and any template you need us to work from. If you also need a security review, a subprocessor list for your vendor assessment, or a written answer on where a specific model routes, ask in the same message and we will cover it in one reply.